Когда обмен между системами «внезапно перестал работать», в большинстве случаев ничего внезапного не произошло: одну из смежных систем обновили по плану. Релиз конфигурации, переезд CRM на новую версию облака, изменение Bot API мессенджера, смена версии языковой модели у провайдера — всё это происходит по чужому календарю и почти всегда с предупреждением, которое приходит на почту сотрудника, не понимающего, что письмо надо кому-то переслать.
Сквозной пример здесь тот же, что и в остальных материалах раздела: оптовая компания на 60 человек, около 74 заказов в рабочий день, обмен с 1С:УТ по остаткам и статусам, CRM, ассистент в клиентском канале и провайдер языковой модели. Четыре внешние зависимости — и четыре чужих календаря обновлений, ни один из которых с вашим не согласован.
Защита стоит недорого и состоит из трёх вещей: постоянная тестовая копия, чек-лист из пяти операций и правило предупреждать подрядчика за пять рабочих дней. Ниже — какие изменения ломают обмен, во что обходится разница между «предупредили» и «узнали постфактум» и что об этом пишут в договоре поддержки.
Четыре типа ломающих обновлений
Обновление смежной системы ломает обмен четырьмя разными способами, и они отличаются не столько техникой, сколько скоростью обнаружения. Два первых видны сразу и потому дёшевы; два последних тихие, и в них уходят основные деньги.
| Тип изменения | Как выглядит со стороны бизнеса | Когда замечают | Что защищает |
|---|---|---|---|
| Изменился интерфейс обмена: переименован метод, сменился адрес, ужесточена проверка данных | Обмен встал целиком и сразу, в журнале ошибки на каждой попытке | В первые часы | Прогон на копии до боевого обновления |
| Отозван или сменён токен, ключ, сертификат | Обмен встал резко и целиком, при этом накануне ничего не меняли | Сразу, но причину ищут долго | Реестр сроков и напоминание за 14, 3 и 1 день |
| Сменилась структура справочника: добавлен реквизит, изменён тип, введена иерархия | Обмен идёт и ошибок почти нет, но часть записей не находится или привязывается не туда | От недели до месяца | Счётчик записей «не найдено» и суточная сверка количеств |
| Появились новые обязательные поля | Часть документов перестала создаваться, остальные проходят нормально | От суток до недели | Очередь необработанного и разбор отказов |
Третий тип самый дорогой, потому что не подаёт сигнала. Формально обмен здоров: запросы уходят, ответы приходят, ошибок нет. Просто часть номенклатуры после введения иерархии перестала сопоставляться, и заказы по этим позициям тихо ложатся мимо. Технический мониторинг такое не видит — нужны бизнесовые сигналы, а не проверка доступности.
Карта связей: в центре блок «наш контур автоматизации», от него четыре линии к внешним узлам — «1С:УТ», «CRM», «Bot API мессенджера», «провайдер языковой модели». На каждой линии подпись, что передаётся: «остатки и статусы заказов», «сделки и контакты», «сообщения клиентов», «запросы к модели». Под каждым узлом маленькая полоска календаря со своей частотой обновлений: «3 релиза в год», «облако, без предупреждения», «версии API», «смена версии модели». Внизу подпись «четыре чужих календаря». Чертёжный стиль, подписи по-русски.
Тестовая копия и чек-лист из пяти операций
Правило звучит скучно и работает почти всегда: сначала обновляем копию, прогоняем по ней пять операций, и только потом трогаем рабочую систему. Копия должна быть постоянной и обновляться из вчерашнего резерва по расписанию — разовая, снятая «когда-то весной», не годится: в ней нет ни свежих справочников, ни последних правок обмена.
- 1Типовой документ туда и обратно
Создать заказ покупателя — самый ходовой тип документа, — провести его через обмен и вернуть статус обратно. Это проверяет маршрут целиком, а не отдельный метод. Ожидаемый результат записывается заранее: номер, сумма, вернувшийся статус.
- 2Выгрузка справочника целиком
Прогнать не выборку, а весь справочник номенклатуры или контрагентов и сравнить два числа: сколько записей ушло и сколько сопоставилось. Разница — это и есть счётчик «не найдено», главный индикатор тихой поломки третьего типа.
- 3Создание новой сущности
Завести нового контрагента и новую позицию номенклатуры и провести по ним операцию. Обновление часто ломает именно создание, оставляя рабочим обновление существующих записей, — и на бою это всплывает с первым новым клиентом.
- 4Отмена и сторно
Обратная операция ломается чаще прямой: её реже тестируют, а условий больше. Отменить заказ, вернуть остаток — и проверить, что смежная система приняла отмену, а не создала второй документ.
- 5Сверка счётчиков за сутки
Сравнить количество документов на двух сторонах за одинаковый период. Совпадение чисел — единственное доказательство, что порция не потерялась; «зелёный статус» им не является.
Самая дорогая ошибка тестового контура — копия базы, в которой остались боевые настройки обмена. Прогон чек-листа отправляет тестовые заказы в реальную CRM, тестовые сообщения — реальным клиентам, а тестовые документы — в реальный ЭДО. Поэтому у копии всегда свои адреса и свои ключи, а клиентские данные в ней желательно обезличены.
Прогон пяти операций занимает около 3 часов вместе с записью результатов. Содержание постоянной копии — место на диске и полчаса в месяц на проверку, что расписание обновления копии работает. Это те расходы, которые в смете внедрения выглядят необязательными, а на втором году окупаются одним предотвращённым простоем.
Регламент предупреждения и журнал версий
Технической защиты недостаточно, потому что прогон на копии можно сделать только тогда, когда вы знаете о предстоящем обновлении. Регламент предупреждения умещается в одну строку: любой сотрудник, получивший письмо вендора об обновлении, пересылает его подрядчику и администратору системы за пять рабочих дней до даты. Если письмо пришло позже — пересылает в день получения.
Ключевое здесь — сотрудник не должен решать, важно ли обновление. У инженера оценка занимает 15 минут, а у бухгалтера её нет вообще: письмо о смене версии платформы и письмо о новом дизайне кабинета выглядят для него одинаково. Как только сотруднику поручают фильтровать такие письма, регламент умирает в первый месяц.
- 1Плановый релиз конфигурации и платформы 1С — сообщает администратор 1С или главный бухгалтер, за 5 рабочих дней. Механику самого обновления доработанной конфигурации мы разбирали отдельно в материале о том, почему обновление 1С после доработок дорого стоит.
- 2Изменения на стороне CRM: смена тарифа, включение новых модулей, письмо об обновлении облачной версии — сообщает администратор CRM, за 5 рабочих дней или в день получения письма.
- 3Письма вендоров об изменении API и о прекращении поддержки версий — сообщает администратор системы, в день получения. Пример живого срока такого рода: с 1 сентября 2026 года Контур.Диадок прекращает поддержку модуля для 1С:Предприятие 7.7.
- 4Смена версии языковой модели у провайдера и плановые работы самого подрядчика — сообщает подрядчик, за 5 рабочих дней. Это его часть регламента, и она должна быть в договоре наравне с вашей.
Второй элемент — журнал версий смежных систем. Это одна таблица, которая нужна ровно в двух ситуациях: при подготовке к обновлению и при разборе инцидента, где первый вопрос инженера всегда звучит одинаково — что менялось за последние две недели. Без журнала ответ на него занимает полдня переписки.
| Система | Что записываем | Кто ведёт | Откуда узнаём об изменении |
|---|---|---|---|
| 1С:УТ | Версия конфигурации и платформы, дата обновления, снята ли с поддержки | Администратор 1С | Письмо вендора и план обновлений |
| CRM | Версия или тариф, дата изменения, состав подключённых модулей | Администратор CRM | Письма вендора, история изменений в кабинете |
| Bot API мессенджера | Версия API, дата последнего изменения, срок действия токена | Администратор системы | Журнал изменений вендора и уведомления |
| Провайдер языковой модели | Имя и версия модели, дата смены, дата истечения ключа | Подрядчик | Уведомления провайдера |
| Сам обмен | Версия сценария, дата выкладки, ссылка на заявку на изменение | Подрядчик | Журнал изменений системы |
Горизонтальная лента из пяти рабочих дней с подписанными узлами. День −5: «письмо вендора переслано подрядчику». День −4: «оценка влияния, 1 рабочий день». День −3 и −2: «обновление копии и прогон пяти операций, 3 часа». День −1: «правка обмена, если нужна». День 0: «окно обновления, остановка обмена флагом». День +1: «догон и сверка счётчиков за окно». Под лентой отдельная короткая ветка с подписью «без предупреждения: 26 часов срочной работы вместо 16». Чертёжный стиль, подписи по-русски.
Сколько стоит адаптация обмена
Мажорное обновление смежной системы почти всегда требует работы по обмену — это нормальная статья эксплуатации, а не признак плохого подрядчика. Вопрос только в том, сколько часов она займёт, и разница между подготовленным и неподготовленным вариантом велика.
Дубли и пересорт возникают именно при догоне очереди: часть документов ушла до остановки, часть приезжает повторно после включения. Механика разобрана в материале о семи ошибках обмена с 1С; коротко — повторный приём той же записи должен обновлять существующий документ, а не создавать второй. Без этого любое окно превращается в ручной разбор.
Сравнение в две колонки. Левая — «Предупредили за 5 рабочих дней»: разбор изменений 3 ч, правка обмена 8 ч, прогон чек-листа на копии 3 ч, выкладка и сверка 2 ч, итого 16 часов и 48 000 ₽. Правая — «Узнали постфактум»: срочная работа 26 часов и 78 000 ₽, простой обмена 2 рабочих дня и 148 заказов вручную на 6 930 ₽, разбор дублей 15 000 ₽, три перенесённые отгрузки 9 000 ₽, итого 108 930 ₽. Под колонками общая подпись «разница 60 930 ₽ на одном обновлении». Чертёжный стиль, подписи по-русски.
Что писать в договоре поддержки
Обновления смежных систем — вторая по частоте тема споров с подрядчиком после границы между дефектом и доработкой. Спор снимается четырьмя абзацами, которые проще согласовать до первого обновления, чем после.
- Определение. Адаптация обмена к обновлению смежной системы — это изменение, а не дефект. Дефект — несоответствие описанию из приёмочного протокола при неизменных внешних условиях; обновление 1С или CRM эти условия меняет. Подробный разбор границы — в материале о том, что входит в поддержку системы.
- Оценка влияния — бесплатно и за один рабочий день. После уведомления подрядчик говорит, затрагивает ли обновление обмен и сколько часов нужно. Без этого пункта каждое письмо вендора становится отдельными переговорами.
- Цена зависит от срока предупреждения. Предупредили за пять рабочих дней — обычная ставка и по возможности включённые часы. Узнали постфактум — ставка срочных работ. Правило симметричное и дисциплинирует обе стороны.
- Обязанность заказчика. Боевая система не обновляется без прогона на копии. Обновили мимо регламента и обмен встал — восстановление оплачивается отдельно: иначе подрядчик страхует риск, которым не управляет, и закладывает его в абонплату всем.
Между обновлениями за обменом достаточно смотреть по четырём числам раз в неделю — это пять минут вместе с обычной сводкой.
- Доля ошибок обмена за неделю. Норма — доли процента; рост до 2 % два дня подряд означает разбор, а не наблюдение.
- Число записей «не найдено» при выгрузке справочника. Норма — как неделю назад; скачок почти всегда след чужого обновления.
- Расхождение счётчиков документов за сутки между двумя системами. Норма — ноль; расхождение больше 1 % два дня подряд — повод звонить подрядчику вне графика.
- Дней до ближайшего истечения токена, ключа или сертификата. Норма — больше 14; ниже это уже задача с датой.
Когда всё это избыточно
Регламент из тестовой копии, чек-листа и журнала версий стоит времени и оправдан не везде. Есть три случая, когда достаточно резервной копии и здравого смысла.
- Зависимость одна, и она ваша: обмен между двумя своими базами, которые вы же и обновляете. Хватает бэкапа и одного контрольного документа после.
- Обмен файловый и с ручной проверкой. Выгрузка раз в сутки, человек её просматривает перед загрузкой — ошибка ловится на следующем шаге.
- Обмен поддерживает сам вендор в составе коробки. Типовой обмен, который вендор обновляет вместе с конфигурацией, — его зона ответственности. Вам остаётся окно, резервная копия и сверка количеств после обновления.
И честная граница регламента: он не защищает от обновлений, которые облачный сервис выкатывает без предупреждения, — а таких в 2026 году всё больше. Против них работает только вторая линия: суточная сверка счётчиков, счётчик «не найдено» и очередь необработанного. Регламент снимает предсказуемую половину проблемы, вторую снимает архитектура обмена.
Обмен не ломается сам. Его ломает чужой календарь, о котором вам не сказали — и защита здесь организационная в той же мере, что и техническая.
