SAP Business One et Facture Normalisée DGI en RDC

À retenir

Cartographie SAP

Le projet identifie les types de documents, séries, établissements, codes taxe, devises, partenaires et références nécessaires. Les personnalisations et add-ons existants doivent être recensés avant de choisir l'interface.

Couche d'intégration

L'adaptateur transforme le document SAP vers le schéma EazLink. La couche fiscale applique les contrôles, soumet selon le parcours configuré et conserve la réponse. SAP reste le système de référence métier.

Gestion des statuts

Un retour immédiat n'est pas toujours possible. Le document SAP reçoit une référence de corrélation puis un état final ou intermédiaire. Une vue d'exploitation centralise les éléments en attente, confirmés, rejetés ou à corriger.

Déploiement par vagues

Commencez avec une société, un établissement et quelques scénarios représentatifs. Mesurez la qualité des données, les délais, le nombre de corrections et la compréhension des statuts avant d'étendre à d'autres sites.

Choisir l'interface après l'inventaire

Un projet SAP Business One Facture Normalisée RDC commence par les versions, la base, les add-ons et les interfaces déjà exploitées. Le Service Layer expose des objets métier via HTTP et OData. La DI API reste présente dans certains environnements Windows. Ce choix technique dépend de l'installation et du support disponible, pas d'une préférence abstraite pour une technologie récente.

Inventoriez aussi les séries, établissements, codes taxe, utilisateurs techniques et traitements nocturnes. Un add-on peut déjà modifier une facture après sa création. Si ce comportement n'est pas identifié, le document envoyé à la DGI risque de ne plus correspondre à celui que la finance consulte dans SAP.

Préserver les frontières transactionnelles

La création dans SAP et la confirmation fiscale ne forment pas toujours une transaction unique. Il faut accepter cet intervalle au lieu de le masquer. SAP conserve son document métier, EazLink persiste la demande avec une référence de corrélation, puis le résultat revient de façon contrôlée. Un statut intermédiaire évite de bloquer inutilement l'utilisateur tout en empêchant une seconde soumission.

Si l'appel échoue après l'envoi, le connecteur vérifie d'abord l'état connu. Il ne recrée pas la facture par réflexe. Cette règle doit être testée avec une coupure placée au mauvais moment, car les doublons apparaissent justement lorsque personne ne sait si le service distant a traité la demande.

Déployer par vagues observables

Commencez par une société et un établissement dont les données sont propres. Le pilote couvre les documents les plus fréquents, mais aussi un avoir, une remise, une devise étrangère et un rejet volontaire. Mesurez le temps de traitement et surtout le temps nécessaire à l'équipe pour comprendre et corriger une anomalie.

Étendre le projet devient raisonnable lorsque les références se rapprochent, les preuves sont retrouvables et le support connaît les responsabilités. Ajouter dix sites à un flux encore opaque ne le rend pas plus mature. Cela multiplie simplement les cas difficiles à expliquer.