Türkiye e-Arşiv & e-Fatura for Odoo

Key Features

Scenario routing on `account.move` — a stored compute selects e-Fatura or e-Arşiv from the buyer's registration status, tax identifiers and invoice type, recalculating via `@api.depends` when master data changes

`res.partner` extension storing e-invoice registration state, alias/mailbox reference and the date the status was last checked, so classification is evidence-based

Configurable tax mapping model translating your existing `account.tax` records into the required document tax codes, exemption reasons and withholding cases

Blocking validation at posting: unmapped taxes, missing tax identifiers or incomplete address data raise a `ValidationError` instead of producing a document that will be rejected

Single posting produces both outputs — the structured machine payload stored as an `ir.attachment`, and a QWeb report rendered as the human-readable copy with reference and code block

Provider-agnostic connector layer isolating transport behind a service model, so switching integrator or private service provider is an adapter change, not a rewrite

Scheduled `ir.cron` status polling that updates document state, writes response codes to the invoice chatter and flags stalled dispatches

Rejection workflow with a dedicated state carrying the response code and reason, plus a button-driven correction path issuing the credit note and reissue with the original document referenced

Append-only log model recording every dispatch, response and reissue with timestamp and acting user, queryable from list and pivot views

Archive views and filters covering document type, scenario, status and period, so an auditor can extract a range without a developer

Security via `ir.model.access.csv` plus record rules — dispatch, cancel and reissue rights separated from ordinary invoicing rights, with multi-company record isolation

Sequence and numbering configuration aligned to document series requirements, with gap-free allocation on posting

Automated action hooks so downstream steps (emailing the e-Arşiv copy, internal notification on rejection) are configured rather than coded

Full XML-RPC / JSON-RPC exposure of document status fields for portals, treasury tools or BI extracts

Version-targeted build for Odoo 17.0, 18.0 or 19.0, Community or Enterprise, reading the Enterprise localisation records rather than duplicating them

Built to order, done for you

No DIY setup — a working app, built, installed and supported by ECOSIRE.

You order

Start with a one-time build price. We scope it with you at kickoff.

We build & install

ECOSIRE builds, configures and installs it on your Odoo.

Go live + support

You go live in about 2–4 weeks, with a post-launch support window.

About this Product

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 two to four weeks 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.

What you get

Installable module source built and tested for your exact Odoo version (17.0, 18.0 or 19.0) and edition

Installation and configuration on your environment, including tax mapping, sequences, partner registration data and connector credentials

Technical documentation — `__manifest__.py` and dependency notes, model and field reference, security matrix, connector adapter contract and extension points

End-user guide plus a live training session for the finance team covering issuing, status checks, rejection handling and correction

UAT on a staging database using your own invoice samples, with a signed-off test checklist and a documented rollback plan

Post-go-live support window for defect fixes and configuration adjustments on the delivered scope

Git repository handover with full commit history — the source is yours, with no runtime licence key

Handover call covering the operational runbook, monitoring of the polling cron, and what to do when the provider endpoint is unavailable

Who this is for

Finance Manager / Muhasebe Müdürü

Owns invoice issuance and month-end close for a Türkiye-registered entity. Needs every outbound invoice to leave Odoo correctly classified the first time, with rejections visible and correctable in the same screen instead of tracked on a spreadsheet.

Group Financial Controller

Runs a multi-country group where Türkiye is one of several entities on one Odoo database. Needs local compliance handled inside the group chart of accounts and multi-company record rules, without a separate system or a parallel invoicing process.

ERP / IT Manager

Responsible for the Odoo instance and its upgrade path. Wants maintainable model extensions, a provider-isolated connector, real access control and full source in a git repo — not an opaque package that blocks the next major-version upgrade.

External Accountant or Audit Lead

Signs off on the records. Needs a durable archive of payloads, responses and rendered documents with an append-only trail, retrievable by period and document type without asking developers to run queries.

How Türkiye e-Arşiv & e-Fatura for Odoo Compares

