Перехід з 1С на K2 ERP

Перехід з 1С на K2 ERP — це процес заміни застарілої російської облікової та ERP-екосистеми 1С/BAS на сучасну українську платформу K2 ERP, що дозволяє переносити дані, відновлювати бізнес-процеси, створювати нові модулі, розвивати автоматизацію та будувати незалежну цифрову інфраструктуру компанії.

Перехід з 1С або BAS на K2 ERP не повинен сприйматися як проста технічна операція “експортували — імпортували — забули”. Насправді це значно глибший процес: очищення даних, перегляд процесів, заміна старої логіки, відмова від російської технологічної залежності, побудова нової архітектури обліку та підготовка бізнесу до розвитку.

Головне. Перехід з 1С на K2 ERP — це не втеча з однієї програми в іншу. Це перехід від старої закритої російської екосистеми до сучасної української ERP-платформи, яка розвивається через модулі, YML, ER-моделі, ORM, API, PostgreSQL, Python, TypeScript та штучний інтелект.

Важливо про санкції. Продукти 1С і BAS пов’язані з російською екосистемою та перебувають у санкційному полі України. Санкції щодо суб’єктів, пов’язаних із 1С, запроваджувалися рішеннями РНБО, введеними в дію указами Президента України, зокрема №133/2017 та №601/2024. Також у 2026 році було оприлюднено перелік забороненого до використання програмного забезпечення, до якого потрапили продукти 1С, BAS та UA-Бюджет.

Практична ідея. Міграція з 1С/BAS — це хороший момент не просто перенести старий хаос у нову систему, а навести порядок: очистити довідники, прибрати дублікати, переглянути документи, структурувати залишки, оновити звіти й перебудувати процеси так, як бізнесу потрібно сьогодні.

Типова помилка. Найгірший сценарій переходу — намагатися перенести в K2 ERP усе “як було в 1С”, включно з дублями, тимчасовими доробками, застарілими звітами, костилями, полями “на всяк випадок” і логікою, яку вже ніхто не пам’ятає. Якщо переносити динозавра в нову квартиру, він усе одно залишиться динозавром.

Вступ

Багато українських компаній роками працювали в 1С або BAS.

Ці системи стали звичними для бухгалтерів, менеджерів, складів, керівників і програмістів. У них накопичилися довідники, документи, звіти, залишки, друковані форми, обробки, інтеграції, доробки та локальні правила, які часто існують тільки тому, що “так колись зробив програміст, який уже не працює”.

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

Це питання безпеки.

Це питання санкцій.

Це питання цифрової незалежності.

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

K2 ERP створюється як українська альтернатива 1С/BAS, але не як копія старої системи іншого кольору. Копіювати стару систему — означає успадкувати її обмеження.

Перехід на K2 ERP має бути переходом у нову архітектуру.

Чому компанії переходять з 1С/BAS

Причин для переходу багато.

Одні компанії починають думати про заміну 1С/BAS через санкції та юридичні ризики. Інші — через безпеку. Треті — через застарілу архітектуру. Четверті — через складність підтримки старих доробок. П’яті — через бажання мати сучасну веб-систему, хмару, API та інтеграції.

Основні причини переходу:

санкції та обмеження щодо російського програмного забезпечення;
ризики використання продуктів російського походження;
потреба в українській ERP-платформі;
необхідність веб-доступу;
бажання перейти до сучасної архітектури;
потреба в API та інтеграціях;
складність підтримки старих конфігурацій;
накопичений технічний борг;
залежність від вузьких 1С/BAS-спеціалістів;
потреба в хмарній або гібридній інфраструктурі;
бажання використовувати штучний інтелект;
потреба в швидкому створенні нових модулів;
цифрова незалежність бізнесу.

Санкції щодо 1С та BAS

Під час підготовки переходу з 1С/BAS важливо враховувати санкційний контекст.

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

Україна поступово обмежувала використання такого програмного забезпечення.

