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

Сформувати SAF-T UA з 1С можна. Обмеження не в платформі, а в якості й повноті даних конкретної бази.
У типовій конфігурації більшість вихідних даних уже структурована: план рахунків, контрагенти, номенклатура, проводки, первинні документи. Але готовий вихідний матеріал — ще не готовий файл.
Складність визначає не назва конфігурації, а ступінь її доопрацювань. Глибоко кастомізована база — це окремий проєкт мапінгу.
1С 7.7 теж може бути джерелом SAF-T. Ризики там вищі через меншу деталізацію довідників і багаторічні доробки, а не через вік платформи.
Для баз на десятки мільйонів проводок стандартна обробка всередині 1С стає вузьким місцем. Потрібні пакетне read-only вивантаження і потокова генерація XML.
Файл, що пройшов XSD, може бути хибним по суті. Головна робота — мапінг і звірка з обліком, а не генерація XML.
Механізм SAF-T, вбудований у конфігурацію 1С, доведеться переписувати при зміні ERP. ERP-незалежний шар зберігає інвестицію.

Від бази 1С до файлу SAF-T: що відбувається між ними

Кнопки «Вивантажити SAF-T» у конфігураціях 1С, як правило, немає. Але навіть якби вона була, формування файлу — це не одна дія, а ланцюжок кроків:

Визначити, де в конкретній базі лежить кожен елемент SAF-T UA.
Звести ці джерела в єдину модель даних.
Доповнити відсутні реквізити.
Згенерувати XML за структурою, затвердженою наказом Мінфіну від 15.09.2020 № 561.
Перевірити результат — спершу за XSD-схемою ДПС, потім логічно.

Схема й бізнес-правила ДПС періодично оновлюються, тому перед формуванням варто звірятися з чинною редакцією. Про структуру файлу — у статті «Що таке SAF-T UA».

Чому 1С — непоганий старт для SAF-T

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

Тому проєкт SAF-T для 1С зазвичай не вимагає перебудови облікової системи. Робота зосереджена поза нею: мапінг полів, нормалізація довідників, заповнення прогалин, валідація.

Важливо. «Дані в 1С добре підходять для мапінгу» і «1С готова до SAF-T» — різні твердження. Готовий лише вихідний матеріал, а не сам файл.

Де в 1С лежать дані для SAF-T UA

Основні блоки SAF-T мають впізнавані аналоги в типовій 1С. У кастомізованій базі джерело може бути іншим — аж до самописного регістру.

Блок SAF-T UA	Типове джерело в 1С	На що звернути увагу
General Ledger	Регістр бухгалтерії, проводки документів	Ручні проводки без прив’язки до первинного документа
Chart of Accounts	План рахунків	Зміна плану рахунків або аналітики посеред періоду
Customers / Suppliers	«Контрагенти», договори, аналітика розрахунків	Дублікати карток, неповні ЄДРПОУ/ІПН, дані нерезидентів
Products / Inventory	«Номенклатура», регістри накопичення, склади, партії	Непослідовне використання субконто й характеристик
Sales	Реалізації, акти, чеки	Розбіжність документів продажу з регістрами доходів
Purchases	Надходження товарів і послуг	Закупівлі без повного комплекту первинних документів
Fixed Assets	Регістри обліку основних засобів	Облік ОЗ в окремій базі чи модулі
Tax	Податкові регістри, облік ПДВ	Податковий і бухгалтерський контури не узгоджені

Особливості різних конфігурацій

1С:Бухгалтерія. Найпередбачуваніший випадок: план рахунків, субконто й типові документи зазвичай ведуться послідовно. Основна робота — прибрати дублікати в довідниках, дозаповнити реквізити нерезидентів і перевірити, що ручні проводки мають підставу для блоку SourceDocuments.

УТП. Оперативний торговий облік і бухгалтерія в одній базі. Даних про продажі та запаси більше, але їх треба узгодити з бухгалтерськими підсумками: регістри товарів — зі складськими залишками й проводками.

УВП. Додається виробничий контур: специфікації, калькуляція, незавершене виробництво. Треба перевірити, що виробничі операції коректно доходять до Головної книги. Нерідко частину виробничих даних веде окремий підрозділ у власних таблицях — це варто виявити на етапі gap-аналізу.

Управління торгівлею. Зазвичай працює в парі з окремою бухгалтерською базою. Ключове питання — чи повно й вчасно дані з торгового контуру доходять до бухгалтерії. Розриви в обміні між базами — прямий ризик для повноти файлу.

1С 7.7. Сформувати SAF-T можна, але ризиків більше: менша деталізація довідників, відсутні реквізити, накопичені доробки, дані в DBF, архівні бази. Втім, вирішує якість конкретної бази: трапляються акуратні бази на 7.7 і недбалі на 8.3.

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

Для BAS, яка історично й технологічно походить з екосистеми 1С, логіка підготовки даних подібна.

Типова, доопрацьована чи глибоко кастомізована

Рівень доопрацювань	Що це означає для SAF-T
Типова конфігурація	Джерела полів передбачувані, індивідуального мапінгу небагато
Помірно доопрацьована	Додаткові реквізити, документи, субконто — потрібен аналіз доробок, але базова логіка зберігається
Глибоко кастомізована	Окремий проєкт мапінгу: аналіз метаданих, SQL-структури, регістрів і реальної бізнес-логіки

