ANAF SPV

Wait for SPV's answer to a request_document (a RASPUNS SOLICITARE message carrying its id), checking the list every few seconds for up to wait_seconds. SPV usually answers within two minutes. With download, the answer's document is saved to the outbox as download_message saves it. answered: false means not yet; call again. A client that asks for progress hears the seconds waited; cancelling ends the wait.

Finish a sign-in that waits for its code (login answered awaiting_code, or a tool failed with needs_login): pass the digits of the newest "Cod de siguranta" mail. SPV honours a code for five minutes; only the newest code works.

A filed declaration's state at ANAF and its receipt (recipisa), by its number, from ANAF's public status service (StareD112): no sign-in, nothing changes. The number is the index de încărcare a RECIPISA prints (the middle of its registration number INTERNT-<index>-<year>, also accepted), or the index de depunere submit_declaration answered. Answers status (processing, not_registered, validation_errors, valid) with ANAF's words, the form, the registration number and dates, and saves the signed receipt to the outbox while ANAF serves it (60 days after filing). The service lists a tax id's last 200 filings of the last three months; for an older one it says how to ask SPV for a duplicate. Any form filed electronically, whoever filed it.

Download one message's document (a signed PDF, as SPV serves it) into the downloads outbox, named <posted date>_<type>_<SPV's file name>. Answers the path, size and SHA-256. Saving the same bytes again finds them there (already_there) instead of writing a copy. A file SPV names for another message (another request's id) is refused as wrong_document and not saved.

Whether this server can work: where the SPV credential comes from (a vault MCP, a file, or none), which mail driver reads the e-mailed code (google, text, auto or manual), whether a session is stored and whether a sign-in waits for its code. No network: it never signs in. Run it first, and before concluding the server is broken.

What SPV lets this account request ("Solicitări"), read from the live form: the identities it may request for, and for one of them every document type with the fields it requires or accepts (year, month, registration_number, pui). Among a person's: Obligatii de plata (the statement of what is owed), Nota obligatiilor de plata, Istoric declaratii PF, Duplicat declaratie unica (year), Duplicat Recipisa (registration_number), Venituri Formular Banca, Interogari Banci, certificates. For a person's CNP, the types SPV makes only for a company (Notificare, and any it has refused that way before) are left out of types and listed under cui_only.

SPV's message list ("Mesaje"): every document ANAF has put in the taxpayer's virtual space and not yet archived, newest first: decisions, summonses (SOMATII), notifications, payment confirmations (PLATA), receipts, and the answers to requests (RASPUNS SOLICITARE, with the request's id). Each has a `key` for download_message, the time SPV posted it (deadlines usually run from there) and the time it will be archived, after which it can no longer be downloaded. `types` counts every type in the whole list.

Sign in to SPV now. Rarely needed: every tool signs in by itself when the session is missing or has ended. The server reads the password from its credential source, SPV e-mails a security code, and the mail driver reads it from the mailbox; the answer says signed_in. When no mail driver can read it (manual, or the code did not come in time) the answer says awaiting_code with a deadline: read the newest "Cod de siguranta" mail from Autentificare.SpatiuPrivat@anaf.ro and pass its digits to complete_login. Each sign-in e-mails the user a code.

Sign out at SPV and forget the session here. The next tool that needs SPV signs in again (and SPV e-mails a new code).

When SPV posted documents, from its alert e-mails ("Documente noi SPV" from Portal.ANAF@anaf.ro) in the mailbox its sign-in codes go to: per line the document (with its form, e.g. D256), the day ANAF processed it ("prelucrata la") and when the alert arrived, newest first. SPV drops most documents about two months after posting them, and an act posted there counts as communicated on the day it was made available, so for an archived document these alerts are the lasting record of that date. Reads mail only, never SPV. details matches list_messages' details for a document still listed.

Ask SPV for a document, as its "Solicitări" form does. SPV registers the request (the answer carries its request_id) and posts the document as a RASPUNS SOLICITARE message a minute or two later: call await_reply with the id. The type must be one list_document_types offers this identity, with the fields it requires; a field the type does not take is refused before anything is sent. Free, and changes nothing at ANAF.

Is a session stored, since when, and when it last worked; with probe, loads one SPV page to prove SPV still honours it. Never signs in (every other tool signs in by itself when it needs to).

Send a message through SPV's contact form ("Formular de contact"): a question or request about the taxpayer's own record, registered at ANAF under the account's name and answered later in SPV as RASPUNS SESIZARE FORMULAR UNIC DE CONTACT. By default a DRY RUN: it reads the live form, checks the message against it and answers it exactly as it would go (identity, category, text without diacritics, attachment with its SHA-256), sending nothing. With dry_run: false it sends, once: it answers the registration number, the date and the text SPV shows. The form preselects its first identity, often a company, so cif is required and read back. The same message is not sent twice unless again: true.

File a D212 with ANAF at formularespv-pf, in the account holder's name: the PDF validate_declaration made, and only that (its SHA-256, size and embedded XML are checked against what was validated). Signs in to formularespv-pf by itself (its own session; SPV e-mails a code), uploads, and answers the index de depunere; then waits for SPV's RECIPISA and downloads it with the DECLARATIE. A filed declaration is a fiscal document: it cannot be withdrawn, only rectified. Requires confirm: true; the same bytes are filed once unless refile. A D100, D300 or D112 PDF is checked and refused as unsupported before anything is sent: ANAF takes those only through e-guvernare.ro, signed with a qualified certificate. Moves money or makes a legal document: the client asks the user to approve each call.

Download every message this server has not saved before (oldest first) and remember it, so a scheduled call keeps a complete archive: SPV drops most documents about two months after posting them. Filters narrow what is synced; `limit` caps one call and `remaining` says how many are left for the next. Answers what was saved, with paths and SHA-256. A client that asks for progress hears each document saved; cancelling stops between documents, and the next sync carries on from there.

Validate a declaration's XML with ANAF's own validator for its form and period (DUKIntegrator with the "soft J" jars of ANAF's package for that period, kept in a cache; D212 for reporting years 2020, 2021, 2022, 2023, 2024, 2025; D100 for periods from 01.2024; D300 for periods from 05.2024; D112 for periods from 01.2025), and answer its errors verbatim, with the period, the taxpayer and what it makes payable. With pdf (the default) a valid XML also becomes the filing PDF, saved to the outbox only once its embedded XML is checked to be the validated file byte for byte. D212's period is its reporting year, an_r (2023 declares 2022's income). Files nothing: submit_declaration files a D212; ANAF takes D100, D300 and D112 only through e-guvernare.ro, signed with a qualified certificate, and the answer says so.