Найголовніше за хвилину

SAF-T UA формується з будь-якої редакції SAP: ECC, S/4HANA on-premise, S/4HANA Cloud, Business One.
У SAP рідко «немає даних». Проблема в тому, що поля SAF-T розкидані між FI, SD, MM і AA, а одна бізнес-подія — між кількома документами.
Основна робота — відновити бізнес-контекст із кількох модулів і перекласти модель даних SAP на структуру SAF-T UA. XML — фінальний і найпростіший крок.
S/4HANA не автоматично простіший за ECC: Universal Journal і CDS/API полегшують вивантаження, але мапінг і збагачення даних лишаються.
У S/4HANA Cloud прямого доступу до бази зазвичай немає — вивантаження будують через API, CDS views та OData.
Стандартна підтримка SAP ERP 6.0 з EHP6–EHP8 триває до кінця 2027 року. Тому SAF-T не варто прив’язувати до ECC, якщо попереду перехід на S/4HANA.
Трансформація не має вигадувати дані: якщо атрибута немає, потрібне задокументоване правило збагачення.

Чим SAP відрізняється від 1С

У 1С чи BAS значна частина полів SAF-T часто вже лежить у зручних довідниках і регістрах — про це стаття про 1С. SAP влаштований інакше. Він містить більшість вихідних даних, але не обов’язково всі потрібні атрибути і не завжди в потрібній деталізації. Дані зібрані в різних функціональних контурах, і звести їх у єдину структуру SAF-T — головне завдання проєкту.

Що конкретно ускладнює роботу:

одна бізнес-подія, наприклад продаж, розкладена між кількома об’єктами й таблицями;
бухгалтерська проводка не містить усієї аналітики — частина деталізації є лише у вихідному документі;
master-дані контрагентів, матеріалів і основних засобів розподілені між FI, MM, SD та AA;
частина полів SAF-T не ведеться в стандартній конфігурації;
українська податкова специфіка реалізована через локалізацію або кастомні Z-об’єкти;
частина даних живе поза SAP і потребує збагачення з інших систем.

Звідси типовий ланцюжок: вивантаження → staging → трансформація → збагачення → мапінг → звірка → генерація XML → XSD- і логічна валідація.

Редакції SAP як джерело SAF-T

Редакція	Що важливо для SAF-T
SAP R/3 та legacy-інсталяції	Потрібен окремий аналіз даних; ступінь кастомізації важливіший за вік
SAP ERP 6.0 / ECC	Класична модель FI, часто багато Z-доробок; працює на AnyDB або HANA як СУБД
S/4HANA on-premise	Universal Journal, Business Partner, розвинений шар CDS/API
S/4HANA Cloud Private Edition	Ближче до on-premise, але доступ до інфраструктури обмежений умовами хостингу
S/4HANA Cloud Public Edition	SaaS: лише опубліковані API, CDS, OData, Integration Suite / BTP
SAP Business One	Компактніша модель даних на MS SQL або HANA; окремий клас проєкту

Строки підтримки ECC. За стратегією SAP, стандартна (mainstream) підтримка SAP ERP 6.0 з EHP6–EHP8 триває до кінця 2027 року, розширена — опційно до кінця 2030-го. Для інсталяцій без EHP або з EHP1–EHP5 стандартна підтримка завершилася 31.12.2025. Перевіряйте фактичний рівень EHP вашої системи. Для SAF-T висновок один: компанія може одночасно працювати в ECC і готувати перехід на S/4HANA, тож рішення не варто прив’язувати до однієї версії.

Частина потрібних даних може лежати й поза core ERP — у SAP BW, EWM, SuccessFactors, Ariba, Concur, зовнішніх WMS, банківських системах чи зарплатних рішеннях. Це не означає, що всі вони потрібні для кожного проєкту, але в складному ландшафті їх варто перевірити.

Де в SAP шукати дані для SAF-T UA

Нижче — орієнтовне зіставлення. Конкретні таблиці навмисно не наводимо: у різних релізах, кастомізаціях і локалізаціях реалізація відрізняється.

