SAF-T UA для SAP: як сформувати стандартний аудиторський файл.

Коротко

• SAF-T UA можна сформувати із SAP — незалежно від того, чи це ECC, S/4HANA, S/4HANA Cloud чи SAP Business One.
• Проблема зазвичай не в тому, що в SAP «немає даних», а в тому, що потрібні для SAF-T поля розподілені між модулями (FI, MM, SD, AA), а одна бізнес-подія — між кількома документами.
• Складність SAF-T для SAP зазвичай полягає не у формуванні XML, а у відновленні бізнес-контексту з кількох модулів і перетворенні SAP data model у структуру SAF-T UA.
• Для пакетів розширення SAP ERP 6.0 EHP6–EHP8 mainstream maintenance триває до кінця 2027 року, з опційною extended maintenance до кінця 2030-го; для старіших версій (без EHP або EHP1–EHP5) mainstream maintenance вже завершилася 31.12.2025 — тому SAF-T не варто жорстко прив'язувати до ECC, якщо компанія планує перехід на S/4HANA.
• S/4HANA не автоматично простіший за ECC для SAF-T: Universal Journal і CDS/API-екосистема можуть спростити частину extraction, але мапінг і enrichment залишаються окремим завданням.
• Для S/4HANA Cloud (Public і, значною мірою, Private Edition) прямий доступ до бази даних зазвичай недоступний — extraction потрібно проєктувати через дозволені API, CDS views, OData чи інші офіційні механізми інтеграції.
• SAP Business One має компактнішу й іншу за структурою модель даних, ніж S/4HANA; SAF-T для B1 — окремий клас проєкту, але його фактична складність так само залежить від кастомізацій, add-ons і якості даних.
• Для великих і розподілених SAP-ландшафтів (кілька company codes, кілька систем, ECC і S/4HANA одночасно) SAF-T за юридичну особу часто вимагає зведення даних із кількох джерел.
• Трансформація даних не повинна створювати інформацію, якої не було у вихідній системі — якщо потрібного атрибута немає, потрібне документоване enrichment-правило, а не вигадане значення.
• XSD-валідність файлу підтверджує лише структуру XML, а не коректність бухгалтерських трансформацій — для цього потрібна окрема логічна перевірка й звірка (reconciliation).

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

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

Чому SAF-T із SAP складніший, ніж простий XML-експорт

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

Типовий SAF-T-проєкт для SAP тому включає більше кроків, ніж просте вивантаження: extraction із SAP → staging → transformation → enrichment → mapping → reconciliation → SAF-T engine → XSD-валідація → логічна валідація → готовий XML.

Які версії SAP можуть бути джерелом SAF-T

SAP R/3 та legacy-інсталяції. У частині українських компаній досі трапляються історичні інсталяції SAP R/3 чи SAP R/3 Enterprise, нерідко суттєво доопрацьовані за роки експлуатації. Такі системи потребують окремого аналізу даних — вік платформи сам по собі менш важливий, ніж те, наскільки кастомізованою є конкретна модель даних.

SAP ERP / ECC / Business Suite 7. Сюди належать SAP ERP, SAP ERP 6.0, SAP ECC, SAP ECC 6.0, SAP Business Suite 7 в цілому, Enhancement Packages (EHP) різних версій, а також інсталяції SAP ERP powered by SAP HANA. Важливо не ототожнювати ECC з HANA: класичний ECC 6.0 історично працював на різних підтримуваних базах даних (AnyDB), і лише окремі інсталяції переведені на HANA як СУБД, зберігаючи класичну ECC-логіку застосунку. За офіційною стратегією підтримки SAP, mainstream maintenance для пакетів розширення SAP ERP 6.0 EHP6, EHP7 і EHP8 триває до кінця 2027 року, з опційною extended maintenance до кінця 2030 року; для інсталяцій без EHP або з EHP1–EHP5 mainstream maintenance вже завершилася 31.12.2025, і такі системи перейшли в режим customer-specific maintenance. Строки підтримки конкретної інсталяції варто перевіряти окремо за фактичним рівнем EHP. Це прямо впливає на архітектуру SAF-T: компанія може одночасно експлуатувати ECC і планувати перехід на S/4HANA, тому SAF-T-рішення не варто жорстко прив'язувати до ECC.

