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

Оцінка готовності (readiness assessment) — структурована перевірка компанії перед генерацією SAF-T UA: джерела даних, якість довідників, мапінг рахунків, технічна інфраструктура.
Оцінка виявляє реальні проблеми, а не гіпотетичні ризики: конкретні поля без даних, системи без API, прогалини в довідниках.
Результат — пріоритизований план виправлень і технічне завдання на впровадження.
Без попередньої оцінки впровадження перетворюється на ланцюг несподіванок, де кожен крок відкриває нову проблему.
Від оцінки готовності до першого коректно сформованого і провалідованого файлу — 3–4 місяці за правильної організації.

Що таке оцінка готовності

Це аналіз поточного стану облікових систем і даних компанії з погляду вимог SAF-T UA. На відміну від загального IT-аудиту, фокус вузький і практичний:

де зберігаються всі дані, потрібні для SAF-T UA;
чи є API або інтерфейс для їх вивантаження;
чи заповнені обов’язкові поля (ІПН, ЄДРПОУ, УКТ ЗЕД);
як внутрішній план рахунків співвідноситься зі стандартом SAF-T UA;
чи є розбіжності між первинними документами і проводками;
яка інфраструктура потрібна для розгортання рішення.

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

Чому починати саме з оцінки

У практиці LUCAS оцінка готовності майже завжди виявляє проблеми, про які компанія не знала:

довідник контрагентів, де 40–60% записів без ІПН або з помилковими ІПН, введеними роки тому;
товари з назвами, але без кодів УКТ ЗЕД — бо при введенні цього ніхто не вимагав;
дані за окремі роки в закритій системі без доступного API;
три системи, що ведуть різні частини обліку без наскрізного ідентифікатора операції.

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

П’ять вимірів готовності

Джерела даних і системний ландшафт. Які системи ведуть облік; де живуть проводки, первинка, рух товарів; чи є в кожної системи API; як давно ведуться дані.
Якість довідників (MasterFiles). Повнота і коректність ІПН/ЄДРПОУ постачальників і покупців; коди УКТ ЗЕД; відповідність плану рахунків стандарту; дані про банківські рахунки.
Якість транзакційних даних. Балансування проводок за періоди; зв’язок первинки з проводками; розбіжності між задекларованим і фактичним; коректність дат і валют.
Мапінг плану рахунків. Зіставлення внутрішнього плану з вимогами специфікації; виявлення нестандартних рахунків, що потребують окремого мапінгу.
Технічна інфраструктура. Де розгортатиметься рішення; ОС, пам’ять, диск; мережеві вимоги до підключення джерел; хто відповідає за обслуговування.

Чекліст перевірки

Область	Що перевіряємо	Результат
Системний ландшафт	Перелік систем, API, доступ до даних за потрібні роки	Карта джерел з оцінкою складності підключення
Довідник контрагентів	% заповнення ІПН/ЄДРПОУ, коректність форматів	Звіт про прогалини з кількістю записів
Довідник товарів	Коди УКТ ЗЕД, одиниці виміру	Перелік позицій без кодів і план заповнення
План рахунків	Актуальність, повнота, нестандартні рахунки	Чернетка мапінгу «план рахунків ↔ SAF-T UA»
Транзакційні дані	Балансування, зв’язок із первинкою	Звіт про розбіжності з пріоритетами
Інфраструктура	Сервер, мережа, безпека, команда	Технічні вимоги до розгортання

Типові знахідки

Значна частка контрагентів без ІПН — характерно для компаній, що довго не вели структурований облік ідентифікаторів; виправлення потребує масової роботи з довідником.
Відсутні коди УКТ ЗЕД у великій частині номенклатури — компанії без ЗЕД часто ніколи їх не заповнювали, а специфікація SAF-T UA їх зазвичай вимагає (конкретні вимоги залежать від виду діяльності).
Дані у 2–4 системах без автоматичної консолідації через єдиний ідентифікатор — потрібна логіка зв’язування.
Проводки, що не балансують за окремі періоди — слід коригувань заднім числом чи некоректних закриттів.
План рахунків відсутній або неактуальний у вигляді, придатному для мапінгу.

Жодна з цих проблем не критична, якщо виявлена завчасно. Критичною вона стає, коли запит ДПС уже отримано.

План впровадження: чотири фази

Фаза	Тривалість	Ключові дії	Результат
1. Оцінка готовності	2–4 тижні	Аналіз систем, довідників, транзакцій; чернетка мапінгу	Звіт і план виправлень
2. Підготовка даних	4–8 тижнів	Заповнення ІПН/ЄДРПОУ та УКТ ЗЕД, фіналізація мапінгу, усунення розбіжностей	Дані, готові до генерації
3. Впровадження і тестування	4–6 тижнів	Розгортання конектора, підключення джерел, тестова генерація, валідація, навчання	Валідний тестовий файл
4. Фінальна генерація і подання	Ongoing	Генерація за звітний період, валідація, архівування, передача за сценарієм	Перший коректний SAF-T-файл і відпрацьований процес

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

Як проходить оцінка з LUCAS

Підхід поєднує аудиторську методологію з технічним впровадженням: перевіряємо не лише IT-архітектуру, а й те, що саме ДПС дивитиметься у файлі.

Kick-off — знайомство з командою, огляд систем і документації.
Технічний аналіз — доступність API, структура даних, можливості вивантаження.
Аналіз якості даних — автоматизована перевірка довідників і транзакцій: відсоток заповнення, формати, перехресні звірки.
Мапінг рахунків — зіставлення плану з вимогами SAF-T UA, виявлення нестандартних рахунків.
Звіт і план — пріоритизований перелік проблем з оцінкою трудомісткості та порядком дій.

Після оцінки клієнт має конкретну картину: що робити, скільки це триватиме і яке технічне рішення реалістичне.

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

Скільки коштує оцінка готовності?

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

Чи можна провести оцінку власними силами?

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

Дані дуже неякісні — чи є сенс у конекторі?

Так. Конектор — не лише генератор XML, а й інструмент системного виявлення і виправлення проблем у даних. Впровадження мотивує привести довідники до ладу, що саме по собі підвищує якість обліку.

Частина даних за потрібні роки недоступна — що робити?

Типова ситуація після міграцій. Варіанти: відновлення з архівних копій; підключення до застарілої системи для вивантаження; підготовка обґрунтування щодо відсутніх даних і з’ясування позиції ДПС у конкретній ситуації. Правильний шлях визначається під час оцінки.

У нас уже налаштований SAF-T-модуль в ERP — оцінка потрібна?

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

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

Від 6 до 14 тижнів залежно від складності: проста архітектура (одна ERP з API, чисті довідники) — ближче до 6; мультисистемне середовище зі значними прогалинами — 10–14 і більше.

Що як ДПС змінить специфікацію?

LUCAS супроводжує клієнтів при оновленнях: відстежує зміни специфікації і XSD-схеми, оновлює SAF-T Connector і допомагає з переналаштуванням.

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

Оцінка готовності — не витрата часу перед впровадженням, а його економія під час впровадження. Команди, що стрибають одразу в технічну реалізацію, витрачають більше на ітераційні виправлення того, що можна було виявити за 2–4 тижні на старті. Якість SAF-T-файлу — дзеркало якості облікових даних; оцінка показує, яке це дзеркало насправді, і дає час виправити картину до того, як її побачить ДПС.