Sujet Le site sonovente.com est-il fiable ?
- 266 réponses
- 109 participants
- 118 991 vues
- 105 followers
Afficher le premier post
Au hasard GLPI, mais il en existe d'autres.
Que je sache, les bases de données criteria ont encore besoin d'une passerelle vers le SQL, mais peut-être que cela a changé. J'ai bossé pas mal de temps sur ce type de chaine de préparation de commandes dont le budget de mise en place avoisine les 5 millions d'euros. J'étais justement sur la partie informatique avec toutes les problématiques de coûts liés au traitement des données (stock temps réel, tracking colis, etc...)
Je sais aussi que la direction n'avait pas adopté certains process qui pour nous coulent de source pour des raisons purement financières, comme pleins d'autres entreprises.
Faut pas rêver les saisies se font encore souvent à la main et donc... Source d'erreurs assez fréquentes surtout en périodes de pics d'activité fait par du personnel intérimaire...
100 % d'accord
Même si ceci n'est valable que sur le papier car beaucoup ont encore de vieux tromblons type AS400, XP, j'ai même encore vu un Unix qui a 30 piges et un 3.11 dans un coin
Donc on est plus sur un vrai temps réel, avec toutes erreurs que cela comporte. Destruction d'article ou tracking erroné...
Ben oui et non
On commande sur le site, l'article est sorti immédiatement du stock en statut "pending" et si le produit ne sort pas de la chaine au bout de X heures, il est réinjecté. Dans le cas ou tout se passe bien l'article est lu en bout de chaine et sera en statut "exit". En fait c'est un poil plus complexe sur les chaines automatiques car il faut aussi tenir compte des défaillances des machines qui parfois sortent 2 étiquettes au lieu d'une ou rien du tout, bref un beau casse tête quand ça déraille
La préparation manuelle c'est bien, mais le personnel a un coût non négligeable. Surtout s'il faut bosser la nuit et les weekends.
Ben si un peu, aujourd'hui les prestataires du e-commerce se battent tous sur le même sujet, mais pas avec les mêmes budgets ni les mêmes stratégies. L'objectif est de traiter les commandes à J+0 avec l'envoi du colis en J+0.
Mis à part quelques rares sites comme LDLC ou Thomman, peux d'autres gèrent eux mêmes leurs envois car c'est très difficile d’absorber les pics tels que les soldes, les fêtes, etc... Sans prendre des retards monstrueux.. J'ai même le souvenir lointain que cela a causé de très graves soucis de trésorerie à ces sites... Sonovente ne doit surement pas y faire exception. Et puis je répondais surtout au fait que 5000 m2 de stock, ça peut paraitre beaucoup, mais en fait non
Momaw Nadow
149
Posteur·euse AFfiné·e
pas besoin de douchette et de code barre pour avoir un logiciel qui maintient le stock à jour... 
Anonyme
522
El Castor (was DDNetweaver)
1032
AFicionado·a
Je vous rassure, toute entreprise connait en permanence l'état de son stock, ou plutôt le nombre d'item "disponible à la vente". Pas besoin d'un lien permanent avec son entrepôt pour ça.
Et contrairement à ce que tout le monde croit, ce stock n'est pas géré par le service logistique, mais par le service commercial !
C'est le nerf de la guerre pour toute boîte de connaître l'état de son stock en temps réel !
Quand au fait de lié du "mysql avec le système de gestion de parc", faut vraiment être un amateur dans un garage pour faire ça...
Tous les systèmes sont interconnectables de nos jours, que ce soit avec celui des sous-traitants, la comptabilité, ou même les impots.
Le dernier point pose d'ailleurs de plus en plus de problème, car vous pouvez pas vous imaginez le nombre de boite qui envoi des infos aux services de l'état (Impots, Pole-emploi, et autres...) sans même les relire, et forcement, les logiciels envoi parfois des belles conneries dans les tuyaux
Et contrairement à ce que tout le monde croit, ce stock n'est pas géré par le service logistique, mais par le service commercial !
C'est le nerf de la guerre pour toute boîte de connaître l'état de son stock en temps réel !
Quand au fait de lié du "mysql avec le système de gestion de parc", faut vraiment être un amateur dans un garage pour faire ça...
Tous les systèmes sont interconnectables de nos jours, que ce soit avec celui des sous-traitants, la comptabilité, ou même les impots.
Le dernier point pose d'ailleurs de plus en plus de problème, car vous pouvez pas vous imaginez le nombre de boite qui envoi des infos aux services de l'état (Impots, Pole-emploi, et autres...) sans même les relire, et forcement, les logiciels envoi parfois des belles conneries dans les tuyaux
Mongo
165
Posteur·euse AFfiné·e
Will Zégal
73389
Will Zégal
Nightwolf38
3105
Squatteur·euse d’AF
Citation de El :
Quand au fait de lié du "mysql avec le système de gestion de parc", faut vraiment être un amateur dans un garage pour faire ça...
Au hasard GLPI, mais il en existe d'autres.
Citation de El :
Tous les systèmes sont interconnectables de nos jours
Que je sache, les bases de données criteria ont encore besoin d'une passerelle vers le SQL, mais peut-être que cela a changé. J'ai bossé pas mal de temps sur ce type de chaine de préparation de commandes dont le budget de mise en place avoisine les 5 millions d'euros. J'étais justement sur la partie informatique avec toutes les problématiques de coûts liés au traitement des données (stock temps réel, tracking colis, etc...)
Je sais aussi que la direction n'avait pas adopté certains process qui pour nous coulent de source pour des raisons purement financières, comme pleins d'autres entreprises.
Faut pas rêver les saisies se font encore souvent à la main et donc... Source d'erreurs assez fréquentes surtout en périodes de pics d'activité fait par du personnel intérimaire...
Lorsque l'on se cogne la tête contre un pot et que cela sonne creux, ça n'est pas forcément le pot qui est vide.
El Castor (was DDNetweaver)
1032
AFicionado·a
Attention, Nightwolf38, je n'ai pas dit qu'un système ne devait pas utiliser mysql, bien au contraire... Ce SGBC fonctionne très bien (tout comme son fork MariaDB).
Ce que j'ai dit c'est qu'on ne fait plus de réquêtage inter-système directement en SQL. Par exemple, une appli comptable qui requeterrai directement en SQL une appli de gestion de parc type GLPI.
Ca c'est fait un temps, mais on s'est vite rendu compte que c'était pas viable, par conséquent les "penseurs" ont conçus des API interropérables, tel que les webservices par exemple.
Pour le second point, comme je disais, il y a deux "coeurs de métier" différent, celui du commerce, et celui de la logistique de distribution.
Pour ce Topic, (le stock affiché sur le site de Sonovente), seul le système commercial est intéréssant.
Or, les deux n'ont pas besoin de connexion temps réel pour fonctionner. chacun fait ça vit dans son coin, ils ne sont synchronisés qu'à intervale fixe (1h, 1 journée, ...) via des échanges de fichier type CSV en FTP.
Celà n'empeche pas le système commercial de disposer d'un "stock vendable" en temps réel, qu'il calcule lui même.
D'ailleurs, ce stock "vendable", sera toujours décalé par rapport au stock "réel", puisqu'il doit déjà prendre en compte les commandes non encore préparé dans les entrepots.
Concernant le système de gestion de l'entrepot de distribution, alors là ce n'est pas la même histoire
C'est un système autrement plus complexe qu'un simple comptage de référence, dont le prix varie énormément selon ce qu'on y gère, mais ce n'est pas le sujet ici
Ce que j'ai dit c'est qu'on ne fait plus de réquêtage inter-système directement en SQL. Par exemple, une appli comptable qui requeterrai directement en SQL une appli de gestion de parc type GLPI.
Ca c'est fait un temps, mais on s'est vite rendu compte que c'était pas viable, par conséquent les "penseurs" ont conçus des API interropérables, tel que les webservices par exemple.
Pour le second point, comme je disais, il y a deux "coeurs de métier" différent, celui du commerce, et celui de la logistique de distribution.
Pour ce Topic, (le stock affiché sur le site de Sonovente), seul le système commercial est intéréssant.
Or, les deux n'ont pas besoin de connexion temps réel pour fonctionner. chacun fait ça vit dans son coin, ils ne sont synchronisés qu'à intervale fixe (1h, 1 journée, ...) via des échanges de fichier type CSV en FTP.
Celà n'empeche pas le système commercial de disposer d'un "stock vendable" en temps réel, qu'il calcule lui même.
D'ailleurs, ce stock "vendable", sera toujours décalé par rapport au stock "réel", puisqu'il doit déjà prendre en compte les commandes non encore préparé dans les entrepots.
Concernant le système de gestion de l'entrepot de distribution, alors là ce n'est pas la même histoire
C'est un système autrement plus complexe qu'un simple comptage de référence, dont le prix varie énormément selon ce qu'on y gère, mais ce n'est pas le sujet ici
Nightwolf38
3105
Squatteur·euse d’AF
Citation de El :
Attention, Nightwolf38, je n'ai pas dit qu'un système ne devait pas utiliser mysql, bien au contraire... Ce SGBC fonctionne très bien (tout comme son fork MariaDB).
Ce que j'ai dit c'est qu'on ne fait plus de réquêtage inter-système directement en SQL. Par exemple, une appli comptable qui requeterrai directement en SQL une appli de gestion de parc type GLPI.
Ca c'est fait un temps, mais on s'est vite rendu compte que c'était pas viable, par conséquent les "penseurs" ont conçus des API interropérables, tel que les webservices par exemple.
100 % d'accord
Même si ceci n'est valable que sur le papier car beaucoup ont encore de vieux tromblons type AS400, XP, j'ai même encore vu un Unix qui a 30 piges et un 3.11 dans un coin
Citation de El :
Pour le second point, comme je disais, il y a deux "coeurs de métier" différent, celui du commerce, et celui de la logistique de distribution.
Pour ce Topic, (le stock affiché sur le site de Sonovente), seul le système commercial est intéréssant.
Or, les deux n'ont pas besoin de connexion temps réel pour fonctionner. chacun fait ça vit dans son coin, ils ne sont synchronisés qu'à intervale fixe (1h, 1 journée, ...) via des échanges de fichier type CSV en FTP.
Donc on est plus sur un vrai temps réel, avec toutes erreurs que cela comporte. Destruction d'article ou tracking erroné...
Citation de El :
Celà n'empeche pas le système commercial de disposer d'un "stock vendable" en temps réel, qu'il calcule lui même.
D'ailleurs, ce stock "vendable", sera toujours décalé par rapport au stock "réel", puisqu'il doit déjà prendre en compte les commandes non encore préparé dans les entrepots.
Ben oui et non
On commande sur le site, l'article est sorti immédiatement du stock en statut "pending" et si le produit ne sort pas de la chaine au bout de X heures, il est réinjecté. Dans le cas ou tout se passe bien l'article est lu en bout de chaine et sera en statut "exit". En fait c'est un poil plus complexe sur les chaines automatiques car il faut aussi tenir compte des défaillances des machines qui parfois sortent 2 étiquettes au lieu d'une ou rien du tout, bref un beau casse tête quand ça déraille
La préparation manuelle c'est bien, mais le personnel a un coût non négligeable. Surtout s'il faut bosser la nuit et les weekends.
Citation de El :
Concernant le système de gestion de l'entrepot de distribution, alors là ce n'est pas la même histoire
C'est un système autrement plus complexe qu'un simple comptage de référence, dont le prix varie énormément selon ce qu'on y gère, mais ce n'est pas le sujet ici
Ben si un peu, aujourd'hui les prestataires du e-commerce se battent tous sur le même sujet, mais pas avec les mêmes budgets ni les mêmes stratégies. L'objectif est de traiter les commandes à J+0 avec l'envoi du colis en J+0.
Mis à part quelques rares sites comme LDLC ou Thomman, peux d'autres gèrent eux mêmes leurs envois car c'est très difficile d’absorber les pics tels que les soldes, les fêtes, etc... Sans prendre des retards monstrueux.. J'ai même le souvenir lointain que cela a causé de très graves soucis de trésorerie à ces sites... Sonovente ne doit surement pas y faire exception. Et puis je répondais surtout au fait que 5000 m2 de stock, ça peut paraitre beaucoup, mais en fait non
Lorsque l'on se cogne la tête contre un pot et que cela sonne creux, ça n'est pas forcément le pot qui est vide.
[ Dernière édition du message le 27/07/2014 à 13:33:09 ]
clindoeil
24
Nouvel·le AFfilié·e
NHL-Events
356
Posteur·euse AFfamé·e
- < Liste des sujets
- Charte