Kā pārbaudīt e-rēķinu pirms pirmās Peppol nosūtīšanas?

Īsā atbilde: pirms pirmā īstā rēķina vienu un to pašu failu vajag izlaist caur trim atsevišķām pārbaudēm. Peppol specifikācija apraksta sintakses pārbaudi, EN 16931 datu modeļa pārbaudi un Peppol papildu noteikumu jeb CIUS pārbaudi kā atsevišķus slāņus. Tehniski nolasāms XML vēl neapliecina atbilstību. 2026. gada 16. septembrī jālieto versija 3.0.21, kas publicēta 2026. gada 20. maijā un kļuva obligāta 2026. gada 17. augustā, kopā ar 2026. gada 10. aprīlī publicētajiem validācijas artefaktiem 1.3.16. Praksē pārbaudiet četras lietas: pircēja e-adresi un tās shēmas kodu, obligātos rekvizītus, summu ķēdi no rindām līdz apmaksājamai summai un profila identifikatorus. Tikai pēc tam sūtiet testa rēķinu caur Peppol Testbed un pēc tam īstajam pircējam.

Kādām trim noteikumu kopām e-rēķins atbilst vienlaikus?

PDF var izskatīties nevainojams: pareizs logo, precīzas summas, pieklājīgs apmaksas termiņš. E-rēķins tomēr paliek karājoties validācijā. Iemesls ir vienkāršs. E-rēķinam vienlaikus jāatbilst trim noteikumu kopām, kas ir uzrakstītas dažādās vietās un ar dažādu mērķi.

Pirmā ir nacionālās rēķinu prasības. Tās nosaka valsts, kurā rodas nodokļa saistība. Igaunijā, piemēram, PVN likums paredz, ka rēķins parastā kārtībā jāizsniedz septiņu kalendāra dienu laikā un rēķinā jābūt likumā uzskaitītajiem datiem. Tas nemainās atkarībā no tā, vai rēķins ceļo uz papīra vai kā mašīnlasāma datu plūsma. Otrā ir EN 16931 jeb Eiropas e-rēķina datu modelis: tas nosaka, kādiem laukiem un kādai aprēķinu loģikai rēķinā jābūt. Trešā ir Peppol papildu ierobežojumi, kas ir šaurāki par EN 16931.

Igaunijas kontekstā tam ir arī pavisam konkrētas sekas, un tās skar ikvienu Latvijas pārdevēju, kuram ir klienti pāri robežai. Kopš 2025. gada 1. jūlija grāmatvedības kārtotājs, kas komercreģistrā atzīmēts kā e-rēķinu saņēmējs, var prasīt pārdevējam e-rēķinu, un par atbilstošu tiek uzskatīts EN 16931-1 standartam atbilstošs e-rēķins, ja puses nav vienojušās par citu piemērotu standartu. Proti, „pagaidām atsūtīsim PDF“ vairs ne vienmēr ir jūsu izvēle.

Kāpēc sākt ar pircēju, nevis ar XML?

Lielākā daļa pirmo neveiksmīgo sūtījumu neizgāžas aprēķinu, bet adresēšanas dēļ. Tāpēc noskaidrojiet ar pircēju trīs lietas, pirms izstrādātājs ķeras pie XML.

Pirmais ir kanāls. Apstipriniet, ka pircējs saņem rēķinus Peppol tīklā un ka viņa puse ir reģistrēta saņemšanai. Ja pircējs vēlas saņemt arī atbildi uz rēķinu, proti, apstiprinājumu par rēķina statusu, Peppol BIS Billing 3.0 tam ir atsevišķs neobligāts profils 02, kuram vajag savu SMP reģistrāciju. SMP (Service Metadata Publisher) ir reģistrs, kas tīklā pasaka, kādus dokumentus dalībnieks spēj pieņemt. Ar parasto rēķina profilu šī iespēja nenāk līdzi.

Otrais ir e-adrese kopā ar shēmas kodu. Peppol prasa, lai gan pārdevēja, gan pircēja elektroniskā adrese (EndpointID) būtu norādīta un lai tai piesaistītais schemeID būtu no Peppol EAS kodu saraksta; pats atribūts ir obligāts, nevis ieteicams. EAS kodu saraksts ir Peppol uzturēts saraksts, kas pasaka, kāda veida identifikators adresē ir izmantots, proti, reģistrācijas numurs, PVN numurs vai cits. Šeit ir viena svaiga lamatu vieta. Versija 3.0.21 izlaboja nepareizu atsauci uz kodu sarakstu, un līdz ar to tika izņemti 14 EAS kodi, kurus iepriekš tehniski varēja lietot. Ja jūsu ERP partnera kartītē sen mierīgi sēž kāds konfigurēts shēmas kods, pārbaudiet to vēlreiz. Vakar strādājoša vērtība šodien var dot kļūdu.