Criterion	ECOSIRE	Custom Build	Competitor	Odoo Native
Scenario routing (e-Fatura vs e-Arşiv)	Stored compute driven by partner registration status, tax IDs and invoice type; recomputes on master-data change	Achievable, but edge cases (status changes mid-period, mixed buyer base) are usually discovered in production	Often a manual selection field the user is expected to set correctly on every invoice	No concept of buyer e-invoice registration or document scenario exists in core
Tax and exemption mapping	Configurable mapping from your existing `account.tax` records, with a blocking validation on unmapped taxes	Frequently hardcoded to the rates known on build day, then quietly wrong after a rate change	Fixed mapping table; sector-specific exemption and withholding cases usually need vendor changes	Taxes and fiscal positions exist, but nothing maps them to compliance document codes
Rejection and correction workflow	Dedicated rejection state with response code, plus a button-driven credit note and reissue referencing the original	Commonly out of scope on the first build and added after the first rejected batch	Status is shown; correction is usually left as a manual process for the accountant	Credit notes exist; the compliance rejection lifecycle does not
Archiving and audit trail	Payloads, responses and renders retained as attachments with an append-only log and period filters	Depends on the developer's discipline; log models are the first thing cut for budget	Attachments usually stored; queryable, filterable audit extraction varies widely	Standard attachments and chatter only — no compliance archive or extraction
Provider / integrator flexibility	Transport isolated behind a service model, so changing provider is an adapter swap	Typically written against one provider's API and coupled through the business logic	Frequently tied to the vendor's own provider relationship or preferred integrator	No dispatch layer at all
Access control and multi-company	`ir.model.access.csv` plus record rules separating dispatch, cancel and reissue rights, with company isolation	Usually inherits generic accounting rights; company isolation depends on the build	Basic group split; fine-grained dispatch-versus-invoicing rights are uncommon	Standard accounting groups only — no compliance-action-level rights
Source code ownership	Full source and git repository handover, no runtime licence key	You own it, and you also own every future fix and version port alone	Often licence-key gated per database, with redistribution restricted	Core is open source, but there is nothing here to own
Version coverage and upgrade path	Built to your target 17.0, 18.0 or 19.0, Community or Enterprise; ports quoted from your existing code	Upgrade cost re-litigated with whoever is available at the time	Version support follows the vendor's release cadence, which you do not control	Upgrades are clean, because the functionality is absent

Frequently Asked Questions about Türkiye e-Arşiv & e-Fatura for Odoo

How long does delivery take?

This is a build-to-order module, so there is no instant download. Typical delivery is two to four weeks from confirmed scope. The clock starts once we have agreed your Odoo version and edition, your service provider or integrator, your KDV and exemption cases, and any sector-specific document requirements. Complex multi-company or high-volume setups can extend that, and we tell you before you commit rather than after.

What happens to support and updates after go-live?

You get a post-go-live support window covering defect fixes and configuration adjustments on the delivered scope. Because you receive the full source in your own git repository, your team can also maintain it directly. Changes driven by new GİB requirements, or a port to a newer Odoo major version, are scoped as follow-on work — quoted from your existing codebase rather than starting over — and there is no runtime key that can switch the module off.

Do I still need an integrator or private service provider?

Yes. The module handles classification, document generation, dispatch orchestration, status tracking and archiving inside Odoo. Actual transmission to the network runs through the special integrator or private service provider you contract with. Our connector layer is provider-agnostic and isolated behind a service model, so we integrate with the provider you already use, and switching later is an adapter change rather than a rebuild.

Does this work on Odoo Community, or do I need Enterprise?

Both are supported. The module builds on core `account` models, so Community works. On Enterprise we respect the existing Türkiye localisation — chart of accounts and tax records stay where they are and our tax mapping reads them rather than duplicating them. Tell us your edition at the scoping call, because it changes which base records we map against.

How are rejected documents handled?

A rejection is a state on the invoice, not an email someone has to notice. The scheduled polling job writes the response code and reason to the document and to the chatter, moves it into a rejection state, and exposes a correction action that issues the credit note and the corrected reissue with the original document referenced. The append-only log keeps the whole chain, so the audit trail shows what was sent, what came back, and what replaced it.

Can our other systems read the document status?

Yes. All status fields sit on standard Odoo models and are exposed over the normal XML-RPC and JSON-RPC API, so a customer portal, a treasury tool or a BI extract can read scenario, dispatch state, response code and archive references without a second integration or a private endpoint.

What if we are migrating to a newer Odoo version soon?

Tell us at scoping and we build against the target version instead of the current one, or against both if you need a parallel run. Because the module extends core models cleanly and keeps transport behind an adapter, version ports are ordinary maintenance work rather than a rewrite — and you hold the source to do it yourself if you prefer.