Comment intégrer SYSPRO à Dynamics 365 Sales ?

Une intégration SYSPRO utile fournit au commercial une disponibilité à promettre, pas une simple copie du stock. Dynamics 365 Sales doit indiquer quelle quantité peut être livrée, depuis quel entrepôt et à quelle date, tandis que SYSPRO reste responsable des stocks, de la demande, des approvisionnements planifiés, des ordres de fabrication et des délais industriels.

Cette frontière est propre à un ERP de production et de distribution. Le projet diffère donc d’une synchronisation clients-commandes avec Sage 300 ou d’un cadrage d’architecture SAP.

Que doit voir le commercial avant de promettre une date ?

Le commercial a besoin d’une promesse datée et traçable : quantité, entrepôt, première date disponible et heure du contrôle dans SYSPRO. Un champ « en stock » ne suffit pas, car les affectations aux autres commandes, la demande de production, les achats, les ordres de fabrication et les transferts modifient ce qui peut réellement être promis à un nouveau client.

SYSPRO documente une requête de disponibilité à promettre pour un couple article-entrepôt. La vue ATP peut prendre en compte les approvisionnements planifiés et la demande issue des commandes clients, des affectations de production et des transferts. Le CRM doit afficher le résultat utile à la décision commerciale, pas refaire le calcul.

L’horodatage est essentiel. Une réponse contrôlée la veille constitue un contexte, pas un engagement. Avant qu’un devis devienne une commande, le flux doit demander une décision actualisée ou imposer une revalidation explicite.

Pourquoi le stock physique n’est-il pas une promesse ?

Le stock physique décrit une quantité présente ; la disponibilité retranche les engagements et l’ATP tient aussi compte des approvisionnements et demandes futurs datés. Un entrepôt peut contenir des unités déjà affectées à d’autres commandes ou à la production. À l’inverse, un ordre de fabrication ou un achat prévu peut permettre une livraison ultérieure alors que la disponibilité du jour est nulle.

Par exemple, 100 unités présentes dont 90 déjà affectées n’en laissent que 10 disponibles immédiatement. Cela ne permet toujours pas de savoir si 40 unités supplémentaires peuvent être promises la semaine suivante : la réponse dépend de la production planifiée, des entrées, des nouvelles demandes et des règles d’entrepôt appliquées par SYSPRO.

Avec plusieurs entrepôts, une quantité située sur un second site n’est pas nécessairement vendable depuis le premier. Les délais de transfert, les autorisations, les règles de réapprovisionnement et le circuit de livraison du client peuvent intervenir. Dynamics 365 ne doit pas fusionner tous les stocks en un total rassurant mais inexploitable.

Faut-il copier les structures de production dans Dataverse ?

Les nomenclatures détaillées, les opérations, les affectations de composants et les ordres de fabrication doivent généralement rester dans SYSPRO. Dynamics 365 Sales a besoin de leur conséquence commerciale : possibilité de livrer, date attendue, configuration utile, jalon de fabrication et exception à communiquer au client.

Copier toute une nomenclature dans Dataverse crée un second modèle industriel à sécuriser, synchroniser et rapprocher après chaque évolution d’ingénierie ou de planification. Cela incite aussi les automatisations CRM à déduire une date sans disposer du contexte complet.

Une projection CRM volontairement limitée peut contenir :

• la référence SYSPRO et la désignation commerciale ;
• la classification sur stock ou à la commande lorsqu’elle aide la vente ;
• la configuration ou la révision nécessaire au devis ;
• le délai de fabrication comme information indicative, jamais comme promesse calculée en direct ;
• la dernière quantité, date, entrepôt et heure de contrôle ;
• un statut global de fabrication ou d’exécution après acceptation de la commande.

Le calcul du délai SYSPRO peut intégrer les opérations, les mouvements, les jours non ouvrés et la sous-traitance. Une valeur statique reprise dans le CRM doit donc être présentée comme une référence, pas comme un nouvel engagement.

