Строительное производство KRA eTIMS и Safaricom M-Pesa Integrations для Odoo 19

Создание программного обеспечения для бизнеса в Восточной Африке означает рассмотрение двух сложных оперативных фактов. Во-первых, Управление по доходам Кении требует, чтобы каждый бизнес-счет имел цифровую фискальную подпись и проверяемый QR-код через eTIMS. Во-вторых, более 80% коммерческих сделок совершаются через Safaricom M-Pesa. Если ваш ERP не может подписать счета-фактуры в режиме реального времени или автоматически сопоставить входящие платежи Paybill, ваша бухгалтерская команда проводит свои дни, делая ручной ввод данных. Если ваш розничный POS отключается при сокращении волокна, вы не можете легально выдавать квитанции. Чтобы решить эти проблемы, мы создали и опубликовали три готовых к производству модуля в официальном App Store. Они поддерживают Odoo 17.0, 18.0 и 19.0 в версиях Community и Enterprise. Вот техническая архитектура того, как мы их построили, как мы справляемся с сетевыми сбоями и что мы узнали на этом пути. Модуль трех интеграций Цель издания и версии JengaStack eTIMS В режиме реального времени KRA OSCU подписывает счет-фактуру и фискальные QR-коды Community & Enterprise (17.0, 18.0, 19.0) JengaStack M-Pesa Daraja STK Push и C2B Paybill/Till ledger Auto-reconciliation Community & Enterprise (17.0, 18.0, 19.0) JengaStack eTIMS VSCU Первый в автономном режиме виртуальный блок управления и пакетная синхронизация соответствия Community & Enterprise (17.0, 18.0, 19.0) 1. Фискальная подпись в режиме реального времени без блокировки ERP-работника Стандартный поток KRA eTIMS Online Sales Control Unit (OSCU) требует отправки элементов линейки счетов, кодов налоговой классификации и PIN-кодов покупателя в KRA по HTTPS. KRA возвращает внутренние данные блока управления (Информация CU), порядковый номер счета-фактуры и URL-адрес проверки, закодированный как QR-код. Непосредственной ловушкой, в которую попадают многие разработчики, является синхронный HTTP-звонок непосредственно в методе подтверждения счета Odoo: При высоком трафике или в пиковые сроки подачи налоговых деклараций конечным точкам KRA часто требуется несколько секунд для ответа. Связывание сотрудников Odoo WSGI с блокированием внешних вызовов быстро истощает пул сотрудников сервера. Asynchronous Buffer and Retry Engine In, мы отделяем подтверждение счета от фискальной передачи. Когда счет-фактура публикует: Модуль присваивает внутреннюю последовательность и создает ожидающую фискальную запись. Если онлайн-режим активен, он пытается немедленно позвонить на короткий перерыв (максимум 4 секунды). Если звонок удался, счет-фактура сразу получает свой контрольный код KRA и QR-код. Если вызов выходит из строя или прерывается, модуль отмечает запись как без отката счета. Выделенный запланированный работник cron подметает ожидающие записи, используя экспоненциальную обратную связь с дрожанием. Полученный QR-код и идентификатор блока управления отображаются как в отчетах PDF QWeb, так и в тепловых квитанциях OWL POS, удовлетворяя нормативным требованиям без остановки расчетных операций. 2. Safaricom M-Pesa Dual-Mode Architecture and Auto-Reconciliation Большинство плагинов M-Pesa для Odoo рассматривают платежи как запоздалую мысль, заставляя персонал вручную читать строки SMS и коды подтверждения типа в Odoo. Мы разработали движок с двумя режимами: Odoo Payment Provider подключается непосредственно к стандартным порталам счетов-фактур и кассам электронной коммерции. Direct POS и Backoffice Engine позволяют кассирам запускать STK Push одним щелчком мыши или позволяют системе принимать нежелательные платежи клиентов C2B, отправленные в Paybill или Till. Webhook Reliability Gap Safaricom отправляет валидацию и подтверждение обратного вызова через HTTPS. Однако сетевые переходы между Safaricom и облачными серверами могут иногда отбрасывать пакеты. Полагаясь исключительно на входящие обратные вызовы приводит к неподтвержденным платежам. Мы решаем эту проблему с помощью трехслойного цикла проверки: Webhook Listener. Принимает входящие полезные нагрузки JSON от Safaricom, хранит необработанную транзакцию в неизменном реестре аудита и подтверждает получение в течение 200 миллисекунд. Active Status Query Fallback. Если инициируется STK Push, и подтверждение не поступает в течение 45 секунд, фоновая работа запрашивает API статуса транзакции Safaricom непосредственно с помощью . Стража Импотенции. Перед регистрацией платежа, транс