SAP S/4HANA on-premise. Основні покоління — S/4HANA 1511, 1610, 1709, 1809, 1909, 2020, 2021, 2022, 2023 та наступні підтримувані релізи (перед впровадженням варто перевіряти актуальну номенклатуру релізів SAP, оскільки вона періодично оновлюється). Ключова архітектурна відмінність від ECC — Universal Journal, який змінює логіку зберігання фінансових даних.

SAP S/4HANA Cloud Private Edition. Керована приватна хмарна модель, історично пов'язана з програмою RISE with SAP, яка за функціональністю та можливостями кастомізації значно ближча до S/4HANA on-premise, ніж до Public Edition. Водночас пряма робота з базою даних чи інфраструктурою може бути обмежена умовами хостингу та архітектурою SAP cloud landscape.

SAP S/4HANA Cloud Public Edition. Стандартизована багатокористувацька (multi-tenant) SaaS-архітектура. Варто зважати, що навесні 2025 року SAP спростив назви хмарних пропозицій — публічну редакцію дедалі частіше називають SAP Cloud ERP, а приватну — SAP Cloud ERP Private, хоча назви «S/4HANA Cloud Public/Private Edition» досі широко вживані на ринку й у документації партнерів. Незалежно від актуальної назви, модель інтеграції тут принципово інша: прямий доступ до бази даних не є доступною моделлю, і extraction потрібно проєктувати на основі опублікованих API, CDS views, OData-сервісів чи інших офіційних механізмів інтеграції SAP.

SAP Business One. Окремий продукт для малого й середнього бізнесу — SAP Business One (B1), включно з версіями 9.2, 9.3 і 10.0. SAP офіційно підтримує Business One 10.0 як у варіанті на Microsoft SQL Server, так і у версії для SAP HANA. Business One не варто плутати з S/4HANA — це інша й зазвичай компактніша модель даних, тому SAF-T для Business One є, по суті, окремим класом проєкту порівняно з великим SAP-ландшафтом.

Крім основних ERP-систем, у ландшафті компанії дані, потрібні для SAF-T, іноді частково зберігаються поза core SAP ERP — наприклад, у SAP BW/BW4HANA, SAP CRM, SAP SRM, SAP SCM, SAP EWM, SAP TM, SAP SuccessFactors, SAP Ariba, SAP Concur, SAP Analytics, а також у зовнішніх WMS/TMS/MES-системах, банківських системах чи рішеннях для розрахунку зарплати. Це не означає, що всі перелічені системи обов'язково потрібні для конкретного SAF-T-проєкту — лише те, що в складному ландшафті частина даних може перебувати поза межами основної ERP.

Які SAP-модулі містять дані SAF-T

SAP — не набір незалежних баз даних, а взаємопов'язана система функціональних модулів, і саме тому SAF-T часто «збирає» інформацію, яка в SAP проходить через різні контури: FI (Financial Accounting) відповідає за бухгалтерський облік і Головну книгу; CO (Controlling) — за управлінський облік і розподіл витрат; MM (Materials Management) — за закупівлі, запаси й матеріальний облік; SD (Sales and Distribution) — за продажі й дистрибуцію; AA / FI-AA (Asset Accounting) — за облік основних засобів; TR (Treasury) — за казначейські операції, де це релевантно; PS (Project System) — за проєктний облік; PP (Production Planning) — за виробниче планування; WM / EWM — за складське господарство. До цього додаються локалізаційні компоненти й кастомні Z-модулі, які реалізують специфічно українську податкову логіку.

Де в SAP знаходяться дані для SAF-T

Нижче — орієнтовне зіставлення елементів SAF-T UA і типових джерел у SAP. Конкретні таблиці й об'єкти тут навмисно не наводяться як універсальна істина — у різних релізах, кастомізаціях і локалізаціях фактична реалізація може відрізнятися.

Чому даних SAP може не вистачати в потрібній деталізації

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

На практиці це виглядає так: бухгалтерська проводка (FI posting) відображає фінансовий результат, але не завжди містить усі атрибути первинного документа. Рахунок реалізації складається з даних, розподілених між SD, FI та master data. Ланцюжок закупівлі — замовлення, надходження товару, рахунок постачальника і бухгалтерський документ — часто існує як кілька окремих пов'язаних об'єктів, а не єдиний запис. Зв'язок між оплатою і конкретним документом може вимагати clearing-логіки для відновлення. Бухгалтерський запис за товарним рухом рідко містить усю кількісну й складську деталізацію. Облік основних засобів вимагає об'єднання master-даних активу, рухів і амортизаційних записів. Українська податкова інформація може зберігатися в кастомних таблицях, локалізаційних об'єктах чи взагалі в зовнішній системі. Номери первинних документів можуть бути внутрішніми ідентифікаторами SAP, зовнішніми референсами або кастомними полями. Потрібні атрибути контрагента можуть бути розподілені між кількома рівнями master data. А деякі документи агрегуються під час рознесення (posting), що ускладнює відновлення деталізації на рівні окремої операції.

