Milliseid teste peab e-arve API läbima enne produktsiooni?

Enne produktsiooni peab e-arve API liidestus läbima neli rühma testjuhtumeid: korrektsed dokumendid (tavaarve, mitmerealine ja mitme käibemaksumääraga arve, dokumendi tasemel allahindlus või lisatasu, ümardamise piirjuhtum, ostja viide versus tellimuse viide, ettemaksuarve, täielik ja osaline kreeditarve), teadlikult vigased dokumendid, marsruudi testid reaalse kontrollitud vastuvõtjani ning talitluslikud testid, mille alla käivad valed volitused, dubleeritud saatmine, kordussaatmine, staatuse pärimine ja päevane võrdlus. Valideerida tuleb kehtiva reeglistiku vastu: Peppol BIS Billing versioon 3.0.21 on kohustuslik kasutada alates 17. augustist 2026. Lisaks tulevad mängu Eesti ja Läti kohalikud kontrollid: kas ostja on e-äriregistris e-arve vastuvõtja ja kas Läti tehingute andmed jõuavad VID-i tähtajaks.

Kas roheline vastus testkeskkonnas tähendab juba valmisolekut?

Meeskonnad loevad liidestuse valmis liiga vara, sest üks samm neljast õnnestus. Tegelikult on need neli sammu üksteisest sõltumatud.

Esiteks koostab teie majandustarkvara andmetest UBL 2.1 formaadis dokumendi. Peppol BIS Billing kasutab UBL 2.1 Invoice ja CreditNote skeeme, seega korrektne XML on skeemi järgi valideeritud dokument, mitte lihtsalt hea väljanägemisega fail. Teiseks saadab teie süsteem selle teenusepakkuja liidesesse. Finbite’i puhul on avalikult viidatud andmevahetuse aadress app.finbite.eu/finance/erp koos WSDL-kirjeldusega, kuid konkreetsed päisväljad ja volitused saate alati oma onboarding-juhendist. Kolmandaks leiab pakkuja ligipääsupunkt (Access Point) vastuvõtja registrist ja edastab dokumendi ostja ligipääsupunktile, kes annab selle üle ostja tarkvarale. Neljandaks suudate te hiljem tõendada, mis dokumendiga täpselt juhtus.

Sammud kaks ja kolm aetakse segamini kõige sagedamini. „API vastas 200″ tähendab, et päring võeti vastu. See ei tähenda, et dokument jõudis ostjani ega et ostja seda oma raamatupidamises kasutada saab.

Millised fikstuurid peavad pakis olema enne produktsiooni puudutamist?

Fikstuurid ehk ette valmistatud näidisdokumendid on kogu asja süda. Ilma nendeta testite juhuslikku valimit sellest, mida teie müügiosakond eelmisel nädalal juhtus arveldama.

Kehtivad juhtumid, mis peaksid pakis olema:

• tavaarve ühe reaga, ühe käibemaksumääraga;
• mitmerealine arve, millel on vähemalt kaks erinevat käibemaksumäära ja korrektne käibemaksu koond;
• dokumendi tasemel allahindlus ja lisatasu koos põhjusega;
• ümardamise piirjuhtum, kus ridade summa ja dokumendi kogusumma lähevad sentides lahku;
• kaks varianti viidetest, millest üks kannab ainult ostja viidet ja teine ainult ostutellimuse viidet. Spetsifikatsioon nõuab, et arvel oleks kas ostja viide (BT-10) või ostutellimuse viide (BT-13);
• manusega arve, kui teie protsess manuseid kasutab;
• ettemaksuarve. Läti puhul tasub siin olla täpne: VID selgitab, et puhtalt informatiivset ettemaksuarvet ei pea e-arvena vormistama ega selle andmeid VID-ile esitama;
• täielik ja osaline kreeditarve viitega algsele arvele, samuti negatiivne arve. Peppol nõuab, et vastuvõttev süsteem toetaks mõlemat parandusmehhanismi, nii kreeditarveid kui negatiivseid arveid.

Teadlikult vigased juhtumid on sama olulised. Minimaalne komplekt: dokument, kus puuduvad nii ostja kui ka tellimuse viide; dokument kehtetu EAS-koodiga; dokument, mille käibemaksu koond ei klapi ridadega; ja dokument, mille CustomizationID sisaldab versiooninumbrit. Viimast kontrolli täpsustati 3.0.21 väljalaskes ja tegemist on fataalse veaga. Iga vigase juhtumi juurde kirjutage, millist veakoodi te ootate. Kui ootuse ja tulemuse vahel on vahe, on teie valideerija vale versiooniga.

Millise reeglistiku versiooni vastu valideerida?

Peppoli kontroll on kihiline: esmalt XML-i süntaks ja UBL-i struktuur, siis EN 16931 semantilised reeglid, siis Peppoli enda CIUS-reeglid ja lõpuks riigipõhised reeglid, mis käivituvad müüja riigikoodi järgi. Parandage vigu samas järjekorras. XSD-viga tähendab, et dokumendi struktuur on katki. BR-koodiga algavad vead viitavad Euroopa standardi sisulisele reeglile (näiteks summade või käibemaksu loogikale), PEPPOL-eesliitega koodid Peppoli lisakitsendusele ja riigikoodiga reeglid kohalikule nõudele. BR-vea parandamine enne XSD-vea kõrvaldamist on ajaraiskamine, sest järgmine kiht ei jõuagi töösse.

