Peppol & e-facturatie
Peppol: XML-tekst
Zie je & in een Peppol-XML-bestand waar je een ampersand verwacht? Dat kan de juiste schrijfwijze zijn. De beslissende vraag is welke tekst na het uitlezen van het bedoelde veld overblijft. Een bestand dat als XML opent, kan nog steeds een andere tekst bevatten dan je wilde doorgeven.
Kort antwoord
Bewaar de bedoelde tekst, de oorspronkelijke XML en de teruggelezen veldinhoud naast elkaar. Beoordeel de schrijfwijze in de context van XML. Vergelijk daarna de inhoud met de afspraak en vraag afzonderlijk om volledige factuurvalidatie.
Kies eerst het tekstveld
De huidige OpenPeppol-syntax voor BT-22 beschrijft de factuurnotitie als tekst over de factuur als geheel. Ze staat als cbc:Note direct onder Invoice en gebruikt het datatype Text. In deze uitleg onderzoeken we alleen die plaats in eigen onvolledige UBL Invoice-fragmenten.
Een gelijknamige notitie bij een factuurregel is een andere plek. Lees daarvoor de controle van documentnotitie, regelnotitie en bovenliggende groep. De vraag in dit artikel is vervolgens hoe bijzondere tekens in één gekozen tekst worden geschreven en teruggelezen, niet hoeveel notities jouw factuur moet bevatten.
Een ampersand heeft in XML een schrijfwijze
XML1.0, onderdeel 2.4, onderscheidt gewone tekst van markup. In gewone tekst tussen tags, buiten een CDATA-sectie, moeten een ampersand en een kleiner-dan-teken passend worden weergegeven, bijvoorbeeld als & en <. In onze proef gebruiken we ook > voor het groter-dan-teken.
Die schrijfwijzen betekenen niet automatisch dat de ontvanger de letters amp of lt hoort te lezen. Onderdeel 4.6 beschrijft de vooraf gedefinieerde entiteiten. Houd wel de context vast: een XML-tag heeft zelf haakjes nodig. Onze uitleg over gewone veldtekst is geen opdracht om alle haakjes of ampersands in een bestand blind te vervangen.
Eigen proef XT3010: drie tekstvarianten
We spreken zelf de fictieve notitietekst Werk & service <extra> af. A, B en C zijn drie alternatieven voor dezelfde tekstplaats. Iedere eigen test heeft een Invoice-wortel en de bijbehorende UBL- en cbc-namespace. Hieronder staat alleen de geschreven inhoud tussen de Note-tags. De fragmenten missen bewust andere factuurgegevens.
| Eigen XML-tekst | Onze controle |
|---|---|
AWerk & service <extra> | Niet als XML gelezen. Geen notitietekst teruggelezen. |
BWerk & service <extra> | Gelezen tekst past bij onze afspraak: Werk & service <extra>. |
CWerk &amp; service &lt;extra&gt; | XML gelezen, maar de tekst bevat letterlijk &, < en >. Dat past hier niet. |
We hebben alle drie de eigen fragmenten streng laten lezen met ElementTree en libxml2, met dezelfde vooraf vastgelegde verwachtingen. A levert bij beide een XML-leesfout op. B en C worden wel gelezen: twee van drie. Alleen B levert onze afgesproken tekst op: één van drie. Deze telling beschrijft onze proef, geen foutpercentage van Peppol.
Lees de inhoud terug, niet alleen de broncode
Bij B staat in de XML-bron &; na het lezen staat op die plaats een ampersand. Bij C staat daar &amp;; na het lezen blijft de letterlijke reeks & over. De bron heeft dus nog een extra representatiestap gekregen. Hetzelfde verschil komt in onze proef bij de hoekhaken terug.
C is in onze situatie verkeerd omdat de afgesproken tekst de tekens zelf bevat. Wilde iemand juist letterlijk de reeks & uitleggen, dan zou een andere afspraak gelden. Noem een gevonden reeks daarom niet zonder inhoudelijke vergelijking een fout. Controleer wat de auteur bedoelde en welk veld werkelijk is uitgelezen.
Vergelijk met de afgesproken tekst
Zet op je eigen werkblad drie kolommen: gewenste inhoud, geschreven XML op de bedoelde plaats en teruggelezen inhoud. Bewaar daarbij conceptversie en veldpad. Een schermafbeelding uit een broncode-editor kan de geschreven referenties tonen; een inhoudsviewer kan de gelezen tekens tonen. Vraag welke weergave je bekijkt voordat je conclusies trekt.
De BIS-uitleg over Text beschrijft tekstinhoud en ook het behoud van regelafbrekingen. Daaruit volgt geen door ons geteste weergave in een boekhoudpakket. Bij een echte controle vergelijk je de teruggelezen tekst en de leesbare factuur van dezelfde versie. Wij hebben hier geen viewer, pdf of ontvangend pakket getest.
Herstel de bron en bewaar de oude export
Een bruikbare vraag over C luidt: “Wij verwachten een ampersand en hoekhaken in de notitie; de gelezen inhoud bevat nu letterlijk de referentieteksten. Welk invoerveld en welke exportstap bepalen dit?” Voeg het bedoelde veldpad en de oorspronkelijke versie toe. Vermijd een algemene melding dat alle bijzondere tekens verkeerd zijn.
Laat de verantwoordelijke broninvoer of exportkoppeling onderzoeken en maak daarna een nieuw concept. Alleen de zichtbare pdf wijzigen zegt niet wat de volgende XML-export bevat. Bewaar oud en nieuw met hun eigen status. Voer geen algemene zoek-en-vervangactie uit op een reeds verzonden factuur op basis van onze drie oefenfragmenten.
Een leesbaar fragment is geen gevalideerde factuur
OpenPeppol beschrijft afzonderlijke validatiestappen voor syntax, Europese regels en aanvullende algemene en landgebonden regels. Onze leesproef voert die volledige toetsing niet uit. B mist nog steeds andere verplichte factuuronderdelen. Een passende notitietekst maakt het fragment dus niet verzendklaar.
Gebruik naast de tekstvergelijking de controle van het validatierapport voor het gekozen formaat. Noteer welk volledig document en welke regelversie onderzocht zijn. Houd XML-leesbaarheid, overeenkomende inhoud, volledige validatie, daadwerkelijke verzending en betaling als verschillende waarnemingen bij.
Officiële bronnen en proefgrenzen
Drie officiële pagina's rechtstreeks gelezen op 30 oktober 2026: W3C XML1.0 Fifth Edition onderdelen 2.1, 2.4, 4.1 en 4.6; de huidige OpenPeppol BT-22-pagina; BIS3.0.21 onderdelen 7.2.9, 14 en 15. Geen volledige standaardenbeoordeling. XT3010 en alle teksten en fragmenten zijn eigen fictief werk. Geen echte factuur, exportpakket, ontvanger, volledige validator of verzending getest. Attributen, CDATA, DTD's, externe entiteiten en tekencodering zijn niet uitgewerkt.