Features

• Monthly intra-Community recapitulative statement — wizard l10n.ro.anaf.d390 generates <declaratie390> under namespace mfp:anaf:dgti:d390:declaratie:v3, validated against the bundled D390.xsd. Two versions are shipped (v3, v4.1); the wizard picks the one matching the period.
• Operation type detection — each posted invoice line is classified as L (supplies of goods), A (acquisitions of goods), P (supplies of services), S (acquisitions of services), T (triangular) or R (non-transfer / specific products) based on its VAT tax tag, the l10n_ro_is_triangular flag and the product l10n_ro_anaf_code.
• Per-partner aggregation — lines are grouped by (partner_vat, operation_type) and partner country is filled from _parse_anaf_vat_info(). The ANAF codO carries only the national part of the VAT number (the country prefix goes on tara separately).
• D300 reconciliation — check_intracom_vat() recomputes the L / A / P / S totals from the D300 tax tags and compares them to the D390 rezumat; the wizard raises a UserError listing the diverging partners if the two do not match within a rounding tolerance.
• Triangular adjustments — lines with l10n_ro_is_triangular are reclassified as T (sales) or excluded entirely (purchases), and the matching amounts are subtracted from the D300 totals during the cross-check to keep the comparison aligned.
• Call-off stock (cos) — stock pickings flag the three call-off scenarios (outbound transfer = tip A; return = tip B motiv 1; partner replacement = tip B motiv 2). The module adds l10n_ro_new_contact and l10n_ro_date_transfer_new_contact on stock.picking to capture the replacement event.
• Interactive report — the bundled anaf_d390_report (account.report.custom.handler) lets accountants drill down from each <operatie> line into the source move lines before generating the XML.
• Rectifying form — the rectificative flag on the wizard sets d_rec in the XML for a corrective filing.
• XSD validation before download — the output is checked against D390.xsd; new schema versions are added as sibling submodules in models/v<N>/.

Configuration

1. Prerequisites

Complete the setup described in the l10n_ro_declaration base module shipped with this one:

• Romanian VAT/CUI on the company.
• At least one ANAF signature under Accounting → Configuration → Romania → ANAF Signatures.
• The company bank account, address, phone and e-mail.

2. Partners

For every partner involved in intra-Community operations:

• Country must be an EU member state (not Romania); the wizard uses _get_l10n_ro_anaf_europe_codes() to validate.
• A valid EU VAT number (with country prefix); the helper _parse_anaf_vat_info() splits the country code from the numeric part to fill tara and codO (ANAF requires the national part only — the prefix is reported separately).
• For non-resident partners, mark them as l10n_ro_partner_type = '3' (Intra-EU). The wizard filters lines to that partner type when computing operation L / A / P / S totals.

3. Tax tags

D390 reads the same Romanian VAT tags used by D300, restricted to the intra-Community lines:

Make sure every intra-EU sale and purchase tax used in your invoices carries the correct tag through the standard ANAF tax report (l10n_ro_account_enterprise).

4. ANAF product codes

For specific reverse-charge product categories (cereals, sugar, etc.) operations are reported under type R. Set the corresponding l10n_ro_anaf_code on the product so the wizard can detect them (category code 21 triggers R; _is_R() in models/v3/d390_*.py).

5. Triangular operations (T)

Triangular operations (Romania as intermediary B in a chain A → B → C, art. 268 alin.(8) lit. b Cod Fiscal) are flagged by the l10n_ro_is_triangular field on the move line. Sales lines carrying that flag are reported under operation type T; the matching acquisition lines are excluded (they are not regular AIC under the triangular regime). See TRIANGULAR_OPERATIONS.md in this readme folder for the complete configuration walkthrough.

6. Call-off stock (cos)

The cos section reports goods placed under the call-off stock simplification, reading data from stock pickings:

• stock.picking._is_outbound_custody_transfer() — initial transfer (tip A).
• stock.picking._is_outbound_custody_return() — goods returning to RO (tip B, motiv 1).
• l10n_ro_new_contact + l10n_ro_date_transfer_new_contact on the picking — customer replacement (tip B, motiv 2). These fields are added by this module on stock.picking.

Custody locations must be configured under l10n_ro_stock_custody (the dependency) before pickings can flow into the cos section.

7. Wizard location

Open the wizard at Accounting → Reports → Romania → D390 Declaration.

After configuration, generate the declaration as described in USAGE.md.

How it works

D390 is exposed in two complementary ways:

• as an interactive report under Accounting → Reports → Romania → D390 (the anaf_d390_report record), which lists every aggregated operation by partner and lets you drill down to the source invoices and pickings;
• as a wizard under Accounting → Reports → Romania → D390 Declaration used to generate the ANAF XML file.

Steps

1. Header fields

   • Declaration / Version — defaults to D390 / Versiunea 4.1.
   • Date From / Date To — defaults to the previous calendar month (D390 is filed monthly, by the 25th of the following month).
   • Signature — pick the ANAF signature configured for the declarant.
   • Rectificativa — tick to emit the corrective form of a previously submitted D390.

2. Get Report — generates the XML, validates it against the ANAF D390.xsd schema and attaches the file to the wizard for download. Internally:

   • The wizard collects every posted invoice in the period with l10n_ro_partner_type = '3' (intra-EU partners).
   • For each move line it classifies the operation using the VAT tax tags (01 → L, 03_1 → P, 20_1 → A, 22_1 → S), the l10n_ro_is_triangular flag (→ T) and the l10n_ro_anaf_code product category (→ R).
   • Lines are aggregated by (partner_vat, operation_type) and rounded.
   • A rezumat block sums all amounts by operation type (bazaL, bazaA, bazaP, bazaS, bazaT, bazaR, total_baza).
   • The cos block is built from outbound custody pickings (transfer / return / partner replacement).

3. D300 cross-check — before emitting the XML, the wizard recomputes the L / A / P / S totals from the D300 tax tags and compares them against the D390 rezumat. If the two do not match within a small rounding tolerance, a UserError is raised listing the differing partners and amounts, so the discrepancy can be fixed in the source documents.

4. Triangular adjustments — lines carrying the l10n_ro_is_triangular flag are excluded or reclassified as T; the matching tag amounts are subtracted from the D300 totals during the cross-check to keep the comparison aligned. See TRIANGULAR_OPERATIONS.md for the full discussion.

5. Validate with DUKIntegrator — run ANAF's local validator before signing.

6. Sign with the digital signature (Sectigo / certSIGN / other token).

7. Upload to ANAF at the Depunere declarații portal under D390.

Generated XML — key fields

• Root <declaratie390> with luna, an, d_rec, totalPlata_A, taxpayer identification (cui, den, adresa, telefon, fax, mail) and declarer info (nume_declar, prenume_declar, functie_declar).
• One <rezumat> child with nrOPI (number of operators), bazaL, bazaT, bazaA, bazaP, bazaS, bazaR, total_baza, nr_pag.
• One <operatie> per (partner, type) combination with tara, codO, denO, tip (L / A / P / S / T / R), baza.
• Optional <cos> entries for call-off stock movements.

Operation types

Screenshots

Captured from a running Odoo instance.

Action run declaration390

Versions

19.0.0.2.0 (2026-05-24)

• Changelog tracking starts at this release.