Коротко: ERP і SAF-T UA
- SAF-T UA можна сформувати з будь-якої ERP — але рівень нативної підтримки суттєво відрізняється залежно від платформи.
- SAP має можливості для доступу до даних через стандартні інтерфейси, але генерація SAF-T UA потребує окремого налаштування, кастомної розробки або зовнішнього рішення під українську специфіку.
- BAS/1С — проблема лежить не тільки в технічних можливостях, але й у правовому статусі: їх використання в Україні несе регуляторні ризики. Детальніше — у статті «Заборона 1С в Україні 2026».
- Odoo є відкритою платформою з API, що дозволяє інтегрувати генерацію SAF-T UA, але готового офіційного універсального модуля SAF-T UA «з коробки» зазвичай немає.
- Якщо дані розподілені між кількома системами — ERP-модуль однієї платформи задачу не вирішить: потрібен ERP-незалежний SAF-T Connector.
Чому вибір ERP впливає на підготовку SAF-T
SAF-T UA — це XML-файл зі структурованими даними: бухгалтерські проводки, первинні документи, довідники контрагентів і товарів. Всі ці дані зберігаються в обліковій або ERP-системі. Тому вибір платформи прямо визначає:
- Повноту даних — чи зберігає система всі обов'язкові поля (ІПН контрагентів, коди УКТ ЗЕД, курси валют тощо)?
- Можливість виводу даних — чи є API або інтерфейс для витягування даних у потрібній структурі?
- Нативну підтримку SAF-T — чи є готовий модуль або потрібна кастомна розробка?
- Консолідацію — якщо систем кілька, як зводити дані в єдиний файл?
Відповідь на ці питання визначає, скільки зусиль і часу знадобиться для підготовки SAF-T, і чи взагалі можна обійтись нативними засобами ERP.
SAF-T UA на SAP
SAP — одна з найпоширеніших ERP-платформ серед великих українських компаній. З точки зору SAF-T UA, SAP має кілька суттєвих переваг:
- Повна фінансова модель — SAP зберігає всі бухгалтерські проводки, документи і довідники в структурованому вигляді.
- Стандартні інтерфейси — RFC, BAPI, OData можуть використовуватись для витягування потрібних даних у структурованому форматі, якщо це дозволяє конкретна архітектура SAP-клієнта.
- ABAP-розробка — за потреби можна створити кастомний звіт або модуль для підготовки даних чи генерації SAF-T UA, але це окремий проєкт локалізації.
Водночас є і виклики:
- Локалізація під Україну — у типовій українській SAP-інсталяції зазвичай немає готового універсального SAF-T UA модуля «з коробки». Потрібна або кастомна ABAP-розробка, або ERP-незалежне рішення, що підключається до SAP через стандартні інтерфейси.
- Якість довідників — якщо дані контрагентів (ІПН, ЄДРПОУ) не заповнені коректно в SAP, файл не пройде валідацію незалежно від якості технічного рішення.
- Мультисистемність — у більшості великих компаній на SAP є супутні системи (склад, CRM, HR). Якщо дані для SAF-T зберігаються не тільки в SAP — потрібна консолідація.
Для багатьох компаній на SAP оптимальним підходом є ERP-незалежний SAF-T Connector, що підключається до SAP через стандартні інтерфейси і дозволяє не обмежуватися даними однієї системи.
SAF-T UA на BAS / 1С
BAS (Business Automation Software) — лінійка бізнес-рішень, яка історично та технологічно пов'язана з екосистемою 1С/BAF. На ринку можуть існувати сторонні модулі або конфігурації для формування SAF-T-файлів із BAS/1С, але їхню якість, актуальність XSD-схеми, повноту даних і юридичний контекст використання потрібно перевіряти окремо.
Проте ситуацію з BAS/1С в Україні у 2026 році не можна розглядати без урахування правового контексту:
Використання 1С/BAS в Україні несе регуляторні та репутаційні ризики у зв'язку зі статусом компанії-розробника. Питання правомірності використання платформи є окремою юридичною темою. Детальніше — у статті «Заборона 1С в Україні 2026: що робити бізнесу».
Якщо компанія планує міграцію з BAS на іншу платформу (наприклад, Odoo), SAF-T-стратегія повинна враховувати перехідний period: дані за попередні періоди часто залишаються в BAS або в архівному сховищі після міграції, і для таких періодів може знадобитися формування SAF-T з архівної системи або з підготовленого сховища даних.
Рішення: ERP-незалежний SAF-T Connector, що може підключатись як до BAS (для архівних даних), так і до нової ERP після міграції.
SAF-T UA на Odoo
Odoo — відкрита ERP-платформа, що активно впроваджується в Україні як альтернатива 1С/BAS. З точки зору SAF-T UA:
Сильні сторони Odoo для SAF-T:
- Структурована бухгалтерська модель — за умови коректної локалізації та налаштування Odoo зберігає проводки, журнали, документи й аналітику у структурованому вигляді.
- Відкрите API (JSON-RPC, REST) — дозволяє витягувати будь-які дані зовнішнім рішенням.
- Гнучкість конфігурації — план рахунків, аналітика і атрибути документів можна налаштувати під вимоги SAF-T UA.
Обмеження:
- Готового офіційного універсального модуля SAF-T UA для Odoo «з коробки» зазвичай немає; можливі сторонні або кастомні рішення різної якості.
- Якість SAF-T-файлу залежить від того, наскільки правильно налаштований план рахунків і чи заповнені обов'язкові поля у довідниках.
- При міграції з BAS на Odoo важливо правильно перенести або замаппити план рахунків — від цього залежить коректність SAF-T для перехідного і наступних периодів.
LUCAS впроваджує Odoo та може окремо налаштувати SAF-T Connector для компаній, які використовують або планують використовувати Odoo. Це дозволяє вирішити питання облікової платформи і SAF-T готовності в одному проєкті.
Мультисистемне середовище: найскладніший випадок
Типова ситуація для середнього і великого бізнесу: фінансовий облік в ERP, продажі й виставлення рахунків у CRM або системі управління продажами, склад і товарооблік у WMS, HR і нарахування зарплати в окремій HR-системі.
Для повного SAF-T UA можуть знадобитися дані з кількох таких систем: проводки з ERP, первинні документи з CRM/WMS, довідники з різних джерел. У багатьох компаніях жодна окрема система не містить усього, що потрібно для повного SAF-T-файлу.
Наслідок: ERP-модуль однієї системи зазвичай не вирішує задачу консолідації, якщо частина даних зберігається поза цією ERP. Це означає або ручну збірку (непрактично при будь-якому реальному обсязі даних), або ERP-незалежний SAF-T Connector — рішення, яке підключається до кількох джерел і збирає дані в єдиний файл.
Порівняльна таблиця підходів
| ERP / ситуація | Нативний SAF-T модуль | Рекомендований підхід | Основний виклик |
|---|---|---|---|
| SAP (одна система) | Немає готового для UA | SAF-T Connector через SAP API | Локалізація і якість довідників |
| BAS / 1С | Є сторонні модулі | Міграція на нову ERP + Connector для архіву | Правовий ризик самої платформи |
| Odoo (одна система) | Немає офіційного для UA | SAF-T Connector через Odoo API | Налаштування плану рахунків і довідників |
| Кілька ERP / систем | Неможливий у межах однієї системи | ERP-незалежний SAF-T Connector | Консолідація і дедублікація даних |
| Кастомна/застаріла система | Відсутній | Connector через доступний інтерфейс або міграція | Наявність і якість API |
Коли ERP-модуля достатньо, а коли потрібен Connector
ERP-модуль може бути достатнім, якщо всі дані для SAF-T UA зберігаються в одній системі, довідники заповнені повністю, структура даних відповідає XSD-схемі, а компанія не планує змінювати ERP у периоді, за який може знадобитися файл.
ERP-незалежний SAF-T Connector потрібен, якщо дані розподілені між SAP, BAS, Odoo, CRM, WMS, DMS, банківськими системами або кастомними базами; якщо компанія проходить міграцію ERP; або якщо потрібен контрольований маппінг і валідація перед поданням.
| Ситуація | Що може підійти |
|---|---|
| Усі дані в одній ERP і є якісний модуль | ERP-модуль або кастомний звіт |
| SAP + додаткові системи | ERP-незалежний SAF-T Connector |
| BAS зараз, Odoo після міграції | Connector, що працює з обома джерелами або архівом |
| Кілька ERP у групі | Connector з консолідацією джерел |
| Кастомна ERP або застаріла база | Connector через доступний інтерфейс або експорт даних |
Коли потрібен ERP-незалежний SAF-T Connector
ERP-незалежний SAF-T Connector — це рішення, що підключається до довільних джерел даних (ERP, CRM, WMS, бази даних) через стандартні інтерфейси і генерує SAF-T UA файл у потрібній структурі та дозволяє перевірити його перед поданням.
Такий підхід виправданий у більшості реальних ситуацій:
- Дані зберігаються в кількох системах і потребують консолідації.
- Нативний SAF-T модуль для вашої ERP відсутній або сторонні рішення не проходять валідацію.
- Компанія планує міграцію ERP і потрібне рішення, що не прив'язане до конкретної платформи.
- Потрібен повний контроль над генерацією: маппінг рахунків, фільтрація, трансформація даних під специфіку бізнесу.
- Вимога безпеки: дані не повинні виходити за межі власної інфраструктури (on-premise рішення).
SAF-T Connector від LUCAS — ERP-незалежне рішення на Python. Підключається до SAP, Odoo, BAS, Microsoft Dynamics, кастомних баз даних та інших джерел через доступні інтерфейси або погоджені формати вивантаження. Розгортається on-premise — дані не виходять з інфраструктури клієнта. Детальніше — на сторінці SAF-T Connector.
Часті запитання
Чи є готовий SAF-T UA модуль для SAP?
У типовій SAP-інсталяції готового універсального SAF-T UA модуля «з коробки» зазвичай немає. Є варіанти: кастомна ABAP-розробка або ERP-незалежний Connector, що підключається до SAP через стандартні інтерфейси. Другий підхід зазвичай більш гнучкий і не залежить від версії SAP.
Чи можна підготувати SAF-T з Odoo самостійно?
Odoo має відкритий API, тому технічно можливо. Але потрібно реалізувати логіку маппінгу даних, генерацію XML за специфікацією ДПС і пройти валідацію. На практиці компанії використовують готові рішення або залучають підрядника.
Якщо ми мігруємо з BAS на Odoo, що з SAF-T за минулі роки?
Дані за попередні періоди часто залишаються в BAS або в архівному сховищі після міграції. Якщо ДПС правомірно запросить дані за ці периоди, потрібно буде мати доступ до архівних даних і можливість сформувати SAF-T або інший потрібний формат на основі цих даних. Рекомендація: не відключати доступ до BAS до закінчення строків зберігання документів і мати рішення, здатне генерувати SAF-T з обох джерел.
Чи підходить SAF-T Connector для компаній зі складом в окремій WMS?
Так. SAF-T Connector від LUCAS — ERP-незалежне рішення, що підключається до довільних джерел. Рух товарів зі складської системи може бути консолідований разом з даними з фінансової ERP у єдиний SAF-T-файл.
Скільки займає впровадження SAF-T Connector для компанії на SAP?
Від аналізу джерел даних до першого коректно сформованого та провалідованого файлу — зазвичай 3–4 місяці. Строки залежать від кількості систем-джерел, якості даних і складності маппінгу. Починати потрібно з readiness assessment.
Чи потрібно оновлювати Connector при зміні XSD-схеми ДПС?
Так. ДПС може оновлювати специфікацію SAF-T UA. SAF-T Connector від LUCAS супроводжується з урахуванням таких оновлень — клієнти отримують актуальну версію без повного переналаштування системи.
Як LUCAS допомагає
LUCAS оцінює архітектуру даних для SAF-T UA: визначає, які дані зберігаються в SAP, BAS, Odoo, Microsoft Dynamics, CRM, WMS, DMS або кастомних системах, де є прогалини і який спосіб підключення є реалістичним.
Після assessment команда готує маппінг джерел, план рахунків, довідники, правила трансформації та сценарій валідації. Якщо дані розподілені між кількома системами, LUCAS впроваджує ERP-незалежний SAF-T Connector, який працює on-premise і не потребує перенесення даних за межі інфраструктури клієнта.
Висновок для CFO
Питання «як готувати SAF-T» для більшості компаній зводиться до одного висновку: ERP-незалежний Connector зазвичай виправданіший за нативний модуль всередині однієї системи. Причини прості — дані рідко зберігаються в одному місці, специфікація ДПС може змінюватись, а підприємство може мінятись ERP.
Якщо ви на SAP, Odoo чи іншій платформі — зверніться до LUCAS для оцінки готовності. Ми визначимо, які дані у вас є, де прогалини і яке рішення підійде саме для вашої архітектури.