Ja tev ir e-rēķina XML fails un validācija neiet cauri, tu neesi viens. Lielākā daļa “kāpēc krīt” gadījumu atkārtojas, un, ja zini kur skatīties, labojums parasti ir vienkāršs.
Šis raksts ir praktisks: kontrolsaraksts + 10 biežākās Peppol/EN16931/UBL kļūdas ar skaidru “ko labot” pieeju.
Pārbaudi failu uzreiz: https://www.erekini.eu/peppol-validator
Validācija notiek pārlūkā, fails netiek augšupielādēts.
Ātrs kontrolsaraksts pirms tu meklē dziļas kļūdas
Pirms tu rokies laukos un tagos, pārbaudi šīs lietas. Tas aizņem 1–2 minūtes un bieži atrisina pusi problēmu.
- Vai fails ir UBL 2.1 formātā?
- Vai dokumenta tips ir pareizs: Invoice vai CreditNote?
- Vai ir BuyerReference (ja to prasa tava plūsma)?
- Vai identifikatori ir konsekventi (piegādātājs, pircējs, PVN numuri)?
- Vai summas sakrīt (rindas, PVN, kopsummas)?
- Vai valūta un noapaļošana ir konsekventa visā dokumentā?
Ja pēc šī joprojām krīt, ejam cauri top 10.
1) Nepareizs schemeID (Latvijā bieži jālieto 0188)
Kā tas izskatās: validācija sūdzas par identifikatoru shēmu, EndpointID vai PartyIdentification schemeID.
Kāpēc krīt: Peppol identifikatori prasa korektu shēmas kodu. Ja ieliec “ne to” (vai sistēma to ģenerē kļūdaini), fails var tikt noraidīts.
Ko labot: atrod vietu, kur tiek definēts pircēja/piegādātāja identifikators (EndpointID, PartyIdentification u.c.), un pārliecinies, ka schemeID ir tas, ko izmanto tava apmaiņas plūsma. Ja sistēma ģenerē schemeID automātiski, labojums jātaisa ģeneratorā, nevis katrā failā ar roku.
Pārbaudi: https://www.erekini.eu/peppol-validator
2) Trūkst BuyerReference (vai tas ir tukšs)
Kā tas izskatās: kļūda par obligātu lauku, bieži “BuyerReference is missing”.
Kāpēc krīt: noteiktos scenārijos BuyerReference ir obligāts. Ja lauks ir tukšs, daļa validatoru to skaita kā “nav”.
Ko labot: ieliec reālu atsauci (pircēja norādītu kodu, projekta kodu, līguma numuru, pasūtījuma atsauci). Svarīgi, lai nav tukšs un nav nejaušs “0”.
3) PVN loģika nesakrīt ar rindām
Kā tas izskatās: “TaxTotal mismatch”, “TaxableAmount mismatch” vai PVN summa neatbilst.
Kāpēc krīt: parasti problēma ir:
- PVN rēķināts pirms atlaides, bet rindas ir pēc atlaides
- vairākas PVN likmes, bet kopsumma salikta kā viena
- noapaļošana notiek citā vietā nekā gaida profils
Ko labot: salīdzini rindu summas, PVN bāzi un PVN summas. Ja ir atlaides, pārliecinies, ka PVN tiek rēķināts pēc atlaides un ka kopsummas tiek pārrēķinātas.
4) Kopsummas nesakrīt (LegalMonetaryTotal vs rindas)
Kā tas izskatās: “PayableAmount mismatch”, “LineExtensionAmount mismatch”.
Kāpēc krīt: kopsummām matemātiski jāizriet no rindām + atlaidēm + PVN + papildmaksām. Ja ģenerators vienu no laukiem aizpilda “aptuveni”, validācija to noraida.
Ko labot: pārliecinies, ka:
- rindu kopsumma = visu rindu summa
- bez PVN kopsumma = rindu summa plus/minus allowances/charges
- ar PVN kopsumma = bez PVN + PVN
5) Nepareizs dokumenta tips (Invoice vs CreditNote)
Kā tas izskatās: korekcijas dokuments, bet XML ir Invoice, vai CreditNote bez atsaucēm.
Kāpēc krīt: CreditNote nav “Invoice ar mīnusu”. Profilos bieži ir specifiski noteikumi korekcijām.
Ko labot: ja tas ir kredītrēķins, ģenerē to kā CreditNote un norādi atsauci uz sākotnējo rēķinu, kā to prasa tava plūsma.
6) Nepareizs datumu formāts vai semantika
Kā tas izskatās: “Invalid date format” vai due date pirms issue date.
Kāpēc krīt: datumi ir jānorāda korektā ISO formātā un loģiskā secībā.
Ko labot: pārbaudi IssueDate, DueDate, un, ja lieto, DeliveryDate. DueDate nedrīkst būt tukšs, ja to prasa integrācija.
7) Valūta un noapaļošana nav konsekventa
Kā tas izskatās: mazas neatbilstības centos, valūtas atribūtu kļūdas.
Kāpēc krīt: vienā vietā noapaļo līdz 2 cipariem, citā līdz 4, un kopsummas “nesakrīt”.
Ko labot: vienojies par vienu noapaļošanas pieeju ģeneratorā (noapaļot rindas un summēt, vai summēt un noapaļot beigās). Nejauc abus vienā dokumentā.
8) Piegādātāja/pircēja ID vai PVN numurs neatbilst formātam
Kā tas izskatās: “VAT ID invalid format”, “EndpointID invalid”.
Kāpēc krīt: bieži ir:
- PVN numurs bez valsts prefiksa (LV…)
- sajaukts reģ. numurs ar PVN numuru
- tukšs EndpointID
Ko labot: pārliecinies, ka PVN numurs ir pareizā formātā un ka identifikatori ir aizpildīti tur, kur profils to prasa.
9) Trūkst adreses/valsts kodu, kur tie ir obligāti
Kā tas izskatās: kļūdas par Country, PostalAddress vai trūkstošiem laikiem.
Kāpēc krīt: “visi taču Latvijā” nav arguments validatoram. Dažos profilos valsts kods ir obligāts.
Ko labot: pievieno valsts kodu (LV) un minimālo adreses komplektu tur, kur to prasa tavs scenārijs.
10) Neatļauts elements konkrētajā profilā
Kā tas izskatās: “unexpected element”, “not allowed”.
Kāpēc krīt: Peppol profilā ir noteikts, kādus elementus drīkst lietot. Daži “papildus” lauki ir aizliegti.
Ko labot: nevis dzēs uz dullo, bet saproti, kur ģenerators to ieliek un kāpēc. Ja tas ir “papildus info”, iespējams tam ir paredzēta vieta (piem., Note), bet atkarīgs no profila.
Praktiska pieeja: salabo sistēmu, nevis katru failu
Ja tu katru reizi labo XML ar roku, tu zaudē laiku un kļūdas atkārtojas. Labāks variants:
- Validē failu
- Atrod top 1 kļūdu
- Salabo ģenerēšanu sistēmā
- Validē vēlreiz
- Atkārto līdz ir tīrs
Parasti pietiek ar 2–3 iterācijām.
Pārbaude: https://www.erekini.eu/peppol-validator
Ja e-rēķinus vajag regulāri
Ja validācija ir tikai viens solis jūsu procesā, noderīgi ir visu turēt vienuviet: klienti, rekvizīti, PVN, žurnāli, e-rēķini.
Business plāns: https://www.erekini.eu/app/pricing/
Mini FAQ
Vai mans XML fails tiek augšupielādēts?
Nē, validācija notiek pārlūkā. Failu nesūtām uz serveri.
Kādu dokumentu tipus var pārbaudīt?
Parasti Invoice un CreditNote (atkarībā no faila).
Ko darīt, ja kļūda ir “unexpected element”?
Tā parasti nozīmē neatļautu elementu konkrētajā profilā. Jālabo ģenerators vai jāizņem elements no neatļautās vietas.
