Zgradili ste račun Factur-X in vsako preverjanje vsebnika je uspešno. Katalog vsebuje polje /AF, drevo imen EmbeddedFiles se razreši v pravo specifikacijo datoteke, vgrajeni factur-x.xml ima pravilni /AFRelationship vrednosti Alternative, vgrajeni ValidateFacturXInvoice pa vrne 1. Nato zaženete isto datoteko prek veraPDF - referenčnega preverjevalnika, ki ga uporabljajo davčni portali - in ta razglasi celoten dokument za neveljaven PDF/A-3. Struktura je pravilna. Metapodatki so težava, in ta napaka je ena od tistih, ki jih je v celotnem delovnem toku z e-računi najlažje spregledati
Razlog je vreden celotnega razumevanja, ker pojasnjuje razred napak PDF/A, ki nima nobene zveze z vidno stranjo ali prilogo, temveč vse z načinom, kako XMP opisuje samega sebe. To je past, ki se skriva za zelenim preverjanjem vsebnika
Štiri lastnosti, ki datoteko ne opravijo
Račun Factur-X zapiše štiri lastnosti po meri v svoj paket XMP, da lahko nadaljnja programska oprema prebere profil računa brez razčlenjevanja vgrajenega XML. Živijo v imenskem prostoru Factur-X pod predpono fx: fx:DocumentFileName, fx:DocumentType, fx:Version in fx:ConformanceLevel. To so natanko metapodatki, ki jih bralnik potrebuje, da ve, da ta PDF vsebuje račun EN 16931 z imenom factur-x.xml pri različici 1.0
Nobena od teh štirih lastnosti ni del katere koli sheme XMP, ki jo PDF/A vnaprej definira. Dublin Core, XMP Basic, PDF in sheme za identifikacijo PDF/A so znane skladnemu bralcu, fx: pa ne. Ko veraPDF pregleduje XMP in naleti na lastnost, katere imenskega prostora ne prepozna, poišče deklaracijo, ki bi mu povedala, kaj lastnost pomeni. Če ta deklaracija ni prisotna, poroča o napaki pri klavzuli ISO 19005-3 6.6.2.3.1, ki zahteva, da je vsaka lastnost, ki ni vzeta iz vnaprej določene sheme, opisana v razširitveni shemi PDF/A. Štiri neopredeljene lastnosti pomeni štiri načine, da bo datoteka zavrnjena - in nobena od njih ni vidna pri preverjanju vsebnika
Zakaj PDF/A zavrne golo lastnost po meri
Pravilo se zdi pedantno, dokler se ne spomnite, čemu je PDF/A namenjen. Format obstaja, da bi datoteko lahko odprli in razumeli čez desetletja, s programsko opremo, ki nikoli ni bila obveščena o konvencijah leta 2026. Od skladnega bralnika se pričakuje, da razume dokument samo iz dokumenta samega, brez zunanjega registra za posvetovanje
Metapodatki po meri kršijo to obljubo, razen če datoteka nosi lastni opis. Glede na golo lastnost fx:ConformanceLevel prihodnji bralnik ne more vedeti, na kateri URI imenskega prostora se predpona fx nanaša, ali je vrednost besedilo, datum ali celo število, ali lastnost opisuje sam dokument ali zunanji vir. Mehanizem razširitvene sheme PDF/A zapolni to vrzel. Datoteki omogoča, da razglasi - v fiksni strukturi XMP - imenski prostor, predpono in za vsako lastnost vrsto vrednosti ter kategorijo internal ali external. Ko je ta deklaracija prisotna, je lastnost samoopisen in klavzula 6.6.2.3.1 je zadovoljna. Brez nje validator nima druge možnosti, kot da lastnost obravnava kot nerazumljivo in datoteko zavrne. Razlikovanje kategorij je tukaj pomembno: lastnosti računa, kot so te, opisujejo podatke, ki prihajajo od zunaj procesorja PDF, zato so deklarirane kot external in ne internal
Kaj vsebuje deklaracija razširitvene sheme
Deklaracija je rdf:Description v paketu XMP, ki uporablja tri z AIIM definirane imenske prostore pdfaExtension, pdfaSchema in pdfaProperty. V vrečki pdfaExtension:schemas sedi en vnos sheme, ki poimenuje shemo Factur-X, poda njen pdfaSchema:namespaceURI in pdfaSchema:prefix, nato pa v zaporedju pdfaSchema:property navede štiri lastnosti. Vsaka lastnost nosi ime, pdfaProperty:valueType vrednosti Text in pdfaProperty:category vrednosti external. Spodnja ponazoritvena oznaka prikazuje obliko tega bloka
<rdf:Description rdf:about=""
xmlns:pdfaExtension="http://www.aiim.org/pdfa/ns/extension/"
xmlns:pdfaSchema="http://www.aiim.org/pdfa/ns/schema#"
xmlns:pdfaProperty="http://www.aiim.org/pdfa/ns/property#">
<pdfaExtension:schemas>
<rdf:Bag>
<rdf:li rdf:parseType="Resource">
<pdfaSchema:schema>Factur-X PDFA Extension Schema</pdfaSchema:schema>
<pdfaSchema:namespaceURI>urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0#</pdfaSchema:namespaceURI>
<pdfaSchema:prefix>fx</pdfaSchema:prefix>
<pdfaSchema:property>
<rdf:Seq>
<rdf:li rdf:parseType="Resource">
<pdfaProperty:name>DocumentFileName</pdfaProperty:name>
<pdfaProperty:valueType>Text</pdfaProperty:valueType>
<pdfaProperty:category>external</pdfaProperty:category>
<pdfaProperty:description>name of the embedded XML invoice file</pdfaProperty:description>
</rdf:li>
<!-- DocumentType, Version, ConformanceLevel declared the same way -->
</rdf:Seq>
</pdfaSchema:property>
</rdf:li>
</rdf:Bag>
</pdfaExtension:schemas>
</rdf:Description>URI imenskega prostora in predpona nista fiksni nizi. Sledita profilu. Dokument Factur-X uporablja urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0# s predpono fx, medtem ko se datoteka ZUGFeRD 2.0, izbrana prek zugferd-invoice.xml, razreši na drugačen URI pod lastnim imenom sheme. Razširitvena shema mora deklarirati isti URI imenskega prostora, ki ga blok lastnosti dejansko uporablja, sicer validator še vedno ne more povezati obeh. PDFlibPas obe vrednosti izpelje iz imena datoteke in različice, ki ju posredujete, zato sta deklaracija in blok lastnosti vedno usklajena
Kako pomočnik zapiše obe polovici skupaj
V PDFlibPas tega XML ne sestavljate ročno. Dokument postavite v način PDF/A-3 in pokličete eno metodo. Najprej je treba določiti zastavico skladnosti, ker Factur-X zahteva PDF/A-3. Klic SetPDFAMode(7) izbere raven PDF/A-3u, ki nastavi pdfaid:part na 3 in pdfaid:conformance na U v shemi za identifikacijo. Paket XMP zdaj nosi pravi del in raven skladnosti, preden se dodajo kakršni koli metapodatki računa
var
FileID: Integer;
begin
PDF.SetPDFAMode(7); // PDF/A-3u: pdfaid:part=3, conformance=U
PDF.NewDocument;
// draw the human-readable invoice page here
FileID := PDF.AddFacturXAssociatedFileFromString(
InvoiceXML, // raw UTF-8 XML bytes
'EN16931', // ConformanceLevel
'factur-x.xml', // embedded file name
'Factur-X invoice XML', // /Desc text
'Alternative', // /AFRelationship
'1.0', // profile version
''); // optional country code
if FileID = 0 then
Exit; // not PDF/A-3, or XML/profile mismatch
PDF.SaveToFile('factur-x.pdf');
end;En sam klic AddFacturXAssociatedFileFromString opravi delo, ki ga manjkajoči datoteki ni uspelo. Vgradi XML kot pridruženo datoteko PDF/A-3 z razmerjem, ki ste ga navedli, in zabeleži štiri lastnosti fx skupaj z imenom sheme, URI imenskega prostora in predpono za izbrani profil. Ko je dokument shranjen, notranje stopnja z imenom ApplyFacturXMetadata vbrizga tako blok lastnosti kot ujemajočo se deklaracijo pdfaExtension:schemas v paket XMP, tako da lastnosti po meri prispejo že opisane. Metoda vrne 0, če dokument ni v načinu PDF/A-3 ali če se XML ne ujema z razglašenim profilom - to je enako preverjanje, ki prepreči, da bi deformiran račun sploh dosegel datoteko
Slepa pega, ki je preverjanje vsebnika ne more videti
Ta del je vredno pojasniti neposredno, ker je to razlog, da se hrošč skriva. ValidateFacturXInvoice preverja vsebnik. Potrdi, da ima katalog vnos /AF, da je drevo imen EmbeddedFiles prisotno, da XML račun obstaja, da se ime vgrajene datoteke ujema s profilom, da se GuidelineID v XML ujema z ravnjo skladnosti in da je /AFRelationship tisto, ki ga PDF/A-3 dovoljuje. To so resnična preverjanja, ki zaznajo resnične napake. GetFacturXValidationIssues jih poroča po imenu z identifikatorji, kot so MissingCatalogAF, NotPDFA3, ConformanceGuidelineMismatch, InvalidAFRelationship in InvalidFileNameProfile
Kar ne preverja, je, ali je razširitvena shema XMP prisotna in pravilna. Datoteka, katere vsebnik je brezhibne kakovosti, toda katere lastnosti fx niso opredeljene, prestane vsako preverjanje in vrne 1, ker nič na tem seznamu ne pregleda bloka pdfaExtension:schemas. To je natanko razlog, zakaj ročno zgrajen račun ali tisti, ustvarjen s cevovodom, ki je zapisal blok lastnosti brez deklaracije, nemoteno preplava vgrajeni validator in vseeno ne prestane veraPDF na klavzuli 6.6.2.3.1. Validator vsebnika in validator metapodatkov PDF/A odgovarjata na različni vprašanji, in le celotni preverjevalnik PDF/A odgovori na drugega
Branje težav, da veste, katera plast se je pokvarila
Ker se obe plasti neodvisno pokvarita, je pravilna diagnostična navada, da najprej preberete težave vsebnika in čisti rezultat obravnavate kot izjavo samo o vsebniku - nikoli o metapodatkih PDF/A. Zaženite vgrajeno validacijo, zberite seznam težav in ukrepajte, preden posežete po zunanjem orodju
var
Issues: WideString;
begin
if PDF.ValidateFacturXInvoice = 0 then
begin
Issues := PDF.GetFacturXValidationIssues('|');
// container-level identifiers, for example:
// MissingCatalogAF, NotPDFA3, MissingEmbeddedFilesNameTree,
// ConformanceGuidelineMismatch, InvalidAFRelationship
WriteLn('Container issues: ', Issues);
end
else
WriteLn('Container OK; verify XMP extension schema with a PDF/A checker.');
end;Ko ta klic vrne ime težave, je napaka v vsebniku in sporočilo pove, kateri del. Ko vrne čist rezultat, pa veraPDF datoteko vseeno zavrne - napaka je skoraj vedno v razširitveni shemi XMP, in popravek je, da pustite AddFacturXAssociatedFileFromString zapisati metapodatke namesto da sami sestavljate blok lastnosti. Ločevanje obeh vprašanj v lastnem razmišljanju je tisto, kar zbegano zavrnitev spremeni v enowrstično diagnozo: težave vsebnika se pojavijo prek seznama težav, težave z deklaracijo sheme pa se pojavijo samo prek validatorja PDF/A, in zamenjevanje obeh je tisto, kar hrošču dovoli skrivanje
Širša slika skladnosti PDF/A in PDF/UA, vključno s tem, kako izvesti predkontrolni prehod, preden datoteka zapusti vaš sistem gradnje, je obravnavana v vodičtu za predkontroliranje PDF/A in PDF/UA. Če mora biti vaš račun prav tako dostopen, je drevo struktur, od katerega sta odvisna PDF/A-3a in označeni PDF, predmet članka o dostopnosti označenega PDF. Obravnavanje razširitvene sheme, opisano tukaj, se prinaša kot del knjižnice PDFlibPas Delphi PDF skupaj s podporo za profile Factur-X, ZUGFeRD in XRechnung, dokumentirano v tem blogu