Daily updates from Odoo
Wednesday, August 5, 2026
7 changes
1 change
New functionality added to Odoo
Adds a Romania-specific EC Sales D390 report so companies can prepare the monthly declaration required by ANAF for EU cross-border transactions. The update includes the required XML export and collection of declarant details, helping Romanian businesses meet electronic filing requirements.
Original PR description
This commit introduces a new module, 'Romania - EC Sales D390 Report'. For the support of Declarația 390 report as an EC List report for Romania in stable versions. Romanian localization has…
This commit introduces a new module, 'Romania - EC Sales D390 Report'.
For the support of Declarația 390 report as an EC List report for Romania in
stable versions.
Romanian localization has different requirements for the
EC Sales List report. So the generic EC Sales List does not work in the case of
Romania.
LEGAL REQUIREMENTS:
- Romanian tax authority accepts the Declarația 390 (Form 390) report for
cross-border transactions within the European Union.
- This declaration is filed on a monthly basis.
- The declaration must be submitted electronically to ANAF by the 25th of the
month following the month in which the transactions occurred. For example,
the declaration for transactions made in July must be filed by August 25th.
- The declaration must include all the intra-community transactions. These
transactions include:
1. Intra-Community acquisition of Goods
2. Intra-Community acquisition of Services
3. Intra-Community triangular trades
4. Intra-Community supplies of Goods
5. Intra-Community supplies of Services
REQUIRED FORMAT:
- Declarația 390 must be submitted electronically in a specific XML format.
The structure of this XML file is defined by ANAF.
- To facilitate compliance, ANAF provides a free software application called
'DUKIntegrator'. This tool allows businesses to:
1. Validate the generated XML file against the official schema to ensure it is
correctly formatted.
2. Generate the final PDF file with the XML attachment, which is the official
format for submission.
TECHNICAL DETAILS:
- Implemented the tax returns for the D390 EC Sales List report filing.
- Implemented XML export file generator, which creates the whole D390 XML report
with the required schema format.
- The D390 report needs to have the declarant's details in the report, the
attributes like 'nume_declar(Middle Name)', 'prenume_declar(First Name)',
'functie_declar(Job Position)' and 'adresa(Fiscal Domicile Address)'.
For collecting these details, we've created a wizard that will be on the
return validation action. Along with these details, we ask the user if the
current return is the corrected/rectified one, with the 'corrective_declaration'
field in this wizard. This wizard will then store these details in the
respective return. And in the XML export file generator, we are retrieving
these details from the return to show in the report.
REFERENCES:
- Drive link for official XML report schema, report structure, 'DUKIntegrator'
software and XML report attribute explanation in English: (
https://drive.google.com/drive/folders/1uzROZAM5Vuiv0HlBXw-vU28x5a9sVOpb)
- Official ANAF sources for D390 report: (
https://static.anaf.ro/static/10/Anaf/Declaratii_R/390.html)
- Official ANAF website for Electronic Declaration: (
https://www.anaf.ro/anaf/internet/ANAF/servicii_online/declaratii_electronice)
Forward-Port-Of: odoo/enterprise#1099211 change
New functionality added to Odoo
Adds a dedicated Romanian Declarația 390 report so businesses can prepare the required monthly EU cross-border transaction declaration in Odoo. The update includes ANAF-compatible XML export, declarant details collection, corrective filing support, and more accurate audit drill-downs for EC sales report lines.
Original PR description
This commit introduces a new module, 'Romania - EC Sales D390 Report'. For the support of Declarația 390 report as an EC List report for Romania in stable versions. Romanian localization has…
This commit introduces a new module, 'Romania - EC Sales D390 Report'.
For the support of Declarația 390 report as an EC List report for Romania in
stable versions.
Romanian localization has different requirements for the
EC Sales List report. So the generic EC Sales List does not work in the case of
Romania.
LEGAL REQUIREMENTS:
- Romanian tax authority accepts the Declarația 390 (Form 390) report for
cross-border transactions within the European Union.
- This declaration is filed on a monthly basis.
- The declaration must be submitted electronically to ANAF by the 25th of the
month following the month in which the transactions occurred. For example,
the declaration for transactions made in July must be filed by August 25th.
- The declaration must include all the intra-community transactions. These
transactions include:
1. Intra-Community acquisition of Goods
2. Intra-Community acquisition of Services
3. Intra-Community triangular trades
4. Intra-Community supplies of Goods
5. Intra-Community supplies of Services
REQUIRED FORMAT:
- Declarația 390 must be submitted electronically in a specific XML format.
The structure of this XML file is defined by ANAF.
- To facilitate compliance, ANAF provides a free software application called
'DUKIntegrator'. This tool allows businesses to:
1. Validate the generated XML file against the official schema to ensure it is
correctly formatted.
2. Generate the final PDF file with the XML attachment, which is the official
format for submission.
TECHNICAL DETAILS:
- Implemented the tax returns for the D390 EC Sales List report filing.
- Implemented XML export file generator, which creates the whole D390 XML report
with the required schema format.
- The D390 report needs to have the declarant's details in the report, the
attributes like 'nume_declar(Middle Name)', 'prenume_declar(First Name)',
'functie_declar(Job Position)' and 'adresa(Fiscal Domicile Address)'.
For collecting these details, we've created a wizard that will be on the
return validation action. Along with these details, we ask the user if the
current return is the corrected/rectified one, with the 'corrective_declaration'
field in this wizard. This wizard will then store these details in the
respective return. And in the XML export file generator, we are retrieving
these details from the return to show in the report.
REFERENCES:
- Drive link for official XML report schema, report structure, 'DUKIntegrator'
software and XML report attribute explanation in English: (
https://drive.google.com/drive/folders/1uzROZAM5Vuiv0HlBXw-vU28x5a9sVOpb)
- Official ANAF sources for D390 report: (
https://static.anaf.ro/static/10/Anaf/Declaratii_R/390.html)
- Official ANAF website for Electronic Declaration: (
https://www.anaf.ro/anaf/internet/ANAF/servicii_online/declaratii_electronice)
Forward-Port-Of: odoo/enterprise#1099212 changes
New functionality added to Odoo
Adds a dedicated Romanian D390 EC Sales report so businesses can prepare the legally required monthly declaration for intra-EU transactions. The change includes XML export in the ANAF-required format and a guided step to collect declarant details, helping Romanian companies submit compliant filings.
Original PR description
This commit introduces a new module, 'Romania - EC Sales D390 Report'. For the support of Declarația 390 report as an EC List report for Romania in stable versions. Romanian localization has…
This commit introduces a new module, 'Romania - EC Sales D390 Report'.
For the support of Declarația 390 report as an EC List report for Romania in
stable versions.
Romanian localization has different requirements for the
EC Sales List report. So the generic EC Sales List does not work in the case of
Romania.
LEGAL REQUIREMENTS:
- Romanian tax authority accepts the Declarația 390 (Form 390) report for
cross-border transactions within the European Union.
- This declaration is filed on a monthly basis.
- The declaration must be submitted electronically to ANAF by the 25th of the
month following the month in which the transactions occurred. For example,
the declaration for transactions made in July must be filed by August 25th.
- The declaration must include all the intra-community transactions. These
transactions include:
1. Intra-Community acquisition of Goods
2. Intra-Community acquisition of Services
3. Intra-Community triangular trades
4. Intra-Community supplies of Goods
5. Intra-Community supplies of Services
REQUIRED FORMAT:
- Declarația 390 must be submitted electronically in a specific XML format.
The structure of this XML file is defined by ANAF.
- To facilitate compliance, ANAF provides a free software application called
'DUKIntegrator'. This tool allows businesses to:
1. Validate the generated XML file against the official schema to ensure it is
correctly formatted.
2. Generate the final PDF file with the XML attachment, which is the official
format for submission.
TECHNICAL DETAILS:
- Implemented the tax returns for the D390 EC Sales List report filing.
- Implemented XML export file generator, which creates the whole D390 XML report
with the required schema format.
- The D390 report needs to have the declarant's details in the report, the
attributes like 'nume_declar(Middle Name)', 'prenume_declar(First Name)',
'functie_declar(Job Position)' and 'adresa(Fiscal Domicile Address)'.
For collecting these details, we've created a wizard that will be on the
return validation action. Along with these details, we ask the user if the
current return is the corrected/rectified one, with the 'corrective_declaration'
field in this wizard. This wizard will then store these details in the
respective return. And in the XML export file generator, we are retrieving
these details from the return to show in the report.
REFERENCES:
- Drive link for official XML report schema, report structure, 'DUKIntegrator'
software and XML report attribute explanation in English: (
https://drive.google.com/drive/folders/1uzROZAM5Vuiv0HlBXw-vU28x5a9sVOpb)
- Official ANAF sources for D390 report: (
https://static.anaf.ro/static/10/Anaf/Declaratii_R/390.html)
- Official ANAF website for Electronic Declaration: (
https://www.anaf.ro/anaf/internet/ANAF/servicii_online/declaratii_electronice)
Forward-Port-Of: odoo/enterprise#109921Resolved issues and error corrections
Ecuadorian invoices now print with the required local header and barcode again. This restores legally required information on PDF invoices and prevents documents from falling back to the generic invoice layout.
Original PR description
### Issue:
In 19.2, the EC invoice header was no longer rendered on invoices, falling back to the standard layout
The header includes legally required data and a barcode, both missing from the printed PDF
### Cause:
The XPath targeting `//t[@t-set='o']` relied on the position of the `t-set` for `o` in `report_invoice_document`
After the refactor in commit `eb6e88a25050`, the injection point no longer resolves as expected, preventing the header from rendering
Targeting `//div[hasclass('invoice_main')]` instead provides a stable anchor that is less sensitive to template restructuring
### Steps to reproduce:
- Install `l10n_ec_edi` and switch to the EC company
- Create and confirm an invoice
- Print the invoice
Before the fix, the EC header and barcode are missing from the PDF
opw-63757331 change
New functionality added to Odoo
Adds support for Romania’s Declarația 390 EC Sales report, enabling Romanian businesses to prepare the required monthly EU cross-border transaction declaration in Odoo. The new module generates the ANAF-required XML export and collects declarant details needed for electronic filing, while also improving audit results for EC Sales reports using tax tags.
Original PR description
This commit introduces a new module, 'Romania - EC Sales D390 Report'. For the support of Declarația 390 report as an EC List report for Romania in stable versions. Romanian localization has…
This commit introduces a new module, 'Romania - EC Sales D390 Report'.
For the support of Declarația 390 report as an EC List report for Romania in
stable versions.
Romanian localization has different requirements for the
EC Sales List report. So the generic EC Sales List does not work in the case of
Romania.
LEGAL REQUIREMENTS:
- Romanian tax authority accepts the Declarația 390 (Form 390) report for
cross-border transactions within the European Union.
- This declaration is filed on a monthly basis.
- The declaration must be submitted electronically to ANAF by the 25th of the
month following the month in which the transactions occurred. For example,
the declaration for transactions made in July must be filed by August 25th.
- The declaration must include all the intra-community transactions. These
transactions include:
1. Intra-Community acquisition of Goods
2. Intra-Community acquisition of Services
3. Intra-Community triangular trades
4. Intra-Community supplies of Goods
5. Intra-Community supplies of Services
REQUIRED FORMAT:
- Declarația 390 must be submitted electronically in a specific XML format.
The structure of this XML file is defined by ANAF.
- To facilitate compliance, ANAF provides a free software application called
'DUKIntegrator'. This tool allows businesses to:
1. Validate the generated XML file against the official schema to ensure it is
correctly formatted.
2. Generate the final PDF file with the XML attachment, which is the official
format for submission.
TECHNICAL DETAILS:
- Implemented the tax returns for the D390 EC Sales List report filing.
- Implemented XML export file generator, which creates the whole D390 XML report
with the required schema format.
- The D390 report needs to have the declarant's details in the report, the
attributes like 'nume_declar(Middle Name)', 'prenume_declar(First Name)',
'functie_declar(Job Position)' and 'adresa(Fiscal Domicile Address)'.
For collecting these details, we've created a wizard that will be on the
return validation action. Along with these details, we ask the user if the
current return is the corrected/rectified one, with the 'corrective_declaration'
field in this wizard. This wizard will then store these details in the
respective return. And in the XML export file generator, we are retrieving
these details from the return to show in the report.
REFERENCES:
- Drive link for official XML report schema, report structure, 'DUKIntegrator'
software and XML report attribute explanation in English: (
https://drive.google.com/drive/folders/1uzROZAM5Vuiv0HlBXw-vU28x5a9sVOpb)
- Official ANAF sources for D390 report: (
https://static.anaf.ro/static/10/Anaf/Declaratii_R/390.html)
- Official ANAF website for Electronic Declaration: (
https://www.anaf.ro/anaf/internet/ANAF/servicii_online/declaratii_electronice)1 change
New functionality added to Odoo
Adds a new Romania-specific D390 EC Sales report so businesses can prepare the required monthly declaration for intra-EU transactions in the ANAF XML format. It also improves report audit drill-downs so users see only relevant tax-tagged entries when reviewing EC Sales report totals.
Original PR description
This commit introduces a new module, 'Romania - EC Sales D390 Report'. For the support of Declarația 390 report as an EC List report for Romania in stable versions. Romanian localization has…
This commit introduces a new module, 'Romania - EC Sales D390 Report'.
For the support of Declarația 390 report as an EC List report for Romania in
stable versions.
Romanian localization has different requirements for the
EC Sales List report. So the generic EC Sales List does not work in the case of
Romania.
LEGAL REQUIREMENTS:
- Romanian tax authority accepts the Declarația 390 (Form 390) report for
cross-border transactions within the European Union.
- This declaration is filed on a monthly basis.
- The declaration must be submitted electronically to ANAF by the 25th of the
month following the month in which the transactions occurred. For example,
the declaration for transactions made in July must be filed by August 25th.
- The declaration must include all the intra-community transactions. These
transactions include:
1. Intra-Community acquisition of Goods
2. Intra-Community acquisition of Services
3. Intra-Community triangular trades
4. Intra-Community supplies of Goods
5. Intra-Community supplies of Services
REQUIRED FORMAT:
- Declarația 390 must be submitted electronically in a specific XML format.
The structure of this XML file is defined by ANAF.
- To facilitate compliance, ANAF provides a free software application called
'DUKIntegrator'. This tool allows businesses to:
1. Validate the generated XML file against the official schema to ensure it is
correctly formatted.
2. Generate the final PDF file with the XML attachment, which is the official
format for submission.
TECHNICAL DETAILS:
- Implemented the tax returns for the D390 EC Sales List report filing.
- Implemented XML export file generator, which creates the whole D390 XML report
with the required schema format.
- The D390 report needs to have the declarant's details in the report, the
attributes like 'nume_declar(Middle Name)', 'prenume_declar(First Name)',
'functie_declar(Job Position)' and 'adresa(Fiscal Domicile Address)'.
For collecting these details, we've created a wizard that will be on the
return validation action. Along with these details, we ask the user if the
current return is the corrected/rectified one, with the 'corrective_declaration'
field in this wizard. This wizard will then store these details in the
respective return. And in the XML export file generator, we are retrieving
these details from the return to show in the report.
REFERENCES:
- Drive link for official XML report schema, report structure, 'DUKIntegrator'
software and XML report attribute explanation in English: (
https://drive.google.com/drive/folders/1uzROZAM5Vuiv0HlBXw-vU28x5a9sVOpb)
- Official ANAF sources for D390 report: (
https://static.anaf.ro/static/10/Anaf/Declaratii_R/390.html)
- Official ANAF website for Electronic Declaration: (
https://www.anaf.ro/anaf/internet/ANAF/servicii_online/declaratii_electronice)
Forward-Port-Of: odoo/enterprise#1099211 change
Enhancements to existing features
Appointment pages now calculate bookable capacities much more efficiently, especially when many linked resources are involved. This makes availability pages load far faster and also corrects capacity values in some resource-selection cases.
Original PR description
Before --- - When opening the appointment page, the possible capacities that a user can book needs to be calculated to show the capacity dropdown. - This is currently done by getting all the possible…
Before
---
- When opening the appointment page, the possible capacities that a user can book needs to be calculated to show the capacity dropdown.
- This is currently done by getting all the possible combinations that could arise from each resource along with its linked resources (Linked resources are resources that are used to combine with the main resource to allow a bigger capacity)
- The complexity of this approach blows up with the increase in linked resources. For each resource we end up with O(2^m) where m is the number of linked resources it has. If they have the same number of linked resources, and n is the number of resources, we end up with O(n*2^m)
Solution:
- Flipping the algorithm, we create a structure for possible capacities and only keep the best combination for a found capacity.
- We first store all available capacity for relevant resources.
Algorithm
---
For a resource:
- We initialize the solution S to {0: []}
- Greedy dynamic programming is then used to get all the possible combinations by building the result dict, adding one resource at a time. We add its capacity to all entries of S -> we use the combination if a new capacity is reached OR update the combination if the number of elements of combination is less than the existing one.
Then, for the global solution:
- We go through S of resources (in the order of self), and add entries to G (the general dict of solutions). Again, on collision, we only keep the lower-cardinal combination.
The complexity of this algorithm is O(n*u) where u is the dynamic programming complexity. u would be quadratic O(m^2) if the sub-sums of capacities overlap heavily, for instance when resources have the same capacity, like tables of a restaurant, but could reach (2^m) in the worst case scenario.
Related changes / side effects
---
1. Fixing an issue
2. Cleaning strange logic
3. Cleaning max capacity computation
Benchmark:
- opw-5177932 goes down from 6 mins to less than 2 seconds using the new algorithm.
Also include
---
Fix the max capacity on resources when skipping resource selection. It computed the max capa based on values that were not yet emptied in the website_appointment controller.
Task-6233563