Як читати XML з KSeF?

XML з KSeF - це файл даних, а не документ для читання як звичайний PDF. Його можна відкрити у текстовому редакторі, але без знання структури FA(3) легко сплутати номер рахунку, номер KSeF, дані сторін або технічні метадані.

Найбезпечніша послідовність така: підтвердити походження файлу, перевірити версію FA(3), прочитати дані продавця і покупця, порівняти позиції та суми, а потім запустити валідацію. Лише після цього читабельна PDF-візуалізація допомагає переглянути рахунок очима людини.

Конвертація XML у PDF не замінює валідації і не підтверджує, що рахунок прийнято KSeF. PDF - це попередній перегляд. Офіційне значення мають XML FA(3), системний статус, номер KSeF і UPO.

Нижче показано, що варто з'ясувати, перш ніж вважати XML-файл з KSeF готовим до обліку або подальшої передачі.

XML-файл з KSeF містить структурований рахунок, тобто документ, записаний за визначеною схемою даних. На практиці назва продавця, NIP, номер рахунку, дата, позиції, ставки VAT і суми записані у конкретних елементах, які може прочитати бухгалтерська система.

Такий файл не обов'язково виглядає зручно для людини. Ви побачите теги, кутові дужки і технічні назви полів, але для KSeF саме ця структура є ключовою. Система оцінює не графічний вигляд рахунку, а дані у форматі XML FA(3).

Якщо хочете зрозуміти основи формату, почніть з матеріалу XML і формат FA(3) у KSeF. Ця стаття зосереджена на практичному читанні файлу, який уже є на диску або отриманий з бухгалтерської програми.

Спочатку встановіть, звідки походить XML. Файл, завантажений безпосередньо з KSeF, експорт з бухгалтерської програми і вкладення з email не слід трактувати однаково. Якщо джерело невідоме, не запускайте макроси, скрипти або конвертери з випадкових сайтів.

Для першого перегляду достатньо звичайного текстового редактора. Але не редагуйте файл, якщо він може бути доказом, частиною бухгалтерського процесу або матеріалом для діагностики помилки. Збережіть оригінал без змін і працюйте з копією.

Якщо файл потрібен для обліку або пояснення розбіжностей, одразу збережіть контекст: хто його передав, коли його завантажено, чи має він номер KSeF, чи є UPO і з якої системи походить експорт.

Саме відкриття файлу ще не означає, що рахунок перевірено. На практиці потрібно розділити чотири дії: читання тексту, візуалізацію, валідацію і підтвердження у KSeF.

Це розмежування захищає від поширеної помилки: хтось бачить читабельний PDF або правильно відкритий `.xml` і вважає, що документ автоматично правильний. Кожен рівень відповідає на інше питання.

Якщо документ має потрапити до обліку, не зупиняйтеся на першому рівні. Відкритий XML показує дані, але лише поєднання валідації, номера KSeF, метаданих і UPO дає змістовну картину статусу рахунку.

Не потрібно знати всю XSD-схему, щоб виконати першу перевірку. Достатньо знати, які області відповідають найважливішим частинам рахунку. Назви вузлів можуть виглядати технічно, але їхній зміст бухгалтерський.

Naglowek описує тип документа, версію структури і системні дані. Podmiot1 - це продавець, а Podmiot2 - покупець. Fa містить дані рахунку, зокрема номер, дати, валюту і тип документа. FaWiersz описує позиції рахунку. Підсумки VAT показують значення за ставками.

Практичний приклад: коли шукаєте NIP продавця, почніть з області Podmiot1. Коли шукаєте власний номер рахунку, перейдіть до області Fa. Коли перевіряєте суми і ставки, порівнюйте FaWiersz з підсумками VAT, а не читайте весь документ від початку.

Не сприймайте цю карту як повний список обов'язкових полів. Вимоги залежать від типу рахунку і детальних правил FA(3). Карта допомагає зорієнтуватися, але не замінює валідацію.

Перша перевірка не полягає у читанні всього файлу зверху вниз. Почніть з полів, які найчастіше визначають ідентифікацію документа і подальшу бухгалтерську роботу.

Порівняйте номер рахунку з вихідним документом або бухгалтерською системою. Потім перевірте NIP продавця, NIP покупця, дату виставлення, дату продажу, валюту, позиції, ставки VAT і підсумки. Якщо рахунок має номер KSeF, збережіть його разом із датою прийняття і статусом.

Якщо бачите різницю між XML і очікуваним документом, не виправляйте фінальний файл вручну без розуміння причини. Найчастіше дані виправляють у вихідній системі, а потім генерують новий XML.

Одне з найчастіших джерел помилок - плутання номера рахунку з номером KSeF. Номер рахунку надає продавець у своїй системі. Номер KSeF надає центральна система після прийняття документа, і він має власну технічну структуру.

Номер KSeF складається з частини, що ідентифікує NIP продавця, дати прийняття і технічної частини з контрольною сумою. Це не заміна номера рахунку з продажної системи, і його не слід вигадувати або виправляти вручну.

Під час отримання рахунків через KSeF можна зустріти і XML рахунку, і метадані. Метадані допомагають знайти документ, перевірити ідентифікатори і статуси, але не є повним змістом рахунку. Для аудиту зберігайте комплект: XML, метадані, номер KSeF і UPO в KSeF, якщо він доступний.

