Ja Peppol XML validācija krīt, schemeID ir viens no biežākajiem iemesliem. Tas nav “sīkums”, jo ar to tiek pateikts, kāda veida identifikatoru tu sūti: uzņēmuma reģistrācijas numuru, PVN numuru, vai kādu citu identifikatoru konkrētā shēmā.
Šajā rakstā es iziešu cauri praktiski:
- kas ir schemeID,
- kur tas dzīvo XML failā,
- kāpēc Latvijā bieži runā par 0188,
- kā labot, lai validācija beidzot iet cauri.
Ja gribi uzreiz pārbaudīt failu: https://www.erekini.eu/peppol-validator
Validācija notiek pārlūkā, fails netiek augšupielādēts.
Kas ir schemeID vienā teikumā
schemeID ir shēmas kods, kas paskaidro, kā interpretēt identifikatoru.
Piemēram, ja tu nosūti “4000…”, bez schemeID tas var nozīmēt jebko. Ar schemeID tu pasaki: “tas ir šī tipa identifikators”.
Peppol ekosistēma shēmas uztver ļoti nopietni, jo tā ir daļa no “vai mēs vispār saprotam, kas tu esi”.
Kur schemeID parādās Peppol XML
Atkarībā no ģeneratora un profila, schemeID var parādīties vairākās vietās. Praktiski biežākās ir:
- EndpointID (piegādātāja vai pircēja endpoint identifikators)
- PartyIdentification/ID
- dažreiz arī citos identificējošos laukos, atkarīgs no tā, ko tu sūti
Svarīgi: kļūda par schemeID var izskatīties tā, it kā problēma ir “pircējs” vai “piegādātājs”, bet patiesībā tā ir tikai shēma pie viena no ID.
Kāpēc Latvijā tiek minēts 0188
Latvijā un Baltijā praksē bieži sastopams scenārijs, kur Peppol plūsmā identifikatoram jābūt ar konkrētu shēmu. Ja ģeneratoris ieliek citu (vai vispār ieliek nepareizu shēmu), validators to noraida.
Te ir galvenā doma:
- tu vari sūtīt pareizu numuru,
- bet, ja schemeID ir nepareizs, sistēma to interpretēs nepareizi,
- un rezultāts ir “validācija krīt”.
Kā izskatās tipiska kļūda
Simptomi, ko parasti redz:
- “Invalid schemeID”
- “Identifier scheme not allowed”
- “EndpointID scheme not supported”
- “Party identifier invalid”
Un tas bieži parādās kopā ar paziņojumu, kurš elements “vainīgs” (EndpointID vai PartyIdentification).
3 biežākie iemesli, kāpēc schemeID ir nepareizs
1) Ģenerators “paņem pēc noklusējuma” shēmu
Daudzas sistēmas izmanto defaultu shēmu, kas nav paredzēta tavai plūsmai.
Ko darīt: schemeID jāiestata kontekstā, nevis globāli. Pircēja un piegādātāja puse var atšķirties.
2) Sajaukti identifikatori (PVN nr vs reģ. nr)
PVN numurs un uzņēmuma reģistrācijas numurs nav viens un tas pats, un tos nevar ielikt vienā laukā ar vienu shēmu “uz visiem laikiem”.
Ko darīt: nošķir, kur sūti PVN numuru un kur sūti juridisko identifikatoru. Ja tu lieto vienu lauku visam, validācija bieži krīt.
3) Vairākas vietas XML, bet salabota tikai viena
Tu salabo EndpointID, bet PartyIdentification/ID paliek ar veco schemeID. Validatorā tas izskatās kā “atkal krīt, bet taču laboju”.
Ko darīt: pārbaudi, vai schemeID nav dublēts vairākās vietās.
Kā salabot (praktiska secība)
1) Validē un atrodi tieši, kurā laukā krīt
Atver https://www.erekini.eu/peppol-validator, augšupielādē failu un paskaties, kur tieši kļūda tiek pieminēta:
- EndpointID?
- PartyIdentification?
Tas nosaka, kur labot.
2) Salabo ģeneratorā, nevis failā ar roku
Ja tu labo XML failu manuāli, nākamais fails atkal būs nepareizs.
Pareizā pieeja:
- atrodi, kur sistēmā tiek veidots party ID
- nosaki, kādu identifikatoru sūti
- piešķir pareizo schemeID tur, kur tas tiek ģenerēts
3) Validē vēlreiz
Pēc labojuma vienmēr pārbaudi vēlreiz. schemeID kļūdas parasti pazūd uzreiz, ja tiešām salaboji pareizo vietu.
Ātra diagnostika: pircējs vai piegādātājs?
Ja neesi drošs, kuru pusi tu labo, izmanto šo loģiku:
- ja kļūda parādās pie laukiem, kas sākas ar “AccountingSupplierParty” → piegādātājs
- ja pie “AccountingCustomerParty” → pircējs
Dažādi ģeneratori šo nosaukumu var paslēpt, bet būtība ir: kļūdas vienmēr ir piesaistāmas vienai pusei.
Ko darīt, ja tu nesaņem endpoint datus no klienta
Dažiem uzņēmumiem trūkst sakārtotas informācijas par klientu identifikatoriem, un sistēma ieliek “kaut ko”, lai tikai aizpildītu lauku.
Šādā gadījumā:
- vispirms definē minimālo “klienta kartīti” (ID, PVN, adrese),
- un tikai tad ģenerē Peppol.
Pretējā gadījumā tu turpināsi cīnīties ar schemeID/ID kļūdām atkal un atkal.
Ja e-rēķini ir regulāri, nevis vienreizēji
Ja tev e-rēķini ir process, nevis vienreizēja validācija, tad svarīgākais ir:
- klientu datu konsekvence,
- veidnes,
- PVN plūsma un pārskati.
Business plāns ir paredzēts tieši šim: https://www.erekini.eu/app/pricing/
Mini FAQ
Vai 0188 vienmēr ir pareizā atbilde?
Nē. Pareizais schemeID ir atkarīgs no tā, kādu identifikatoru tu sūti un kādā plūsmā. Šis raksts palīdz atrast tieši, kur un kāpēc krīt.
Vai pietiek salabot tikai vienu lauku?
Ne vienmēr. schemeID var būt vairākās vietās, un jālabo visas, kas attiecas uz nepareizo identifikatoru.
Vai varu pārbaudīt failu bez reģistrācijas?
Jā. Pārbaude: https://www.erekini.eu/peppol-validator
