Features

• Generic mixin override — extends l10n.ro.anaf.mixin.validate_xml so every wizard built on the shared base (D100, D101, D300, D390, D394, D406, D120, Intrastat, Bilant ...) is validated through DUK automatically; no per-declaration code change required.
• HTTP client to the NextERP DUKIntegrator service — multipart POST to <url>/validate with the declaration code, basename and XML payload, X-API-Key auth, JSON reply parsed into DukValidationResult.
• Verdict persisted on the wizard — duk_state (not_run / valid / invalid / skipped), duk_log (DUK stdout or the infrastructure error), duk_pdf (printable form returned by DUK, stored as attachment) and duk_pdf_filename.
• Inline UI on every wizard — a DUKIntegrator Validation block is injected into the base wizard view, with a coloured badge, the log textarea and a download link for the PDF when the declaration is accepted.
• Soft-fail on production — infrastructure problems (DNS, TLS, HTTP 5xx, timeouts, malformed JSON) become skipped instead of blocking the wizard; the XML is still saved and the user can retry.
• Hard-fail on non-production — neutralized DBs, localhost base URL, test_enable or current_test flags raise UserError on rejection / skip so failures surface immediately during development.
• Per-declaration code override — wizards covering multiple ANAF codes through versions (e.g. l10n.ro.anaf.bilant → S1002/S1014/...) override _get_duk_declaration_code() to send the version-correct -p argument.
• Production-only alert mail — the service's failure email is suppressed (send_alert=false) outside production, so staging reruns never open Helpdesk tickets.
• Bundled defaults via noupdate="1" — URL, timeout and the enable flag are seeded but admin overrides survive upgrades.

Configuration

Go to Accounting -> Configuration -> Settings and locate the ANAF DUKIntegrator Service block in the Fiscal Localizations section. The block is only visible when the current company is set to Romania.

Fill in:

• Enable DUK Validation — master switch. When off, every wizard returns a skipped result without contacting the service.
• Service URL — base URL of the validator (default https://duk.nexterp.ro). Leave empty to bypass validation without touching the enable flag.
• API Key — shared secret sent in the X-API-Key header on every request. The field is masked (password="True").
• Timeout (seconds) — request timeout. SAF-T (D406) validations on large files can take a few minutes; 300 s is a safe default.

Defaults for URL, timeout and the enable flag are seeded by data/ir_config_parameter_data.xml with noupdate="1", so admin overrides survive module upgrades.

How the test-environment detection works

The mixin checks three signals to decide whether the database is a production one. If any of them is true, DUK alert emails are suppressed and validation failures raise immediately instead of being silently logged:

You don't have to configure anything; the behaviour is automatic. A neutralized DB will simply never trigger a Helpdesk ticket from the service even if every declaration in it fails validation.

Storage

DUK results are stored on the wizard record itself (transient model): duk_state, duk_log, duk_pdf (as attachment=True binary) and duk_pdf_filename. There is nothing to clean up; the records are garbage-collected with the standard transient cleanup cron.

How it works

1. Run any declaration wizard

Open any ANAF declaration wizard from Accounting -> Reporting -> Romania (D100, D300, D390, D394, D406, D120, Intrastat ...) and click Execute as you normally would.

Internally:

1. the underlying declaration model builds the XML;
2. the shared l10n.ro.anaf.mixin.validate_xml runs the local XSD check first;
3. this module's override then POSTs the XML to <service_url>/validate with X-API-Key auth, the declaration code (D300, S1002, ...) and the basename <CODE>-<VAT>-<YYYY>-<MM>;
4. the JSON reply is translated into a DukValidationResult and persisted on the wizard.

2. Read the verdict

After Execute, the wizard re-renders with the DUKIntegrator Validation block visible. It shows three pieces of information:

• DUK Validation — coloured badge:
  • Valid (green) — DUK accepted the declaration;
  • Invalid (red) — DUK rejected it; DUK Validation Log contains the rejection reason;
  • Skipped (orange) — infrastructure problem (service down, timeout, missing config), the XML is still saved and you can retry.
• DUK PDF — when DUK accepted the declaration and produced a printable form, click to download.
• DUK Validation Log — DUK's stdout / err.txt on rejection, warnings on success, or the infrastructure error that caused the skip. Hidden when the log is empty or equal to "ok".

The Report File field always carries the generated XML, even on rejection — fix the source data and re-run the wizard, or download the (rejected) XML if you have a reason to.

3. Special cases

• Non-production databases: rejection and skip raise a UserError instead of being silently logged, so the failure surfaces immediately during development.
• Multiple declaration codes per wizard: wizards like l10n.ro.anaf.bilant (mapping to S1002 / S1014 / S1039 / S1070 via the version record) override _get_duk_declaration_code() to send the right -p argument to DUKIntegrator.
• Service outage: turn off Enable DUK Validation from the Accounting Settings to keep generating declarations until the service is back.

Versions

19.0.0.2.4 (2026-05-24)

• Changelog tracking starts at this release.