Блок SAF-T UA	Типове джерело в SAP	Чому потрібна трансформація
General Ledger	FI / Universal Journal	SAF-T вимагає власної структури транзакцій і рядків
Chart of Accounts	G/L master data	Мапінг локального плану рахунків до атрибутів SAF-T
Customers / Suppliers	Customer / Vendor або Business Partner	Атрибути розподілені між загальним рівнем, company code і sales area
Products	Material master	Потрібних атрибутів може не бути в одному об’єкті
Inventory	MM / WM / EWM, документи руху матеріалів	Вартісна і кількісна деталізація — в різних структурах
Sales invoices	Billing document SD + документ FI	Потрібно поєднати документ реалізації і проводку
Purchase invoices	Замовлення, надходження, invoice verification MM + FI	Ланцюжок з кількох пов’язаних об’єктів
Payments	FI, банківська інтеграція	Зв’язок оплати з рахунком відновлюється через кліринг
Fixed Assets	FI-AA	Картка активу, надходження, амортизація і вибуття — окремо
Tax	Податкові рядки FI, податкові коди, локалізація	Українські атрибути часто треба збагачувати з кастомних джерел

Базове джерело — FI. Але проводка відображає фінансовий результат, а не весь первинний документ, тому зазвичай потрібні ще SD, MM, FI-AA, іноді CO, PS, PP чи EWM. Точний перелік визначає gap-аналіз.

Трансформації: що доводиться робити з даними

з’єднувати дані різних модулів;
відновлювати зв’язки між документами одного ланцюжка;
мапити типи документів SAP на типи SAF-T і рахунки Головної книги;
перекладати коди між класифікаторами, нормалізувати одиниці виміру й валюти;
коректно обробляти сторно, кліринг, кредит-ноти й внутрішньогрупові операції;
збагачувати дані з додаткових джерел;
вивантажувати історію за минулі періоди.

Правило. Трансформація не створює даних, яких не було в системі. Якщо атрибута бракує — шукаємо альтернативне джерело або фіксуємо задокументоване правило мапінгу. Розбивати агрегати без вихідної деталізації — небезпечна практика.

ECC vs S/4HANA

	SAP ECC	SAP S/4HANA
Фінансова модель	Класична FI, більше окремих таблиць і агрегатів	Universal Journal
Контрагенти	Окремі Customer і Vendor master	Business Partner
Кастомізація	Часто багато Z-коду	In-app і side-by-side extensibility
Інтеграція	Переважно класичні інтерфейси	CDS views, API
СУБД	AnyDB або SAP HANA	Лише SAP HANA
Для SAF-T	Мапінг спирається на доробки конкретної інсталяції	Вивантаження простіше, але мапінг і збагачення все одно потрібні

Хмарні редакції і Business One

Private Edition за гнучкістю близька до on-premise. Але підключитися напряму до бази зазвичай не можна — доступ залежить від умов хостингу. Вивантаження будують через API, CDS views, OData, інструменти інтеграції SAP або погоджену схему реплікації.

Public Edition (дедалі частіше — SAP Cloud ERP) — стандартизований багатокористувацький SaaS. Прямий доступ до бази тут не передбачений у принципі. SAF-T будують на опублікованих API, CDS, OData та SAP Integration Suite / BTP, тож архітектура суттєво відрізняється від ECC.

Business One — окремий продукт для малого й середнього бізнесу, версії 9.2–10.0 на MS SQL або HANA. Модель даних компактніша, рівнів master data менше. Але сильно кастомізований B1 з add-ons не обов’язково простіший за типовий великий проєкт.

Кастомізовані ландшафти і групи компаній

У глибоко доопрацьованій інсталяції — Z-таблиці, Z-поля, власний ABAP-код, сторонні add-on — назва «ECC» чи «S/4HANA» мало що каже про реальну архітектуру даних. Потрібні data discovery, аналіз метаданих, інтерв’ю з власниками процесів і трасування вибіркових транзакцій від первинного документа до проводки.

У групах додаються кілька company codes і clients, паралельні ECC і S/4HANA, SAP поряд із локальною ERP, спільний сервісний центр, різні плани рахунків і фінансові роки. SAF-T за одну юрособу тоді збирається з кількох джерел — ще один аргумент за ERP-незалежний шар.

