PDF/A — це стандартизована ISO підмножина PDF (ISO 19005), призначена для довготривалого зберігання: файл має за десять років виглядати так само, як сьогодні, хоч би яка програма його відкривала. PDF/A-3 — третя частина, ISO 19005-3 — додає одну-єдину здатність, і саме вона робить гібридні рахунки можливими.
Чого вимагає PDF/A
Норма прибирає з PDF усе, що робить документ залежним від оточення:
- Шрифти мають бути вбудовані. Файл не може розраховувати, що шрифт є на комп’ютері читача, — інакше зміниться розбивка рядків, і суми поїдуть.
- Кольори мають описувати себе самі — через вбудований кольоровий профіль, а не через налаштування екрана.
- Жодних зовнішніх залежностей: ні JavaScript, ні шифрування, ні посилань на файли, що лежать деінде.
- Метадані у XMP, машиночитні й усередині самого документа.
Для рахунку це не формалізм: у Німеччині строк зберігання — вісім років, а документ, чий вигляд залежить від встановленого шрифту, через вісім років уже не є надійним доказом.
Чому саме третя частина
PDF/A-1 і PDF/A-2 довільних вкладень не допускають: PDF/A-2 приймає лише інші файли PDF/A. Тільки PDF/A-3 дозволяє вбудувати в PDF будь-який файл і позначити його як рівноцінну складову документа.
На цьому й тримається гібридний формат. Файл ZUGFeRD чи Factur-X — це PDF/A-3 з одним особливим вкладенням: файлом XML, зазвичай factur-x.xml, який несе той самий рахунок у структурі CII. Людина бачить сторінку, програма читає вкладення — і обидва лишаються разом під час пересилання, розкладання по теках і архівування, бо це один файл.
Рівні відповідності A, B і U
Усередині PDF/A-3 є три рівні з різними вимогами:
| Рівень | Чого вимагає додатково |
|---|---|
| B (Basic) | збережено вигляд — документ завжди виглядає однаково |
| U (Unicode) | додатково: текст надійно видобувається як Unicode |
| A (Accessible) | додатково: структурна розмітка для доступності та порядку читання |
Для електронних рахунків звичним і достатнім є PDF/A-3B — машиночитні дані все одно лежать у вкладеному XML, а не в тексті сторінки. E-Rechnung Pro створює файли саме цього рівня.
Самого вкладення замало
Саме тут найчастіше падають саморобні файли — і побачити це, дивлячись лише на PDF, неможливо. Специфікація вимагає, щоб вкладення було оголошене, і то у двох місцях:
AFRelationshipу вбудованому об’єкті. Для XML рахунку цеData: воно каже одержувачеві, що вкладення — це дані документа, а не додаток «до купи».- Метадані XMP у PDF, які називають формат, версію і профіль.
PDF, до якого «прикріпили XML», — ще не електронний рахунок. Без оголошення програма одержувача просто не знайде вкладення — або знайде й не зрозуміє, що воно означає. Файл відкривається бездоганно, сторінка читається, і все одно перевірку він не проходить. Це найчастіша несподіванка з першим власноруч створеним файлом.
Простори імен у вбудованому XML
Хто вперше відкриває XML, спотикається об довгі URI на початку документа. Це простори імен: вони кажуть, з якого словника походить елемент, і не дають переплутати однойменні елементи різних стандартів.
У файлі ZUGFeRD головні два:
urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100— кореневий словник рахунку;urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100— багаторазові будівельні блоки в ньому.
Практично це важить для тих, хто пише власний розбирач: змішані версії просторів імен — часта причина того, чому файл з іншої системи раптом не читається. Хто бере готову бібліотеку, про це може не думати: вона керує просторами імен сама, а правити їх руками майже завжди помилка.
Що ламається під час створення
| Що каже перевірка | Причина |
|---|---|
| Шрифт не вбудовано | типовий шрифт генератора, який вважають «і так наявним» |
| Немає кольорового профілю | вивід у RGB без вбудованого профілю |
| Прозорість або шари | логотип у PDF, відрендерений із прозорістю |
| Вкладення без зв’язку | не задано AFRelationship |
| Метадані XMP відсутні або не збігаються | PDF після створення обробили іншим інструментом |
Останній рядок найпідступніший: дійсний файл, який потім проходить через інструмент, що не знає PDF/A — для склеювання, штампування чи стиснення, — виходить звідти звичайним PDF. Вкладення може й лишитися всередині, а оголошення зникає.
Архівування: чому один файл кращий за два
Зберігати треба структуровану частину — незміненою і простежуваною, у Німеччині вісім років. Саме тут гібридний формат і виправдовує себе: немає окремої структурованої частини, яку можна було б розгубити. Хто кладе в архів PDF і XML двома файлами, сам відповідає за їхню зв’язність — іменами файлів, архівною системою, дисципліною. PDF/A-3 несе обидві частини в собі.
Додається ще й читабельність: за вісім років будь-який поширений переглядач покаже цей PDF. Чи існуватиме тоді ваша нинішня бухгалтерська програма — питання інше; сторінка читатиметься.
Часті питання
Чи кожен PDF/A-3 є електронним рахунком?
Ні. PDF/A-3 — це конверт. Електронним рахунком файл робить вбудований XML за EN 16931 та його правильне оголошення.
Чи можна перетворити наявний PDF на PDF/A-3 постфактум?
Технічно так, і саме це роблять конвертери. Чи вийде — залежить від початкового PDF: якщо шрифти не вбудовані або є прозорість, документ доведеться переробити. Докладний шлях — у статті Конвертація PDF-рахунку.
Який рівень відповідності мені потрібен?
Для електронних рахунків досить B. Рівень A стає цікавим, якщо ви і так маєте дотримуватися доступності: для цього PDF потрібна повна структурна розмітка, а вона сама собою не з’являється.
Як дізнатися, що мій PDF справді PDF/A-3?
Найнадійніше — перевіркою: саме це робить шар контейнера. Переглядач цього надійно не показує — він охоче відобразить і документ, який норми не дотягує.
Чи можна додавати інші файли?
PDF/A-3 це дозволяє. У рахунку варто подумати двічі: кожне зайве вкладення одержувач має якось витлумачити, а XML рахунку мусить лишатися однозначно впізнаваним.
Чи всюди визнають PDF/A-3?
Як архівний формат — так, це норма ISO. Але чи прийме одержувач ваш рахунок, вирішує профіль і повнота даних усередині, а не контейнер.
Стисло
- PDF/A забезпечує читабельність роками: вбудовані шрифти, власні кольорові профілі, жодних зовнішніх залежностей.
- Третя частина дозволяє довільні вкладення — без неї гібридного рахунку не було б.
- Рівня B досить; U і A вимагають більшого, не будучи потрібними для рахунку.
- Вкладення має бути оголошене —
AFRelationship: Dataплюс XMP. Без цього це PDF із файлом усередині, а не електронний рахунок. - Подальша обробка руйнує відповідність. Штампування, склеювання і стиснення після створення — тихий убивця.
- Один файл замість двох — ось справжній виграш для восьмирічного зберігання.
Перевірити, чи проходить ваш файл шар контейнера? Завантажте його без реєстрації — або заведіть безкоштовний обліковий запис і створюйте рахунки одразу як дійсний PDF/A-3.