etransport-declare

name	etransport-declare
description	File a Romanian RO e-Transport declaration and obtain a UIT code from transport data found in any source — an email, a PDF invoice, a CMR, a spreadsheet, or the conversation. Use when the user wants to declare a transport, get/generate a UIT, file an e-Transport declaration, or correct an already-issued one. Drives the anafpy MCP tools (etransport_prepare_declaration → etransport_submit).

File an e-Transport declaration

You are filing a legal declaration with Romania's tax authority (ANAF). The flow is: extract the transport data from whatever source the user has → map it onto the structured declaration → etransport_prepare_declaration (composes the XML, returns a preview + confirmation token) → show the preview and get the user's explicit approval → etransport_submit → poll etransport_get_status → report the UIT.

Two rules override everything else:

• Never invent a value. Every field on the declaration must come from the source document or the user. If a required field is missing, ask — do not guess plates, weights, tariff codes, dates, or fiscal codes.
• Never self-approve. etransport_submit files with ANAF. Only call it after the user has seen the preview from prepare and explicitly approved it in this conversation. The confirmation token is single-use and bound to the exact XML — pass back the xml the prepare tool returned, verbatim.

Step 0 — does this transport need declaring at all?

Quick orientation (not legal advice — when unclear, state the rule and let the user decide). RO e-Transport (OUG 41/2022, as amended) requires a UIT for road transports in vehicles with a maximum authorized mass of ≥ 2.5 t carrying goods with total gross mass > 500 kg or total value > 10,000 RON (excl. VAT), when the transport is:

• domestic (TTN) carrying goods on ANAF's high-fiscal-risk list (fruits & vegetables, alcohol, mineral products, clothing/footwear, iron & steel, etc.), or
• international — any goods: intra-community acquisition/delivery (AIC/LIC), import/export (IMP/EXP), lohn (LHI/LHE), call-off stock (SCI/SCE), or intra-community transit with storage/regrouping in Romania (DIN/DIE).

Timing constraints the user must be able to meet:

• The UIT may be obtained at most 3 calendar days before the declared transport_date, and before the vehicle starts moving on national roads.
• The UIT is valid 5 calendar days from the declared transport date (15 days for intra-community acquisitions and call-off stock operations).

Step 1 — check the connection

Call auth_status first. It tells you whether a token is available and — critically — whether the server is on the test or prod environment. On prod this files a real declaration; say so in the approval prompt. If there is no token, stop and tell the user to run anafpy auth login in a terminal (the server cannot do it).

Step 2 — extract and map the data

The source can be anything: a supplier email, an invoice (PDF or e-Factura XML — the efactura_download view exposes parties, lines, quantities, and values), a CMR, a delivery note, a spreadsheet. Read it and fill the declaration below. What each part means:

Field	Required	Notes
operation_type	yes	TTN domestic, AIC/LIC intra-EU in/out, IMP/EXP, LHI/LHE lohn, SCI/SCE call-off stock, DIN/DIE transit storage. Infer from the route (where the goods enter/leave Romania) and confirm with the user.
partner	yes	name, country, fiscal code. Who this is depends on the operation: the foreign seller for AIC/IMP, the foreign buyer for LIC/EXP, the commercial counterparty for TTN.
vehicle	yes	plate, carrier_name/carrier_country/carrier_code, transport_date; trailer1/trailer2 if any. Plates are normalized automatically (spaces/dashes stripped).
start_location / end_location	yes	Exactly one of address (county + locality + street), border_point, or customs_office per end. Which combination each operation type expects is in the rules table below — ANAF rejects mismatches on upload.
goods[]	≥ 1 line	per line: name, operation_scope (usually COMERCIALIZARE; ACELASI_CU_OPERATIUNEA when the scope is the operation itself), quantity + unit_code (UN/ECE: KGM kg, LTR litre, H87 piece), gross_weight (kg), optional net_weight, tariff_code (NC, 4/6/8 digits — copy from the invoice, never guess), value_ron (excl. VAT).
documents[]	≥ 1	the accompanying document: doc_type CMR / FACTURA / AVIZ_DE_INSOTIRE_A_MARFII / ALTELE, with date and number. Cite the actual source document you extracted from.
declarant_ref	no	the user's own reference (order number, file id) — useful for finding the filing later via etransport_lookup.
correction_of_uit	no	set only when correcting an already-issued UIT (see below).

