Kontroller CustomizationID og ProfileID hver for seg
Spesifikasjonsidentifikatoren angir regelsettet, mens profilidentifikatoren angir prosessen.
CustomizationID og ProfileID finnes begge høyt i en UBL-faktura, men de beskriver forskjellige forhold. CustomizationID identifiserer spesifikasjonen; ProfileID identifiserer forretningsprosessen. Feil i én av dem skal ikke repareres ved å kopiere verdien fra den andre.
OpenPeppols feltbeskrivelse knytter CustomizationID til semantikk, forekomst og forretningsregler. ProfileID skal hjelpe mottakeren å behandle dokumentet i riktig prosess. Standardverdien for vanlig fakturering er ikke et vilkårlig versjonsnummer som avsenderen kan øke ved hver oppgradering.
Kontroller en eksport fra to systemer
Dette er en syntetisk sammenligning av testfiler, ikke en komplett XML-faktura.
| Testfil | CustomizationID | ProfileID | Beslutning |
|---|---|---|---|
| A | Publisert Billing 3.0-identifikator | Publisert profil 01-identifikator | Valider videre mot avtalt prosess |
| B | Samme spesifikasjonsidentifikator | Intern kode FAKTURA | Rett eksportens profilverdi |
| C | Identifikator med lokalt release-suffiks | Profil 01 | Kontroller mot gjeldende identifikatorregel |
For vanlig profil 01 viser dokumentasjonen urn:fdc:peppol.eu:2017:poacc:billing:01:1.0. Den publiserte spesifikasjonsidentifikatoren begynner med urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0. Bruk hele den aktuelle regelen når verdien kontrolleres; ikke godkjenn en vilkårlig tekst bare fordi begynnelsen ligner.
Hold release og prosess atskilt
En ny valideringsutgave kan endre kodelister eller kontroller uten at dere skal legge måneden inn i XML-identifikatoren. Registrer derfor regelutgaven i testprotokollen, sammen med validatorversjon og filens kontrollsum. Da kan dere gjenskape resultatet uten å endre fakturaens identitet.
May 2026-utgaven beskriver også profil 02 for fakturering med svar og særskilt SMP-registrering. Ikke bytt til denne profilen bare for å få en kvittering; avklar at både avsender og mottaker støtter den aktuelle prosessen.
- Les identifikatorene direkte fra XML, ikke bare en PDF-visning.
- Kontroller at aksesspunktets metadata stemmer med dokumentet.
- Test både faktura og kreditnota hvis begge brukes.
- Avvis interne systemkoder i standardiserte identifikatorfelt.
Godkjenningsgrensen
Riktige identifikatorer beviser ikke at beløp, avgiftskategori eller referanser er korrekte. De avgjør hvilket regelgrunnlag som skal brukes. Neste kontroll er derfor hele dokumentets validering og den avtalte mottaksprosessen.
Les hvordan regelutgaver prøves.
En ny testprotokoll bør omfatte identifikatorene i både dokument og transportmetadata. Hvis bare XML kontrolleres, kan en uoverensstemmelse med sendingens deklarerte prosess bli oversett. Be om at aksesspunktet forklarer hvilken dokumenttype og prosess som faktisk brukes i registrering og levering av prøvefilen.
Kilder
Når spørsmålet gjelder valg mellom eksisterende fakturaformater, bruk overgangen for E2B og EDIFACT. Et lovbestemt formatvindu og en teknisk profilidentifikator avgjør forskjellige spørsmål.