Comment CertiPOS s’intègre à SAP Business One

CertiPOS traite SAP Business One comme le livre de référence. La caisse n’appelle jamais SAP ; le serveur central enregistre chaque événement via la Service Layer et conserve la preuve de chaque appel.

Interface

• Toutes les lectures et écritures passent par la Service Layer ; la DI API n’est jamais utilisée et rien n’est écrit dans le schéma de la société. Cela garde un seul chemin de code pour HANA et SQL Server et fonctionne avec un SAP hébergé.
• Les sessions sont mutualisées par société et renouvelées à expiration. La requête brute, la réponse et le temps de chaque appel sont stockés sur la tâche d’enregistrement.
• Les lectures de masse peuvent utiliser un pack de vues optionnel en lecture seule quand l’agent de connexion a accès à la base ; le code métier n’exécute jamais de SQL ad hoc.

Documents par événement

• Vente au comptant : facture client, puis un encaissement par devise d’espèces ; les espèces étrangères sont changées via un compte de compensation par une écriture.
• Retour et échange : avoir client basé sur la facture et paiement sortant ; un échange est un seul ticket dans les deux sens.
• Acomptes et arrhes : facture d’acompte client et son encaissement ; la facture finale impute l’acompte.
• Compte client : une facture client ouverte sur le partenaire avec un contrôle de crédit en caisse.
• Gestion des espèces : écritures et paiements pour les entrées et sorties, les écarts, les versements de pourboires, sur les comptes que vous indiquez.
• Cartes cadeaux, avoirs et fidélité : la vente en ligne article ; les utilisations en moyens de virement sur les comptes de passif ; écritures de provision et d’expiration.
• Stock : entrée de marchandises, sortie, transfert et demande de transfert, inventaire ; les documents interceptés par une procédure d’approbation SAP sont signalés avec leur propre code d’erreur.
• Commandes et livraisons : commande client, bon de livraison, et une facture basée sur la commande qui impute l’acompte à la remise.

Par ticket ou regroupé

L’enregistrement par ticket est le défaut : une facture et un encaissement par ticket, ce qui donne à SAP un retour par vente et correspond à ce qu’attendent les régimes de facturation électronique. Une société peut choisir un regroupement journalier : une facture et un encaissement par société et par jour avec des lignes agrégées, et le détail des tickets écrit dans les tables utilisateur @CP_TICKETS et @CP_TICKETLINES.

Champs et tables

Une action du portail provisionne les champs utilisateur sur les documents (ticket, caisse, promotion, coupon et autres) et les tables utilisateur pour le regroupement. Une définition de champ existante n’est jamais modifiée. Le provisionnement est idempotent et peut être relancé après une mise à jour de SAP.

Exactement une fois et contre-passations

• Chaque ticket et chaque événement portent un ULID client ; chaque tâche d’enregistrement et chaque suite chaînée ont leur propre clé d’idempotence : une relance ne crée jamais un second document.
• La facture est enregistrée, son DocEntry persisté, puis l’encaissement est enregistré sur sa base ; une panne entre les deux reprend à la bonne étape.
• Chaque contre-passation reflète ce qui a été enregistré : annulation là où SAP l’autorise, document miroir là où il la refuse.
• Chaque flux d’enregistrement n’est accepté qu’après qu’un vrai document a été enregistré dans une société réelle et contre-passé.

Données de base et événements

Articles, prix, codes-barres, unités, partenaires, listes de prix, codes de taxe, plan comptable, numéros de série, devises et taux se synchronisent par delta chaque minute et en intégralité une fois par jour ; les caisses chargent un flux ordonné par version. Les changements côté SAP atteignent CertiPOS par interrogation ou par un récepteur de webhooks signé.