ANAF enforces these cross-field rules on upload (prepare deliberately doesn't — map the data so it survives them):

operation_type	Partner country	operation_scope per goods line	Typical route
TTN (30)	RO only	COMERCIALIZARE, TRANSFER_INTRE_GESTIUNI, BUNURI_PUSE_LA_DISPOZITIA_CLIENTULUI or ALTELE	address → address
AIC (10)	EU, not RO	any scope except the two TTN-only transfers and 9999	border point → address
LIC (20)	EU, not RO	COMERCIALIZARE, GRATUITATI, OPERATIUNI_DE_LIVRARE_CU_INSTALARE, LEASING_FINANCIAR_OPERATIONAL, BUNURI_IN_GARANTIE or ALTELE	address → border point
LHI / SCI (12/14)	EU, not RO	ACELASI_CU_OPERATIUNEA	border point → address
LHE / SCE (22/24)	EU, not RO	ACELASI_CU_OPERATIUNEA	address → border point
IMP (40)	outside the EU	ACELASI_CU_OPERATIUNEA	customs office or border point → address
EXP (50)	outside the EU	ACELASI_CU_OPERATIUNEA	address → customs office or border point
DIN / DIE (60/70)	EU, not RO	ACELASI_CU_OPERATIUNEA	like AIC / like LIC

• Customs offices are import/export only: at the start of an IMP, at the end of an EXP — every other operation uses addresses and border points.
• tariff_code, net_weight and value_ron are required on every goods line except for DIN/DIE, where they may be omitted.
• prior_notifications only for the intra-community operations (AIC/LHI/SCI/LIC/LHE/SCE) — ANAF rejects them elsewhere.
• For TTN, the partner's fiscal code is required: a valid RO code, or PF for a private individual. A RO carrier always needs a valid carrier_code (PF accepted on TTN).

Helpers while mapping:

• etransport_nomenclature lists the accepted values for any enum-coded field (operation_types, operation_scopes, counties, border_points, customs_offices, countries, document_types). Fields accept the member name (TTN, CLUJ, NADLAC) or the ANAF numeric code. kind="unit_codes" lists the closed UN/ECE unit-code list ANAF accepts for goods lines — check it before guessing a unit (kilogram is KGM, piece is H87; KG/PCS don't exist).
• anaf_lookup_taxpayers (no auth needed) verifies a Romanian CUI and returns the registered company name — use it to check the partner/carrier instead of transcribing names from a scan.
• If values are in EUR or another currency, ask the user for the RON value — do not apply an exchange rate yourself.
• Which weight a document states: unless a document explicitly labels its figure otherwise, a weight on an invoice is the net weight of the goods, while a weight on a transport document (CMR, Aviz de însoțire a mărfii) is the gross weight. So an invoice-only source gives you net_weight — ask for the gross rather than reusing the figure, and treat identical gross and net copied from a single document as a red flag to raise in the summary.

Before preparing, show the user a short summary of what you extracted and which fields came from where, flagging anything you had to ask about or that looks off (e.g. gross weight lower than net weight, transport date in the past or more than 3 days ahead).

Step 3 — prepare

Call etransport_prepare_declaration with the declaration (and cif if the filing CIF differs from the configured default). It composes the exact ANAF XML and returns:

• transport_preview — the parsed-back declaration, with computed goods_count and total_gross_weight;
• xml — the exact document that will be filed;
• confirmation_token — single-use, bound to those XML bytes and the CIF.

If valid is false, fix the reported field problems and prepare again. Nothing has been filed yet, and prepare does not validate against ANAF's business rules — there is no standalone validator; ANAF validates on upload.

Step 4 — human approval (hard gate)

Present the declaration with the fixed template below, filled from transport_preview — the declaration parsed back from the XML that will actually be filed — never from your own extraction notes, so the user reviews what ANAF will receive. Then ask for explicit approval. Do not proceed on silence, on a vague "looks good" about something else, or by inferring consent from the original request.

---

### 📋 e-Transport declaration `REVIEW BEFORE FILING`

<🟢 | 🔴> **Environment: <TEST — no real filing | PROD — this files a real declaration with ANAF>**
Filing CIF `<cif>` · Operation **<SIGLA> — <label from etransport_nomenclature>**
Correction of UIT `<uit>`

#### Transport

|---|---|
| Partner | <name> — <country>, <fiscal code> |
| Carrier | <carrier_name> — <carrier_country>, <carrier_code> |
| Vehicle | <plate> + trailer(s) <trailer1>, <trailer2> |
| Transport date | <YYYY-MM-DD> |
| From | <locality, county — street number | border point | customs office> |
| To | <locality, county — street number | border point | customs office> |
| Reference | <declarant_ref> |

#### Goods — <goods_count> line(s) · <total_gross_weight> kg gross · <total value> RON

| # | Goods | Quantity | Gross kg | Net kg | NC code | Value (RON) |
|---|---|---|---|---|---|---|
| 1 | <name> | <quantity> <unit_code> | <gross_weight> | <net_weight> | <tariff_code> | <value_ron> |

#### Documents

<document-type label> no. <number> / <date>; …

⚠️ <flags carried over from step 2, if any>

---

File this declaration with ANAF (<test | prod>)?

Template rules:

• Drop, don't blank: omit the Correction of UIT line, the Reference row, the trailer suffix, and the ⚠️ line entirely when unset; inside the goods table an unset optional cell is —.
• Totals: total value is the sum of value_ron over the lines that carry one — if some lines don't, write <sum> RON (<n> of <goods_count> lines).
• Frame: the horizontal rules and the two-emoji vocabulary (📋 title, 🟢 test / 🔴 prod) are the visual frame that sets the declaration apart from conversation — keep them exactly as templated, and keep the approval question outside the closing rule.
• Scope: when every goods line has the same operation_scope, append it once to the Goods heading (… RON · scope Comercializare); otherwise add a Scope column.
• Post-incident: if post_incident is true, add a bold **Post-incident declaration (declPostAvarie)** line under the environment line.
• Human labels, not member names: render enum-coded values with ANAF's labels from etransport_nomenclature — the operation sigla with its label, goods scopes (Comercializare, Același cu operațiunea), document types (Factura, Aviz de însoțire a mărfii), and border points / customs offices by name.
• Keep everything else verbatim from the preview (plates already normalized, dates ISO).

Step 5 — submit and poll

On approval, call etransport_submit with document={"xml": <the xml from prepare>}, the confirmation_token, the same cif, and confirm=True. A successful upload returns the UIT immediately, but it only becomes valid once processing finishes: poll etransport_get_status with the returned upload_id until the state leaves in prelucrare (usually seconds).

• ok — report the UIT prominently, plus: the declarant must communicate it to the transporter/driver before departure, and its validity window (step 0). Optionally confirm the record via etransport_list or etransport_lookup.
• nok — report ANAF's error messages verbatim, propose the fix, and go back to step 3: the token was consumed, so a corrected filing needs a fresh prepare and a fresh approval.

After filing

• Fix a mistake in an issued UIT: re-run this flow with correction_of_uit set to that UIT (full declaration again, corrected).
• Vehicle broke down / plate changed: etransport_prepare_vehicle_change → etransport_submit (only the plate/trailers change; anything else needs a correction).
• Transport cancelled: etransport_prepare_deletion → etransport_submit.
• Goods received (beneficiary side): etransport_prepare_confirmation with CONFIRMAT / CONFIRMAT_PARTIAL / INFIRMAT.

All of these are two-step gated the same way: preview, explicit user approval, then submit with the token. Present them with step 4's frame, adapted:

---

### 📋 e-Transport <deletion | vehicle change | confirmation> `REVIEW BEFORE FILING`

<🟢 | 🔴> **Environment: <TEST — no real filing | PROD — this files a real <action> with ANAF>**
Filing CIF `<cif>` · UIT **<uit>**

#### Declared transport

|---|---|
| Declarant | <declarant_name> (`<declarant_code>`) |
| Carrier | <carrier_name> — <carrier_country>, <carrier_code> |
| Vehicle | <plate> + trailer(s) |
| Transport date | <YYYY-MM-DD> |
| Route | <start> → <end> |
| UIT valid until | <uit_expiry> |

#### <operation-specific body — see below>

---

<operation-specific approval question, naming the UIT>

• Declared transport is context: fill it from a fresh etransport_lookup on the UIT — never from conversation memory. If the lookup returns nothing, drop the section and say so; do not reconstruct it.
• Deletion body is #### Effect: a bold one-liner — deleting makes the UIT invalid and the transport must not run under it. Question: Delete UIT <uit> with ANAF (<test | prod>)?
• Vehicle change body is #### Vehicle change: a Current → New table for the plate and trailers (current from the lookup, — if unknown; new values bold), plus Changed at: <datetime | now>. Drop the Vehicle row from the context table — it is the Current column. Question: Change the vehicle on UIT <uit> with ANAF (<test | prod>)?
• Confirmation body is #### Confirmation: the type's ANAF label in bold (Confirmat, Confirmat parţial, Infirmat), the note after a dash. Question: File this confirmation for UIT <uit> with ANAF (<test | prod>)?
• Step 4's rules apply unchanged: drop unset lines, human labels, frame kept verbatim, approval question outside the closing rule.