Stock et osCom

[xpatval]

Bonjour, après'm,

Ce doit être une question qui revient fréquemment. J'ai lu quelques posts traitant du problème ici, néanmoins, vos avis ne me sont pas indifférents.

D'une manière générale, est-il préférable d'utiliser une solution préconisée par les éditeurs de softs propiétaires (Sage, EBP...), donc payante, afin de gérer en temps réel les stocks (donc, je suppose, passerelle entre ces dits-softs, et osCom, ou bien le développement d'une application dédiée à ce problème est-il préconisé ?

Sachant qu'au préalable, (c'est-à-dire, avant le lancement de tout commerce web), cette gestion était gérée via l'un de ces logiciels (ebp pour le citer) ,installé sur serveur pour les différents postes de vente boutiques (vrai boutiques, magasins, quoi...)

Quel est votre avis ?

xpatval

[bshop]

A mon avis la question est :

- les outils actuels (ebp et consors) correspondent ils aux besoins du client et quel est le périmétre exact que doit couvrir ton outil de gestion de stock?

il faut savoir que d'une maniére générale pour couvrir le périmétre fonctionnel d'un outil de gestion commercial digne de ce nom tu auras pas mal de développements nécessaires à réaliser avec oscommerce.

Une synchronisation avec un outil de gestion commercial peut alors etre très intéressante mais là aussi il faut que tu saches exactement ce que tu veux synchroniser (ca peut aller très très loin) et comment (temps réel / sur déclenchement / à intervalle régulier) ....

le top a mon avis : synchro temps réel oscommerce<->Sage(déjà fait)/Cegid(jamais testé)

Aprés je pense que ton post va occasionner un bon débat bien enrichissant donc à étudier mais encore une fois tout dépend du besoin, une solution tout intégrée à osco sera optimale pour un besoin X et pas pour un besoin Y et vice versa avec une synchro avec un autre outil ...

Modifié 27 Juin 2005 par bshop

[xpatval]

Bien sur, bshop, ta réponse engendre nombre de questions.

Un des problèmes particuliers (que je me pose) reste la synchro temps réel de la gestion vente/stock, dans un commerce magasin/e-commerce.

Si, en stock, ne reste qu'une seule unité d'un produit NON RENOUVELABLE, je suppose que sa mise en vente via le site marchand doit s'accompagner d'un système particulier (réservation, par exemple, avant achat réel ?), car, comment "paralléliser" sa mise en vente, en magasin ET en E-commerce ?

xpatval

[bshop]

et pourquoi ne pas prendre le probleme a l'envers et envisager la vente en magasin 'powered by oscommerce', avec une version locale spécifique dédié aux commerciaux du magasin ?

[Toucouleur]

Bien sur, bshop, ta réponse engendre nombre de questions.

Un des problèmes particuliers (que je me pose) reste la synchro temps réel de la gestion vente/stock, dans un commerce magasin/e-commerce.

Si, en stock, ne reste qu'une seule unité d'un produit NON RENOUVELABLE, je suppose que sa mise en vente via le site marchand doit s'accompagner  d'un système particulier (réservation, par exemple, avant achat réel ?), car, comment "paralléliser" sa mise en vente, en magasin ET en E-commerce ?

xpatval

<{POST_SNAPBACK}>

Dans tous les cas, et vu ce que vous évoquiez l'un et l'autre, il semble indispensable d'avoir simplement le moyen de recréditer vos clients en cas de non disponiblités des produits. Pratiquement toutes les banques offrent ce service en option...

