Le Forum des Utilisateurs Sage

Bonjour à tous,

Je dois réaliser un site eCommerce en php dont le back office est basé sur Sage Gestion Commercial 14.0. Après avoir cherché pas mal d'information sur internet, des choses restent assez flous pour moi.

J'ai retenue comme méthode d'interaction entre le site et le back office :

• Driver ODBC Sage : Permet d'interagir en lecture/écriture sur les tables de la base Sage en préservant un minimum l'intégrité des données.
• SQL : Tape directement sur les tables de la base sans aucun contrôle d'intégrité.
• Fichiers au format Sage : Permet d'exporter/importer des données. Sage réalise automatiquement les contrôles d'intégrités et mouvemente les tables connexes (par exemple suite à une commande, mouvement automatiquement le stock)

Quant aux objets métiers, d'après ce que j'ai compris, il s'agit d'active X utilisable par exemple sous Windev... Serait-il possible d'avoir un peu plus de précisions sur ces objets ? Est-il possible de les utiliser en php ?

Je me posé également la question de l'architecture, sachant que le serveur Web sera hébergé sur une machine indépendante du serveur Sage :

• Est-il préférable d'utiliser le driver ODBC pour lire et écrire dans la base ?
• Ou vaut-il mieux lire avec le driver ODBC et utilisé les fichiers en import ?
• J'écarte pour l'instant l'accès direct SQL qui me parait trop dangereux pour l'intégrité des données...

Merci d'avance pour vos avis et votre aide

Bonjour,

Perso, j'oublierai le fonctionnement avec fichiers d'import/export, ça alourdirai le processus; sauf si tu y vois une valeur ajoutée bien spécifique.

En ce qui concerne les objets métier, je n'y ai jamais touché, je ne peux pas t'aider.

Pour le reste, il est effectivement recommandé d'utiliser le driver ODBC pour écrire dans la bdd et ainsi préserver l'intégrité de la base SAGE; les requêtes peuvent par contre mettre des plombes à s'exécuter.

En lecture, pas de risque, je te conseille donc d'y aller en SQL direct, sachant donc que tu perd l'accès aux champs virtuels (cf documentation Sage).

Quelques questions supplémentaires:
-Ton site se basera t-il uniquement sur la Base Sage, ou créera tu d'autres bases afin de le faire fonctionner? Si oui? SQL Server aussi?
-Sous quel OS tourne ton serveur Web?
-Ton serveur Web est-il sur le même réseau privé que le serveur Sage?

Bonjour Jozzz,

J'avais en fait privilégier les fonctions d'import/export de sage pour pouvoir utiliser un site e-commerce open source (genre os-commerce) ce qui m'éviterais d'avoir à réécrire des composants déjà existants (panier, gestion des règlements, etc...). Je suis d'accord que le processus de mise à jour entre les deux bases peut alors devenir assez lourd mais cela donnerais de l'indépendance au système e-commerce permettant de le faire fonctionner aussi pendant que le serveur sage est en maintenance.

Ce qui me gène un peu avec le driver ODBC, c'est qu'il n'est apparemment pas maintenu et que vais devoir écrire pas mal de code spécifique...

Sinon pour répondre à tes questions :

• Le site e-commerce se basera uniquement sur la base sage.
• Le serveur web tournera sous linux
• Le serveur web sera positionné dans une DMZ pour des raisons de sécurité

Merci pour ton aide.

Thib

Bonjour,

De mon coté je fais de la sélection en SQL direct (depuis Excel et access). Par contre, j'utilise l'import de données paramétrable pour l'intégration de données, après avoir généré automatiquement un fichier texte au format souhaité.

Mais attention, je suis dans un cas différent : je remonte des données seulement tous les mois, je peux donc me permettre de réaliser manuellement cette manipulation de remontée. A ma connaissance, on ne peut pas réaliser un import de données dans Sage autrement que Manuellement. Et quand bien ce serait possible, il faudrait également récupérer / analyser le contenu de la fenêtre de debug pour s'assurer que les données sont bien remontées, voire réaliser un vrai contrôle de cohérence entre la source remontée et les données intégrées.

Dans un site d'e-commerce, j'imagine que le besoin de remontée de données en compta doit au moins être quotidien. Cela peut donc poser problème de passer par l'import manuel.

Salut,

Les solutions proposé ci dessus sont bonnes.
Je touche (commence à toucher) les objets métiers.

Ils sont assez bien fait, même si leur utilisation demande certaines connaissance coté POO (architecture 3 couche n-tiers)

Logiquement, les objets métiers ne sont pas des active X mais des composant COM. C'est ce qui en fait l'intérêt.
Je ne vois pas de barrière avec le langage PHP, si celui ci permet le référencement des composant COM

En revanche, les objets métiers s'utilisent comme s'utilise SAGE. L'organisation est quasiment identique. et le nom des propriétés correspond à celui des champs SQL.

A étudier donc

Bonjour

Si ça peut aider à ne pa réinventer la roue.
nous avons déjà développé une solution depuis peu basée sur (au choix) OsCommerce ou Prestashop pour l'ecommerce php opensource et sur la Gestion commerciale Sage.

La solution réplique les données dans les deux sens en temps réel (pas d'import/export), et réplique les clients / commandes / produits / stocks / tarifs / remises / familles, et permet un grand nombre d'autres paramètres...

C'est basé sur une version Sage Ligne 100 SQL Server uniquement (intégration directe)

Si ça peut vous intéresser...

Cordialement

Bonjour,

Encore merci pour ces différents avis. En ce qui concerne les export/import de fichier plat, je n'ai trouvé nul part la possibilité de les faire de manière automatisés... cette solution me parait donc plus très viable.

@Le_Maraudeur : Ta solution pourrait me convenir mais il faut que vérifie le format de la base Sage déjà existante. Serait-il possible d'avoir quelques infos supplémentaire sur ton composant de synchronisation (retour d'expérience desssus, etc...) ? Comme il ne fonctionne qu'avec une base SQL Server, j'imagine que les requêtes sont effectués directement en SQL dans la base ? (on peut éventuellement en discuter par MP si besoin)

Merci d'avance pour ces infos.

bonjour

apparemment sur ce forum on ne peut pas s'envoyer de mp.

tu peux me contacter pour plus d'info sur

vdimuzio 'ar0bAze' proconsult.lu

merci