Quelles interfaces SYSPRO utiliser ?

Le catalogue Microsoft ne répertorie aucun connecteur SYSPRO édité par Microsoft au 14 octobre 2026. Le chemin pris en charge part des interfaces disponibles dans la version du client : OData en lecture seule pour certaines requêtes, et objets métier e.net sous licence via les services SYSPRO pour appliquer les règles et enregistrer les transactions.

Power Automate peut convenir à un processus limité et piloté par le métier. Azure Logic Apps ou un service d’intégration dédié est plus adapté lorsque l’appel de disponibilité est critique, traverse un réseau privé, nécessite une file d’attente ou impose une supervision technique et une reprise contrôlée.

La discipline d’interface ressemble à celle décrite pour Sage 300 et Dynamics 365 Sales, mais la décision métier diffère : SYSPRO doit apporter les preuves industrielles et logistiques nécessaires à une promesse de livraison.

Pourquoi refuser l’accès direct à la base ?

SQL n’est pas une interface d’intégration opérationnelle. La documentation SYSPRO recommande les objets métier e.net pour appliquer les règles et présente OData comme solution contrôlée en lecture seule. Un accès direct réduit la traçabilité, dépend des tables internes, complique les mises à jour et peut affecter les performances, la disponibilité, les niveaux de service et les licences.

L’interdiction est encore plus forte pour les écritures. Créer ou modifier directement des clients, commandes, ordres de fabrication ou affectations peut contourner les contrôles appliqués par l’ERP. Une requête SQL réussie ne prouve pas que SYSPRO a accepté une transaction métier valide.

L’analyse en lecture seule sur une plateforme gouvernée constitue un besoin distinct. Même dans ce cas, la documentation actuelle positionne OData et les Business Activity Queries comme voies maîtrisées, notamment parce que l’accès direct à la base n’est pas disponible dans SYSPRO Cloud ERP.

Quel système doit maîtriser chaque décision industrielle ?

SYSPRO doit maîtriser les faits de production, de stock et d’exécution ; Dynamics 365 doit maîtriser l’opportunité, la relation et la prochaine action commerciale. Les fiches partagées nécessitent une propriété par champ, mais la règle centrale reste simple : le CRM peut afficher une conclusion ERP sans devenir l’application qui la recalcule ou l’écrase.

Cette matrice constitue un cadre de décision, pas une configuration universelle. Un fabricant à la commande et un distributeur peuvent vendre les mêmes produits avec des règles de validation, de responsabilité et de délai différentes.

Comment construire une demande de disponibilité ?

Le premier flux doit répondre à une question commerciale limitée et conserver les preuves nécessaires pour contrôler la réponse. Partez d’un produit, d’une quantité, d’une date souhaitée et des entrepôts autorisés ; renvoyez un résultat SYSPRO avec identifiant de corrélation, horodatage et statut explicite plutôt que de synchroniser tout le modèle industriel.

1. Le commercial choisit dans Dynamics 365 le produit relié à SYSPRO, la quantité et la date souhaitée.
2. Dataverse vérifie l’existence d’une référence SYSPRO stable et le bon rapprochement du compte.
3. L’orchestrateur attribue un identifiant de corrélation et détermine la société et les entrepôts autorisés.
4. L’interface SYSPRO prise en charge récupère les éléments de disponibilité prévus par la règle validée.
5. La réponse renvoie quantité, date, entrepôt, statut et heure de contrôle ; un incident technique ne renvoie aucune promesse.
6. Dataverse enregistre cette réponse comme photographie du devis et affiche son ancienneté au commercial.
7. Avant de créer la commande, le flux revalide la promesse puis utilise une transaction séparée et idempotente.

La consultation et l’engagement restent volontairement distincts. Une vérification de devis ne doit pas réserver le stock sauf si le processus le prévoit explicitement. Après un délai dépassé, la création d’une commande ne doit jamais être relancée à l’aveugle.