Читабельний PDF допомагає швидко побачити, що є на рахунку, але спочатку варто знати, чи XML технічно коректний. Валідатор знаходить проблеми, які людина не побачить у перегляді, наприклад неправильний формат дати, відсутній обов'язковий елемент або невідповідність схемі.

Технічна валідація не гарантує податкової правильності. Вона допомагає знайти структурні проблеми і частину невідповідностей, але не вирішує, чи операція правильно оподаткована, чи ставка VAT суттєво правильна і чи рахунок відповідає договору.

Якщо хочете перевірити файл перед подальшою роботою, скористайтеся валідатором XML KSeF. Це публічний інструмент з денним лімітом, тому актуальні умови використання краще перевірити безпосередньо на сторінці інструмента.

XML - це формат для систем, а PDF - зручний вигляд для людини. Конвертація у PDF має сенс, коли потрібно швидко порівняти дані із замовленням, показати рахунок нетехнічній особі, передати документ на погодження або перевірити позиції без прокручування сирого XML.

Однак не сприймайте PDF як нову версію рахунку. Якщо PDF створено з XML, це лише візуалізація даних. Якщо у вихідних даних є помилка, PDF покаже ту саму помилку у зручнішій формі.

KSeFGPT надає конвертер XML у PDF KSeF. Це публічний інструмент з денним лімітом, тому актуальні умови варто перевірити безпосередньо на сторінці конвертера.

Наведені нижче сигнали не завжди означають відхилення рахунку, але потребують зупинити процес і перевірити джерело даних. Особливо обережно ставтеся до файлів, які мають потрапити до обліку або бути підставою спору з контрагентом.

Якщо щось виглядає підозріло, не обмежуйтеся PDF-візуалізацією. Збережіть оригінальний XML, запустіть валідацію, перевірте метадані і порівняйте документ з даними в системі, яка його створила.

Не завантажуйте чутливий XML у випадкові конвертери з пошуку. Рахунок може містити дані контрагентів, адреси, номери рахунків, суми і комерційну інформацію, тому використовуйте інструменти, політику приватності і обсяг обробки яких розумієте.

Практичний процес має мати три шари. Спочатку зберігається оригінальний XML і метадані завантаження. Потім файл перевіряється технічно. Наприкінці створюється читабельний PDF-перегляд або дані передаються до бухгалтерської системи.

Так ви не втрачаєте джерельний доказ. Якщо дорогою з'явиться помилка, можна повернутися до оригіналу, перевірити статус KSeF, порівняти номер рахунку з номером KSeF і відтворити, хто та коли працював з файлом.

При більшій кількості документів ручне відкривання XML швидко стає ризикованим. Тоді варто спиратися на інструмент, який поєднує імпорт, валідацію, перегляд, пошук за контрагентом і архівування результатів.

Якщо хочете зрозуміти структуру документа, почніть з матеріалу XML і формат FA(3) у KSeF. Якщо працюєте з рахунком, отриманим як PDF, і спочатку потрібен XML, перейдіть до статті Безкоштовний конвертер PDF у XML KSeF.

Для технічного контролю файлів стане у пригоді текст Валідація та обробка XML у KSeF. Якщо XML відхилила система, прочитайте Рахунок відхилено KSeF.

Як відкрити XML-файл з KSeF? - XML-файл можна відкрити у текстовому редакторі, але для реальної роботи краще використати валідатор або конвертер XML у PDF. Редактор покаже сирі теги, а інструмент покаже дані рахунку у читабельному вигляді і допоможе знайти технічні проблеми.

Чи PDF з XML є офіційним рахунком KSeF? - Ні. PDF є лише зручною для людини візуалізацією. У KSeF значення має структурований XML FA(3) разом із системними метаданими, номером KSeF і статусом прийняття.

Де в XML знайти номер KSeF? - Номер KSeF присвоює система після прийняття рахунку; це не звичайний номер рахунку, який вводить продавець. Він може бути в метаданих, завантажених з KSeF, або у відповіді системи, тому завжди порівнюйте його зі статусом документа.

Чи достатньо вручну прочитати XML, щоб перевірити рахунок? - Ні. Вручну можна перевірити сторони операції, номер рахунку, дати, позиції та суми, але структуру FA(3), типи даних і частину технічних правил має перевірити валідатор.

Що перевірити першим після завантаження XML з KSeF? - Спочатку підтвердіть джерело файлу, версію FA(3), номер KSeF або статус прийняття, NIP продавця і покупця, номер рахунку, дату виставлення, позиції, суми та результат технічної валідації.

Чи конвертер XML у PDF виправляє помилки рахунку? - Ні. Конвертер показує рахунок у читабельній формі, але не виправляє вихідні дані і не підтверджує податкову правильність. Помилки треба виправити у системі, яка створила XML, а потім знову перевірити файл.

Не починайте з переписування даних з XML у таблицю. Спочатку збережіть оригінал, підтвердьте джерело, перевірте номер KSeF або статус документа і запустіть валідацію. Лише потім створюйте PDF, передавайте дані до обліку або пояснюйте розбіжності з контрагентом.

Для окремих файлів достатньо поєднання валідатора і конвертера XML у PDF. При більшій кількості рахунків потрібен процес, який дозволяє відстежувати джерело файлу, версію, результат валідації і архів документів.

Рекомендовані матеріали: XML і FA(3) у KSeF, Валідація та обробка XML у KSeF, Отримання рахунків через KSeF та UPO в KSeF.