Санкції щодо суб’єктів, пов’язаних із 1С, запроваджувалися рішеннями Ради національної безпеки і оборони України, введеними в дію указами Президента України. Зокрема, у 2017 році був Указ Президента України №133/2017, яким введено в дію рішення РНБО щодо застосування персональних спеціальних економічних та інших обмежувальних заходів. У 2024 році Указом Президента України №601/2024 було введено в дію рішення РНБО від 2 вересня 2024 року щодо застосування, скасування та внесення змін до санкцій. У 2026 році був оприлюднений перелік забороненого до використання програмного забезпечення, де серед іншого згадувалися продукти 1С, BAS та UA-Бюджет.

Практичний висновок. Для бізнесу 1С/BAS — це вже не просто “стара знайома програма”. Це програмне забезпечення з російським походженням, санкційними ризиками, репутаційними ризиками та проблемами для довгострокової цифрової стратегії.

Кого стосуються обмеження

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

Для приватних компаній важливо не зводити питання тільки до формального “можна чи не можна саме нам сьогодні”.

Потрібно дивитися ширше:

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

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

Чому не варто чекати до останнього

Багато компаній відкладають перехід з 1С або BAS, бо “поки працює”.

Це зрозуміло.

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

Але чекати до останнього — небезпечно.

Бо міграція в аварійному режимі майже завжди дорожча, нервовіша й менш якісна.

Проблеми відкладеного переходу:

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

Краще правило. Переходити з 1С/BAS потрібно не тоді, коли вже горить, а тоді, коли ще можна спокійно скласти план, зробити тестову міграцію і не шукати програміста о третій ночі.

Що таке K2 ERP

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

На відміну від старої парадигми 1С/BAS, K2 ERP розвивається як сучасна платформа:

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

У K2 ERP важливу роль відіграють:

Перехід як стратегічний проєкт

Перехід з 1С на K2 ERP потрібно сприймати як стратегічний проєкт.

Це не просто “поставити нову програму”.

Це можливість:

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

Правильний перехід дає не тільки нову систему, а й новий рівень керованості бізнесу.

Що потрібно перенести з 1С/BAS

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

Зазвичай переносяться:

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

Але не все потрібно переносити автоматично.

Частину даних краще очистити.

Частину — архівувати.

Частину — не переносити взагалі, якщо вона давно не використовується.

Аудит перед міграцією

Перший етап переходу — аудит поточної системи.

Потрібно зрозуміти, що саме є в 1С або BAS.

Аудит має відповісти на питання:

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

Без аудиту міграція перетворюється на гру “перенесемо все, а потім розберемося”.

А “потім” у таких проєктах часто настає в момент, коли користувачі вже працюють і дуже голосно питають, чому контрагентів стало вдвічі більше.

Інвентаризація конфігурації

У 1С/BAS часто використовуються типові або сильно дороблені конфігурації.

Наприклад:

бухгалтерія;
управління торгівлею;
управління виробничим підприємством;
зарплата і кадри;
документообіг;
BAS ERP;
галузеві конфігурації;
самописні доробки.

Потрібно визначити:

що є типовим;
що дороблено;
що використовується;
що не використовується;
що критично для бізнесу;
що можна замінити стандартним функціоналом K2 ERP;
що потрібно реалізувати окремим модулем.

Карта об’єктів міграції

Для якісного переходу створюється карта об’єктів міграції.

Об’єкт у 1С/BAS	Об’єкт у K2 ERP	Дія	Коментар
Контрагенти	Довідник контрагентів	Перенести з очищенням	Прибрати дублікати, перевірити ЄДРПОУ
Номенклатура	Довідник номенклатури	Перенести з групами	Переглянути одиниці виміру й характеристики
Склади	Довідник складів	Перенести	Перевірити активність складів
Договори	Довідник або об’єкт договорів	Перенести частково	Архівні договори можна залишити в архіві
Замовлення покупців	Документ замовлення	Перенести активні	Старі документи можна перенести в архів
Залишки товарів	Початкові залишки	Перенести на дату переходу	Критичний етап
Взаєморозрахунки	Початкові борги	Перенести на дату переходу	Потрібна звірка
Звіти	Звіти K2 ERP	Переглянути	Не всі старі звіти потрібні

Очищення довідників

Довідники — одна з найбільших проблем при переході.