Проблеми з даними, які трапляються найчастіше

дублікати контрагентів і номенклатури;
неповні ЄДРПОУ, ІПН, дані нерезидентів;
різна аналітика за субконто для однакових за суттю операцій;
ручні проводки й операції без первинного документа;
старі документи без реквізитів, яких SAF-T вимагає сьогодні;
зарплата, склад, виробництво чи основні засоби в окремих базах;
частина даних у Excel, CRM, WMS чи TMS;
розподілена інформаційна база з розбіжностями між вузлами;
кілька юросіб в одній базі або кілька баз на одну юрособу;
неповна історія після міграції 7.7 → 8.x чи 1С → BAS;
зміна плану рахунків посеред року.

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

Великі бази: коли стандартна обробка не впорається

Десятки мільйонів проводок, кілька років історії, SQL Server, розподілена база чи кілька юросіб — для таких обсягів формування XML обробкою всередині 1С або завантаження всього масиву в пам’ять непрактичне.

Робочі варіанти: пакетне формування, проміжний шар (staging), ETL або контрольоване вивантаження безпосередньо з СУБД, потокова генерація XML і контрольні суми на кожному етапі. Архітектура залежить від обсягу й інфраструктури, але правило одне: доступ до робочої бази — лише на читання.

XSD-валідність — ще не коректність

XSD перевіряє структуру: типи даних, обов’язкові поля, допустимі значення. Вона не бачить помилкового мапінгу, дублікатів, неправильних залишків чи розбіжностей між блоками — наприклад, коли продажі в GeneralLedgerEntries не сходяться з SourceDocuments.

Мінімум логічних перевірок після XSD:

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

Детальніше про два рівні перевірки — у статті «Валідація SAF-T UA».

Етапи проєкту

Аудит даних і їхньої якості.
Інвентаризація джерел: бази, модулі, суміжні системи.
Мапінг SAF-T ↔ 1С.
Gap-аналіз: чого бракує і де це взяти.
Вивантаження, нормалізація, генерація XML.
XSD- і логічна валідація.
Звірка з бухгалтерською звітністю.
Тест на реальних обсягах і приймання користувачами.
Регламент регулярного формування файлу.

Генерація XML — найпростіший крок. Найбільше часу забирають мапінг і звірка: саме там знаходяться розбіжності, які інакше спливли б під час перевірки.

Чому SAF-T не варто вбудовувати в конфігурацію 1С

Щодо продуктів 1С в Україні діють санкційні та кібербезпекові обмеження, перелік яких періодично оновлюється. Для державного й регульованого сектору це може означати пряму заборону, для приватного бізнесу — фактор ERP-стратегії. Правовий контекст ми розбирали в статті «SAF-T UA для SAP, BAS та Odoo».

Але висновок тут практичний, а не політичний. Якщо механізм SAF-T вбудований у конфігурацію, після переходу на BAS, Odoo, SAP чи Dynamics його доведеться будувати заново: інтеграцію, мапінг, валідацію. Якщо SAF-T — окремий шар, змінюються лише вивантаження й мапінг, а ядро й правила перевірок лишаються.

Архітектура такого шару: 1С або СУБД → вивантаження → мапінг → SAF-T engine → XSD і логічна валідація → XML.

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

SAF-T Connector — ERP-незалежне рішення LUCAS. Воно бере дані з 1С, інших облікових систем, напряму з SQL і з додаткових джерел, зводить їх через мапінг і формує XML з Excel-переглядом для перевірки. Перед поданням рішення виконує XSD-валідацію, бухгалтерські контролі й міжсекційні звірки. Розгортається on-premise, тож дані не залишають інфраструктуру клієнта. Мапінг адаптується під фактичну структуру бази — від типової Бухгалтерії до кастомізованих УТП, УВП чи 7.7.

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

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

Так. Платформа не є перешкодою, результат залежить від даних і структури конкретної бази.

Чи потрібно доопрацьовувати конфігурацію 1С?

Не обов’язково. Основна робота відбувається поза конфігурацією — на рівні вивантаження й мапінгу. Точкова доробка довідників доречна, якщо в базі систематично бракує реквізитів, наприклад повних даних контрагентів.

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

Так. Для великих баз це часто практичніше за обробку всередині 1С — за умови контрольованого доступу лише на читання.

Чи можна зібрати SAF-T з кількох баз 1С?

Так, але потрібен окремий етап зведення: довідники в різних базах треба узгодити й очистити від дублікатів.

А якщо частина даних в Excel?

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

Яких даних у 1С найчастіше бракує?

Повних реквізитів нерезидентів, зв’язку ручних проводок з первинними документами та узгодженості, коли зарплата, склад чи виробництво ведуться в окремих базах.

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

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

Що буде із SAF-T після переходу з 1С на іншу ERP?

Якщо рішення побудоване як окремий шар, ядро й правила валідації зберігаються. Під нову систему оновлюються вивантаження і мапінг.

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

SAF-T UA можна сформувати з будь-якої конфігурації 1С — від типової Бухгалтерії до доопрацьованої 7.7. Структура даних 1С — реальна перевага, але вона не скасовує мапінгу, нормалізації, заповнення прогалин і звірки. Друге питання — архітектура: рішення, прив’язане до поточної конфігурації, доведеться переробляти при зміні ERP. Почніть з оцінки готовності або розкажіть про вашу базу — підкажемо підхід.