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

Коротко

• SAF-T UA можна сформувати з 1С — платформа сама по собі не є перешкодою; питання завжди в конкретних даних конкретної бази.
• У типовій або помірно модифікованій конфігурації 1С значна частина потрібних для SAF-T даних (план рахунків, довідники контрагентів і номенклатури, проводки, первинні документи) вже існує у структурованому вигляді.
• Це не означає, що «1С повністю готова до SAF-T» — потрібні мапінг кожного поля, нормалізація довідників, доповнення відсутніх реквізитів і валідація.
• Підхід відрізняється залежно від конфігурації: 1С:Бухгалтерія, УТП, УВП, Управління торгівлею, 1С 7.7 і галузеві рішення мають різну структуру довідників і документів.
• SAF-T теоретично можна сформувати і з 1С 7.7 — ризики там вищі не через «вік» платформи, а через типово меншу деталізацію даних і нестандартні доробки.
• XSD-валідність файлу не означає автоматично коректний SAF-T: файл може пройти структурну перевірку, але містити неправильний мапінг, дублікати чи розбіжності між журналом проводок і залишками.
• Для великих баз 1С (десятки мільйонів проводок, кілька юросіб, SQL Server) формування SAF-T стандартною обробкою 1С — не найкращий підхід; потрібні контрольована пакетна обробка й read-only extraction.
• SAF-T-рішення, жорстко вбудоване в 1С, створює технологічний ризик при майбутній міграції на іншу ERP — доцільніше проєктувати SAF-T Connector незалежно від конкретної облікової системи.
• Найважливіша частина впровадження — не генерація XML, а мапінг джерел даних і звірка (reconciliation) з бухгалтерською звітністю.

Як сформувати SAF-T UA з 1С