За роки роботи в 1С або BAS у довідниках часто накопичується хаос.

Типові проблеми:

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

Приклад дублювання:

ТОВ Ромашка
ТОВ "Ромашка"
Ромашка ТОВ
ТОВ РОМАШКА
Romashka LLC

Перед міграцією такі дублікати потрібно об’єднати.

Перенесення контрагентів

Контрагенти — один із ключових довідників.

Під час перенесення потрібно зберегти:

назву;
код;
ЄДРПОУ;
ІПН;
юридичну адресу;
фактичну адресу;
телефони;
email;
банківські реквізити;
договори;
ознаку активності;
групи або категорії.

Приклад структури в YML:

entity: contractor
title: "Контрагенти"
type: directory

fields:
  code:
    type: string
    title: "Код"

  name:
    type: string
    title: "Назва"
    required: true

  edrpou:
    type: string
    title: "ЄДРПОУ"

  tax_number:
    type: string
    title: "ІПН"

  phone:
    type: string
    title: "Телефон"

  email:
    type: string
    title: "E-mail"

  active:
    type: boolean
    title: "Активний"
    default: true

Перенесення номенклатури

Номенклатура — ще один складний довідник.

Потрібно перенести:

код;
назву;
артикул;
групу;
одиницю виміру;
штрихкод;
ціну;
характеристики;
ознаку послуги або товару;
ставку ПДВ;
активність.

Під час перенесення важливо вирішити, як працювати з характеристиками.

Наприклад, у 1С частина властивостей могла бути реалізована через додаткові реквізити, частина — через окремі довідники, частина — просто в назві товару.

Приклад поганої номенклатури:

Футболка синя М
Футболка синя L
Футболка червона М
Футболка червона L

Кращий підхід:

Товар: Футболка
Характеристика: колір = синій, розмір = M
Характеристика: колір = синій, розмір = L

Перенесення складів і залишків

Перенесення залишків — один із найвідповідальніших етапів.

Потрібно визначити дату переходу.

Наприклад:

Дата переходу: 01.01.2027

На цю дату потрібно перенести:

залишки товарів;
залишки по складах;
партії;
серії;
собівартість;
резерви;
незавершені операції.

Приклад таблиці залишків:

Склад	Товар	Кількість	Собівартість
Основний склад	Ноутбук Lenovo	12	28000
Основний склад	Монітор Samsung	25	7200
Склад сервісу	Кабель USB-C	80	95

Залишки потрібно звірити з 1С/BAS до запуску.

Перенесення взаєморозрахунків

Взаєморозрахунки з контрагентами потрібно переносити дуже уважно.

Зазвичай переносяться:

заборгованість покупців;
заборгованість перед постачальниками;
аванси;
неоплачені рахунки;
відкриті договори;
залишки по договорах;
залишки по валюті.

Важливо зробити звірку з бухгалтерією та менеджерами.

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

Перенесення документів

Не всі документи потрібно переносити повністю.

Можливі підходи:

Підхід	Опис	Коли використовувати
Повне перенесення	Переносяться всі документи за весь період	Якщо потрібна повна історія в новій системі
Перенесення активних документів	Переносяться тільки незакриті або актуальні документи	Якщо історію можна залишити в архіві
Перенесення залишків	Переносяться тільки початкові залишки на дату переходу	Якщо стара система залишається архівом
Гібридний підхід	Частина документів переноситься, частина архівується	Найчастіший практичний варіант

Для більшості бізнесів доцільний гібридний підхід.

Стару 1С/BAS можна залишити як архів для перегляду історії, а в K2 ERP перенести активні дані та залишки.

Архів старої системи

Після переходу стара система може залишитися в режимі архіву.

Архів потрібен для:

перегляду старих документів;
перевірок;
аудиту;
історичних звітів;
юридичних питань;
звірки;
підтримки перехідного періоду.

Але архів не повинен залишатися робочою системою.

Інакше компанія отримає дві паралельні ERP, а це вже не міграція, а бухгалтерський серіал із багатьма сезонами.

Перенесення звітів

Старі звіти з 1С/BAS потрібно переглянути.

Не всі звіти варто переносити один в один.

