Перехід з 1С/BAS: як зберегти інтеграції сайту, CRM і маркетплейсів

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

Правовий контекст: що перевірити перед плануванням

Постанова Кабінету Міністрів №1335 затвердила порядок формування та ведення переліку програмного забезпечення й обладнання, що створює ризики. Це не формулювання універсальної заборони для кожної приватної компанії. Держспецзв’язку публікує конкретні позиції, а вимоги залежать від системи, даних, статусу установи чи оператора та інших обставин. Перед рішенням звірте конкретний продукт із чинним переліком і отримайте юридичну оцінку саме для вашого випадку.

Законопроєкт №13505 відхилено та знято з розгляду 30 червня 2026 року. Згадувані в обговореннях 2% обороту й дата 2030 року не є чинним правом на підставі цього законопроєкту. Це питання варто відокремити від технічного плану: інвентаризація інтеграцій корисна для керованого переходу, але сама собою не визначає юридичний обов’язок компанії.

Де саме виникає ризик під час переходу

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

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

Інвентаризація: опишіть кожен потік окремо

Складіть реєстр не просто систем, а напрямків обміну. Один сервіс може мати кілька незалежних потоків: наприклад, отримувати каталог і відправляти замовлення. Для кожного запишіть:

• Дані й мету: що саме передається та для якого процесу.
• Джерело й одержувача: яка система є власником даних, а яка лише використовує копію.
• Напрямок і режим: односторонній чи двосторонній обмін, за розкладом, подією або вручну.
• Ідентифікатори та правила: ключі зіставлення, довідники, трансформації, валюти й одиниці виміру.
• Технічний контракт: API, файл, прямий доступ до бази або проміжний сервіс; формат, автентифікація та обмеження.
• Відновлення й контроль: де видно помилки, як повторити операцію, як звірити результат і хто реагує.
• Власника: бізнес-відповідального та технічну команду, включно з підрядником, якщо він підтримує з’єднання.

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

Типові потоки та що в них перевіряти

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

Приклади інтеграцій не дорівнюють кейсам міграції. У кейсі MedHouse Club описано обмін каталогу, цін, наявності й замовлень між обліком та Telegram/Viber-магазинами. Це приклад того, як облікова система може підтримувати кілька каналів. Він не підтверджує, що проєкт був міграцією з 1С/BAS на іншу платформу.

NFM AGRO демонструє інший сценарій: мобільна CRM обмінюється даними з ERP через REST API. Це приклад інтеграції ERP і CRM, а не доказ переходу з 1С/BAS. Такі приклади корисні, щоб побачити типи потоків, але склад і поведінку вашої інтеграції потрібно встановити окремо.

Для ширшого контексту можна переглянути опубліковані матеріали про автоматизацію бізнес-процесів і n8n у робочих процесах. Інструменти автоматизації можуть обслуговувати окремі потоки, але самі собою не замінюють бухгалтерську чи ERP-систему.

Коли допоможе інтеграційний шар

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

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

Сім кроків переходу інтеграцій

1. Зафіксуйте поточний стан. Збережіть схеми, налаштування, розклади, приклади повідомлень, версії конекторів і контактних осіб. Перевірка: інша людина може пояснити призначення кожного потоку.
2. Визначте цільову модель даних. Узгодьте власників довідників, ідентифікатори, статуси, обов’язкові поля й правила перетворення. Перевірка: для кожного поля є джерело, значення та правило зіставлення.
3. Підготуйте адаптер і тестове середовище. Перенесіть обмін на тестову інсталяцію, не спрямовуючи тестові замовлення в бойові процеси. Перевірка: доступи обмежені, а журнал містить корисні помилки без секретів.
4. Перевірте сценарії та межі. Пройдіть успішне створення, зміну, скасування, дубль, часткову помилку, порожнє значення й недоступність однієї системи. Перевірка: критичні бізнес-правила збігаються з погодженими прикладами.
5. Запустіть контрольований паралельний прогін. Якщо архітектура дозволяє, порівнюйте результати нової системи зі старою на копіях або в режимі без побічних записів. Перевірка: розбіжності класифіковані та пояснені до перемикання.
6. Перемикайте потоки по одному. Узгодьте вікно, відповідальних, ознаки успіху та зворотний маршрут. Перевірка: контрольні замовлення, залишки й статуси пройшли шлях до кінцевої системи; повторне повідомлення не створило дубль.
7. Звірте дані й закрийте старий маршрут. Порівняйте кількість і суми документів, залишки, статуси та відкладені операції за визначений період. Перевірка: бізнес-власник прийняв розбіжності, а старий маршрут вимикають лише після узгодження.

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

Rollback і відновлення: домовтеся до запуску

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

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

Ризики, які легко пропустити:

• Невідомі залежності: старий скрипт або ручний експорт не потрапив до реєстру.
• Семантичні відмінності: схожі назви статусів означають різні етапи процесу.
• Повторна доставка: вебхук або запит приходить вдруге й створює дубль без idempotency key.
• Тиха втрата: повідомлення не обробилося, а система не показала його в черзі помилок.
• Розбіжності часу: різні часові зони або затримки змінюють порядок оновлень.
• Надмірні доступи: тимчасові ключі залишилися активними після тесту чи перемикання.
• Передчасне вимкнення: старе з’єднання зупинили до завершення звірки й обробки відкладених даних.

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

Як оцінювати нову систему за інтеграціями

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

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

BotLabs допомагає проєктувати CRM/ERP-системи та їхні інтеграції; докладніше — на сторінці розробки CRM-систем.

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

Поширені запитання

Джерела

• Верховна Рада України: картка законопроєкту №13505.
• Верховна Рада України: картка постанови Кабінету Міністрів №1335.
• Урядовий портал: про перелік програмного забезпечення та його адресатів.
• Урядовий портал: оновлення переліку в червні 2026 року.
• Держспецзв’язку: відповіді на запитання щодо сфери застосування переліку.
• BotLabs: NFM AGRO — CRM з обміном даними з ERP.