Переход с 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-хранилище для необработанных сообщений. Для каждой такой записи определите ответственного и процедуру повторной обработки.

Откат и восстановление: договоритесь до запуска

До переключения определите, кто и по каким признакам останавливает новый поток. Сохраните доступ к прежней конфигурации, зафиксируйте точку восстановления и опишите, как обработать записи, уже поступившие в новую систему. Возврат старого коннектора без согласования может создать две версии правды, поэтому отдельно проверьте, не записывались ли данные в обе системы.

Укажите предельное время реакции, канал эскалации и порядок ручной обработки критичных заказов. Если откат без потери новых записей невозможен, включите в план экспорт или другой согласованный способ перенести их обратно. Отработайте сценарий на тесте, прежде чем полагаться на него во время инцидента.

Риски, которые легко упустить:

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

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

Как оценивать новую систему с точки зрения интеграций

Сравнивайте системы на собственных потоках и тестовых примерах. Спросите о документированном API или поддерживаемых форматах импорта, стабильных идентификаторах, вебхуках, ограничениях запросов, журналировании, резервном копировании, тестовой среде и порядке обновлений. Выясните, кто владеет данными и можно ли получить их в пригодном для переноса формате.

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

Команда BotLabs помогает проектировать CRM/ERP-системы и интеграции; подробнее — на странице разработки CRM-систем.

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

Частые вопросы

Источники

• Верховная Рада Украины: карточка законопроекта №13505.
• Верховная Рада Украины: карточка постановления Кабинета Министров №1335.
• Портал правительства: о перечне программного обеспечения и его адресатах.
• Портал правительства: обновление перечня в июне 2026 года.
• Госспецсвязи: ответы на вопросы о сфере применения перечня.
• BotLabs: NFM AGRO — CRM с обменом данными с ERP.