Частина звітів могла бути створена тимчасово.

Частина дублюється.

Частина давно не використовується.

Частина показує дані в незручному вигляді.

Перед перенесенням потрібно скласти список:

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

Для кожного звіту потрібно визначити:

хто його використовує;
як часто;
для якого рішення;
які поля потрібні;
які фільтри потрібні;
чи можна замінити його стандартним звітом K2 ERP;
чи потрібно створити новий звіт.

Приклад карти звітів

Звіт у 1С/BAS	Потрібен після переходу	Рішення в K2 ERP	Коментар
Оборотно-сальдова відомість	Так	Стандартний звіт	Перевірити відповідність обліку
Продажі по менеджерах	Так	Новий управлінський звіт	Додати фільтри по періоду й підрозділу
Залишки по складах	Так	Стандартний складський звіт	Має збігатися на дату переходу
Старий звіт по акціях 2019 року	Ні	Не переносити	Залишити в архіві
Звіт для директора	Так	Дашборд	Краще зробити сучасну панель

Перенесення друкованих форм

Друковані форми часто є дуже важливими для бізнесу.

Потрібно перенести або відтворити:

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

Але друковані форми — це також шанс навести порядок.

Іноді в 1С/BAS існує десять версій одного рахунку:

Рахунок
Рахунок новий
Рахунок новий 2
Рахунок для ПДВ
Рахунок для директора
Рахунок старий не видаляти

У K2 ERP краще одразу зробити нормальну структуру шаблонів.

Перенесення інтеграцій

Інтеграції — один із найважливіших блоків переходу.

У 1С/BAS могли бути інтеграції з:

сайтами;
інтернет-магазинами;
банками;
маркетплейсами;
службами доставки;
CRM;
телефонією;
касами;
електронним документообігом;
BI-системами;
державними сервісами;
складським обладнанням.

Під час переходу потрібно визначити:

які інтеграції критичні;
які працюють стабільно;
які потрібно переписати;
які вже застаріли;
які можна замінити через API;
які краще реалізувати як окремі модулі.

API-first підхід

K2 ERP має розвиватися як система з сильним API.

Це важливо для міграції з 1С/BAS, бо сучасний бізнес не може жити в ізольованій обліковій програмі.

ERP повинна спілкуватися з іншими системами.

Приклад JSON-запиту для створення замовлення:

{
  "external_id": "WEB-10025",
  "date": "2027-01-01",
  "customer": {
    "name": "Іван Петренко",
    "phone": "+380671234567",
    "email": "ivan@example.ua"
  },
  "items": [
    {
      "sku": "NB-001",
      "quantity": 1,
      "price": 32000
    }
  ]
}

Такий підхід значно сучасніший, ніж обмін файлами через папку “Обмін_не_чіпати”.

Вибір дати переходу

Дата переходу — критичне рішення.

Зазвичай обирають:

початок року;
початок кварталу;
початок місяця;
дату після інвентаризації;
дату після закриття періоду.

Найзручніше переходити на початок облікового періоду.

Наприклад:

31.12.2026 — закриття старого періоду в 1С/BAS
01.01.2027 — старт роботи в K2 ERP

Це спрощує перенесення залишків і звірку.

Тестова міграція

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

Тестова міграція дозволяє перевірити:

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

Тестова міграція — це репетиція перед запуском.

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

Контрольні звірки

Після тестової та основної міграції потрібні звірки.

Типові контрольні звірки:

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

Приклад таблиці звірки:

Показник	1С/BAS	K2 ERP	Різниця	Статус
Контрагенти	12500	12480	-20	Потрібна перевірка дублів
Номенклатура	8200	8200	0	Добре
Залишок товарів	4 580 000	4 580 000	0	Добре
Дебіторська заборгованість	1 250 000	1 248 500	-1 500	Перевірити аванси

Навчання користувачів

Перехід на нову ERP неможливий без навчання.

Навчати потрібно не тільки “куди натискати”.

Потрібно пояснити:

нову логіку роботи;
нові довідники;
нові документи;
нові ролі;
нові звіти;
правила введення даних;
типові помилки;
сценарії підтримки;
що змінилося порівняно з 1С/BAS;
чому перехід важливий для бізнесу.

