Коллизии при обмене 1С: что это и как их устранить

При обмене данными между базами 1С — например, между «Управлением торговлей» и «Бухгалтерией», центральным узлом и магазином в РИБ, приложением в облаке и локальной базой — нередко возникает ситуация, когда один и тот же объект изменён сразу в двух системах. Пользователь в одной базе отредактировал договор контрагента, а коллега во второй базе за то же время поменял его реквизиты. При синхронизации программа сталкивается с двумя разными версиями одного объекта и не может автоматически решить, какая из них верна. Это и есть коллизия обмена данными.

Коллизия — не ошибка программы и не признак поломки обмена. Это штатный механизм защиты от потери данных: 1С фиксирует конфликт версий и по умолчанию сохраняет данные текущей информационной базы, а входящие изменения отклоняет или ставит в очередь на ручной разбор. Понимание того, как возникают коллизии, где их смотреть и как правильно разрешать, избавляет от «залипших» синхронизаций, расхождений в остатках и документах между базами.

Что такое коллизия и какие бывают её виды

В типовых конфигурациях 1С (на платформе с механизмами обмена данными и БСП) выделяют два вида коллизий. Первая — коллизия изменения данных: объект отредактирован в обеих базах. Вторая — коллизия «изменение против удаления»: в одной базе объект изменён, а в другой удалён (помечен на удаление или удалён физически). Второй вид потенциально опаснее, так как автоматическое применение входящей версии может восстановить объект, который осознанно удалили.

Технически конфликт определяется по регистрации изменений: объект зарегистрирован к выгрузке в обоих узлах плана обмена, и при загрузке сообщения система видит, что версия в текущей базе тоже менялась после последнего обмена. Важно понимать: коллизия фиксируется на уровне объекта целиком, а не отдельных реквизитов. Если в одной базе поменяли комментарий документа, а в другой — его дату, это всё равно коллизия, хотя изменения и не пересекаются по смыслу.

Почему возникают коллизии при обмене

Основная причина — параллельная работа пользователей с одними и теми же данными в разных базах. Типичные сценарии: менеджер правит карточку контрагента в торговой базе, а бухгалтер в это же время корректирует того же контрагента в бухгалтерии; складской документ проводится в центральном узле РИБ и одновременно корректируется в периферийной базе магазина.

Вторая группа причин — организационные просчёты в настройке обмена:

• в обеих базах разрешено создавать и редактировать одни и те же справочники (номенклатуру, контрагентов, договоры) без разделения полномочий;
• обмен выполняется редко, из-за чего накапливается много расхождений и вероятность конфликтов растёт;
• после сбоев обмен восстанавливали из старой копии базы, и нумерация сообщений синхронизации сбилась;
• данные загружались в базу сторонними обработками, минуя штатные правила, — версии объектов разошлись незаметно.

Чем опасны коллизии и как они влияют на данные

Сама по себе коллизия не портит данные — наоборот, механизм призван их защитить. Проблемы начинаются, когда коллизии игнорируют. По умолчанию при конфликте применяется версия принимающей базы, а входящие изменения отклоняются. Если таких конфликтов много и их никто не разбирает, базы постепенно расходятся: в одной системе документ исправлен, в другой — нет; остатки, взаиморасчёты и отчёты перестают сходиться.

Отдельный риск — автоматическое разрешение коллизий без контроля. Если настроить приоритет «всегда принимать данные из другой базы», то изменения, сделанные в текущей базе, будут молча перезаписываться. Пользователь исправил документ, после обмена правка исчезла — и никто не понимает почему. Поэтому автоматический приоритет допустим только там, где одна база заведомо главная по конкретным данным.

Где посмотреть коллизии в типовых конфигурациях

В конфигурациях на базе Библиотеки стандартных подсистем (УТ 11, КА 2, ERP, БП 3.0, ЗУП 3.1 и других) информация о коллизиях доступна в разделе синхронизации данных. Путь может немного отличаться, но логика одна: Администрирование → Синхронизация данных, далее ссылка вида «Предупреждения» или «Результаты обмена данными» рядом с нужной настройкой синхронизации.

В форме предупреждений отображаются непрошедшие коллизии: какой объект конфликтует, в каком узле, какая версия была отклонена. По каждому объекту можно открыть сравнение версий — программа покажет, какие реквизиты различаются в текущей базе и в принятом сообщении обмена. Это ключевой инструмент для осознанного разрешения конфликта.

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

Контрольные точки

Как проверить результат

Список предупреждений синхронизации

Норма

