L'azienda del caso e cosa vuole ottenere
Esempio Caso illustrativo: l'azienda e i suoi dati sono inventati per spiegare il flusso.
Distribuciones Kessel SRL è un'azienda inventata che vende materiale da ufficio ad altre aziende in Belgio e fattura da Odoo 18. Ha appena installato Belgium Peppol B2B E-Invoicing Compliance e vuole inviare le sue fatture tramite Peppol senza perdere di vista cosa è partito, cosa è arrivato e cosa non è andato a buon fine. La sua responsabile amministrativa, Marta, dedica la prima settimana a mettere tutto in ordine. Quello che segue è ciò che fa lei e ciò che vede in ogni elenco.
Primo giorno: il profilo di conformità dell'azienda
Marta parte da Compliance Profiles, dentro Fatturazione. Nell'animazione più sotto, con dati dimostrativi, si vede un profilo dell'azienda Acme Belgium SPRL con il suo ID Peppol, lo stato Completed, la modalità Test / SMK e la casella di uscita spuntata.
Tra gli stati definiti dal modulo c'è un campo state con i valori Draft, In Progress e Completed. Il modulo ha inoltre campi di stato per ogni passaggio, da step_1_state a step_7_state, e ognuno può essere Not Started, In Progress o Completed. Marta si annota questi nomi per riconoscerli quando compaiono e non considera concluso l'avvio finché vede passaggi in Not Started o In Progress.
Secondo giorno: gli ID Peppol dei clienti
Prima di inviare qualsiasi cosa, Marta controlla a chi invierà. Il modulo memorizza un peppol_id_status con questi valori: Not Yet Resolved, Resolved, Not Found, Non-Belgian Scheme e Lookup Failed. Esiste anche un inbound_endpoint_status con Unknown, Resolvable e Not Resolvable.
Il suo criterio è semplice: i clienti in Resolved vanno avanti; quelli che compaiono in Not Found, Lookup Failed o Non-Belgian Scheme li controlla uno per uno prima di fatturarli via Peppol, e quelli ancora in Not Yet Resolved li lascia in sospeso. Le etichette sono quelle letterali del modulo ed è meglio leggerle così come sono, senza tradurle mentalmente in altro.
Terzo giorno: le regole di validazione prima della prima fattura
In Invoicing › Belgium Peppol › Validation Rules Marta trova l'elenco delle regole. Le colonne sono Rule Name, Rule Code, Severity, FR Reference e Active. Nell'elenco quasi tutte bloccano la trasmissione e una è solo un avviso, così sa quali regole fermeranno una fattura e quale si limiterà ad avvisarla.

Non tocca la colonna Active senza sapere cosa fa ogni regola. Se una fattura non passa, il testo esatto dell'avviso è spiegato in i messaggi di errore e gli avvisi del modulo.
La prima settimana: leggere il Transmission Log
Con le prime fatture inviate, l'elenco che Marta apre ogni mattina è Transmission Log. Lì vede il riferimento della fattura, la direzione, l'ID Peppol del destinatario, la data di trasmissione e lo stato.

Il campo status può assumere questi valori: Draft / Validation, Sent, Delivered, Acknowledged, Failed, Received e Manual. C'è inoltre un transmission_status con Sent, Delivered e Failed. La routine di Marta nella prima settimana:
- Filtra per
Failede non chiude la giornata lasciandone qualcuno senza controllarlo. - Controlla quelli ancora in
Draft / Validation. - Apre quelli in
Manuale li verifica uno per uno. - Verifica che i documenti ricevuti compaiano come
Received.
Altri stati che Marta impara a riconoscere
Il modulo usa altri due gruppi di stati. Uno con New, Acknowledged, Resolved e Dismissed, e un altro con Open, Resolved e Past Deadline. La regola che si dà Marta è non lasciare nulla in New a fine settimana e trattare qualsiasi Past Deadline come priorità.
Trova anche un registro con i campi company_id (Company), field_name (Field Name), old_value (Old Value), new_value (New Value), user_id (User), timestamp (Timestamp) e notes (Notes). Marta si segna i nomi delle colonne per leggerle quando le servono e usa Notes per lasciare i suoi commenti.
Archivio e pacchetti di evidenze
In Archive Scans ogni record mostra la data della scansione, il risultato Pass o Fail, il totale dei file e le colonne dei file mancanti e alterati. Marta fa attenzione a qualsiasi Fail e a queste ultime due colonne.
In Invoicing › Evidence Packs c'è l'elenco dei pacchetti di evidenze, con il pulsante New e la colonna Pack Name.

