Bonjour, après'm,

Une question simple:

J'ai une boutique sur pied, et une boutique en ligne en projet (OsCom). Les produits mis en vente sont les mêmes dans les deux cas.
La boutique sur pied possède un serveur (NT), à partir duquel sont gérés les produits, via un logiciel propriétaire (gestion de stock, pour ce qui m'intéresse dans un premier temps).

Ma question:
Est-il viable, envisageable, pérenne, d'avoir la base OsCommerce sur ce serveur NT, à partir de laquelle (la base) les ventes boutique sur pied, ET les ventes boutique en ligne se feront ? (je pense à des accès via IP fixe pour la boutique en ligne...) ?

Le pourquoi de cette solution: Ne posséder qu'une base OsCommerce, facilitant ainsi les traitements gestion de stock.

Merci de vos réponses,

xpatval

Tu veux mettre à jour les stocks dans le logiciel proprietaire a partir de la boutique web si j'ai bien compris.

Gerer seulemnt les mises a jour de stocks ce n'est pas suffisant en general il faut inserer les commandes completes a partir desquelles le stock se met a jour automatiquement dans le logiciel de gestion.

Pour arriver a obtenir toutes les données necessaires a la constitution d'une commande valide sur OSCommerce (commande qui sera acceptee par le logiciel de gestion en insertion) tu dois importer dans OSC toutes les données necessaires CAD les fiches clients, la structure du catalogue produits, et toutes les relations entre les deux comme les tarifs.

Ceci suppose que ta base OSC soit formatee (type et longueur des champs) pour recuperer correctment les données.

C'est quoi ce logiciel de gestion de stock? base de données standard client-serveur ou "merd..." du style dBASE, etc...

Le stock sera mis à jour par la boutique en ligne ET par une pseudo boutique en ligne réservée au magasin. D'où ma question concernant l'architecture, puisque deux points de vente possibles.

La question même du stock est en cours d'étude.

Le soft de gestion est EBP.

xpatval

xpat tu dois d'abord decider quelle est la base de donnees directrice et pour quelle operation : selon moi:

- base de donnees directrice pour les nouveaux comptes clients et les nouvelles commandes (internes ou externes) crees sur le web = OSC

eventuellemnt tu peux gerer sur OSC les planchers et plafond de commnde pour differentes zones de lvraison (non pris en charge par EBP)

- base de donnee directrice pour toutes les autres operations (mises a jour comptes clients, mise a jour structure catalogue, traitement des commandes, taxes, etc...= EBP)


Sur le plan de l'architecture AMHA:

ta pseudo boutique sert aux commandes internes (interfaces plus "pro" qu'un site grad public) et sert aussi a assurer les stocks temps reel : donc c'est la meme base de donnees que la boutique publique et elle devrait etre sur le meme serveur : en fait ce n'est que quelques pages web de plus.


Les echanges de donnees decrits + haut entre EBP et ta base web dependent de 2 choses :

- trouver un bon driver ODBC pour DBASE qui a ma connaissance est la base de donnees EBP.
- la techno d'echange de donnees proprement dite serait un flux XMLhttp généré par un connecteur visual basic sur le serveur sur lequel se trouve EBP.
Ce connecteur envoie ses donnees sur un serveur web IIS qui attaque ta base mysql.

Ceci suppose d'avoir quelques pages ASP ou .NET qui recoivent et envoie les messages. Il te faut donc un hebergeur qui propose du linux pour tes pages php et du microsoft pour tes pages ASP-tu as besoin de 2 sites.

Tout ceci n'est pas bien complique sur le plan de l'architecture.

La plus grande difficulte que tu rencontreras c'est que la base EBP sera sollicitee en interne par les personnes qui font la gestion (par exemple le comptable) en meme temps que tu vas inserer des commandes web.

Et la c'est un gros probleme car dBASE n'est pas une vraie base de donnees client-serveur donc il est tres probable que tu auras des plantages de la base en cours d'utilisation.

Mais une solution doit bien exister, oxatis la vend...( http://www.oxatis.fr/ ).

Bon courage

Oula je met mon grain de sel ca m'intéresse.

Xpatval en lisant ton sujet de départ je ne comprend pas ta problématique de cette maniére: tu souhaitais en fait ne recourir qu'a une seule BDD pour ton outil de gestion co et pour oscommerce c'est ca ?

Dans ton cas : EBP

1- tu ne peux pas utiliser la base osco avec EBP
2- Utiliser ta base propriétaire EBP pour Oscommerce releve de l'utopie. Ca sera toujours bancale, il va falloir que tu modifie tout osco en profondeur pour t'adapter a une base qui n'est pas optimisée pour l'e-commerce.

Bon qu'est ce qu'il te reste, et regardons tes objectifs.

A priori tu souhaites vendre en ligne et en magasin. conserver EBP

Pourquoi ne pas utiliser osco également pour la vente en magasin. C'est une problématique couramment abordée, cela te demandera d'adapter un peu le fonctionnement de la boutique pour créer un genre de super utilisateur pouvant prendre les commandes en magasin.
Ensuite concernant la connectivité, EBP, car j'imagine que tu vas vouloir le conserver pour ta gestion, si mes souvenirs sont bons (je n'ai pas travaillé dessus depuis longtemps et je confonds toujours avec ciel) permet selon la version un import /export par fichier texte (en fin de journée par exemple pour mise à jour, c'est simple à développer, pas énormément de contraintes) .

Bon de toute maniére pour être honnête tu t'engages là dans un domaine périlleux car EBP etant un outil entrée de gamme en gestion co tu n'auras pas bcp de marge de manoeuvre.

Si tu veux faire des échanges Temps réels avec ta gestion co, envisage de t'équiper avec une ligne Sage (ou quelque chose dans cette gamme), ca sera bien plus efficace AMA.

Heu ouais mais des solutions comme celle là non merci
Le seul avantage qu'elles ont est d'être intégrées parce que question vente en ligne ca n'a d'e-commerce que le nom...

Oui à voir les imports texte mais en general ils ne concernent que la comptabilite (echange de donnees avec l'expert comptable =import de comptes clients et lignes d'ecriture), ce qui n'est pas suffisant dans ton cas.

Avec SAGE ligne 30 c'est un peu mieux qu'avec EBP parceque tu as un driver ODBC existant -celui de la ligne 100 qui peut faire l'affaire, pas officiellement, mais bon...le cout pour ton client reste raisonnable.

En revanche la base de donnees SAGE 30 t'interdira tout comme EBP les operations simultanees - donc les imports de commande ne seront possible que SAGE etant ferme- mais peut etre que bshop a la solution ? ...allez, dis nous tout bshop !

Lol, a vrai dire on n'intervient pas dans le même cas de figure que ce soit sage 30 ou 100 (et sup.). Déjà parce qu'il s'agit de technos différentes (Sage et sa manie de racheter les sociétés les unes aprés les autres ) et que les clients n'ont pas en général les mêmes besoins, ni moyens comme tu le précises.
Pour la ligne 30 de sage on fait en effet de l'échange de fichiers, ce sont des mises à jours en différées assez simples comme on peut le faire avec des outils du type EBP.
Pour la ligne 100 c'est bien différent: que ce soit en ligne 100 propriétaire ou SQL(on traite les 2), il s'agit d'une connexion en temps réel (+connexion différée si coupure réseau, bref la totale niveau sécurité) avec un ensemble de librairies qui permettent des échanges d'informations intélligentes (on attaque pas la base Sage comme cela, il y a un ensemble de controles à effectuer etc...). A notre niveau on à travaillé plusieurs mois pour mettre en place ce genre d'outils, il y a un gros travail d'étude a réaliser en amont, ce n'est pas uniquement une problématique 'technique' loin de là...
Bon je m'arrete la parce que je dois justement présenter tout ca lors d'un salon prochainement et il faut bien que je garde une part d'inédit
mais dans ton cas en effet c'est AMA la rolls royce des solutions aprés tout dépend de ton activité, ce type de solution est utile pour de gros volumes...

par contre l'idée d'utiliser l'odbc ligne 100 avec la 30 est sympathique,ca m'intéresse, même si comme je l'ai dit on n'adresse pas le même type de clientéle, ni de budget...

Tu as aiguisé notre appetit ...

Au sujet de SAGE 30 le moteur et la structure des données sont quasi identique à SAGE 100.

La pricipale difference est le nombre d'utilisateurs possibles.

Ce qui fait de sage 30 un excellent produit à recommander AMHA de preference a CIEL et EBP qui sont moins evolutifs.

PS bonne chance pour ton salon, il faut les convaincre toutes ces PME de se lancer dans l'e-business ! c'est pas une tache facile...