Trešais ir atsauce. Peppol papildu noteikums PEPPOL-EN16931-R003 prasa, lai rēķinā būtu vai nu pircēja atsauce, vai pirkuma pasūtījuma atsauce, un abu trūkums ir fatal līmeņa kļūda. Pajautājiet pircējam tieši: vai rēķinā liekam pasūtījuma numuru vai norunātu pircēja atsauces (buyer reference) vērtību, un no kuras vietas tā precīzi nāk.

Kas notiek pēc tam, kad ERP rēķinu izsūta?

Ķēde ir īsāka, nekā šķiet. ERP vai grāmatvedības programma nodod rēķina datus pa API jūsu operatoram, kas ir sertificēts piekļuves punkts (Access Point). Operators sagatavo vai pārbauda XML failu UBL formātā, proti, standartizētā XML struktūrā, kādā e-rēķins tiek uzrakstīts. Pēc tam tas izlaiž failu caur validāciju, pēc pircēja e-adreses atrod viņa operatoru un nodod rēķinu Peppol tīklā. Pircēja operators nogādā rēķinu pircēja sistēmā, kur dati nonāk tieši pirkumu rēķinu darbvirsmā. Ja jūsu operators validē rēķinu nosūtīšanas brīdī (sinhronā validācija), kļūdu saņemat atpakaļ uzreiz API atbildē, un tas ir jūsu lētākais tests.

Kuriem rekvizītiem jābūt rēķinā un XML failā?

Izejiet šo sarakstu cauri uz viena īsta rēķina, nevis uz paraugfaila. Peppol BIS Billing 3.0 starp citu prasa:

• specifikācijas identifikatoru un rēķina numuru;
• izsniegšanas datumu un rēķina tipa kodu;
• rēķina valūtu;
• pārdevēja un pircēja nosaukumu, kā arī abu pušu pasta adresi;
• vismaz vienu rēķina rindu.

Papildus tam: kas tika pārdots (preces vai pakalpojuma nosaukums rindā), maksājuma dati, pēc kuriem pircējs samaksā, nodokļa maksātāja reģistrācijas numuri tur, kur tie ir prasīti, un pircēja atsauce vai pasūtījuma numurs. Katrai rēķina rindai jābūt tieši vienai PVN kategorijai. Ja vienā rindā ir sajaukta ar standarta likmi apliekamā un ar nodokli neapliekamā daļa, rinda jāsadala divās.

Kādā secībā Peppol pārbauda summas?

Summu pārbaude nav brīvā formā. Peppol kopsummu ķēde ir obligāta un iet tieši šādi:

1. Rindu neto summa ir visu rēķina rindu neto summu kopsumma.
2. Kopsumma bez nodokļa = rindu neto summa − dokumenta līmeņa atlaides + dokumenta līmeņa papildmaksas.
3. Kopsumma ar PVN = kopsumma bez nodokļa + PVN kopsumma.
4. Apmaksājamā summa = kopsumma ar PVN − priekšapmaksa + noapaļošanas summa.

PVN sadalījums tiek pārbaudīts atsevišķi. Katras PVN kategorijas summai jābūt ar nodokli apliekamā vērtība × likme / 100, noapaļota līdz divām zīmēm pēc komata, un šo summu kopsummai jāsakrīt ar rēķina PVN kopsummu. Izplatītākā kļūda šeit ir tā, ka ERP aprēķina PVN pa rindām un noapaļo katru rindu atsevišķi, bet rēķina kopsavilkums rēķina pa kategorijām. Sanāk viena centa atšķirība, un rēķins neiziet validāciju. Pārbaudiet, pēc kuras loģikas strādā jūsu sistēma, pirms sūtāt.

XML pārbaude: profils, kodi, datumi un noapaļošana

Profila identifikatoriem jābūt tieši tādiem, kā prasa specifikācija. Parastam rēķinam un kredītrēķinam CustomizationID pamatvērtība ir `urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0`, bet ProfileID vērtība ir `urn:fdc:peppol.eu:2017:poacc:billing:01:1.0`. Nepievienojiet tiem pašu izdomātu versijas galotni. Noteikums PEPPOL-EN16931-R004 versijā 3.0.21 tika precizēts, un CustomizationID ar versijas informāciju tagad dod skaidru kļūdas paziņojumu.

