Invoicing in Türkiye is not a printing problem, it is a routing problem. Every customer invoice has to be classified before it is sent: a buyer registered in the GİB e-Fatura user list must receive a structured e-Fatura through the interoperability network, while everyone else must receive an e-Arşiv document delivered by other means and reported to the administration. Get the classification wrong and the document is rejected downstream, the receivable is disputed, and the finance team is re-keying invoices at month end. Odoo core stops well short of this. account.move gives you a posting, a QWeb PDF and a fiscal position, but it has no concept of a buyer's e-invoice registration status, no scenario field, no structured payload generation, no rejection state and no dedicated legal archive — the Enterprise localisation covers chart of accounts and tax basics, not the end-to-end document lifecycle.

What ECOSIRE builds is a compliance layer that lives inside the invoicing flow rather than beside it. We extend account.move with the fields the process actually needs — document scenario, profile, document UUID, GİB status, response code, dispatch timestamps — and add a res.partner extension holding the buyer's e-invoice registration state with a dated check, so the scenario is decided from evidence rather than habit. Scenario selection is a stored compute (@api.depends on the partner registration flag, the partner's tax identifiers and the invoice type) so it recalculates when master data changes but stays queryable for reporting. Tax lines are mapped from your existing Odoo tax records through a configurable mapping model, so KDV rates, exemption reasons and withholding cases resolve from data you already maintain instead of from hardcoded logic — and an unmapped tax raises a blocking ValidationError at posting rather than producing a silently wrong document.

One posting produces both the machine format and the human-readable rendering. The structured payload is generated from the invoice and its mapping, validated for required fields before dispatch, and stored as an ir.attachment alongside a QWeb report designed for the layout your customers expect, including the document reference and code block where applicable. Dispatch runs through a configurable connector layer so we integrate with the special integrator or private service provider you already contract with; transport is isolated behind a service model, which means changing provider later is a configuration and adapter change rather than a rewrite. Status polling runs as a scheduled ir.cron job that updates the document state and writes to the chatter, so accountants see acceptance, rejection or pending status on the invoice itself.

Rejections are treated as a first-class workflow. When a document comes back refused, the invoice moves to a rejection state carrying the response code and reason, and the correction path — credit note plus corrected reissue, with the original document referenced — is driven from a button rather than from tribal knowledge. Archiving is equally deliberate: payloads, responses and rendered documents are retained with immutable references and an append-only log model, visible through views and filters that let auditors pull a period without asking IT. Access is controlled through ir.model.access.csv plus record rules so only the finance roles you nominate can dispatch, cancel or reissue, and multi-company setups keep their documents separated. Everything is exposed over the standard XML-RPC and JSON-RPC API, so a portal or treasury tool can read document status without a second integration.

This is a build-to-order product, not a download. After a short scoping call we confirm your Odoo version (17.0, 18.0 or 19.0), Community or Enterprise, your service provider or integrator, your KDV and exemption cases, and any sector-specific document requirements. We then build the module against your configuration, deliver it to a staging database for UAT with your own invoice samples, and go live with a documented rollback plan. Typical delivery is one working week from confirmed scope. You receive the full source, a git repository handover, and a post-go-live support window — the code is yours, and nothing is locked behind a runtime key.