Формування SAF-T UA з 1С — це не одна технічна операція «вивантажити XML», а послідовний процес: визначити, де саме в конкретній базі 1С зберігається кожен елемент SAF-T UA (план рахунків, довідники, проводки, первинні документи), звести ці джерела в єдину модель даних, доповнити відсутні реквізити, згенерувати XML-файл за структурою, встановленою наказом Мінфіну від 15.09.2020 №561 (зареєстрований у Мін'юсті 12.11.2020 за №1123/35406, набрав чинності 27.08.2021), і провалідувати результат — спочатку за XSD-схемою, потім за логікою. Технічний опис структури файлу й актуальну XSD-схему публікує ДПС; конкретна XSD-версія та бізнес-правила можуть оновлюватися, тому перед формуванням варто перевіряти чинну редакцію.

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

Чому структура 1С добре підходить для SAF-T UA

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

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

Які конфігурації 1С підтримують формування SAF-T

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

1С:Підприємство 8 — основна платформа для більшості чинних впроваджень: 1С:Бухгалтерія 8 для України та її Базова версія, 1С:Управління торговим підприємством для України (УТП, УТП8), 1С:Управління виробничим підприємством для України (УВП), 1С:Управління торгівлею для України, 1С:Управління невеликою фірмою для України, 1С:Зарплата і Управління Персоналом для України, 1С:Роздріб, 1С:Документообіг, 1С:Консолідація, а також різноманітні комплексні конфігурації, що поєднують кілька контурів обліку в одній базі.

1С 7.7 — досі трапляється в експлуатації, здебільшого в компаніях, які з тих чи інших причин не мігрували на 8-у платформу: 1С:Бухгалтерія 7.7 для України, Торгівля і Склад 7.7, Зарплата і Кадри 7.7, Комплексна поставка для України, а також галузеві конфігурації на кшталт «Виробництво + Послуги + Бухгалтерія».

Окремо варто зважати, що в Україні досі експлуатуються старі, локалізовані або сильно модифіковані конфігурації на різних платформах — 7.7, 8.1, 8.2 і 8.3, — і версія платформи сама по собі не визначає, наскільки складно буде побудувати SAF-T-мапінг.

Галузеві та спеціалізовані рішення на базі 1С охоплюють практично всі сектори економіки:

• Торгівля і роздріб: Управління торговим підприємством, Управління торгівлею, Роздріб, а також вузькогалузеві рішення для магазинів одягу та взуття, автозапчастин, ювелірних виробів, побутової техніки, книжкових магазинів, будівельних матеріалів, салонів оптики та аптечного роздрібу.
• Виробництво: Управління виробничим підприємством та галузеві рішення для металургійних комбінатів, фармвиробництва, м'ясокомбінатів, хлібобулочного й кондитерського виробництва, лікеро-горілчаних і виноробних заводів, борошномельно-круп'яного виробництва, елеваторів і комбікормових заводів, процесного виробництва (хімія) та ремонтних підприємств.
• Агросектор: Управління сільськогосподарським підприємством, рішення для елеваторів і комбікормових заводів, а також аграрні кастомні конфігурації на базі УВП чи УТП.
• Послуги: конфігурації для ресторанів і громадського харчування, фітнес-клубів, салонів краси, автосервісів, сервісних центрів, турагенцій, таксі та оренди автомобілів.
• Логістика: TMS «Логістика», Управління транспортним підприємством, а також складські та транспортні модулі в межах більших конфігурацій.
• Будівництво: Бухгалтерія будівельної організації та кастомні конфігурації для девелоперів і генпідрядників.
• Фарма: Управління аптечною мережею, Роздріб: Аптека, рішення для фармвиробництва.
• Інші напрями: управління майном, MDM-системи, документообіг, управління ремонтами, а також численні галузеві та самописні конфігурації, які не входять до жодної із зазначених категорій.

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

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

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

SAF-T для 1С:Бухгалтерія

1С:Бухгалтерія для України — конфігурація з найбільш передбачуваною для SAF-T структурою: план рахунків, стандартний набір субконто, регістр бухгалтерії і типові документи первинного обліку тут зазвичай ведуться послідовно. Основна робота з мапінгу — узгодити довідник контрагентів і номенклатури (якщо історично заводились дублікати), перевірити повноту реквізитів контрагентів-нерезидентів і переконатися, що ручні проводки мають достатнє обґрунтування для SourceDocuments. Це, як правило, найпростіший стартовий кейс серед конфігурацій 1С — детальніше про специфіку саме цієї конфігурації ми розглянемо в окремій статті серії.

SAF-T для 1С УТП

1С:Управління торговим підприємством для України (УТП, УТП8) поєднує оперативний торговий контур і бухгалтерію в одній базі, тому дані про продажі, закупівлі та запаси часто деталізованіші, ніж у чистій бухгалтерській конфігурації, — але й мапінг складніший через більшу кількість документів і регістрів оперативного обліку, які потрібно узгодити з бухгалтерськими підсумками. Типове завдання — звірити регістри оперативного обліку товарів зі складськими залишками і бухгалтерськими проводками, щоб уникнути розбіжностей у SAF-T-файлі. Докладніше про підготовку SAF-T саме для УТП — тема окремого матеріалу серії.

SAF-T для 1С УВП

1С:Управління виробничим підприємством для України (УВП) додає виробничий контур — специфікації, планування, облік витрат і калькуляцію собівартості. Для SAF-T це означає додаткову роботу з даними про запаси незавершеного виробництва, партії матеріалів і готової продукції, а також перевірку, що виробничі проводки коректно потрапляють у General Ledger. У компаніях з УВП часто трапляється ситуація, коли частина виробничих даних веде окремий підрозділ у власних таблицях поза системою, — це джерело, яке варто виявити на етапі gap-аналізу. Детальніше про SAF-T для виробничих конфігурацій — в окремій статті серії.

SAF-T для Управління торгівлею

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

SAF-T для 1С 7.7

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

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

SAF-T для галузевих конфігурацій

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

Чим відрізняється SAF-T для типової і кастомізованої 1С

Складність SAF-T-проєкту для 1С визначає не назва конфігурації, а ступінь її кастомізації.

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

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

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

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

Типові проблеми даних 1С

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

• Дублікати контрагентів, заведені під різними картками для того самого підприємства.
• Неповні коди ЄДРПОУ, ІПН або дані нерезидентів у довіднику контрагентів.
• Некоректні або історично змінені довідники — назви, реквізити, категорії мінялися протягом років без ретроспективного оновлення.
• Непослідовне використання субконто — однакові по суті операції відображені з різною аналітикою.
• Ручні проводки без чіткого зв'язку з первинним документом.
• Операції, введені без первинного документа взагалі.
• Старі документи, які не містять реквізитів, потрібних для SAF-T сьогодні.
• Неповна узгодженість податкового й бухгалтерського контурів обліку.
• Дані про основні засоби, що зберігаються в окремій конфігурації чи модулі.
• Зарплата, яка ведеться в окремій базі без прямого зв'язку з основною.
• Торгівля, склад і виробництво, розведені по кількох окремих базах.
• Частина оперативних чи допоміжних даних, що досі ведеться в Excel.
• Дані з CRM, WMS, TMS, MES чи іншої суміжної системи, які не потрапляють у бухгалтерську базу з потрібною деталізацією.
• Розподілена інформаційна база (РІБ) з можливими розбіжностями між вузлами.
• Кілька юридичних осіб, які ведуться в одній базі.
• Кілька баз для однієї юридичної особи — історично розділені за роками чи напрямами діяльності.
• Закриті чи архівні бази за старі звітні періоди, потрібні для ретроспективного SAF-T.
• Наслідки міграції 7.7 → 8.x або з 1С на BAS, коли частина історії перенесена не повністю або зі спрощеннями.
• Зміна плану рахунків чи структури аналітики в середині періоду, яка ускладнює зведення даних за весь рік.

Жодна з цих проблем не є унікальною для 1С — вони типові для будь-якої облікової системи з тривалою історією експлуатації. Але саме тому їх варто виявляти на етапі gap-аналізу, а не під час формування фактичного файлу на запит ДПС.

XSD-валідність ще не означає правильний SAF-T

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

Файл, структурно валідний за XSD, усе одно може містити неправильний мапінг полів, неповні дані за окремими операціями, логічні розбіжності, некоректно розраховані залишки, дублікати контрагентів чи номенклатури, а також невідповідність між різними блоками файлу — наприклад, коли сума продажів у GeneralLedgerEntries не збігається з сумою відповідних документів у SourceDocuments. Детальніше про два рівні перевірки й типові помилки — у статті «Валідація SAF-T UA: XSD-схема, бізнес-правила і типові помилки».

Що робити, якщо база 1С дуже велика

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

Для дуже великих баз стандартна обробка всередині 1С може стати вузьким місцем. У таких випадках варто окремо оцінити пакетне формування, staging-layer, ETL або контрольоване read-only extraction із бази даних — а також потокову (streaming) генерацію XML і контрольні суми й підсумки (checksum/totals) для перевірки цілісності на кожному етапі. Конкретна архітектура залежить від конфігурації, обсягу даних, інфраструктури та вимог клієнта. Незалежно від обраного підходу, доступ до продакшн-бази має бути контрольованим і виключно read-only.

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

Типовий проєкт впровадження SAF-T для 1С проходить через кілька практичних етапів:

1. Data audit — огляд наявних даних і їхньої якості.
2. Inventory джерел — які бази, модулі й системи містять потрібні дані.
3. Mapping SAF-T ↔ 1С — визначення джерела для кожного елемента файлу.
4. Gap-аналіз — які дані відсутні або недостатньо деталізовані.
5. Extraction — контрольоване вивантаження даних із джерел.
6. Transformation / нормалізація — приведення даних до єдиної структури.
7. Генерація XML.
8. XSD-валідація.
9. Логічна валідація.
10. Reconciliation — звірка з бухгалтерською звітністю.
11. Performance testing — перевірка роботи на реальних обсягах даних.
12. User acceptance — приймання результату відповідальними користувачами.
13. Процедура регулярного формування файлу на майбутнє.

Найважливіша частина цього процесу — не генерація самого XML (це технічно проста дія після завершення мапінгу), а мапінг і reconciliation. Саме тут виявляються й усуваються розбіжності, які інакше спливли б лише під час фактичної перевірки ДПС.

Як перевірити сформований SAF-T

Крім проходження XSD-схеми, варто перевірити файл за низкою логічних критеріїв:

• XML проходить актуальну на дату формування XSD-схему.
• Дебет дорівнює кредиту за кожною операцією й у підсумку.
• Залишок на початок періоду плюс рух за період дорівнює залишку на кінець періоду.
• Обороти узгоджуються з оборотно-сальдовою відомістю та Головною книгою.
• Дані про продажі узгоджуються з рахунками обліку доходів.
• Дані про закупівлі узгоджуються з відповідними обліковими даними.
• Залишки запасів узгоджуються з регістрами складського обліку.
• Дані про основні засоби узгоджуються з балансом і відповідними регістрами.
• Усі ключові довідники (контрагенти, номенклатура, рахунки) мають унікальні ідентифікатори.
• У файлі відсутні дублікати записів довідників.
• Обов'язкові за схемою реквізити заповнені, а не залишені порожніми чи заповнені формально.

Наведений перелік — практичний мінімум внутрішньої перевірки й не замінює актуальні XSD-схеми, технічні описи, приклади файлів та інші контрольні матеріали, які публікує ДПС.

Чи варто вбудовувати SAF-T безпосередньо в 1С

До цього питання варто підходити обережно й окремо від питання про заборону 1С як такої. В Україні існують санкційні та кібербезпекові обмеження щодо низки продуктів 1С — актуальний перелік потрібно перевіряти на дату публікації, оскільки він періодично оновлюється. Для частини державного й регульованого сектору це може створювати прямі обмеження; для приватного бізнесу пряма заборона наразі відсутня, але це також може бути фактором ERP-стратегії й майбутньої міграції — детальніше про це ми писали в статті «Перелік забороненого ПЗ оновлено: що робити бізнесу з 1С, BAS та обліковими системами».

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

Що станеться із SAF-T при міграції з 1С на іншу ERP

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

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

Як працює ERP-independent SAF-T Connector

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

Типова архітектура такого незалежного рішення виглядає як послідовність шарів: ERP чи база даних → шар extraction (контрольоване вивантаження даних) → шар mapping (приведення до моделі SAF-T) → SAF-T engine (побудова структури файлу) → валідація (XSD і логічна) → готовий XML. При зміні ERP оновлюються переважно шари extraction і mapping — сам SAF-T engine і логіка валідації залишаються стабільними. Для 1С це особливо актуально через реальний ризик майбутньої міграції ERP — саме на цьому принципі побудований SAF-T Connector LUCAS.

Що робити бізнесу зараз

• Провести інвентаризацію джерел даних: скільки баз 1С використовується, які модулі й підсистеми задіяні.
• Оцінити ступінь кастомізації конфігурації — типова, помірно чи глибоко кастомізована.
• Перевірити якість ключових довідників — контрагентів і номенклатури — на дублікати й неповні реквізити.
• Визначити, чи всі потрібні для SAF-T дані (основні засоби, зарплата, склад) ведуться в тій самій базі, чи розкидані по окремих системах.
• Сформувати тестовий SAF-T-файл за невеликий період, щоб побачити реальний стан даних, а не оцінювати готовність абстрактно.
• Розглядати архітектуру рішення з урахуванням можливої майбутньої зміни ERP, а не лише поточної конфігурації 1С.

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

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

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

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

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

Так. Платформа 1С сама по собі не є перешкодою для формування SAF-T UA — питання завжди в конкретних даних і структурі конкретної бази, а не в платформі як такій.

Чи можна сформувати SAF-T з 1С:Бухгалтерія?

Так, 1С:Бухгалтерія часто є одним із більш передбачуваних випадків для мапінгу SAF-T завдяки типовій структурі плану рахунків, довідників і документів.

Чи можна сформувати SAF-T з УТП?

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

Чи можна сформувати SAF-T з УВП?

Так, з додатковою увагою до виробничого контуру — запасів незавершеного виробництва, калькуляції собівартості і того, чи всі виробничі дані взагалі ведуться в основній базі.

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

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

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

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

Чи потрібно змінювати 1С для SAF-T?

Не обов'язково фундаментально. У більшості випадків основна робота виконується на рівні extraction і mapping поза конфігурацією, без глибокого втручання в саму 1С.

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

Іноді — якщо в базі систематично бракує реквізитів, потрібних для SAF-T (наприклад, повних даних контрагента), точковий доробок довідників може бути доречним. Але це не є обов'язковою умовою для формування файлу.

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

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

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

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

Скільки займає впровадження SAF-T для 1С?

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

Які дані найчастіше відсутні в 1С?

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

Чи достатньо пройти XSD-валідацію?

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

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

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

Чи можна об'єднати дані 1С і Excel в одному SAF-T?

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

Висновок

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