Finance teams invoicing in Tanzania face a split reality: the accounting entry lives in Odoo, but the fiscal receipt lives in an EFD device or a virtual fiscal device service registered with the Tanzania Revenue Authority. In practice that means an accountant posts account.move, then re-keys the same customer, TIN, line items and VAT into a separate terminal or portal, then staples the returned fiscal number back onto the Odoo record by hand — or worse, into a spreadsheet. The two ledgers drift. A credit note issued in Odoo has no fiscal counterpart. A rejected submission is discovered a week later during a VAT return. Odoo core has no concept of fiscalisation at all: account.move gives you a posted invoice, a sequence and a QWeb PDF, and nothing that speaks to a fiscal device or carries a verification code, device serial, receipt number or signature.

ECOSIRE builds a module that closes that gap inside the ERP. We add a fiscalisation layer on account.move — new fields for the fiscal document number, verification/QR payload, device or VFD identifier, submission timestamp and a fiscal_state selection (to_submit, submitted, accepted, rejected, cancelled) — plus a dedicated tra.efd.submission model that stores every request and response payload so the exchange is reconstructable months later. Submission is triggered from the posting flow or from an explicit button, then handed to a queued job so a slow or unreachable endpoint never blocks a user's post. Tax mapping is driven off your existing ERP master data rather than hardcoded: account.tax records carry the TRA tax code, product.template carries the item classification and unit of measure mapping, and res.partner supplies the TIN and VRN, all validated with @api.constrains so a bad master-data record is caught at source instead of at the tax authority.

One posting produces both outputs. The human-readable document is a QWeb report that renders the fiscal identifiers, verification code and QR image alongside your normal invoice layout, so the customer copy and the fiscal copy can never disagree. The machine format is generated from the same recordset by a dedicated builder method, signed or wrapped per the integration's requirements, and transmitted over the vendor's HTTP interface. Rejections are first-class: the response code and message are stored on the submission record, the invoice moves to rejected and is flagged in a filtered list view, and a correction workflow lets a user fix the underlying data and resubmit under a controlled sequence rather than silently re-posting. Every state change writes to the chatter via message_post, so mail.thread becomes your audit trail. Access is governed by ir.model.access.csv plus record rules — accountants submit, a billing supervisor can retry or cancel a fiscalised document, and nobody can edit stored payloads once written.

Because the exchange happens inside Odoo, the rest of your automation keeps working. Scheduled actions (ir.cron) retry queued submissions and reconcile documents stuck in submitted, automated actions can notify a channel on rejection, and everything is reachable over XML-RPC/JSON-RPC if a POS front end, e-commerce store or third-party system needs to trigger or read fiscal status. The module targets Odoo Community and runs unchanged on Enterprise; where Enterprise is present we hook the accounting dashboard and use its reporting engine, and where it is not, the same data is exposed through standard list, pivot and QWeb views so no feature sits behind a licence.

This is a build-to-order product, not an off-the-shelf download. After a short scoping call we confirm your Odoo version (17.0, 18.0 or 19.0), your VFD or device vendor and credentials, your chart of accounts and tax structure, and the exact document types in scope — invoices, credit notes, POS receipts, multi-company or multi-branch. We then write the module against your database, package it with a proper __manifest__.py and version pin, and deliver it for UAT on a staging copy of your production data before anything touches live. Typical delivery is one working week from confirmed scope, and you receive the full source in a git repository you own.