Pour relier Sage 100 à un site marchand ou à une application interne, commencez par déterminer le mécanisme d’accès disponible. Une passerelle REST, les Objets Métiers et un import encadré ne présentent pas le même contrat ni le même modèle d’exploitation.
Le piège consiste à décrire un endpoint fictif comme une ressource Sage native. Avant de développer, il faut connaître la version, les modules, le dossier et le fournisseur éventuel du connecteur. Les règles des pièces commerciales restent celles de l’ERP.
Ce guide porte sur Sage 100, notamment Gestion Commerciale et Comptabilité. Il ne transpose pas les API X3, Active ou Intacct. Les exemples sont des propositions de contrat et des adaptations pédagogiques non exécutées sur une instance Sage client.
Notre accompagnement en intégration de Sage à votre SI prend en charge les flux et l’application métier. Le partenaire Sage valide l’installation, les licences, le paramétrage et les accès au dossier. Le cadrage de cette passerelle s’inscrit dans notre accompagnement en intégration API et middleware.
Constituer la fiche d’accès Sage 100
Relevez la version Sage, les modules et la version des Objets Métiers ou du connecteur. Demandez l’environnement de recette, le mode d’hébergement, le nom du dossier et les habilitations nécessaires. Une licence de l’application ne prouve pas que l’interface souhaitée est installée et utilisable.
La documentation officielle de connexion distingue les bases sur site et Sage Partner Cloud. Certaines propriétés dépendent de la version des Objets Métiers. Faites valider le mode de connexion retenu plutôt que de copier un exemple ancien sans examiner son contexte.
Choisir Objets Métiers, REST partenaire ou fichiers
Objets Métiers : une dépendance à qualifier
Les Objets Métiers donnent un accès aux fonctionnalités de Sage 100 dans leur environnement compatible. Leur utilisation exige les composants et références adaptés. Un backend web peut s’appuyer sur un service intermédiaire qui encapsule cet accès et limite les opérations autorisées.
Passerelle REST : vérifier son contrat propre
Demandez au fournisseur son OpenAPI ou sa documentation équivalente. Vérifiez les méthodes, les ressources couvertes, l’authentification, les erreurs, les limites et le support de la version installée. Une route REST de ce fournisseur ne doit pas être présentée comme un endpoint commun à tous les Sage 100.
Imports : accepter un délai pour mieux contrôler le lot
Un import/export supporté peut convenir à un échange périodique. Le fichier doit porter une référence de lot et un compte rendu exploitable. Écartez les modifications directes de tables qui contourneraient les règles métier et rendraient la maintenance dépendante du schéma interne.
Comprendre une connexion documentée en C#
Le court exemple ci-dessous illustre l’ouverture d’une base comptable sur site avec les Objets Métiers 100c à partir de la version 3. Il adapte les propriétés documentées par Sage ; les valeurs viennent ici de la configuration. Les références aux composants, l’installation, la gestion des exceptions et la fermeture doivent être adaptées au projet. Il ne crée aucun document et n’a pas été exécuté sur votre environnement.
var accounting = new BSCPTAApplication100c();
accounting.CompanyServer = configuration.Server;
accounting.CompanyDatabaseName = configuration.Database;
accounting.Loggable.UserName = configuration.SageUser;
accounting.Loggable.UserPwd = secretStore.ReadSagePassword();
accounting.Open();Les classes configuration et secretStore représentent votre code, pas des classes Sage. Une connexion SPC demande son contexte propre : ne réutilisez pas les paramètres sur site comme s’ils formaient un appel OAuth REST. Consultez les sections correspondantes de la documentation avant de choisir les identifiants.
Définir les correspondances articles, tiers et dépôts
Utilisez une référence stable pour chaque article et chaque tiers. La désignation commerciale n’est pas une clé. Si deux boutiques emploient des SKU différents pour la même référence Sage, conservez une table de correspondance explicite avec le canal et la variante.
Pour les stocks, distinguez quantité physique, réservation, préparation et disponibilité proposée à la vente. Une disponibilité globale n’explique pas quel dépôt peut expédier. Il faut intégrer les règles de l’entreprise, le WMS éventuel et les marges de sécurité avant de publier un chiffre aux canaux.
Écrire une commande complète plutôt qu’un assemblage de lignes
La création doit préserver le tiers, le dépôt, les articles, les quantités, les unités, les remises, les taxes et les frais. Le contrat doit préciser si la pièce et ses lignes sont validées ensemble ou si une écriture partielle peut subsister.
Choisissez un résultat métier observable : numéro de pièce obtenu, statut de validation et éventuelles lignes refusées. Un accusé de réception du middleware peut seulement signifier que le travail attend dans une file ; il ne doit pas être présenté au commerce comme une commande créée dans Sage.
| Information | Contrôle proposé |
|---|---|
| Référence externe | Retrouver la même vente lors d’une reprise. |
| Tiers | Vérifier existence et conditions applicables. |
| Article et dépôt | Utiliser les codes reconnus dans le dossier cible. |
| Montants | Rapprocher lignes, remises, frais et arrondis. |
| Pièce Sage | Conserver le numéro et le résultat de validation. |
Donner un contrat stable au middleware
Le contrat d’application peut utiliser une commande normalisée puis la traduire vers la passerelle choisie. L’exemple JSON suivant est une proposition interne, sans attribution à Sage ou au partenaire historique NetMinds. Les noms et validations doivent être définis dans votre propre documentation.
{
"source": "boutique-fr",
"external_order_id": "WEB-10482",
"target_company": "societe-recette",
"customer_code": "CLI-42",
"warehouse_code": "DEPOT-1",
"lines": [{"article_code": "ART-100", "quantity": 2}]
}La réponse interne doit distinguer reçu, créé, rejeté et résultat incertain. La documentation de la passerelle fournit ensuite les appels concrets. Une collection Postman reproductible ne peut être préparée qu’une fois cette interface et ses droits connus.
Traiter le timeout avant de réessayer
Imaginez une commande dont l’appel expire après envoi. La pièce peut avoir été créée malgré l’absence de réponse. Recherchez la référence externe ou rapprochez le résultat avec les moyens documentés. Si le fournisseur ne permet pas cette vérification, suspendez la reprise automatique et demandez un contrôle.
Un client absent ou un code taxe invalide demande une correction de données. Une panne temporaire peut justifier une nouvelle tentative limitée. La clé doit rester liée à l’opération métier, pas changer avec chaque tentative. Ne supposez pas que la passerelle honore un en-tête d’idempotence sans preuve.
Valider un jeu de recette avec l’ADV et la logistique
Préparez une commande simple, une remise, des frais de port, une annulation et un article inconnu. Comparez les documents dans Sage avec les sources de vente. Vérifiez également un même message envoyé deux fois et une interruption entre réception et confirmation.
La sortie de recette exige une procédure claire : comment isoler une vente, identifier la cause et choisir entre correction et reprise. Les seuils de suspension se fixent selon la promesse de livraison et les contraintes finance. Ils ne sont pas des propriétés universelles de Sage 100.
NetMinds : relier Sage 100c et les canaux de vente
Chez Pixminds, NetMinds utilisait une API REST exposée par un partenaire technique sur Sage 100c. L’application sur mesure articulait des données ERP, des échanges marketplace et des fonctions de pilotage. Le architecture API de NetMinds pour Pixminds précise l’architecture historique sans nommer un fournisseur dont l’identité reste inconnue.
Pour un nouveau projet, cette organisation peut être reproduite avec les interfaces compatibles de votre environnement. La relation se construit entre vos équipes, le prestataire ERP et Dawap ; elle ne dépend pas d’une promesse de REST natif sur toute version cloud.
Prolonger le cadrage technique
Le guide adaptateur et SDK approfondit la séparation entre backend web et interface ERP. Le plan de reprise des commandes aide à définir les états et le rapprochement après incident.
Priorisez une seule chaîne mesurable avant les extensions CRM, BI et achats. La documentation de livraison doit réunir le contrat fournisseur, les correspondances, les tests et la responsabilité de maintenance après montée de version.
Conclusion : Rendre chaque échange vérifiable
La faisabilité Sage 100 dépend d’un accès concret et d’une couverture métier vérifiée. Le protocole REST, à lui seul, ne prouve pas que tous les documents nécessaires sont disponibles.
Le premier lot doit conserver les identifiants, protéger les créations et rendre un échec compréhensible par l’ADV. Les écritures et la reprise se valident avec le même soin.
Une passerelle bien documentée peut séparer efficacement l’environnement ERP du backend web. Les coûts de licence, support et évolution doivent rester visibles dans le choix.
Dawap construit cette chaîne avec vos intervenants Sage dans le cadre de son accompagnement en intégration API. La qualification commence par votre version et un document représentatif.
