„Kohale toimetatud” tähendab Peppol’is kaht eri asja ja enamik integratsioonivigu sünnib nende segiajamisest. Transpordikinnitus – ligipääsupunktide vahel AS4 üle liikuv sõnumitaseme staatus – kinnitab, et saaja ligipääsupunkt võttis sinu dokumendi vastu: marsruutimine töötas, ümbrik valideerus, vastutus läks üle. Ostja kohta ei ütle see midagi. Ärivastus (Invoice Response ehk ostja poolelt tagasi liikuv `ApplicationResponse` UBL-dokument) on see, mis ütleb, kas arve on menetluses, aktsepteeritud või tagasi lükatud. Esimene on süsteemne ja kiire; teine sõltub ostja tarkvarast ja harjumustest ning jääb paljudel turgudel lihtsalt tulemata. Ehita oma staatusemudel selle aususe peale: transpordiseisund on garanteeritud, äriseisund on boonus.
Milliseid seisundeid rakenduses hoida?
Praktiline miinimum on viis: esitatud (API-kutse võeti pärast valideerimist vastu), kohale toimetatud (saaja ligipääsupunkt kinnitas AS4 üle), toimetamine ebaõnnestus (marsruutimis- või transpordiviga – saaja ei pruugi seda dokumenditüüpi üldse vastu võtta), äriliselt aktsepteeritud ja äriliselt tagasi lükatud (Invoice Response’ist, kui see tuleb). Käsitle äriseisundeid valikuliste täiendustena oma ajatemplitega, mitte kohustuslike sammudena ühes torus: arve, mis jääb igaveseks „kohale toimetatud” seisu, on normaalne tulemus turgudel, kus ostjad vastuseid ei saada.
Webhook või pollimine?
Mõlemad, selgete rollidega. Webhook on põhikanal: pakkuja lükkab transpordi- ja ärisündmused sinu otspunkti kohe, kui need juhtuvad; ainus viis saada õigeaegset staatust ilma API-t pommitamata. Staatuse-otspunkti pollimine on võrdluskanal: plaanitud ülekäik, mis püüab kinni kõik, mis webhook’ist mööda läks; sest webhook’id lähevad aeg-ajalt kaduma, ükskõik kui hea pakkuja. Kaks reeglit hoiavad selle töökindlana. Kontrolli allkirju: pakkujad allkirjastavad webhook-saadetised (Finbite’i API näiteks HMAC-iga) ja kontrollimata webhook-otspunkt on lahtine uks võltsstaatustele. Ja tee töötlus idempotentseks: kordussaadetised on disaini osa, sama sündmuse teistkordne töötlemine peab olema ohutu.
Mida tagasilükkamine päriselt ütleb?
Oleneb kihist. Transporditaseme tõrge on taristuline: vale või registreerimata saaja, dokumenditüüp pole vastuvõetav, võrguviga; paranda adresseerimine või kontrolli saaja registreeringut. Äritaseme tagasilükkamine on kaubanduslik: ostja süsteem või raamatupidaja ei võtnud arve sisu vastu; vale tellimuseviide, ootamatud summad, nende sisereeglid. Esimene kuulub sinu arendusjärjekorda, teine sinu kasutaja töövoogu. Nende kahe ühtemoodi kuvamine on koht, kus klienditoe piletid sünnivad.
Does ’delivered’ mean the buyer accepted my Peppol invoice?
No. Transport acknowledgment means the recipient’s Access Point accepted the message. Buyer acceptance or rejection arrives, if at all, as a separate business-level Invoice Response.
What is the difference between MLS and MLR?
Message-level status is the system-generated transport acknowledgment between Access Points; the Invoice Response (business response) is a UBL ApplicationResponse from the buyer’s side stating in-process, accepted or rejected.
Should I use webhooks or polling for Peppol status?
Webhooks as the primary push channel, polling as scheduled reconciliation for anything missed. Verify webhook signatures (e.g. HMAC) and keep handlers idempotent.
Is the business response mandatory on Peppol?
No — adoption varies by market and buyer software. An invoice that remains ’delivered’ without a business response is a normal outcome; model it as such.