Controllo XML autofatture — Luglio 2026

1 · Cosa ho controllato

Due dimensioni indipendenti, spesso confuse tra loro.

2 · Come il codice imposta le DATE

La fonte della data cambia in base al tipo di documento e ai dati che abbiamo. Questa è la parte da tenere d'occhio in fase di verifica.

Autofattura positiva (AF) — cascata _reference_date_for_communication()

La data è la prima disponibile in questa scala di priorità (righe 21-50):

È esattamente il caso «a volte usiamo quella del CSV/fattura, a volte la data delle mail»: se la fattura Airbnb (o il CSV) è stata acquisita si usa la sua data; altrimenti si ripiega sulla data dell'email, poi sulla prenotazione, poi sull'emissione.

Autofattura negativa (AFN / storno)

Qui la logica è diversa e dipende dal fatto che si trovi la comunicazione originale da stornare (_build_afn_context, righe 154-184):

3 · Autofatture negative — dettaglio riga per riga

Tutti i 50 XML con importo totale negativo. Colonna «Meccanismo» = come è stata costruita la collegata; «Data doc = coll» = coerenza tra data del documento e data della fattura collegata.

4 · Distribuzione delle date documento

Le date non sono tutte di luglio: con la nuova logica la Data segue la competenza della prenotazione/fattura originale, non il mese di emissione. La massa è giugno 2026, con code su mesi precedenti (prenotazioni vecchie lavorate ora).

5 · Il caso particolare 07482

L'unico XML negativo che non è uno storno.

Ha numero AF/2026/07/0072 (prefisso AF, non AFN) e importo −150,62 €. È negativo perché la fattura Airbnb sottostante è una nota di credito: AIUC-58458179-IT-3819155-CN-1 (il suffisso CN-1 = Credit Note). Passa quindi dal flusso AF standard — che referenzia sempre il numero fattura Airbnb — ed è corretto: non è un fallback dello storno, è proprio un'altra fattispecie.

6 · Come verificare (per il collega)

1. Nuova modifica vs fallback — apri lo storno e guarda <DatiFattureCollegate><IdDocumento>. Se è AF/AAAA/MM/NNNN → nuova modifica ✓. Se è un codice tipo 85007534IT5804914 → fallback (da controllare, e a DB dovrebbe esserci un alert Sentry).
2. Coerenza date interne — nello stesso XML, DatiGeneraliDocumento/Data deve essere uguale a DatiFattureCollegate/Data. Nella tabella sopra è la colonna «=».
3. Fonte della data (serve accesso ai dati origine) — per una AF positiva la data dovrebbe essere quella della fattura Airbnb/CSV; se manca, quella dell'ultima email CONFIRMED/MODIFIED; poi la prenotazione. Per confermarlo serve incrociare con la fattura PDF / le email / il DB, non basta l'XML.
4. Storni «nuova modifica» — per confermare la data, ritrova a DB l'autofattura originale AF/AAAA/MM/NNNN indicata nella collegata e verifica che la data usata (emissione dell'originale) sia quella attesa.