Які трансформації потрібні найчастіше

Типовий набір трансформацій для SAF-T із SAP включає: об'єднання (joins) даних між функціональними областями; мапінг master data; відновлення зв'язків між документами (document relationships); збагачення даних (enrichment) з додаткових джерел; переклад кодів (code translations) між системами класифікації; нормалізацію одиниць виміру та валют; звірку посилань між об'єктами; агрегацію чи деагрегацію даних там, де це обґрунтовано вихідною структурою; вивантаження історичних даних за минулі періоди; мапінг типів документів SAP до типів SAF-T; мапінг рахунків Головної книги; коректну обробку сторнувань (reversals), клірингу, кредит-нот та внутрішньогрупових операцій.

SAF-T для SAP ECC

ECC — класична FI data model з історично більшою кількістю окремих таблиць і агрегатів, можливими Enhancement Packages, часто значним обсягом кастомного ABAP-коду (Z-розробок) і локальних доопрацювань, накопичених за роки експлуатації. Для SAF-T це означає, що мапінг варто будувати на основі фактичної конфігурації конкретної інсталяції, а не лише загальної версії ECC. Особливості мапінгу саме для ECC 6.0 і різних Enhancement Packages розглянемо в окремому матеріалі серії.

SAF-T для SAP S/4HANA

S/4HANA on-premise вводить Universal Journal — уніфіковану структуру фінансових записів, яка спрощує частину логіки, характерної для класичного ECC, а також підхід Business Partner замість роздільних Customer/Vendor master, розвинену екосистему CDS-подань і API. Це може полегшити частину extraction, але не скасовує потреби в мапінгу й enrichment для приведення даних до структури SAF-T UA. Специфіку мапінгу для різних релізів S/4HANA on-premise розглянемо в окремому матеріалі серії.

ECC vs S/4HANA: у чому різниця для SAF-T

Не варто робити висновок, що S/4HANA автоматично простіший за ECC для SAF-T. Коректніше сформулювати так: S/4HANA може спростити частину extraction завдяки Universal Journal і розвиненому API/CDS-шару, але мапінг у структуру SAF-T UA і збагачення даних (enrichment) залишаються окремим завданням незалежно від релізу.

SAF-T для S/4HANA Cloud Private Edition

