Чому SAF-T UA не проходить XSD-перевірку? 5 причин і як їх виявити до подання звіту

Файл SAF-T UA потрібно надати протягом двох робочих днів після запиту податкової. Якщо XML не відповідає XSD-схемі, ці дні йдуть на пошук помилки в файлі розміром у сотні мегабайтів. Більшість відмов має кілька типових причин, і всі вони виявляються ще до подання.

Що саме перевіряє XSD

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

Типові причини помилок

• Порожні обов'язкові елементи. В обліковій системі довідник контрагента може не містити коду ЄДРПОУ/ІПН, країни чи адреси, бо для внутрішнього обліку ці реквізити не потрібні. У схемі вони обов'язкові, і один контрагент без реквізиту зупиняє валідацію всього файлу.
• Порушення формату і довжини. Дата в неправильному форматі, рядок довший за ліміт, число з зайвими знаками після коми, текст у полі, де очікується код. У кастомізованих конфігураціях BAS такі значення з'являються через вільне введення в довільні реквізити.
• Недопустимі значення довідників. Одиниці виміру, коди податків, типи руху, типи операцій мають збігатися з переліками схеми. Назва «шт.» з облікової системи не дорівнює коду одиниці виміру з таблиці UOMTable.
• Порушена послідовність і зв'язність. Проводка посилається на рахунок, якого немає в GeneralLedgerAccounts. Документ продажу вказує клієнта, відсутнього в Customers. Для XSD це помилка посилання, і файл не проходить.
• Спеціальні символи і кодування. Лапки, амперсанд, керуючі символи й нерозривні пробіли в назвах номенклатури та контрагентів ламають XML ще до перевірки структури.

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

Як модуль знаходить помилки до подання звіту

Модуль «Формування SAF-T UA» для BAS перевіряє дані на двох рівнях.

Спочатку виконується перевірка реквізитів у самій обліковій системі. Модуль перевіряє заповнення обов'язкових полів, формати і довжини на етапі підготовки даних, показує проблемні об'єкти (контрагента, номенклатуру, рахунок) і дає змогу виправити їх у базі. Бухгалтер бачить, що саме і де не заповнено, а не загальне повідомлення про помилку валідації.

Потім сформований XML перевіряється на відповідність XSD-схемі. Технічні помилки виявляються до відправки через Електронний кабінет платника податків, а не після відмови.

Сформований файл зберігається в базі облікової системи. Його можна відкрити, скоригувати й доповнити без повного перерахунку, що важливо, коли реквізити виправляються пакетами.

Для великих обсягів передбачено окремі можливості формування і швидшого тестування. Версія Desktop працює з обсягом до 3 млн бухгалтерських записів за період, Big Data не має обмеження. Ці версії мають відкритий код, тому логіку формування можна адаптувати під кастомізовану конфігурацію, і саме такі конфігурації найчастіше дають нестандартні значення.

Що зробити до запиту податкової

1. Сформуйте тестовий файл за останній закритий період і перегляньте перелік помилок перевірки реквізитів.
2. Виправте довідники: реквізити контрагентів, одиниці виміру, типи операцій, назви з недопустимими символами.
3. Повторіть формування та XSD-перевірку, доки помилок не залишиться.
4. Перевірте, скільки часу займає формування за повний період на реальному обсязі даних.

Після цього підготовка до запиту складається з формування файлу за період із запиту і повторної перевірки.

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