Il modulo definisce gli stati Draft, Generating, Done ed Error per un campo state, e Draft, Running, Done e Partial Success per un altro. Marta non considera concluso nulla che sia in Error o Partial Success.
L'elenco 2028 Readiness
Infine apre Invoicing › 2028 Readiness. È un elenco con codice, titolo, stato di preparazione, tipo e responsabile. Lo stato di preparazione assume i valori Ready, Partial e Gap.

La prima cosa che fa è assegnare un responsabile a ogni elemento, perché nell'elenco risultano vuoti.
Cosa imparare dal caso
- Controlla il profilo di conformità prima di tutto e impara gli stati per passaggio.
- Guarda il
peppol_id_statusdei clienti prima di inviare, non dopo. - Leggi le regole di validazione per sapere quali bloccano e quale si limita ad avvisare.
- Nella prima settimana, il
Transmission Logfiltrato perFailedè il tuo elenco quotidiano. - Assegna i responsabili in
2028 Readinessfin dal primo giorno.
Se vuoi vedere come si incastrano menu e record dietro le quinte, trovi come funziona il modulo in Odoo.
Come ti aiuta FlexigoTech
FlexigoTech implementa Odoo 17, 18, 19 e 20 e sviluppa connettori e integrazioni su misura, quindi possiamo affiancarti in questo avvio o adattare il flusso alla tua azienda. Su Odoo Apps il modulo costa 9 € per versione di Odoo (17, 18, 19 e 20), pagamento una tantum e IVA esclusa; ogni versione di Odoo si acquista lì separatamente. Il servizio locale costa 29 €/mese o 290 €/anno IVA esclusa (Pro: 58 €/mese o 580 €/anno) e, con l'abbonamento, il modulo per le nuove versioni di Odoo è incluso se l'hai acquistato su flexigotech.com. Senza abbonamento, o con il servizio sospeso, si ferma ciò che offre l'abbonamento, ma i dati restano nel tuo Odoo; trovi i dettagli nella pagina del modulo e nella scheda di Odoo Apps.
Continua a leggere
Verificato nel codice del modulo (versione 20.0) e nelle fonti collegate
Fonti
- Codice del modulo: flexigo_belgium_peppol_b2b_e_invoicing_compliance_wizar 20.0 (8c3e3f48): models/be_peppol_configuration_snapshot.py
- Codice del modulo: flexigo_belgium_peppol_b2b_e_invoicing_compliance_wizar 20.0 (8c3e3f48): models/be_peppol_alert.py
- Codice del modulo: flexigo_belgium_peppol_b2b_e_invoicing_compliance_wizar 20.0 (8c3e3f48): models/be_peppol_compliance_profile.py
- Codice del modulo: flexigo_belgium_peppol_b2b_e_invoicing_compliance_wizar 20.0 (8c3e3f48): models/be_peppol_evidence_pack.py
- Codice del modulo: flexigo_belgium_peppol_b2b_e_invoicing_compliance_wizar 20.0 (8c3e3f48): models/be_peppol_fallback_entry.py
- Codice del modulo: flexigo_belgium_peppol_b2b_e_invoicing_compliance_wizar 20.0 (8c3e3f48): models/be_peppol_readiness_item.py
- Codice del modulo: flexigo_belgium_peppol_b2b_e_invoicing_compliance_wizar 20.0 (8c3e3f48): models/be_peppol_transmission_log.py
- Codice del modulo: flexigo_belgium_peppol_b2b_e_invoicing_compliance_wizar 20.0 (8c3e3f48): wizard/be_peppol_batch_evidence_wizard.py
- Codice del modulo: flexigo_belgium_peppol_b2b_e_invoicing_compliance_wizar 20.0 (8c3e3f48): wizard/be_peppol_historical_import_wizard.py
- Codice del modulo: flexigo_belgium_peppol_b2b_e_invoicing_compliance_wizar 20.0 (8c3e3f48): wizard/be_peppol_setup_wizard.py
- apps.odoo.com/apps/modules/20.0/flexigo_belgium_peppol_b2b_e_invoicing_compliance_wizar
- apps.odoo.com/apps/modules/17.0/flexigo_belgium_peppol_b2b_e_invoicing_compliance_wizar
- apps.odoo.com/apps/modules/18.0/flexigo_belgium_peppol_b2b_e_invoicing_compliance_wizar
- apps.odoo.com/apps/modules/19.0/flexigo_belgium_peppol_b2b_e_invoicing_compliance_wizar
- flexigotech.com/en/services.html
- flexigotech.com/precios.html