Private Edition (однокористувацьке хмарне розгортання, історично пов'язане з програмою RISE with SAP) за функціональністю і можливостями розширення ближче до on-premise S/4HANA, ніж до Public Edition. Але це не означає, що можна просто підключитися до бази даних чи HANA напряму — доступ до інфраструктури залежить від умов хостингу й архітектури конкретного SAP cloud landscape. Extraction для Private Edition варто проєктувати через дозволені механізми — API, CDS views, OData-сервіси, інструменти інтеграції SAP чи узгоджену архітектуру реплікації/staging, залежно від конкретного контракту й ландшафту.

SAF-T для S/4HANA Cloud Public Edition

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

SAF-T для SAP Business One

SAP Business One (B1) — окремий продукт для малого й середнього бізнесу, доступний у версіях на Microsoft SQL Server і у версії для SAP HANA (включно з релізами 9.2, 9.3 і 10.0). Data model і архітектура B1 зазвичай компактніші й інші за структурою, ніж у S/4HANA чи ECC, тому SAF-T-проєкт для Business One технічно є окремим класом завдання — з іншим обсягом даних і, як правило, меншою кількістю рівнів master data. Але фактична складність такого проєкту так само залежить від кастомізацій, add-ons, зовнішніх систем і якості даних конкретної інсталяції. Детальний розбір підготовки SAF-T саме для SAP Business One — тема окремого матеріалу серії.

SAF-T для кастомізованого SAP

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

Кілька SAP-систем в одній групі

У групах компаній типові сценарії включають кілька company codes, кілька controlling areas, кілька SAP-клієнтів (clients) чи навіть окремих інсталяцій SAP, паралельну роботу ECC і S/4HANA, поєднання SAP з локальною ERP чи legacy-системою, спільний сервісний центр (shared service center), різні плани рахунків, різні локалізації і різні фінансові роки в різних юридичних особах групи.

У таких випадках SAF-T за конкретну юридичну особу може вимагати зведення даних із кількох джерел в єдину модель — що є ще одним практичним аргументом на користь ERP-independent SAF-T-шару, а не рішення, вбудованого в одну конкретну систему.

Міграція ECC → S/4HANA і SAF-T

Значна частина клієнтів SAP перебуває в процесі або планує перехід з ECC на S/4HANA — не в останню чергу через те, що mainstream maintenance для EHP6–EHP8 SAP ERP 6.0 триває до кінця 2027 року (опційна extended maintenance — до кінця 2030-го), а для старіших версій вона вже завершилася наприкінці 2025-го. Типова практична ситуація: дані за 2025–2026 роки — в ECC, а вже з 2027–2028 років компанія працює в S/4HANA. Запит ДПС на SAF-T може стосуватися періоду, що охоплює обидві системи.

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

Data lineage для SAF-T

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

SAF-T для дуже великих SAP-систем

SAP-клієнти нерідко оперують сотнями мільйонів операцій, і формування SAF-T для такого обсягу вимагає окремого технічного підходу: чітко визначені вікна extraction, дельта- чи пакетну обробку замість повного вивантаження щоразу, окрему staging-базу, партиціонування даних, потокову (streaming) генерацію XML, паралельну трансформацію там, де це можливо, повноцінну reconciliation, здатність процесу перезапускатися з контрольної точки (restartable processing), докладне логування і data lineage. Конкретні показники продуктивності без контексту конкретного ландшафту наводити недоцільно — вони надто залежать від інфраструктури й обсягу даних. Показовий орієнтир масштабу самої вимоги: ДПС публікує власні тестові приклади SAF-T UA обсягом до кількох гігабайт (за версією 2.0 — файли на сотні мегабайтів і приклад обсягом близько 2,4 ГБ), що підтверджує актуальність роботи саме з великими файлами, а не лише з тестовими наборами на кілька записів.

Як перевірити правильність трансформацій

Після трансформації даних SAP варто перевірити результат за низкою критеріїв: підсумки Головної книги узгоджуються з оборотно-сальдовою відомістю (Trial Balance); залишок на початок періоду плюс рухи за період дорівнює залишку на кінець; сальдо розрахунків з контрагентами (клієнтами й постачальниками) узгоджені; підсумки продажів і закупівель відповідають обліковим даним; податкові підсумки узгоджені; кількісні та вартісні залишки запасів відповідають складському обліку; залишки основних засобів узгоджені з балансом; коректно оброблені валюти, сторнування, кліринг і внутрішньогрупові операції. Офіційні контрольні співвідношення, які ДПС може застосовувати при перевірці файлу, тут навмисно не наводяться як вичерпний перелік — цей список варто розглядати як практичний мінімум внутрішньої перевірки.

XSD validation vs логічна валідація

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

Як проходить впровадження SAF-T для SAP

1. SAP landscape assessment — огляд систем, версій і конфігурацій у ландшафті компанії.
2. SAF-T gap-аналіз — які дані відсутні або недостатньо деталізовані.
3. Інвентаризація джерел (source inventory).
4. Трасування вибіркових транзакцій наскрізь — від первинного документа до фінального запису.
5. Mapping — визначення джерела для кожного елемента SAF-T.
6. Проєктування extraction відповідно до доступної моделі доступу (on-premise, Private чи Public Cloud).
7. Розробка правил трансформації.
8. Enrichment — доповнення даних, яких бракує в SAP, з інших джерел.
9. Побудова прототипу.
10. Reconciliation з обліковими даними.
11. XSD-валідація.
12. Логічна валідація.
13. Performance testing на реальних обсягах.
14. User acceptance testing.
15. Налаштування процедури регулярного формування файлу.

Для SAP найбільш трудомісткими етапами зазвичай є discovery, mapping і проєктування трансформацій — а не власне генерація XML, яка технічно є фінальним і відносно простим кроком уже узгодженого процесу.

Чому ERP-independent архітектура зручна для SAP

Архітектура SAF-T-рішення, незалежна від конкретної SAP-системи, зазвичай виглядає як послідовність шарів: SAP (ECC / S/4HANA / Business One / Cloud) та інші системи → extraction → staging → transformation & enrichment → mapping → SAF-T engine → логічний контроль → XSD-валідація → готовий XML з Excel-поданням даних для перевірки.

Переваги такого підходу для SAP-ландшафту конкретні: рішення не прив'язане жорстко до ECC чи однієї версії S/4HANA; воно зберігається при міграції на нову систему; здатне збирати дані з кількох SAP- та не-SAP-джерел одночасно; правила трансформації документовані централізовано, а не розкидані по точкових інтеграціях; простіше адаптувати до оновленої XSD-схеми; і, за потреби, дозволяє обробляти великі обсяги даних поза транзакційним контуром продуктивної SAP-системи.

Як LUCAS впроваджує SAF-T для SAP

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

Головна комерційна логіка тут та сама, що і для інших ERP: для SAP доцільно відокремити бізнес-логіку SAF-T від конкретної версії системи. Тоді при переході ECC → S/4HANA чи зміні SAP-ландшафту не потрібно будувати SAF-T-рішення заново — оновлюється переважно шар extraction і частина мапінгу.

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

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

Так, незалежно від того, чи це ECC, S/4HANA, S/4HANA Cloud чи SAP Business One. Складність визначається не платформою як такою, а конкретним ландшафтом і ступенем кастомізації.

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

Так. Основна робота — мапінг даних, розподілених між модулями, і врахування накопичених за роки кастомних доробок конкретної інсталяції.

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

Так, SAP ERP 6.0 — це та сама лінійка Business Suite 7 / ECC 6.0, і підхід до SAF-T тут аналогічний.

Чи можна сформувати SAF-T із S/4HANA?

Так. Universal Journal і розвинений API/CDS-шар можуть спростити частину extraction, але мапінг у структуру SAF-T UA все одно потрібен.

Чи можна сформувати SAF-T із SAP S/4HANA Cloud?

Так, але модель extraction відрізняється від on-premise: пряма робота з базою даних, як правило, недоступна, і потрібно використовувати офіційні API, CDS views чи OData-сервіси.

Чим Public Edition відрізняється від Private Edition для SAF-T?

Public Edition — стандартизована багатокористувацька SaaS-модель із суворо обмеженим набором дозволених інтеграційних механізмів. Private Edition ближча за гнучкістю до on-premise, але доступ так само залежить від умов конкретного хостингу й контракту.

Чи можна сформувати SAF-T із SAP Business One?

Так. SAP Business One має іншу й зазвичай компактнішу модель даних, ніж великий ECC/S/4HANA-ландшафт. Але фактична складність SAF-T залежить від кастомізацій, add-ons, зовнішніх систем і якості даних — сильно кастомізований B1 не обов'язково простіший за типовий проєкт.

Які SAP-модулі потрібні для SAF-T?

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

Чому недостатньо лише SAP FI?

Бухгалтерська проводка у FI відображає фінансовий результат, але не завжди містить усю деталізацію первинного документа — частина даних (наприклад, про продаж чи закупівлю) зберігається в SD чи MM, а не лише в бухгалтерському записі.

Чи потрібні дані SAP MM і SD?

Часто так. Якщо SAF-T потребує деталізації продажів і закупівель, якої немає у FI, джерелом відповідних атрибутів можуть бути SD, MM або інші системи. Конкретний набір джерел визначається під час mapping і gap-аналізу, оскільки в окремих ландшафтах потрібні дані вже можуть бути зведені в іншу проміжну систему (staging, DWH).

Чи можна формувати SAF-T прямо з SAP HANA?

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

Чи потрібен прямий доступ до SAP database?

Не універсально. Це залежить від моделі розгортання: для on-premise систем контрольований read-only доступ може бути прийнятним варіантом, а для хмарних моделей extraction зазвичай будується через дозволені API та інтеграційні механізми.

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

Проаналізувати їх окремо в межах data discovery — Z-таблиці й кастомні поля часто містять специфічну для конкретної компанії логіку, яку неможливо визначити лише за назвою стандартної SAP-конфігурації.

Чи можна об'єднати SAF-T із кількох SAP-систем?

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

Що станеться із SAF-T при переході ECC → S/4HANA?

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

Чи достатньо XSD-валідації?

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

Скільки трансформацій зазвичай потрібно?

Залежить від складності конкретного SAP-ландшафту та кількості модулів і систем, задіяних у процесі, — універсальної кількості немає, вона визначається після gap-аналізу.

Чи можна додавати дані з Excel або зовнішніх систем?

Технічно так, якщо ці дані структуровані й піддаються мапінгу — типова ситуація, коли частина інформації (наприклад, з WMS, TMS чи MES) не потрапляє в SAP із потрібною деталізацією.

Висновок

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