คุณได้ทำการสร้างใบแจ้งหนี้ Factur-X ขึ้นมา และการตรวจสอบที่ตัวคอนเทนเนอร์ (container) ทุกด่านก็ผ่านฉลุย แคตตาล็อกมีอาร์เรย์ (array) /AF ต้นไม้รายชื่อของ EmbeddedFiles ได้รับการจำแนกแจกแจงไปยังข้อกำหนดเฉพาะของไฟล์ที่ถูกต้อง factur-x.xml ที่ฝังตัวอยู่มีความสัมพันธ์ /AFRelationship ของ Alternative ที่ถูกต้อง และ ValidateFacturXInvoice ที่มีติดตั้งอยู่ในตัวก็ทำการส่งกลับ (returns) ค่ามาเป็น 1 ทว่าหลังจากนั้นคุณก็นำเอาไฟล์เดียวกันนี้ไปเข้าสู่การทำงานผ่านทาง veraPDF ซึ่งเป็นตัวตรวจสอบอ้างอิงที่บรรดาพอร์ทัลทางภาษี (tax portals) นิยมนำมาใช้งาน และมันก็ให้คำชี้ขาดว่าเอกสารทั้งฉบับนั้นไม่ใช่ PDF/A-3 ที่ถูกต้อง โครงสร้างนั้นถูกต้องแล้ว เมทาดาตา (metadata) ต่างหากล่ะที่เป็นตัวปัญหา และความล้มเหลวก็คือหนึ่งในสิ่งที่เป็นเรื่องที่ง่ายดายที่สุดในบรรดาเวิร์กโฟลว์ (workflow) ของ e-invoice ทั้งหมดที่จะเกิดการหลุดรอดสายตาไปได้
เหตุผลนั้นมีความคุ้มค่าที่จะทำความเข้าใจให้ถ่องแท้สมบูรณ์ เนื่องจากว่ามันจะช่วยอธิบายถึงชั้น (class) หนึ่งของข้อบกพร่องแบบ PDF/A ที่ไม่ได้มีความเกี่ยวเนื่องกับหน้าเพจที่มองเห็นได้ หรือแม้กระทั่งสิ่งที่แนบมาด้วย (attachment) เลยแม้แต่น้อย หากแต่เป็นเรื่องของวิธีที่ XMP ใช้ในการอธิบายคุณลักษณะของตัวมันเองล้วนๆ และนี่ก็คือกับดักซึ่งแอบซ่อนตัวอยู่เบื้องหลังสีเขียวผ่านฉลุยจากการตรวจสอบที่ตัวคอนเทนเนอร์
คุณสมบัติทั้งสี่ข้อที่เป็นต้นเหตุทำให้ไฟล์ล้มเหลว
ใบแจ้งหนี้แบบ Factur-X จะทำการเขียนคุณสมบัติแบบกำหนดเอง (custom properties) ลงไปสี่ประการในแพ็กเก็ต (packet) XMP ของมัน เพื่อที่จะให้ซอฟต์แวร์ปลายทาง (downstream software) สามารถอ่านโปรไฟล์ (profile) ของใบแจ้งหนี้ได้โดยที่ไม่จำเป็นต้องแจกแจงวิเคราะห์ (parsing) ตัว XML ที่ถูกฝังไว้ พวกมันอาศัยอยู่ในเนมสเปซ (namespace) ของ Factur-X ภายใต้คำนำหน้า fx อันประกอบไปด้วย: fx:DocumentFileName, fx:DocumentType, fx:Version และ fx:ConformanceLevel พวกมันเหล่านี้นี่ล่ะคือเมทาดาตาอย่างแท้จริงที่ผู้อ่าน (reader) จำเป็นจะต้องทราบ เพื่อที่จะได้รับรู้ว่า PDF นี้บรรทุกใบแจ้งหนี้ EN 16931 ที่มีชื่อว่า factur-x.xml เอาไว้ที่เวอร์ชัน 1.0
คุณสมบัติทั้งสี่ข้อนั้นไม่ได้มีข้อใดที่เป็นส่วนหนึ่งของสคีมา (schema) XMP เลยแม้แต่ข้อเดียวที่ทาง PDF/A กำหนดไว้ล่วงหน้า สคีมาในการระบุอัตลักษณ์ (identification schemas) ของ Dublin Core, XMP Basic, PDF และ PDF/A ต่างก็เป็นที่รู้จักกันดีของผู้อ่านที่ปฏิบัติตามข้อกำหนด ทว่าไม่ใช่กับ fx: เวลาที่ veraPDF ย่างกรายไปบน XMP และเข้าถึงคุณสมบัติซึ่งเป็นสิ่งที่ตัวมันเองไม่รู้จักเนมสเปซ มันจะทำการสอดส่องหาคำประกาศที่จะเป็นตัวบอกมันว่าคุณสมบัติดังกล่าวหมายความว่าอย่างไร ในกรณีที่ไม่มีคำประกาศนั้นปรากฏตัวอยู่ มันก็จะรายงานความล้มเหลวเมื่อเทียบกับเนื้อความ (clause) 6.6.2.3.1 ของ ISO 19005-3 ที่ระบุให้คุณสมบัติทุกๆ ข้อที่ไม่ได้ถูกร่างมาจากสคีมาที่มีการกำหนดไว้ล่วงหน้า จำเป็นจะต้องได้รับการอธิบายไว้ในสคีมาส่วนขยาย (extension schema) ของ PDF/A คุณสมบัติสี่ข้อที่ไม่ได้รับการประกาศ ก็คือสี่หนทางที่จะทำให้ไฟล์นั้นถูกปฏิเสธกลับมา และก็ไม่มีข้อใดที่การตรวจสอบในระดับคอนเทนเนอร์จะสามารถมองเห็นได้
เหตุใด PDF/A จึงทำการปฏิเสธคุณสมบัติแบบกำหนดเองแบบเปลือยๆ
กฎที่ตั้งเอาไว้ดูเหมือนจะเป็นเรื่องจุกจิกเจ้าระเบียบ จนกว่าคุณจะพึงรำลึกได้ว่า PDF/A นั้นมีไว้เพื่อการใด รูปแบบนี้มีตัวตนอยู่เพื่อให้ไฟล์สามารถถูกเปิดขึ้นมาและทำความเข้าใจได้นับจากนี้ไปอีกหลายทศวรรษ ด้วยซอฟต์แวร์ที่ไม่เคยได้รับคำบอกเล่าเกี่ยวกับธรรมเนียมปฏิบัติของปี 2026 เลยแม้แต่น้อย ผู้อ่านที่ปฏิบัติตามข้อกำหนดถูกคาดหวังให้สามารถทำความเข้าใจเอกสารได้จากตัวเอกสารเพียงอย่างเดียวเท่านั้น โดยที่ปราศจากการปรึกษาทะเบียน (registry) ภายนอกใดๆ
เมทาดาตาที่ถูกกำหนดขึ้นเองเป็นสิ่งที่มาทำลายคำสัญญานั้น นอกเสียจากว่าไฟล์นั้นจะมีการบรรทุกคำอธิบายของตัวมันเองเอาไว้ เมื่อได้รับคุณสมบัติแบบ fx:ConformanceLevel โล่งๆ มาสักตัว ผู้อ่านในอนาคตก็จะไม่อาจล่วงรู้ได้เลยว่าคำนำหน้า fx ไปจับคู่ผูกมัดเข้ากับ URI ของเนมสเปซอะไร ค่าที่ให้มานั้นเป็นข้อความ เป็นวันที่ หรือเป็นจำนวนเต็ม หรือคุณสมบัตินั้นๆ บรรยายเอกสารตัวมันเองหรืออาจจะเป็นทรัพยากรที่อยู่ภายนอกบางอย่างกันแน่ กลไกของสคีมาส่วนขยาย (extension schema mechanism) ของ PDF/A ได้เข้ามาทำการอุดช่องโหว่นั้นเอาไว้ โดยการอนุญาตให้ไฟล์สามารถทำการประกาศสิ่งต่างๆ ออกมาในโครงสร้าง XMP ที่คงที่ได้ ไม่ว่าจะเป็นเนมสเปซ, คำนำหน้า (prefix) และในส่วนของแต่ละคุณสมบัติก็ยังครอบคลุมไปถึงชนิดของค่า (value type) ควบคู่ไปกับหมวดหมู่ (category) ของความเป็น internal (ภายใน) หรือ external (ภายนอก) ซึ่งเมื่อใดก็ตามที่คำประกาศนั้นปรากฏตัวอยู่ คุณสมบัติก็จะกลายเป็นสิ่งที่อธิบายคุณลักษณะในตัวมันเองได้ (self-describing) และเนื้อความ (clause) 6.6.2.3.1 ก็จะได้รับการเติมเต็ม หากปราศจากสิ่งนี้ ตัวตรวจสอบความถูกต้อง (validator) ก็จะไม่มีทางเลือกอื่นใดนอกเสียจากต้องปฏิบัติต่อคุณสมบัตินั้นราวกับเป็นสิ่งที่ไม่อาจทำความเข้าใจได้ (unintelligible) และมอบความล้มเหลวให้แก่ไฟล์นั้นไป ความแตกต่างของหมวดหมู่เป็นเรื่องที่มีความสำคัญในที่นี้: คุณสมบัติของใบแจ้งหนี้ในลักษณะนี้ได้อธิบายข้อมูลที่ถูกส่งมาจากโลกภายนอกกระบวนการโปรเซสเซอร์ของ PDF ดังนั้นพวกมันจึงถูกประกาศให้เป็น external แทนที่จะเป็น internal
เนื้อหาในคำประกาศสคีมาส่วนขยาย (extension schema declaration)
คำประกาศนั้นก็คือ rdf:Description ในแพ็กเก็ต (packet) ของ XMP ซึ่งใช้เนมสเปซที่กำหนดโดย AIIM ถึงสามตัว อันได้แก่ pdfaExtension, pdfaSchema และ pdfaProperty ภายในกระเป๋า pdfaExtension:schemas จะมีรายการสคีมานั่งประจำการอยู่หนึ่งรายการ ที่ทำหน้าที่ระบุชื่อของสคีมาของ Factur-X พร้อมทั้งให้ค่า pdfaSchema:namespaceURI และ pdfaSchema:prefix ของมัน จากนั้นจึงได้ทำการแสดงรายการของคุณสมบัติทั้งสี่ในลักษณะที่เป็นลำดับแบบ pdfaSchema:property แต่ละคุณสมบัติจะบรรทุกชื่อ pdfaProperty:valueType ที่เป็น Text และ pdfaProperty:category ที่เป็น external ตัวอย่างของการทำมาร์กอัป (markup) ที่แสดงอยู่ทางด้านล่างได้สะท้อนให้เห็นถึงรูปพรรณสัณฐานของบล็อก (block) ดังกล่าว
<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 ของเนมสเปซและคำนำหน้า (prefix) ไม่ใช่สตริง (strings) ที่ตั้งค่าคงที่ตายตัวไว้ พวกมันจะปฏิบัติตามโปรไฟล์ (profile) เอกสาร Factur-X จะใช้งาน urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0# ที่มีคำนำหน้า fx ในขณะที่ไฟล์ ZUGFeRD 2.0 ซึ่งคัดเลือกมาผ่านทาง zugferd-invoice.xml จะได้รับการจำแนกแจกแจงไปสู่ URI ในรูปแบบอื่นภายใต้ชื่อสคีมาของมันเอง สคีมาส่วนขยายจำต้องประกาศ URI ของเนมสเปซให้เป็นเช่นเดียวกันกับที่บล็อกคุณสมบัติ (property block) นั้นๆ มีการใช้งานจริงๆ หรือไม่อย่างนั้นตัวตรวจสอบความถูกต้องก็ยังไม่สามารถที่จะเชื่อมโยงพวกมันเข้าหากันได้อยู่ดี PDFlibPas จะดึงคุณค่า (values) ทั้งสองมาจากชื่อของไฟล์รวมทั้งเวอร์ชันที่คุณส่งผ่าน (pass) ไปให้ ดังนั้นคำประกาศรวมถึงบล็อกของคุณสมบัติก็จะให้ความยินยอมซึ่งกันและกันเสมอ
ผู้ช่วยทำการเขียนให้ทั้งสองซีกอยู่คู่กันได้อย่างไร
ใน PDFlibPas คุณไม่ต้องทำการประกอบ XML ที่ว่านี้ด้วยมือของคุณเอง คุณจับให้เอกสารนั้นเข้าไปอยู่ในโหมด PDF/A-3 และเรียกใช้ (call) เมธอด (method) หนึ่งตัว สิ่งแรกที่คุณต้องจัดการให้เข้าที่เข้าทางก็คือฟล็กของการปฏิบัติตามข้อกำหนด (conformance flag) เนื่องจาก Factur-X นั้นมีความต้องการ PDF/A-3 การเรียกใช้ SetPDFAMode(7) จะเป็นการเลือกคัดเอาระดับแบบ PDF/A-3u ซึ่งจะทำหน้าที่ในการตั้งค่า pdfaid:part ให้กลายเป็น 3 และตั้งค่า pdfaid:conformance ให้เป็น U เอาไว้ในสคีมาการระบุอัตลักษณ์ บัดนี้แพ็กเก็ตของ XMP ก็ทำการบรรทุกพาร์ทและการปฏิบัติตามข้อกำหนดที่ถูกต้องเอาไว้แล้ว ก่อนที่เมทาดาตาของใบแจ้งหนี้ใดๆ จะถูกเพิ่มเติมเข้ามา
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;การเรียกใช้เพียงแค่ครั้งเดียวเพื่อไปหา AddFacturXAssociatedFileFromString จะช่วยทำงานต่างๆ ให้กับสิ่งที่เป็นส่วนที่ขาดหายไปอันทำให้ไฟล์เกิดความล้มเหลว มันจะฝัง XML ไว้ให้กลายมาเป็นไฟล์ที่เกี่ยวข้องในระดับ PDF/A-3 ควบคู่กันกับความสัมพันธ์ (relationship) ที่คุณได้เป็นผู้เอ่ยนามเอาไว้ และมันก็จะทำการบันทึกคุณสมบัติ fx ทั้งสี่พร้อมกับชื่อของสคีมา URI ของเนมสเปซ และคำนำหน้าสำหรับโปรไฟล์ (profile) ที่คุณคัดเลือกมาเอาไว้ด้วย ในยามที่ตัวเอกสารถูกบันทึก ขั้นตอนภายใน (internal step) ที่มีนามว่า ApplyFacturXMetadata จะทำการฉีด (injects) บล็อกคุณสมบัติ (property block) และคำประกาศของ pdfaExtension:schemas ซึ่งมีความสอดคล้อง (matching) ให้ไหลเวียนเข้าสู่แพ็กเก็ต (packet) XMP ซึ่งนั่นก็ทำให้คุณสมบัติแบบที่ถูกกำหนดเองเดินทางมาพร้อมกับลักษณะที่ได้รับการอธิบายความเอาไว้ให้เรียบร้อยแล้ว เมธอด (method) จะส่งกลับ (returns) ค่าเป็น 0 ถ้ายามใดที่เอกสารไม่ได้อยู่ในโหมดของ PDF/A-3 หรือไม่เช่นนั้นตัว XML ไม่สามารถเข้าคู่กันกับโปรไฟล์ที่มีการประกาศแจ้งไว้ได้ ซึ่งส่วนนี้ก็คือกองกำลังรักษาความปลอดภัย (guard) รูปแบบเดียวกันกับที่ใช้ในการหยุดยั้งใบแจ้งหนี้ที่มีลักษณะผิดรูปไม่ให้เข้าถึงตัวไฟล์ได้ตั้งแต่ช่วงเวลาเริ่มต้นเป็นต้นมา
จุดบอดแห่งการตรวจสอบคอนเทนเนอร์ที่ไม่อาจมองเห็น
นี่คือส่วนที่ควรจะเอ่ยขานกันอย่างตรงไปตรงมา เพราะมันคือสาเหตุที่ว่าทำไมตัวบั๊ก (bug) ถึงแอบซ่อนตัวอยู่ได้ ValidateFacturXInvoice ทำหน้าที่ในการตรวจสอบตัวคอนเทนเนอร์ (container) มันจะทำหน้าที่ยืนยันว่าแคตตาล็อกมี /AF เข้ามา (entry) ตัวต้นไม้รายชื่อของ EmbeddedFiles ปรากฏตัวอยู่ XML ของใบแจ้งหนี้มีตัวตนอยู่ ชื่อของไฟล์ที่ฝังไว้จับคู่เข้ากันกับโปรไฟล์ (profile) รหัสโครงร่าง (guideline ID) ใน XML ให้ความยินยอมพร้อมใจกันกับระดับการปฏิบัติตามข้อกำหนด และ /AFRelationship คือสิ่งที่ PDF/A-3 ยินยอมอนุญาต สิ่งที่ว่ามานั้นทั้งหมดคือการตรวจสอบที่มีอยู่จริง และมันก็ตรวจจับพบถึงข้อบกพร่องที่เกิดขึ้นจริงได้ด้วยเช่นกัน GetFacturXValidationIssues ทำการรายงานข้อมูลเหล่านี้ให้ทราบตามชื่อ โดยใช้ตัวระบุอัตลักษณ์ (identifiers) ยกตัวอย่างเช่น MissingCatalogAF, NotPDFA3, ConformanceGuidelineMismatch, InvalidAFRelationship และ InvalidFileNameProfile
สิ่งที่มันไม่ได้มีการตรวจสอบเอาไว้ด้วยเลยก็คือว่า สคีมาส่วนขยาย (extension schema) ของ XMP มีการปรากฏตัวและเป็นไปอย่างถูกต้องหรือไม่ ไฟล์ซึ่งคอนเทนเนอร์ของมันมีความไร้ที่ติอย่างสมบูรณ์แบบ ทว่าคุณสมบัติ fx ของมันดันไม่ได้ถูกประกาศแจ้งเอาไว้ จะสามารถพาตัวเองผ่านพ้นไปได้ในทุกๆ ด่านการตรวจสอบถึงปัญหาและส่งกลับ (returns) ค่าออกมาเป็น 1 นั่นก็เป็นเพราะไม่มีสิ่งใดเลยในรายการนั้นที่มุ่งหมายเข้าทำการตรวจสอบที่ตัวบล็อก (block) pdfaExtension:schemas นั่นคือสาเหตุที่อธิบายได้อย่างตรงจุดเลยว่า ทำไมใบแจ้งหนี้ที่ประกอบขึ้นมาด้วยมือ หรือใบที่ถูกผลิตขึ้นมาจากบรรดาเส้นท่อรับส่ง (pipeline) ซึ่งทำการเขียนบล็อกของคุณสมบัติลงไปโดยที่ปราศจากคำประกาศแจ้งนั้น สามารถที่จะแล่นผ่านฉลุยไปกับตัวตรวจสอบที่ถูกตั้งค่าติดตั้งไว้ (built-in validator) ได้ และยังไปพังครืนล้มเหลวลงที่ veraPDF ในเนื้อความ (clause) 6.6.2.3.1 ตัวตรวจสอบคอนเทนเนอร์และตัวตรวจสอบเมทาดาตา (metadata) ของ PDF/A ตอบคำถามในประเด็นที่แตกต่างกันออกไป และก็จะมีเพียงแค่ผู้ตรวจสอบของ PDF/A อย่างเต็มรูปแบบเท่านั้นที่จะตอบคำถามข้อที่สองได้
อ่านประเด็นปัญหาต่างๆ เพื่อที่จะได้ทราบว่าความเสียหายไปแตกหักอยู่ที่ชั้นใด
สืบเนื่องมาจากการที่สองชั้นดังกล่าวนั้นมีโอกาสที่จะล้มเหลวอย่างเป็นอิสระซึ่งกันและกัน อุปนิสัยในการวินิจฉัยเพื่อสืบหาสาเหตุที่ถูกต้องก็คือ ให้ไปทำการอ่านบรรดาปัญหาที่เกี่ยวเนื่องกับตัวคอนเทนเนอร์ก่อนเป็นอันดับแรก และจงปฏิบัติต่อผลลัพธ์ที่สะอาดไร้มลทินนั้นประหนึ่งว่าเป็นเพียงข้อความแถลงการณ์ถึงตัวคอนเทนเนอร์เพียงอย่างเดียว แต่จะต้องไม่ใช่ข้อมูลเกี่ยวกับตัวเมทาดาตาของ PDF/A เป็นอันขาด ทำการรัน (Run) การตรวจสอบความถูกต้องที่มีมาในตัวเพื่อรวบรวมเอารายการประเด็นปัญหาทั้งหลาย และจัดการกับมันซะก่อนที่คุณจะเอื้อมมือออกไปหาเครื่องมือที่อยู่ภายนอก
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;เมื่อยามที่การเรียกใช้ถูกตอบกลับมาเป็นชื่อของปัญหาใดๆ ความผิดพลาดนั้นๆ จะตั้งอยู่ที่ตัวคอนเทนเนอร์ และข้อความก็จะบอกให้คุณรับรู้ได้ว่าเกิดขึ้น ณ ที่ส่วนไหน แต่เมื่อยามที่มันส่งกลับผลตอบรับอันสะอาดสะอ้าน ในขณะที่ veraPDF ยังคงยืนกรานปฏิเสธตัวไฟล์นั้นอยู่ ความผิดพลาดที่เกิดขึ้นนั้นมักจะสิงสถิตอยู่ที่สคีมาส่วนขยายของ XMP ซะเกือบจะทั้งหมด และวิธีการเยียวยารักษาให้ตรงจุดก็คือ การปล่อยให้ AddFacturXAssociatedFileFromString ทำการเขียนตัวเมทาดาตาลงไป แทนที่จะมามัวสร้างบล็อกของคุณสมบัติขึ้นมาด้วยตนเอง การเก็บเอาคำถามทั้งสองประการแยกส่วนกันเอาไว้ในใจคุณนั่นล่ะ คือสิ่งที่จะเปลี่ยนการปฏิเสธที่น่าฉงนให้กลายมาเป็นเพียงคำวินิจฉัยบรรทัดเดียว: ปัญหาของคอนเทนเนอร์จะโผล่พ้นผิวน้ำผ่านทางรายชื่อประเด็นปัญหา ปัญหาคำประกาศของสคีมาจะผุดโผล่พ้นน้ำขึ้นมาเฉพาะเมื่อเจอกับตัวตรวจสอบของ PDF/A และการสับสนปนเปเอาสองสิ่งนี้เข้ามารวมกันก็คือการเปิดทางให้ตัวบั๊ก (bug) แอบซ่อนตัวอยู่ได้
ภาพรวมของการปฏิบัติตามข้อกำหนด (conformance) ในส่วนของ PDF/A และ PDF/UA ซึ่งรวมไปถึงการประมวลผลก่อนบิน (preflight pass) ก่อนที่ไฟล์ใดๆ จะได้โบยบินออกจากขอบข่ายการสร้างของคุณ ได้รับการครอบคลุมอยู่ในเนื้อหา คำแนะนำเบื้องต้นเกี่ยวกับการประมวลผลก่อนบินของ PDF/A และ PDF/UA หากใบแจ้งหนี้ของคุณจำเป็นจะต้องมีคุณสมบัติในการเข้าถึงได้ (accessible) ด้วย ต้นไม้โครงสร้าง (structure tree) ซึ่ง PDF/A-3a และไฟล์ PDF ที่ติดแท็ก (tagged PDF) มักจะไปฝากผีฝากไข้ (depend on) ด้วยนั้น ก็คือหัวข้อของ บทความการเข้าถึงได้ของ PDF ที่ติดแท็ก การจัดการกับสคีมาส่วนขยายที่ได้รับการอธิบายเอาไว้ ณ ที่แห่งนี้ ถูกจัดส่งมาในฐานะส่วนหนึ่งของ PDFlibPas Delphi PDF Library โดยเคียงข้างมากับการสนับสนุนโปรไฟล์ของ Factur-X, ZUGFeRD และ XRechnung ซึ่งปรากฏเด่นชัดอยู่ทั่วทั้งบล็อกแห่งนี้