Ja tu strādā ar e-rēķiniem, “BIS Billing 3.0” var izklausīties kā kaut kas, kas interesē tikai integratorus. Realitātē tas ir vienkāršāk: tas ir noteikumu kopums, kas pasaka, kādi dati e-rēķinā ir jābūt, lai saņēmēja sistēma to pieņemtu un varētu apstrādāt automātiski.
Šajā rakstā mērķis ir viens: iedot praktisku kontrolsarakstu, ko vari izmantot, lai:
- saprastu, kāpēc fails krīt,
- ko pārbaudīt ģenerēšanā,
- un kā ātri testēt, pirms sūti.
Ja tev jau ir XML fails, pārbaudi to šeit:
https://www.erekini.eu/peppol-validator
Validācija notiek pārlūkā, fails netiek augšupielādēts.
Kas īsti ir BIS Billing 3.0 (vienkārši)
BIS Billing 3.0 ir Peppol e-rēķinu profils, kas balstās uz:
- UBL 2.1 (XML struktūra)
- EN16931 (semantika un prasības laukiem)
Praktiski tas nozīmē:
- noteikts, kur “dzīvo” pircējs, piegādātājs, rindas, summas, PVN
- noteikts, kādas vērtības ir obligātas
- noteikts, kā loģiski jāsakrīt summām un nodokļiem
Kāpēc e-rēķini krīt: 3 īstie iemesli
Lielākā daļa neveiksmju nav “mistika”, bet:
- Trūkst kritiska lauka
- Identifikatori ir nepareizā shēmā / nepareizā vietā
- Matemātika nesakrīt (rindas, PVN, kopsummas)
BIS Billing 3.0 ir stingrs tieši šajās vietās.
Kontrolsaraksts: minimālais komplekts, lai fails parasti ietu cauri
Šis nav “pilns standarts”, bet ir praktiskais minimums, ko pārbaudīt uzņēmuma sistēmā.
1) Dokumenta pamati
- Dokumenta tips: Invoice (vai CreditNote, ja korekcija)
- Rēķina numurs (unikāls)
- Izrakstīšanas datums
- Valūta (parasti EUR)
Biežākā kļūda: CreditNote tiek ģenerēts kā Invoice ar negatīvām rindām, un profils to negrib.
2) Piegādātājs (Supplier)
- Nosaukums
- Reģistrācijas numurs (korekti ielikts pareizajā laukā)
- PVN numurs (ja ir PVN maksātājs)
- Valsts kods (LV)
Biežākā kļūda: PVN numurs bez “LV” prefiksa vai sajaukts ar reģ. numuru.
3) Pircējs (Customer)
- Nosaukums
- Identifikators (ja prasa plūsma)
- Adrese / valsts kods
Biežākā kļūda: pircēja identifikators ielikts ar nepareizu schemeID.
4) BuyerReference (atsauce)
Dažās plūsmās BuyerReference ir obligāts un bez tā krīt.
Praktiska pieeja: ja klientam nav specifiskas atsauces, izmanto:
- līguma numuru
- projekta kodu
- pasūtījuma numuru
Svarīgi: lai nav tukšs.
5) Rindas (Invoice lines)
Katrai rindai parasti jābūt:
- aprakstam
- daudzumam un mērvienībai (ja lieto)
- vienības cenai
- rindas summai
- PVN kategorijai/likmei
Biežākā kļūda: rindas summa un aprēķins nesakrīt pēc atlaidēm.
6) PVN loģika
PVN ir vieta, kur krīt visbiežāk.
Pārbaudi:
- PVN bāze (TaxableAmount)
- PVN summa (TaxAmount)
- PVN likme un kategorija konsekventa rindās un kopsummās
Biežākā kļūda: kopsummā PVN ir “viens”, bet rindās ir miksētas likmes.
7) Kopsummas (Totals)
Šeit BIS Billing 3.0 ir nepielūdzams.
Pārbaudi:
- bez PVN kopsumma
- PVN kopsumma
- apmaksājamā summa
Biežākā kļūda: noapaļošana tiek darīta dažādos līmeņos (rindas vs kopsumma), un sanāk centu atšķirības.
Kur uzņēmumi visbiežāk iekrīt Latvijā
schemeID un identifikatori
Ja tev ir kļūdas par schemeID, izlasiet arī šo:
/app/blog/schemeid-0188-latvija-peppol/
Peppol XML kļūdas (pilns saraksts)
Ja gribi top 10 ar labojumiem:
/app/blog/peppol-xml-kludas-validacija/
Kā ātri pārbaudīt failu pirms nosūtīšanas
Vienkāršākā plūsma, lai taupītu laiku:
- ģenerē XML
- ielādē validatorā
- izlabo ģeneratoru (nevis failu ar roku)
- validē vēlreiz
Pārbaude:
https://www.erekini.eu/peppol-validator
Kad ir jēga no sistēmas, nevis “vienreizēja labojuma”
Ja tu validē vienu failu reizi mēnesī, var arī ar vienkāršu pārbaudi pietikt.
Ja tu validē regulāri (vai kāds tavā uzņēmumā to dara), tad vērtība ir:
- sakārtotas klientu kartītes
- veidnes
- PVN un žurnāli
- e-rēķini vienuviet
Business plāns: https://www.erekini.eu/app/pricing/
Mini FAQ
Vai BIS Billing 3.0 = EN16931?
EN16931 ir “semantiskais kodols”, BIS Billing 3.0 ir profils, kas to ieliek konkrētā Peppol rāmī.
Kāpēc fails krīt, ja man “vizuāli” viss ir pareizi?
Jo XML nav tikai teksts. Tur ir struktūra, shēmas, identifikatori un matemātika. Validatorā šīs lietas uzreiz izlec.
Kā pārbaudīt bez reģistrācijas?
Pārbaude te: https://www.erekini.eu/peppol-validator