Користувачі повинні розуміти не тільки інтерфейс, а й сенс переходу.

Опір користувачів

Опір змінам — нормальне явище.

Люди звикли до старої системи.

Навіть якщо стара система незручна, вона знайома.

Типові фрази під час переходу:

А в 1С було не так.
А де моя кнопка?
А чому назва інша?
А можна як раніше?
А хто це придумав?

Це не привід зупиняти міграцію.

Це привід правильно організувати навчання, підтримку й поступову адаптацію.

Паралельна робота систем

Іноді на перехідний період 1С/BAS і K2 ERP працюють паралельно.

Це може бути корисно для перевірки.

Але паралельна робота не повинна тривати занадто довго.

Ризики:

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

Краще мати чіткий план:

Тестовий період → міграція → звірка → запуск K2 ERP → 1С/BAS тільки архів

Типові етапи переходу

Етап	Що робиться	Результат
1. Аудит	Аналіз 1С/BAS, даних, доробок, звітів, інтеграцій	Розуміння обсягу переходу
2. Проєктування	Опис майбутньої структури в K2 ERP	Карта міграції та модель
3. Очищення даних	Видалення дублів, архівація старого, нормалізація	Якісніші дані
4. Тестова міграція	Перенесення даних у тестове середовище	Перевірка помилок
5. Налаштування	Форми, меню, права, звіти, інтеграції	Робочий прототип
6. Навчання	Підготовка користувачів	Менше опору на запуску
7. Основна міграція	Перенесення актуальних даних	Готовність до старту
8. Звірка	Перевірка залишків і ключових показників	Підтвердження коректності
9. Запуск	Початок роботи в K2 ERP	Нова система в роботі
10. Підтримка	Допомога користувачам, виправлення, оптимізація	Стабілізація роботи

Технічний сценарій міграції

Технічно міграція може включати кілька каналів перенесення:

експорт з 1С/BAS у файли;
обмін через XML;
обмін через JSON;
пряме читання проміжних таблиць;
імпорт через шаблони;
API-імпорт;
спеціальні конвертори;
ручне очищення критичних довідників;
комбінований підхід.

Найчастіше використовується комбінований підхід.

Наприклад:

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

Приклад структури імпорту контрагентів

code,name,edrpou,phone,email,active
000001,ТОВ Ромашка,12345678,+380501112233,office@romashka.ua,true
000002,ФОП Петренко,23456789,+380671234567,petrenko@example.ua,true

Або у форматі JSON:

[
  {
    "code": "000001",
    "name": "ТОВ Ромашка",
    "edrpou": "12345678",
    "phone": "+380501112233",
    "email": "office@romashka.ua",
    "active": true
  },
  {
    "code": "000002",
    "name": "ФОП Петренко",
    "edrpou": "23456789",
    "phone": "+380671234567",
    "email": "petrenko@example.ua",
    "active": true
  }
]

Приклад структури початкових залишків

{
  "date": "2027-01-01",
  "warehouse": "main",
  "items": [
    {
      "sku": "NB-001",
      "quantity": 12,
      "cost": 28000
    },
    {
      "sku": "MN-001",
      "quantity": 25,
      "cost": 7200
    }
  ]
}

Такі структури можуть використовуватися для імпорту залишків у K2 ERP.

Міграція як можливість для рефакторингу

Міграція — це ідеальний момент для рефакторингу бізнес-логіки.

У старій 1С/BAS могли бути доробки, які вже давно не відповідають реальності.

Наприклад:

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

Під час переходу потрібно вирішити, що справді потрібно перенести, а що краще залишити в минулому.

Що не варто переносити

Не варто переносити:

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

Правило міграції. Не треба переносити сміття тільки тому, що воно історичне. Історичне сміття — це все ще сміття, просто з досвідом.

Що потрібно переносити обов’язково

Обов’язково потрібно перенести або відновити:

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

Перехід бухгалтерії

Бухгалтерія — один із найчутливіших блоків.

Потрібно забезпечити:

коректні початкові залишки;
відповідність рахунків;
перенесення контрагентів;
перенесення договорів;
перенесення відкритих розрахунків;
формування первинних документів;
контроль ПДВ;
звітність;
друковані форми;
звірку з попередньою системою.

Бухгалтери повинні бути залучені до тестової міграції.

Без них запуск буде ризикованим.

Перехід складу

Складський облік потребує точності.

Потрібно перевірити:

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

Перед переходом бажано провести інвентаризацію.

Перехід продажів

Для відділу продажів важливо перенести:

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

Також потрібно навчити менеджерів працювати з новими формами, журналами і звітами.

Перехід закупівель

Для закупівель потрібно перенести:

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

Закупівлі часто залежать від складу, тому їх потрібно тестувати разом.

Перехід виробництва

Виробництво — один із найскладніших напрямів.

Потрібно врахувати:

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

Для виробництва міграція потребує окремого проєктування.

Перехід документообігу

Якщо в 1С/BAS використовувався документообіг, потрібно перенести або відтворити:

внутрішні документи;
маршрути погодження;
ролі погоджувачів;
статуси;
вкладення;
коментарі;
історію погоджень;
шаблони документів.

У K2 ERP це може бути реалізовано через BP-моделі, статуси, процеси, документи та права доступу.

Перехід прав доступу

Права доступу не варто переносити механічно.

У старій системі ролі могли бути налаштовані хаотично.

Потрібно створити нову модель доступу.

Наприклад:

Роль	Доступ
Бухгалтер	Документи обліку, звіти, контрагенти
Менеджер продажів	Клієнти, замовлення, рахунки, залишки
Комірник	Складські документи, залишки, інвентаризація
Керівник	Звіти, дашборди, погодження
Адміністратор	Налаштування, користувачі, ролі

Перехід користувачів

Потрібно перенести або створити користувачів у K2 ERP.

Для кожного користувача потрібно визначити:

ПІБ;
email;
роль;
підрозділ;
права;
активність;
доступ до компаній;
доступ до складів;
доступ до звітів.

Неактивних користувачів краще не переносити як активних.

Роль ER-моделі при переході

ER-модель допомагає описати майбутню структуру даних у K2 ERP.

Під час переходу з 1С/BAS вона дозволяє зрозуміти:

які сутності потрібні;
які довідники створюються;
які документи використовуються;
які зв’язки між об’єктами;
де потрібні табличні частини;
які дані можна об’єднати;
які структури варто змінити.

Приклад:

Контрагент 1 ─── * Договір
Контрагент 1 ─── * Замовлення покупця
Склад      1 ─── * Замовлення покупця
Замовлення 1 ─── * Рядок замовлення
Товар      1 ─── * Рядок замовлення

Роль YML при переході

YML може використовуватися для опису структур компонентів у K2 ERP.

Під час переходу з 1С/BAS YML дозволяє формалізувати нову модель.

Наприклад, опис документа замовлення:

entity: customer_order
title: "Замовлення покупця"
type: document

fields:
  number:
    type: string
    title: "Номер"
    auto: true

  date:
    type: datetime
    title: "Дата"
    required: true

  contractor_id:
    type: reference
    title: "Контрагент"
    entity: contractor
    required: true

  warehouse_id:
    type: reference
    title: "Склад"
    entity: warehouse

table_parts:
  items:
    title: "Товари"
    fields:
      product_id:
        type: reference
        title: "Товар"
        entity: product

      quantity:
        type: decimal
        title: "Кількість"

      price:
        type: decimal
        title: "Ціна"

      amount:
        type: decimal
        title: "Сума"
        calculated: true

З такої моделі K2 ERP може автоматично створювати структуру, ORM-модель, міграції, форми, журнали та базовий функціонал.

AI при переході з 1С/BAS

Штучний інтелект може допомагати в переході.

Його можна використовувати для:

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

Наприклад, можна описати ШІ старий документ із 1С і попросити сформувати YML-модель для K2 ERP.

Створи YML-модель для документа "Замовлення покупця".
Поля: номер, дата, контрагент, склад, коментар.
Таблична частина: товар, кількість, ціна, сума.

Міграція і K2 Update

