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