Production de bâtiments Intégrations KRA eTIMS et Safaricom M-Pesa pour Odoo 19

Construire des logiciels d'affaires en Afrique de l'Est signifie traiter de deux faits opérationnels difficiles. Premièrement, la Kenya Revenue Authority exige que chaque facture commerciale porte une signature fiscale numérique et un code QR vérifiable via eTIMS. Deuxièmement, plus de 80 % des transactions commerciales sont réglées par Safaricom M-Pesa. Si votre ERP ne peut pas signer les factures en temps réel ou faire correspondre automatiquement les paiements de factures entrants, votre équipe comptable passe ses jours à faire la saisie manuelle des données. Si votre point de vente au détail est hors ligne lorsque la fibre coupe, vous ne pouvez pas délivrer légalement des reçus. Pour résoudre ces problèmes, nous avons construit et publié trois modules prêts à la production sur l'Odoo App Store officiel. Ils soutiennent Odoo 17.0, 18.0 et 19.0 dans les éditions Communauté et Entreprise. Voici l'architecture technique derrière la façon dont nous les avons construits, comment nous traitons les défaillances du réseau, et ce que nous avons appris en cours de route. Le module des trois intégrations Objectif Édition et versions JengaStack eTIMS En temps réel KRA OSCU signature de facture et codes QR fiscaux Communauté et Entreprise (17,0, 18,0, 19,0) JengaStack M-Pesa Daraja STK Push et C2B Paybill/Till leger auto-reconciliation Communauté et Entreprise (17,0, 18,0, 19,0) JengaStack eTIMS VSCU Unité de contrôle virtuel hors ligne et synchronisation de la conformité par lots Community & Enterprise (17,0, 18,0, 19.0) 1. Signature fiscale en temps réel sans blocage des ERP Le flux standard de KRA eTIMS Online Sales Control Unit (OSCU) nécessite l'envoi d'éléments de ligne de facture, de codes de classification fiscale et de NIP de l'acheteur à KRA sur HTTPS. KRA retourne les données internes de l'unité de contrôle (informations UC), un numéro de séquence de facture et une URL de vérification codée comme code QR. Le piège immédiat dans lequel de nombreux développeurs tombent est de faire un appel HTTP synchrone directement dans la méthode de confirmation de facture d'Odoo: Sous un trafic élevé ou pendant les délais de production de la taxe maximale, les paramètres de la KRA prennent souvent plusieurs secondes pour répondre. L'assemblage des travailleurs d'Odoo WSGI avec le blocage des appels externes épuise rapidement le pool de travailleurs du serveur. L'Asynchrone Buffer and Retry Engine In, nous dissocions la confirmation de facture de la transmission fiscale. Lorsqu'une facture affiche: Le module attribue une séquence interne et crée un dossier fiscal en attente. Si le mode en ligne est actif, il tente un appel immédiat de courte durée (maximum 4 secondes). Si l'appel réussit, la facture reçoit immédiatement son code de contrôle KRA et son code QR. Si l'appel échoue ou s'il s'écoule, le module marque l'enregistrement comme s'il n'avait pas retourné la facture. Un ouvrier de cron programmé spécial balaye les enregistrements en attente en utilisant exponentielle backoff avec jitter. Le code QR et l'ID de l'unité de contrôle qui en résultent sont affichés sur les rapports PDF QWeb et les reçus thermiques OWL POS, ce qui répond aux exigences légales sans retarder les opérations de facturation. 2. Safaricom M-Pesa Architecture Dual-Mode et Réconciliation Auto La plupart des plugins M-Pesa pour Odoo traitent les paiements comme un post-pensée, forçant le personnel à lire manuellement les chaînes de SMS et les codes de confirmation dans Odoo. Nous avons conçu avec un moteur bimode : Odoo Payment Provider se connecte directement aux portails de facture clients standard et aux commandes eCommerce. Direct POS et Backoffice Engine permet aux caissiers de déclencher une Push STK en un seul clic, ou permet au système d'accepter les paiements clients C2B non sollicités envoyés à un PayBill ou Till. Le Webhook Reliability Gap Safaricom envoie des rappels de validation et de confirmation via HTTPS. Cependant, le saut en réseau entre les serveurs Safaricom et Cloud peut occasionnellement déposer des paquets. Se contenter des rappels entrants conduit à des paiements non confirmés. Nous résolvons cela avec une boucle de vérification en trois couches : Webhook Auditer. Accepte les charges utiles JSON entrantes de Safaricom, stocke la transaction brute dans un registre d'audit immuable, et accuse réception dans les 200 millisecondes. Statut actif Demande de remboursement. Si un STK Push démarre et qu'aucune confirmation n'arrive dans les 45 secondes, une tâche de fond interroge directement l'API d'état de transaction de Safaricom en utilisant le . Garde d'urgence. Avant d'enregistrer tout paiement, les