Ensuite pour réprendre les propos de BShop, un OsCommerce dédié aux commerciaux est envisageable mais encore mieux, une double gestion de stock dans la seule et même base de donnée éviterait bien des erreurs. C'est très facile à mettre en place en tout cas, et c'est le principe exploité par LDLC par exemple (même s'ils ne tournent pas sous OsC)

[xpatval]

et pourquoi ne pas prendre le probleme a l'envers et envisager la vente en magasin 'powered by oscommerce', avec une version locale spécifique dédié aux commerciaux du magasin ?

<{POST_SNAPBACK}>

Ben, parce qu'il fallait que quelqu'un me le dise !!! ...

...une double gestion de stock dans la seule et même base de donnée...

Qu'entends-tu par là ? J'ai bien une idée, mais...

[Toucouleur]

j'entend par là 2 accès à votre boutique. L'un pour le magasin l'autre accès pour les acheteurs sur Internet. Il suffit de gérer de façon indépendante la variable de quantité en stock. On duplique soit le champ products_quantity et tu as alors un products_quantity_pro par exemple ou encore si tu as des objects compliqués à gérer avec des attributs produits, il est aussi possible de gérer les quantitté en fonction d'attributs produits, mais là pour l'avoir fait sur un projet c'est un peu lus complexe à mettre en place (programmation conséquente sur de l'OsCommerce de base)

[bshop]

Ben, parce qu'il fallait que quelqu'un me le dise !!! ...

<{POST_SNAPBACK}>

Rhooo s'il faut tout te dire, c'est beaucoup moins drôle

[bshop]

j'entend par là 2 accès à votre boutique. L'un pour le magasin l'autre accès pour les acheteurs sur Internet. Il suffit de gérer de façon indépendante la variable de quantité en stock. On duplique soit le champ products_quantity et tu as alors un products_quantity_pro par exemple ou encore si tu as des objects compliqués à gérer avec des attributs produits, il est aussi possible de gérer les quantitté en fonction d'attributs produits, mais là pour l'avoir fait sur un projet c'est un peu lus complexe à mettre en place (programmation conséquente sur de l'OsCommerce de base)

<{POST_SNAPBACK}>

ce qui implique donc d'utiliser Osco coté magasin également, on parle de la même chose donc. A quoi bon utiliser dans ce cas deux notions de stocks ? Si ce n'est pour distinguer 2 stocks distincts ? Mais je suis pas sur que ce soit la problématique d'xpatval dans le cas présent ?

[xpatval]

Tu as raison bshop: nous avons un stock et un seul. Partant de là, il n'y a qu'une gestion. Ce sont les accès à celle-ci qui se différencient. Mais cela soulève la question même de la base. De la base, ou des bases ? Car, il doit y en avoir deux. A moins d'héberger le site sur son propre serveur, alimentant aussi le magasin.

Cela faisait entièrement partie de la problématique.

Merci de m'avoir mis tous les deux sur la voie, je crois que je vais faire fumer mon neurone, là...

Modifié 28 Juin 2005 par xpatval

[robinsonvendredi]

D'une manière générale, est-il préférable d'utiliser une solution préconisée par les éditeurs de softs propiétaires (Sage, EBP...), donc payante, afin de gérer en temps réel les stocks (donc, je suppose, passerelle entre ces dits-softs, et osCom, ou bien le développement d'une application dédiée à ce problème est-il préconisé ?

xpatval

<{POST_SNAPBACK}>

Sujet very interesssant !

Les éditeurs de soft tels que SAGE ou EBP ont leur propres logiciels de e-business qui n'ont rien a voir avec OS Commerce.

Il ne s'agit pas du tout de temps reel mais de synchronisations de temps en temps (au maximum 12 synchro / jour), ce qui rend ces solutions impropres à une utilisation réellement professionnelle : les stocks sont faux en permanence.

A vrai dire il n'y a pas de solution logicielle vraiment pro tout intégrée pour pas cher, le premier prix si on peut dire, c'est la nouvelle version d'Adonix X3 qui est full web et s'adresse à de grosses PME.

Au sujet d'une éventuelle synchro SAGE avec un produit e-commerce (OSC ou autre), il faut savoir que seule la version pour SQL server permet un échange de données "pseudo temps réel" , car la base propriétaire SAGE est un un peu faible pour ce genre d'utilisation.

Or la version SQL server de SAGE 100 est assez chère : il faut compter 15 à

20 000 euros pour une dizaine de postes utilisateurs rien que pour la gestion commerciale.

Si tu ajoutes le developpement web (de préférence sur base SQLServer, car tu peux dans certains cas préférer une réplication de base à base plutot que des flux XML), tu te retrouves avec un système d'information dont le cout risque d'effrayer tes clients !

J'en ai fait quelque uns, je peux te dire que la signature ne tombe pas comme ca !

En fait la vraie solution consiste à développer une appli web qui gère à la fois toute la gestion et l'e-business, avec des connecteurs non synchrones vers les logiciels de comptabilité, dont SAGE (les échanges de journaux comptables n'ont pas besoin d'etre en temps réel, une mise à jour la nuit est suffisante).

Ceci représente un boulot important, mais qui vaut le coup... sachant que la partie e-commerce ne pourra que difficilement être standardisée par les éditeurs (qui savent que les web agencies n'arrivent pas bien à vendre leurs heures !!)

En revanche pour ce type de dev il faut bien connaitre :

- l'informatique de gestion ,

- les technos d'échanges de données avec des appli microsoft (eh oui malheureusement on n'en sort pas facilement ... )

Bon courage

[robinsonvendredi]

Encore quelques précision pour ceux qui souhaitent se lancer dans cette aventure comme je l'ai fait.

Cette appli doit comporter (en plus de la partie e-commerce), la gestion des stocks et des contremarques, les grilles de tarifs, la chaine devis-facturation, la saisie de caisse (pour les magasins), la gestion des reglement, le multi-échéances (pour les clients pros), les nomenclatures produits, les taux de tva, la gestion du plan comptable (pour les exports de journaux), + divers parametrages comptables notamment chaque zone de livraison, chaque famille de produit et chaque produit.

En fait, il faut regarder ce qu'il y a dans un logiciel de gestion comme SAGE et choisir les fonctionnalités de base qui vont servir à la plupart des clients.

Par exemple, le multi-devise ne sert plus à rien, de ma modeste expérience.

Idem pour les abonnement, la gestion par affaires, les mises à jour de tarifs qui sont de toute facon très mal gérées par ces logiciels.

C'est très long à faire mais pas si compliqué et au final, on a une appli de gestion/ e-business temps réel : stocks, encours clients, etc...

[sdelaunay]

Hello,

Sujet interessant, je vais vous faire par de quelques remarques à ce sujet.

Je développe depuis plus de 3 ans un site Internet relié à Sage L100 SQL en temps réel, utilisant en plus une base mySQL.

Les problématiques sont importantes et à tous les niveaux. A partir du moment où l'on n'utilise pas les drivers ODBC, que l'on fait du natif, il faut connaître parfaitement les processus.

Pour donner un exemple, le calcul des prix, pour avoir le prix d'un client sur un produit il faut connaître et différencier :

-> les promos clients (remises, etc..)

-> le tarif d'un produit propre au client

-> le tarif d'une famille de produits

-> le tarif propre au produit

Ce tarif (brut) est soit un prix calculé (coefficient) à un prix d'achat ou pondéré, soit un prix fixe, ce qui multiplie les possibilités.

Après il faut appliquer les règles d'arrondis pour les prix calculés.

De plus il faut différencier si le prix donnés est HT ou TTC, dans le cas du TTC il faudra récupérer la TVA du produit pour ce client.

Autant dire que le processus de calcul est relativement complexe et délicat à gérer, en effet il faut prévoir une optimisation pour éviter la lourdeur du calcul, surtout si vous l'utilisez 'online'. Imaginez l'affichage de 100 produits sur le site Internet, et refaire ce calcul à chaque fois. Ceci n'est qu'un exemple (incomplet par ailleurs) d'une longue liste.

Les documentations sont très maigres et seul l'expérience fait office de référence. En effet, cette expérience est la valeur ajouter d'une SSII dans le domaine, et reflète parfaitement la stratégie de SAGE : faire prospérer son réseau de partenaires, et tout cela est légitime : 'on à rien sans rien'.

Bon nombre de développeurs veulent se lancer dans la course, mais beaucoup abandonnent ou baclent pour la simple et unique raison, qu'ils sont confrontés à eux-même. Vous pouvez le voir à travers les forums, entre autres, parlant du sujet : c'est beaucoup de questions pour peu de réponses. Parce que lorsque vous passez des jours à solutionner un problème, vous en avez bavé, personne ne vous a aidé, et cette connaissance acquise après tant de labeur ne mérite sûrement pas un étalage public qui servira bien plus à vos concurents.

L'utilisation d'un ERP (Sage, EBP..) synchronisé avec un e-commerce pose différentes problématiques qui ne sont pas toutes gérables automatiquement. En effet le stock ne peut pas être considéré comme parfait, mais au plus juste. Une nuance importante à spécifier dans vos conditions générales de vente.

Pour exemple si deux clients commandes en même temps (à quelques secondes d'intervalles) vous aurez l'impossibilité de les livrer parce que le stock, insuffisant et non réapprovisionnable, aura été rafraîchit en même temps, dans ce cas il faut gérer les priorités (la vente offline est prioritaire) et prévoir une modification de la commande client, soit en lui proposant un avoir ou un remplacement de produit (je rejoins les propos de Toucouleur à ce sujet). Ce cas n'arrive pas souvent sauf si vous gérez votre synchronisation trop espacée dans le temps.

Il y a d'autres conflits possible : certaines informations peuvent être modifiées du site et de l'ERP en même temps. Il faut également établir des priorités (exemple d'un client qui modifie ses coordonnées de l'e-commerce), d'autant plus que vos procédures de 'détection' de modifications doivent être très accomplies afin de ne pas perdre les informations.

Pour compléter les propos de robinsonvendredi, je dirai que le développement d'une solution SAGE <-> e-commerce ne s'improvise pas, surtout sans les connaissances structurelles côté SAGE, des connaissances de gestion approfondies. Il vous faudra des mois de travail et de l'archarnement, beaucoup d'autonomie mais rien n'est impossible.

Attention à la fumisterie des 'synchro. ERP' qui sont, pour la plupart, que des 'import/export' très limités qui ne gèrent pas la majorité des problématiques liés à cette utilisation (voir exemples).

Encore une fois à propos de SAGE Ligne 100 SQL, je rassure certains qui font des remarques sur le natif : 'Attention on peut flinguer la base'. Les triggers se lancent automatiquement à chaque requête, via les procédures stockées, permettant de protéger l'intégrité de Sage. Qu'on ne me parle plus de ça

Dans tous les cas, bonne chance.

PS : L'url du site que j'ai développé en spécifique : Nove

(+ de 1000H de travail)

Parmis les principales fonctionnalités avancées :

- Commande directe en gestion

- Consultation de tous documents de vente du client (devis, commandes, factures..)

- Tarifs personnalisés

- Stocks et Arrivages

- Gestion des SAV (avec recherche automatique par numéro de série ou facture)

- Configurateurs

etc..

[bshop]

parfaite analyse de la situation

[Nicolas]

Bonjour sdelaunay,

Je fais un petit HS pour dire que ton forum Phpbb est en version 2.06. Je te conseil vivement de le mettre à jour ;-)

[sdelaunay]

Bonjour sdelaunay,

Je fais un petit HS pour dire que ton forum Phpbb est en version 2.06. Je te conseil vivement de le mettre à jour ;-)

<{POST_SNAPBACK}>

C'est marrant, je me suis au moment ou je postais, que quelqu'un allait me faire la remarque !

Mais oui tu as raison je vais le mettre à jour, il faut dire qu'il est un peu tombé dans les oubliettes !

[robinsonvendredi]

Bonjour sdelaunay,

Bravo pour ton site nove.fr

Comme quoi un developpeur motivé peut faire beaucoup de boulot tout seul comme un grand !

Sache que je compatis sur les efforts que tu as du faire pour le configurateur produits, j'en ai fait un pour des consommables informatiques et rien que de lister toutes les marques, les imprimantes , etc...quelle galère...

Bon courage et encore bravo !