K2 Update може бути корисним після переходу.

Після міграції компанія отримує не просто статичну систему, а платформу, яку можна оновлювати.

Через K2 Update можуть поширюватися:

нові модулі;
виправлення;
оновлення форм;
нові звіти;
галузеві компоненти;
інтеграції;
шаблони;
покращення бізнес-процесів.

Це важливо, бо ERP не повинна застигнути після міграції.

Вона має розвиватися.

Порівняння 1С/BAS і K2 ERP

Критерій	1С/BAS	K2 ERP
Походження	Російська екосистема	Українська ERP-платформа
Санкційний ризик	Високий	Немає російського санкційного походження
Архітектура	Стара закрита парадигма	Сучасна модульна веб-архітектура
Технології	Власна специфічна екосистема	Python, TypeScript, PostgreSQL, YML, ORM, API
Інтеграції	Часто через доробки й обмінні механізми	Орієнтація на API та сучасні формати
AI	Не є природною основою старої архітектури	Орієнтація на ШІ для моделей, генерації та автоматизації
Модульність	Часто залежна від конфігурацій і доробок	Незалежні компоненти, модулі, K2 Update
Розвиток	Обмежений старою екосистемою	Орієнтація на партнерську екосистему й український ринок

Переваги переходу на K2 ERP

Перехід на K2 ERP дає бізнесу такі переваги:

відмова від російського ПЗ;
зменшення санкційних і репутаційних ризиків;
перехід на українську платформу;
сучасна веб-архітектура;
робота з PostgreSQL;
використання Python і TypeScript;
можливість API-інтеграцій;
модульність;
розвиток через K2 Update;
підтримка YML-моделей;
автоматична генерація компонентів;
можливість використання ШІ;
гнучкість для партнерів та інтеграторів;
можливість хмарного або серверного розгортання.

Ризики переходу

Будь-яка міграція має ризики.

Основні ризики:

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

Ці ризики можна зменшити правильним плануванням.

Як зменшити ризики

Для зменшення ризиків потрібно:

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

План переходу на K2 ERP

Приклад плану:

Тиждень	Роботи
1	Аудит 1С/BAS, збір інформації, аналіз конфігурації
2	Карта міграції, опис довідників, документів, звітів
3	Очищення довідників, підготовка шаблонів імпорту
4	Перша тестова міграція
5	Перевірка результатів, виправлення помилок
6	Налаштування форм, меню, звітів, прав
7	Навчання користувачів, друга тестова міграція
8	Основна міграція, звірка, запуск

Реальні строки залежать від складності компанії.

Мінімальний сценарій переходу

Для малого бізнесу мінімальний сценарій може бути таким:

перенести довідники;
перенести залишки товарів;
перенести взаєморозрахунки;
налаштувати основні документи;
налаштувати базові звіти;
навчити користувачів;
залишити стару 1С як архів.

Це дозволяє стартувати швидко.

Розширений сценарій переходу

Для середнього або великого бізнесу потрібен розширений сценарій:

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

Поетапний перехід

Не завжди потрібно переходити всією компанією одразу.

Можна переходити поетапно:

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

Але поетапний перехід потребує контролю, щоб не створити хаос між старою і новою системами.

Big Bang перехід

Big Bang — це коли компанія переходить на нову систему одразу в певну дату.

Переваги:

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

Недоліки:

високі ризики;
потрібна сильна підготовка;
усі помилки проявляються одночасно;
велике навантаження на підтримку.

Такий підхід краще використовувати тільки після якісної тестової міграції.

Поетапний підхід проти Big Bang

Підхід	Переваги	Недоліки
Поетапний	Менше ризику, легше навчати користувачів	Довше, можливі паралельні системи
Big Bang	Швидкий повний перехід	Високий ризик, потрібна сильна підготовка

Чек-лист готовності до запуску

Перед запуском потрібно перевірити:

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

Перші дні після запуску

Перші дні після запуску найважливіші.

Потрібно організувати:

швидку підтримку користувачів;
канал для питань;
фіксацію помилок;
щоденні короткі підсумки;
контроль критичних документів;
звірку залишків;
перевірку звітів;
пріоритизацію виправлень.

