Odoo Changelog — 2026-01-13

Tuesday, January 13, 2026

1 change · 19.0

New Features(1)

New functionality added to Odoo

[ADD] l10n_tr_nilvera_einvoice_extended: import invoice/bill from UBL TR 1.2

Core19.0l10n_tr_nilvera_einvoice_extendedHigh impact

Odoo can now correctly import Turkish e-invoices and vendor bills received through Nilvera in the TR 1.2 format. This prevents empty or incomplete invoices and improves reliability for supported Turkish sales, purchase, public sector, export, exemption, and withholding scenarios.

Original PR description

## Description of the issue/feature this PR addresses: Nilvera uses a customized UBL format (UBL TR 1.2) that differs from the standard UBL 2.1 structure. Odoo's existing decoder only supports UBL…

## Description of the issue/feature this PR addresses:
Nilvera uses a customized UBL format (UBL TR 1.2) that differs from the standard UBL 2.1 structure.
Odoo's existing decoder only supports UBL 2.1, meaning any UBL TR 1.2 XML fetched, results in an empty or incomplete invoice, as the fields cannot be extracted.

## Current behavior before PR:

- Importing a TR 1.2 invoice (CustomizationID="TR1.2") results in an empty invoice most of the time, because the system attempts to parse it using the UBL 2.1 decoder.

## Desired behavior after PR is merged:

- A dedicated TR 1.2 decoder is introduced to fully support Turkish e-invoice imports for Nilvera.

- The decoder extracts all invoice content based on Customization-ID 1.2(UBL TR):

  - Partner details + fallback partner creation

  - Postal address and country/state resolution

  - Bank account

  - Delivery and export exemption fields

  - Product lookup via default code or CTSP number

  - Line taxes, discounts, and pricing

- Supported scenarios are explicitly limited to:

  - ProfileID: TEMELFATURA, IHRACAT, KAMU

  - InvoiceTypeCode: SATIS, TEVKIFAT, ISTISNA, IHRACKAYITLI

  - Both sale and purchase imports

- The decoder falls back to the base UBL importer when CustomizationID is not TR1.2.

- Comprehensive test cases are added to validate successful imports and edge scenarios.

task-5079559

---------
I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)

#turkey#e-invoicing#nilvera#invoice-import

## Description of the issue/feature this PR addresses: Nilvera uses a customized UBL format (UBL TR 1.2) that differs from the standard UBL 2.1 structure. Odoo's existing decoder only supports UBL 2.1, meaning any UBL TR 1.2 XML fetched, results in an empty or incomplete invoice, as the fields cannot be extracted. ## Current behavior before PR: - Importing a TR 1.2 invoice (CustomizationID="TR1.2") results in an empty invoice most of the time, because the system attempts to parse it using the UBL 2.1 decoder. ## Desired behavior after PR is merged: - A dedicated TR 1.2 decoder is introduced to fully support Turkish e-invoice imports for Nilvera. - The decoder extracts all invoice content based on Customization-ID 1.2(UBL TR): - Partner details + fallback partner creation - Postal address and country/state resolution - Bank account - Delivery and export exemption fields - Product lookup via default code or CTSP number - Line taxes, discounts, and pricing - Supported scenarios are explicitly limited to: - ProfileID: TEMELFATURA, IHRACAT, KAMU - InvoiceTypeCode: SATIS, TEVKIFAT, ISTISNA, IHRACKAYITLI - Both sale and purchase imports - The decoder falls back to the base UBL importer when CustomizationID is not TR1.2. - Comprehensive test cases are added to validate successful imports and edge scenarios. task-5079559 --------- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)