Коллизий нет или все разобраны с осознанным выбором версии

Тревожный признак

Список растёт от обмена к обмену, никто не разбирает

Состояние синхронизации

Норма

Обмен завершается успешно, данные в базах совпадают

Тревожный признак

Обмен «висит» на предупреждениях, документы расходятся

Конкретный объект после разрешения

Норма

В обеих базах реквизиты объекта одинаковые

Тревожный признак

В одной базе старая версия, изменения потерялись

Как разрешить коллизию: пошаговый порядок действий

Разрешение коллизии — это выбор, какая версия объекта должна остаться в итоге. Действовать стоит не «по кнопке», а после анализа содержимого.

1. 1
   Откройте Администрирование → Синхронизация данных и перейдите по ссылке предупреждений (непрошедших коллизий) для нужной настройки обмена.
2. 2
   Откройте конфликтующий объект и сравните версии: посмотрите, какие реквизиты различаются и чьи изменения важнее по смыслу.
3. 3
   Уточните у ответственных пользователей, какая правка актуальна, если по данным это неочевидно.
4. 4
   Выберите действие: принять версию из другой базы (применить входящие изменения) либо подтвердить версию текущей базы (отклонить входящие).
5. 5
   Дождитесь следующего сеанса обмена и проверьте, что объект совпадает в обеих базах и предупреждение исчезло.
6. 6
   Зафиксируйте причину конфликта, чтобы скорректировать регламент работы и не наступать на те же грабли.

Если конфликт по объекту повторяется регулярно, правильный ответ — не рутинное нажатие «принять», а пересмотр процесса: кто и где должен редактировать этот тип данных. Например, договоры заводятся только в бухгалтерии, а в торговую базу приходят по обмену в режиме «только чтение».

Настройка приоритетов: автоматическое разрешение коллизий

В настройках синхронизации можно задать поведение по умолчанию: какая база считается главной при конфликте. Это разумно, когда роли систем чётко разграничены: например, центральный узел РИБ главенствует над периферийным, или бухгалтерская база является мастер-системой по контрагентам.

Сравнение вариантов

Ручное разрешение

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

Приоритет главной базы

Подходит, когда одна система заведомо ведущая по конкретным данным. Риск: изменения в подчинённой базе будут перезаписаны без уведомления.

Разделение данных по базам

Самый надёжный вариант: каждый вид объектов редактируется только в одной системе. Требует настройки прав и дисциплины, но сводит коллизии к минимуму.

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

Профилактика: как снизить число коллизий

Полностью исключить коллизии в распределённой работе невозможно, но свести их к единичным случаям — вполне реально. Работающие меры:

• Разделите зоны ответственности: каждый справочник и вид документов редактируется только в одной базе, в остальные попадает по обмену.
• Настройте права: в «подчинённой» по данным базе запретите редактирование объектов, приходящих по синхронизации.
• Выполняйте обмен часто и по расписанию — чем меньше окно между сеансами, тем меньше шанс одновременного редактирования.
• Назначьте ответственного за разбор предупреждений синхронизации и контролируйте, чтобы список коллизий не копился.
• Не загружайте данные сторонними обработками в обход правил обмена — это провоцирует скрытые расхождения версий.

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

Коллизия — это ошибка обмена?

Нет. Это штатная ситуация конфликта версий. Ошибкой она становится, только если её игнорировать или разрешать вслепую: тогда данные в базах расходятся, а отчёты перестают сходиться.

Какая версия объекта сохраняется по умолчанию при коллизии?

По умолчанию применяется версия текущей (принимающей) базы, а входящие изменения отклоняются и попадают в список предупреждений. Это поведение можно изменить настройкой приоритетов в параметрах синхронизации.

Что делать, если коллизий очень много и список не уменьшается?

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

Можно ли настроить обмен так, чтобы коллизий не было совсем?

Полностью исключить их нельзя, пока один объект может изменяться в двух базах. Но если каждый вид данных редактируется только в одной системе, а в остальные попадает по обмену в режиме чтения, коллизии сокращаются до редких исключений.

Опасна ли коллизия «изменение против удаления»?

Да, это самый рискованный вид. Если принять входящее изменение, объект, который осознанно удалили в другой базе, будет восстановлен. Такие конфликты разрешайте только после уточнения у инициатора удаления.

Где смотреть коллизии в РИБ?

В распределённой базе конфликты видны в форме настройки синхронизации через предупреждения обмена данными, а также через журнал регистрации по событиям загрузки. Логика разрешения та же: сравнение версий и осознанный выбор приоритета.