Versioon loeb. 3.0.21 avaldati 20. mail 2026 ja see kasutab UBL-i ning CII valideerimisartefakte versioonis 1.3.16, mis avaldati 10. aprillil 2026. Sama väljalase parandas EAS-koodiloendi ja eemaldas 14 kasutuskõlbmatut koodi ning muutis reeglid PEPPOL-COMMON-R052 ja PEPPOL-COMMON-R053 hoiatustest vigadeks kõigi profiilide jaoks. Tõlkes: identifikaatorite fikstuurid, mis eelmisel aastal andsid kollase hoiatuse, võivad täna dokumendi tagasi lükata. Käivitage valideerija lokaalselt, oma CI-s, ja fikseerige artefaktide versioon konfiguratsioonis, mitte arendaja sülearvutis.

Miks ei piisa ainult XML-i testimisest?

Vormiliselt korrektne arve, mis läheb valele vastuvõtjale, on halvem kui tagasilükatud arve. Kontrollige eraldi:

• Vastuvõtja identifikaator ja skeem. Kas te ehitate Peppol-ID õigest registrikoodist või käibemaksunumbrist ja õige EAS-skeemikoodiga? Siia lisage negatiivne test eemaldatud koodiga.
• Vastuvõtja võimekuse päring. Enne saatmist tuleb registrist küsida, kas adressaat üldse võtab vastu selle dokumendiliigi. Kui teie süsteem seda ei tee, avastate vea kliendi käest.
• Profiili valik. Vaikimisi kasutate profiili 01 (Billing). Uus valikuline profiil 02 ehk Billing with Response nõuab eraldi SMP-registreeringut. SMP on avalik register, kus on kirjas, mida vastuvõtja vastu võtta suudab. Testige seda profiili ainult siis, kui nii saatja kui saaja on sellele registreeritud.
• Kohaletoimetamine päris vastuvõtjani. Vähemalt üks dokument peab liikuma lõpuni teie kontrolli all olevasse kontosse või koostöövalmis partnerini, kes kinnitab, et andmed avanesid tema tarkvaras loetavalt.

Milliseid tõrkeid tuleb ise tekitada enne, kui klient need avastab?

Produktsioonis tekivad vead, mida testkeskkond ei tekita. Need tuleb ise tekitada:

• valed või aegunud volitused: kas viga logitakse arusaadavalt ja kas saatmine peatub, mitte ei jää lõputult kordama;
• vigane päring (puuduv kohustuslik väli, katkine XML): kas teie pool eristab „meie viga” ja „pakkuja viga”;
• ajalõpp ja katkenud ühendus: kas kordussaatmine on ohutu ja kas sellel on ülempiir;
• dubleerimise vältimine: sama arvenumbri teistkordne saatmine ei tohi tekitada ostjale kahte arvet. Kuidas pakkuja korduspäringut käsitleb, on iga pakkuja enda lepinguline detail, seega küsige see kirjalikult üle ja ärge jääge eeldama;
• staatuste eristamine: vahepealne staatus („töötluses”) ei ole lõppstaatus. Salvestage pakkuja poolne dokumendi tunnus iga saadetise juurde, muidu ei ole hiljem millegagi vaielda;
• päevane võrdlus: ERP-s saadetuks märgitud arvete arv versus pakkuja logi. Erinevus, mida keegi ei vaata, kasvab vaikselt.

Millised raamatupidamise stsenaariumid paljastavad nõrga liidestuse?

Enne go-live’i võtke kaks tundi raamatupidaja aega. Testige numeratsiooni järjepidevust, käibemaksu ja kogusummade kokkulangevust ERP-i ja saadetud faili vahel, ostja viite nähtavust ostja poolel, kreeditarve seotust algse arvega, manuste jõudmist kohale ning inimloetavat kuju. Viimane ei ole kosmeetika: Rahandusministeerium rõhutab, et algdokument peab võimaldama igal lugejal tehingu sisust aru saada, mistõttu praktikas liigub masinloetava e-arve kõrval sageli ka PDF.

Minge live’i väikese ja jälgitava vooruga

Külmutage testitud mapping ja valideerija versioon. Kinnitage produktsiooni volitused ja vastuvõtjate andmed. Saatke esimesel päeval käputäis päris arveid, mida te ise jälgite, ja võrrelge õhtul pakkuja ning ERP-i kirjeid. Määrake nimeliselt, kes tagasilükatud dokumendi järgmise tööpäeva hommikul üles võtab.

Eesti kliendi puhul lisage väljalaskekontrolli üks päring: kas ostja on end e-äriregistris e-arve vastuvõtjaks registreerinud. Alates 2025. aastast on igal sellisel raamatupidamiskohustuslasel õigus e-arvet nõuda (RPS § 7¹ lg 7). Sama allikas ütleb selgelt, et Eesti lähtub formaadivabadusest: nii Eesti kui Euroopa standard on lubatud. Seega ei tasu kodeerida eeldust, et ainus õige väljund on Peppol.

Läti kliendi puhul on kalender teine. Lätis registreeritud ettevõtete arved avaliku sektori saajatele peavad olema struktureeritud e-arved alates 1. jaanuarist 2025, ja alates 1. jaanuarist 2026 tuleb B2G, G2B ja G2G tehingute e-arve andmed esitada ka VID-ile, hiljemalt viie tööpäeva jooksul arve saatmisest. Välisriigi ettevõttel seda VID-i esitamiskohustust praegu ei ole. Kohustuslik B2B struktureeritud arvete ringlus ja andmete esitamine lükkus 1. jaanuarile 2028, mitte 2026. aastasse, nagu esialgu plaaniti. Praktiline testjuht: saatke arve, salvestage saatmise ajatempel ja kontrollige, et teie süsteem oskab näidata, millised Läti arved on VID-ile esitatud ja millised on viie tööpäeva piiri sees veel lahtised.

Loe ka: English · latviski

Viimati kontrollitud: 21. september 2026