Перші дні не повинні перетворитися на хаотичний чат “у кого що не працює”.

Потрібен порядок.

Типові питання користувачів

Питання	Відповідь
Чи буде все як у 1С?	Не завжди. Частина логіки буде іншою, бо K2 ERP — це не копія 1С, а сучасна платформа.
Чи перенесеться історія?	Залежить від сценарію міграції. Частину історії можна перенести, частину залишити в архіві.
Чи можна буде переглядати старі документи?	Так, стара система може залишитися в режимі архіву або дані можуть бути перенесені частково.
Чи будуть старі звіти?	Критичні звіти потрібно відтворити або замінити новими в K2 ERP.
Чи потрібно навчання?	Так. Навіть якщо логіка знайома, інтерфейс і процеси будуть іншими.
Чи можна буде доробляти систему?	Так. K2 ERP орієнтована на модулі, компоненти, API, YML, ORM і розвиток.

Міграція і цифрова незалежність

Перехід з 1С/BAS на K2 ERP — це частина цифрової незалежності України.

Це означає:

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

Цифрова незалежність — це не гасло.

Це щоденне рішення, на якому програмному забезпеченні працює бізнес.

Чому не треба копіювати 1С

Одна з помилок переходу — вимагати, щоб K2 ERP повністю повторювала 1С.

Це неправильний підхід.

Якщо нова система повністю копіює стару, вона успадковує старі проблеми.

Потрібно переносити бізнес-сенс, а не стару форму.

Наприклад:

не “зробіть таку саму кнопку”;
а “нам потрібно швидко створювати рахунок з замовлення”.

Не “зробіть такий самий звіт”;

а “нам потрібно бачити продажі по менеджерах, товарах і періодах”.

Не “повторіть стару доробку”;

а “нам потрібно автоматизувати цей процес сучасно”.

K2 ERP як новий підхід

K2 ERP має будувати перехід не як копіювання старої системи, а як створення нової платформи.

Ключові відмінності:

модельно-орієнтована розробка;
YML-структури;
ER-моделі;
автоматична генерація;
ORM;
сучасні мови програмування;
API;
модульність;
ШІ;
партнерська екосистема;
K2 Update.

Це дозволяє не просто замінити програму, а створити новий фундамент для розвитку.

Коротко

Питання	Відповідь
Що таке перехід з 1С на K2 ERP?	Це заміна старої російської екосистеми 1С/BAS на сучасну українську ERP-платформу K2 ERP.
Чому потрібно переходити?	Через санкції, безпекові ризики, російське походження 1С/BAS, застарілу архітектуру та потребу в сучасній ERP.
Чи треба переносити всі дані?	Ні. Потрібно переносити актуальні дані, залишки, відкриті документи й критичну історію. Сміття краще не переносити.
Що робити зі старою 1С?	Її можна залишити як архів для перегляду історії, але не як робочу систему.
Що найважливіше при міграції?	Аудит, очищення даних, тестова міграція, звірка залишків, навчання користувачів і підтримка після запуску.
Чи можна перейти поетапно?	Так. Можливий поетапний або одночасний перехід залежно від складності бізнесу.
Чи K2 ERP копіює 1С?	Ні. K2 ERP має бути не копією 1С, а сучасною українською ERP-платформою з новою архітектурою.
Яка роль AI?	ШІ може допомагати аналізувати структури, генерувати YML, створювати моделі, документацію й тестові сценарії.

Висновок

Перехід з 1С на K2 ERP — це важливий крок для українського бізнесу.

Це не просто заміна інтерфейсу.

Це відмова від російської технологічної залежності.

Це реакція на санкційні, безпекові й репутаційні ризики.

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

K2 ERP дає можливість перейти не в “ще одну облікову програму”, а в українську платформу, яка може розвиватися через модулі, YML, ER-моделі, ORM, API, PostgreSQL, Python, TypeScript, штучний інтелект і партнерську екосистему.

Перехід з 1С на K2 ERP — це не просто міграція даних. Це міграція мислення: від старої залежності до сучасної української ERP-архітектури.

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

Див. також

Зовнішні посилання