Міграція ECC → S/4HANA: що буде із SAF-T

Типова ситуація: 2025–2026 роки — в ECC, з 2027–2028 — в S/4HANA. Запит ДПС може охопити період в обох системах. Для цього потрібні:

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

Якщо ядро SAF-T не залежить від версії SAP, при міграції змінюються вивантаження і частина мапінгу, а не все рішення.

Походження даних і великі обсяги

У складному ландшафті кожне значення у файлі має мати простежуване походження: поле SAF-T → правило трансформації → об’єкт і поле SAP → бізнес-процес. Такий data lineage потрібен для аудиту, пояснень на запит ДПС, оновлення релізу й міграції.

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

Перевірка: XSD плюс звірка

XSD підтверджує структуру файлу, але не бухгалтерську правильність трансформацій. Після неї варто перевірити:

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

Це практичний мінімум, а не вичерпний перелік контрольних співвідношень ДПС. Детальніше — у статті «Валідація SAF-T UA».

Етапи проєкту для SAP

Огляд SAP-ландшафту: системи, версії, моделі розгортання.
Gap-аналіз та інвентаризація джерел.
Наскрізне трасування вибіркових транзакцій.
Мапінг кожного елемента SAF-T.
Проєктування вивантаження під модель доступу: on-premise, Private чи Public Cloud.
Правила трансформації та збагачення.
Прототип і звірка з обліком.
XSD- і логічна валідація.
Навантажувальне тестування і приймання користувачами.
Регламент регулярного формування файлу.

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

Як це працює у SAF-T Connector

SAF-T Connector — ERP-незалежне рішення LUCAS. Воно працює з SAP та іншими джерелами одночасно, а механізм вивантаження підлаштовується під ландшафт: ECC, S/4HANA on-premise, Private чи Public Cloud, Business One. Усередині — staging, мапінг, трансформації зі збагаченням, бухгалтерські контролі й міжсекційні звірки, XSD-валідація та XML з Excel-переглядом. Рішення розраховане на великі обсяги й розгортається on-premise, тож обробка йде поза транзакційним контуром продуктивної SAP. Схема інтеграції — на головній сторінці.

Часті запитання

Чи можна сформувати SAF-T UA із SAP ECC чи SAP ERP 6.0?

Так. SAP ERP 6.0 — це та сама лінійка ECC 6.0. Основна робота — мапінг даних із різних модулів з урахуванням Z-доробок конкретної інсталяції.

Чи достатньо даних із SAP FI?

Зазвичай ні. Проводка у FI відображає фінансовий результат, а деталізація продажів і закупівель живе в SD і MM. Точний набір джерел визначає gap-аналіз.

Чи можна брати дані напряму з бази HANA?

Для on-premise систем контрольований read-only доступ технічно можливий. Для хмарних редакцій, особливо Public Edition, це не передбачена модель інтеграції — потрібні офіційні API.

Що робити із Z-таблицями?

Аналізувати окремо в межах data discovery. Вони часто містять логіку конкретної компанії, яку не видно зі стандартної конфігурації.

Чи можна об’єднати дані кількох SAP-систем в одному файлі?

Так. Для груп із кількома company codes чи інсталяціями потрібен окремий етап зведення в єдину модель.

Чи простіше SAF-T із SAP Business One?

Модель даних компактніша. Але складність визначають кастомізації, add-ons, суміжні системи та якість даних.

Скільки триває впровадження?

Залежить від кількості систем і модулів. Орієнтир для SAF-T Connector — приблизно 3–4 місяці до першого провалідованого файлу. Точніша оцінка можлива після gap-аналізу.

Висновок для CFO

SAF-T UA формується з будь-якої версії SAP — від R/3 до S/4HANA Cloud і Business One. SAP містить більшість потрібних даних, але вони розподілені між модулями й документами, тому основний обсяг робіт — мапінг, трансформація і збагачення, а не XML. Друге питання — архітектура: рішення, прив’язане до релізу чи моделі розгортання, доведеться переробляти при переході ECC → S/4HANA. ERP-незалежний підхід зберігає інвестицію. Почніть з оцінки готовності або опишіть ваш SAP-ландшафт.