Kodi un datumi ir tikpat konkrēti. Valūtas kodam jābūt no spēkā esošā ISO 4217 saraksta. Versija 3.0.21 no tā izņēma ANG un BGN, kā arī pievienoja XCG. Datumi tiek rakstīti pēc specifikācijas semantisko datu tipu prasībām formā YYYY-MM-DD, tādējādi 2026. gada 16. septembris failā ir `2026-09-16`, nevis `16.09.2026`.

Par noapaļošanu ir vērts paturēt prātā vienu lietu. Rindas neto summa, nodokļa kopsavilkuma summas, kopsummas, apmaksājamā summa, kā arī atlaižu un papildmaksu summas drīkst saturēt ne vairāk par divām zīmēm pēc komata. Vienības cenai šāda ierobežojuma nav, dokumentācijā kā piemērs ir vērtība 10000.1234. Precīza vienības cena tātad ir atļauta, bet gala summām jābūt centa precizitātē un savstarpēji jāsakrīt.

Kādā secībā labot kļūdas?

Validācijas rīks atdod trīs veidu kļūdas, un tās ir vērts labot no augšas uz leju:

1. XSD jeb sintakses kļūdas. Fails neatbilst UBL shēmai: elements ir nepareizā vietā, trūkst nosaukumtelpas, vērtībai nepareizs tips. Kamēr tās ir spēkā, pārējās pārbaudes līdz saturam nemaz nenonāk.
2. BR un BR-CO kļūdas. Tās nāk no EN 16931 noteikumiem: trūkst obligāta lauka, salūzis aprēķins, aizliegts kods.
3. PEPPOL un UBL-SR kļūdas. Peppol papildu ierobežojumi un sintakses noteikumi, piemēram, PEPPOL-EN16931-R003 vai atkārtošanās ierobežojumi. Šeit ir arī valstij specifiskie noteikumi.

Skatieties arī brīdinājumus, ne tikai kļūdas. Versijā 3.0.21 noteikumi PEPPOL-COMMON-R052 un R053 no brīdinājumiem tika pārvērsti kļūdās, jo tie tagad ir obligāti visiem profiliem. Šodienas brīdinājums diezgan bieži ir nākamā laidiena kļūda.

Kādu testu kopu izlaist pirms pirmā īstā rēķina?

Viens korekts paraugrēķins neapliecina neko. Sagatavojiet piecus gadījumus un izlaidiet tos visus caur Peppol Testbed vai sava operatora validācijas rīku:

• parasts rēķins ar jūsu valsts standarta PVN likmi;
• rēķins ar dokumenta līmeņa atlaidi vai papildmaksu;
• rēķins, kurā vienlaikus ir vairākas PVN kategorijas (piemēram, standarta likme un ar nodokli neapliekams pārdevums);
• kredītrēķins vai labojuma rēķins ar atsauci uz sākotnējo rēķinu;
• pārrobežu rēķins, ja jūs tādus vispār sūtāt, jo citas valsts pircēja e-adrese, shēmas kods un nodokļu identifikatori uzvedas citādi.

Saglabājiet šos failus. Kad pēc pusgada iznāks jauna validācijas artefaktu versija, jums piecās minūtēs būs skaidrs, vai kaut kas ir salūzis.

Ko sekmīga validācija vēl neapliecina?

Izieta validācija apliecina vienu lietu: fails atbilst sintaksei, EN 16931 datu modelim un Peppol papildu noteikumiem. Tā neapliecina, ka rēķins nonāks galā vai ka pircējs to apmaksās.

Atsevišķi jāpārbauda četras lietas. Vai pircējs tiešām spēj rēķinu saņemt un vai izmantojāt viņa pareizo e-adresi. Vai pircēja iekšējais noteikums prasa pasūtījuma numuru. Nepareizs vai trūkstošs numurs atstāj rēķinu stāvēt viņa apstiprināšanas darbplūsmā, pat ja Peppol bija apmierināts. Vai rēķina saturs atbilst līgumam: cenas, daudzumi, apmaksas termiņš. Un vai nodokļa piemērošana ir pareiza pēc būtības. Validācijas rīks pārbauda, ka PVN aprēķins ir saskaņā ar sevi pašu, nevis to, ka izvēlējāties pareizo PVN kategoriju.

Pirmā nosūtīšana paiet visrāmāk tad, ja ar pircēju vienojaties par vienu konkrētu rēķinu, ko apskatīt kopā: jūs apstiprināt, ka rēķins izgāja un izgāja validāciju, viņš apstiprina, ka rēķins nonāca sistēmā un ir apstiprināšanas ciklā. Pēc tam pārējais ir tikai apjoma jautājums.

Pieejams arī: eesti keeles · English · lietuviškai

Pēdējo reizi pārbaudīts: 2026. gada 16. septembris