If your business trades in Jordan, the Income and Sales Tax Department (ISTD) mandate to clear invoices through the JoFotara national e-invoicing platform is not something you can satisfy from stock Odoo. Odoo Community and Enterprise handle Jordanian VAT/general sales tax on the accounting side, but neither ships a JoFotara connector: there is no ISTD-compliant XML export, no submission client for the JoFotara API, no clearance-status tracking on the invoice, and no QR code carrying the validated fiscal reference. Teams end up re-keying every account.move into the JoFotara portal by hand, which does not scale and breaks the moment invoice volume rises or an audit asks for a reconciled trail.

ECOSIRE builds a dedicated Odoo module that closes that gap end to end. We extend account.move with the JoFotara lifecycle — clearance state, submission UUID, ISTD invoice number, QR payload and error log — as stored fields driven by compute/@api.depends methods, so status is always derivable and auditable rather than typed in. On validation (or via a queued automated action), the module serialises the invoice into the ISTD-mandated XML structure: seller/buyer identifiers, tax registration numbers, line-level sales-tax and general-sales-tax mapping from your Jordanian tax codes, totals, and the required digital signature envelope. It calls the JoFotara REST API over an authenticated channel, parses the clearance response, stores the returned reference, and generates the compliant QR code that is embedded into the customer-facing invoice via a QWeb report override. Retries, rejection reasons and resubmission are handled explicitly so a failed clearance never silently blocks your billing.

Technically the module is a clean, upgrade-safe addon: a proper __manifest__.py declaring dependencies on account, models under models/ using models.Model with typed fields, access control through ir.model.access.csv plus record rules so only authorised accounting users can resubmit or view raw payloads, backend views and an OWL status widget for at-a-glance clearance state, and server-side automated actions for bulk/scheduled submission. Because JoFotara is a live external system, we also expose the submission logic through Odoo's XML-RPC/JSON-RPC layer so upstream systems or your own scripts can trigger clearance programmatically. It is built and tested against Odoo 17.0, 18.0 and 19.0, and against both Community and Enterprise (Enterprise's account_edi framework is used where present; a self-contained submission path is provided for Community).

Because this is build-to-order, you are not downloading a generic zip and hoping it fits. After a short scoping call we confirm your Odoo version and edition, your JoFotara taxpayer credentials and onboarding stage, your chart of accounts and exact sales-tax/general-sales-tax code mapping, and any branch or multi-company requirements. We then build the module to that scope, test it against the JoFotara sandbox, deploy to your staging environment for UAT, and cut over to production with a rollback plan. Typical delivery is one working week from confirmed scope. You receive the full installable source, documentation, a training session, and a post-go-live support window — you own the code and the git repository at handover.