KRA eTIMS und Safaricom M-Pesa Integrationen für Odoo 19

Der Aufbau von Business-Software in Ostafrika bedeutet, sich mit zwei harten operativen Fakten auseinanderzusetzen. Erstens verlangt die Kenya Revenue Authority, dass jede Geschäftsrechnung eine digitale Steuersignatur und einen überprüfbaren QR-Code über eTIMS trägt. Zweitens werden über 80 Prozent der kommerziellen Transaktionen über Safaricom M-Pesa abgewickelt. Wenn Ihr ERP keine Rechnungen in Echtzeit unterschreiben oder eingehende Paybill-Zahlungen automatisch abgleichen kann, verbringt Ihr Buchhaltungsteam seine Tage mit der manuellen Dateneingabe. Wenn Ihr Einzelhandels-POS offline geht, wenn die Faser schneidet, können Sie keine Quittungen ausstellen. Um diese Probleme zu lösen, haben wir drei produktionsbereite Module im offiziellen Odoo App Store erstellt und veröffentlicht. Sie unterstützen Odoo 17.0, 18.0 und 19.0 sowohl für Community- als auch für Enterprise-Editionen. Hier ist die technische Architektur, wie wir sie aufgebaut haben, wie wir mit Netzwerkausfällen umgehen und was wir auf dem Weg gelernt haben. The Three Integrations Module Purpose Edition & Versionen JengaStack eTIMS Real-time KRA OSCU bill signature and fiscal QR codes Community & Enterprise (17.0, 18.0, 19.0) JengaStack M-Pesa Daraja STK Push und C2B Paybill/Till ledger auto-reconciliation Community & Enterprise (17.0, 18.0, 19.0) JengaStack eTIMS VSCU Offline-erste virtuelle Steuerungseinheit und Batch-Compliance-Synchronisierung Community & Enterprise (17.0, 18.0, 19.0) 1. Real-Time Fiscal Signing ohne ERP Worker Blocking Der Standardfluss der KRA eTIMS Online Sales Control Unit (OSCU) erfordert das Senden von Rechnungszeilen, Steuerklassifizierungscodes und Käufer-PINs an KRA über HTTPS. KRA gibt interne Daten der Kontrolleinheit (CU Information), eine Rechnungsfolgenummer und eine als QR-Code codierte Verifizierungs-URL zurück. Die unmittelbare Falle, in die viele Entwickler geraten, ist ein synchroner HTTP-Aufruf direkt innerhalb der Rechnungsbestätigungsmethode von Odoo: Bei hohem Traffic oder während der Abgabefristen für die Steuererklärung benötigen KRA-Endpunkte oft mehrere Sekunden, um zu reagieren. Die Bindung von Odoo WSGI-Mitarbeitern an das Blockieren externer Anrufe erschöpft den Server-Arbeiterpool schnell. Die asynchrone Puffer- und Retry-Engine In, trennen wir Rechnungsbestätigung von steuerlicher Übertragung. Wenn eine Rechnung Posts: Das Modul ordnet eine interne Sequenz zu und erstellt einen ausstehenden Steuerdatensatz. Wenn der Online-Modus aktiv ist, versucht er einen sofortigen Kurzzeitanruf (maximal 4 Sekunden). Wenn der Anruf erfolgreich ist, erhält die Rechnung sofort ihren KRA-Steuercode und QR-Code. Wenn der Anruf fehlschlägt oder ausfällt, markiert das Modul den Datensatz, ohne die Rechnung zurückzudrehen. Ein dedizierter geplanter Cron-Arbeiter fegt ausstehende Aufzeichnungen mit exponentiellem Backoff mit Jitter. Der resultierende QR-Code und die Control Unit ID werden sowohl auf PDF-QWeb-Berichten als auch auf OWL-POS-Thermoquittungen dargestellt und erfüllen die gesetzlichen Anforderungen, ohne die Abrechnungsvorgänge zu verzögern. 2. Safaricom M-Pesa Dual-Mode-Architektur und Auto-Reconciliation Die meisten M-Pesa-Plugins für Odoo behandeln Zahlungen als nachträglichen Einfall und zwingen die Mitarbeiter, SMS-Strings manuell zu lesen und Bestätigungscodes in Odoo einzugeben. Wir haben mit einer Dual-Mode-Engine entwickelt: Odoo Payment Provider verbindet sich direkt mit Standard-Kundenrechnungsportalen und E-Commerce-Checkouts. Direct POS und Backoffice Engine ermöglicht es Kassierern, einen STK Push mit einem einzigen Klick auszulösen, oder ermöglicht es dem System, unerwünschte C2B-Kundenzahlungen zu akzeptieren, die an eine Paybill oder Till gesendet werden. Die Webhook Reliability Gap Safaricom sendet Validierungs- und Bestätigungsaufrufe über HTTPS. Netzwerk-Hops zwischen Safaricom und Cloud-Servern können jedoch gelegentlich Pakete fallen lassen. Sich ausschließlich auf eingehende Rückrufe zu verlassen, führt zu unbestätigten Zahlungen. Wir lösen dies mit einer dreischichtigen Verifizierungsschleife: Webhook Listener. Akzeptiert eingehende JSON-Nutzlasten von Safaricom, speichert die Rohtransaktion in einem unveränderlichen Audit-Ledger und bestätigt den Empfang innerhalb von 200 Millisekunden. Active Status Query Fallback. Wenn ein STK Push initiiert wird und innerhalb von 45 Sekunden keine Bestätigung eintrifft, fragt ein Hintergrundjob die Transaktionsstatus-API von Safaricom direkt über die . Idempotency Guard. Vor der Registrierung einer Zahlung, die trans