Qu’est-ce qui change entre fabrication sur stock et à la commande ?

La vente sur stock part de l’inventaire et des réapprovisionnements prévus ; la fabrication à la commande part de la capacité à produire une configuration donnée avant une date. L’écran CRM peut se ressembler, mais les preuves SYSPRO, le niveau de confiance et le moment où la date devient ferme diffèrent.

Pour un produit fabriqué, un délai publié n’est pas automatiquement une réponse. Il peut supposer la disponibilité des matières et de la capacité. L’intégration doit afficher le résultat de la décision de planification retenue dans SYSPRO, pas ajouter un nombre de jours à la date du jour dans le CRM.

Que faire lorsque la date promise change ?

Une promesse modifiée doit créer une exception commerciale visible, pas écraser silencieusement la date précédente. L’intégration doit identifier le devis ou la commande concerné, conserver l’ancienne réponse, afficher le nouveau résultat SYSPRO et attribuer une action à la personne chargée d’informer le client.

La supervision doit distinguer :

• une pénurie de composant ou un retard d’ordre de fabrication ;
• une nouvelle demande ayant consommé la disponibilité précédente ;
• une modification de transfert ou de réapprovisionnement ;
• un mauvais rapprochement de produit, client ou entrepôt ;
• un incident d’authentification, de point d’accès ou de réseau ;
• un délai dépassé après une transaction qui a peut-être réussi.

Chaque échange requiert un identifiant de corrélation et une règle d’idempotence. Les alertes d’exploitation doivent nommer l’objet métier, l’engagement client concerné et le responsable de la reprise ; un simple message « flux en erreur » ne permet pas à l’équipe commerciale d’agir.

Que faut-il connaître avant d’estimer le projet ?

Une estimation crédible exige l’environnement SYSPRO réel et une première décision commerciale précisément définie. « Connecter SYSPRO au CRM » ne dit pas si le premier flux est une consultation d’entrepôt, une demande ATP, un rapprochement client ou la création d’une commande, alors que les risques diffèrent.

Validez ces dix points :

1. version de SYSPRO, mode d’hébergement et sociétés concernées ;
2. domaines fonctionnels e.net sous licence et disponibilité de Data Connector - OData ;
3. points d’accès pris en charge, réseau, authentification et responsabilité des certificats ;
4. première question commerciale et action utilisateur qui déclenche le flux ;
5. modèle sur stock, à la commande ou mixte ;
6. produits, nomenclatures, ordres et entrepôts concernés ;
7. règle ATP et responsable qui valide la date promise ;
8. volume moyen et de pointe ainsi que temps de réponse acceptable ;
9. règles de relance, de rapprochement et de traitement des exceptions ;
10. spécialiste SYSPRO responsable du paramétrage ERP et de la recette.

Benly Consulting réalise le périmètre Dynamics 365, Dataverse, correspondances et orchestration Microsoft. L’administrateur, le partenaire ou le spécialiste SYSPRO du client valide la version, les licences, les points d’accès, les objets métier, la sécurité et les règles industrielles. Notre page Intégration ERP et Dynamics 365 détaille cette répartition.

Utilisez le simulateur de budget Dynamics 365 pour un premier ordre de grandeur. Le montant ne peut être confirmé qu’après validation de l’interface prise en charge et du premier flux industriel ; aucun prix spécifique à SYSPRO n’est inventé ici.

Sources officielles vérifiées

Sources vérifiées le 14 octobre 2026 :

• SYSPRO Help — SYSPRO OData Service
• SYSPRO Help — Inventory Available to Promise Query
• SYSPRO Help — Warehouse Maintenance for Stock Code
• SYSPRO Help — Lead Time Calculation
• SYSPRO Help — Business Objects
• SYSPRO Help — Best practice for connecting to SYSPRO
• Microsoft Learn — Power Automate connector catalogue
• Microsoft Learn — custom connectors overview
• Microsoft Learn — use upsert with Dataverse