Коллизия при синхронизации 1С: чья версия объекта осталась в базе и как вернуть нужную

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

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

Откуда берётся коллизия при обмене данными

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

Сценарии, в которых коллизия возникает чаще всего:

• 🔁 Распределённая информационная база (РИБ) — центральный узел и периферийные с одной конфигурацией.
• 🔄 Обмен между разными конфигурациями — например, Бухгалтерия и Управление торговлей через EnterpriseData.
• 📚 Общие справочники — номенклатура, контрагенты, договоры, которые правят в обеих базах.
• 📄 Документы, перепроведённые с двух сторон — один документ открыли и записали в двух базах.
• ⏳ Редкая синхронизация — чем больше времени между сеансами, тем выше шанс, что объект успеют изменить дважды.

Кто выигрывает конфликт

Логика РИБ простая: главный узел — эталон. Если объект изменили и там, и в филиале, после обмена в обеих базах будет версия главного узла. Изменения филиала по этому объекту не потеряются полностью — они попадут в историю версий, если её ведут.

Как найти источник коллизии: журнал регистрации и предупреждения

Начинайте с предупреждений синхронизации — там уже собраны объекты с конфликтами.

1. Откройте Администрирование → Синхронизация данных.
2. Найдите ссылку с предупреждениями синхронизации (в старых релизах она называлась «Конфликты при синхронизации данных»). Ссылка видна, только если предупреждения есть.
3. В списке отберите тип «Конфликт» или похожий по смыслу. Каждая строка — объект, версия которого была отклонена.
4. Для каждой строки посмотрите: какой узел прислал версию, когда, принята она или отклонена.

Если ссылки нет, а сообщение было, идите в журнал регистрации:

1. Администрирование → Обслуживание → Журнал регистрации.
2. Нажмите «Установить отбор» и в поле событий отметьте группу событий обмена данными.
3. Задайте интервал — день, когда прошла синхронизация.
4. Ищите записи с уровнем «Предупреждение». В комментарии будет представление объекта и узел, с которым шёл обмен.

Что выписать из записи

• 🧾 Объект: вид и номер документа или наименование элемента справочника.
• 🏢 Узел: из какой базы пришла версия.
• 🕒 Время сеанса обмена.
• 👤 Пользователь, который последним менял объект в каждой базе (видно в истории версий или в журнале на стороне каждой базы).

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

Как настроить синхронизацию, чтобы коллизий стало меньше

Конфликт нельзя «выключить» галочкой. Его можно сделать редким, если развести права на правку и ускорить обмен.

Расписание обмена

Чем короче окно между сеансами, тем меньше шанс двойной правки. Если обмен идёт раз в сутки ночью, любая правка одного объекта в обеих базах за день даст коллизию.

1. В Администрирование → Синхронизация данных откройте настройку нужного обмена.
2. Включите синхронизацию по расписанию.
3. Для активной работы с общими справочниками ставьте интервал 15–30 минут, а не раз в сутки.

Даты запрета загрузки

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

Правила обмена между разными конфигурациями

• ⚙️ В «Конвертации данных» 2.x у правила конвертации объектов есть флаг «Не замещать». Если его поставить, существующий в базе-приёмнике объект не перезаписывается входящей версией. Так защищают, например, справочник номенклатуры, который ведут только в одной базе.
• ⚙️ В обменах через EnterpriseData поведение при загрузке задаётся в модуле менеджера обмена. Менять его без программиста не стоит: правка типовой конфигурации усложнит обновления. Если нужно — делайте через расширение.
• ⚙️ Отборы в настройках обмена: часть справочников можно вообще не выгружать в обратную сторону. Тогда коллизии по ним невозможны.

Как разрешить конфликт версий объекта вручную

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

Проверить, что история включена

1. Администрирование → Общие настройки.
2. Найдите группу «История изменений» и флажок «Хранить историю изменений».
3. В настройках хранения проверьте, что для нужных справочников и документов история включена.

Принять отклонённую версию

1. Откройте список предупреждений синхронизации (см. раздел про поиск источника).
2. Выделите строку с конфликтом.
3. Откройте отчёт по версиям объекта: он покажет обе версии рядом и подсветит отличающиеся реквизиты.
4. Решите, какая версия верная:
   • если победила верная — отметьте конфликт как просмотренный или скройте его из списка;
   • если победила неверная — используйте команду принятия версии, которая была отклонена.
5. Объект перезапишется отклонённой версией и зарегистрируется к отправке. На ближайшем обмене эта версия уйдёт в другую базу.

Если истории изменений нет

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

Что проверить после разрешения конфликта

Принятая версия уходит в другую базу только на следующем сеансе. До него базы расходятся, и это нормально. После обмена сделайте короткую проверку:

1. Откройте объект в обеих базах и сравните ключевые реквизиты: для контрагента — ИНН, КПП, наименование, для номенклатуры — единицу измерения и ставку НДС.
2. Для документа сравните сумму и проведённость. Если документ проведён в одной базе и не проведён в другой, перепроведите его там, где он не проведён.
3. Сформируйте оборотно-сальдовую ведомость по затронутому счёту за период документа в обеих базах. Итоги должны совпасть.
4. Загляните в список предупреждений синхронизации ещё раз. Если по тому же объекту появилась новая коллизия, значит, его снова правили в двух местах до обмена.

Профилактика: регламент правки и обслуживание истории версий

Коллизии почти всегда организационные. Техника лишь фиксирует, что двое правили одно и то же.

Договориться о «хозяине» данных

• 🏷️ Номенклатуру и цены ведёт одна база — обычно центральная.
• 🏷️ Контрагентов заводят там, где с ними работают, но реквизиты правит одна служба.
• 🏷️ Документы правят только в той базе, где их создали.

Запишите это в регламент и закройте права. В филиале можно оставить чтение справочника без права изменения — тогда коллизий по нему не будет.

Следить за размером истории версий

История изменений растёт с каждой записью объекта. При активном обмене каждая загрузка — тоже запись. Через год база может вырасти в разы. Ограничьте хранение:

1. В настройках истории изменений задайте срок хранения версий, например год.
2. Включите регламентное задание удаления устаревших версий.
3. Для объектов, которые пишутся часто и неважны (служебные регистры, технические справочники), историю не ведите вовсе.

Не путать с хранилищем конфигурации

Иногда при поиске решения советуют «очистить хранилище ». Хранилище конфигурации — это механизм групповой разработки в Конфигураторе. К обмену данными и коллизиям объектов оно не относится. Чистить его при сообщении о коллизии бессмысленно.

Частые ошибки при разборе коллизий

• ❌ Повторный запуск обмена «до победного». Коллизия уже разрешена, повторный сеанс ничего не изменит. Если в обеих базах объект продолжают править, конфликт просто повторится.
• ❌ Снятие регистрации изменений, чтобы сообщение пропало. Объект перестанет уходить в другую базу, данные разойдутся тихо. Это хуже, чем коллизия, — о ней хотя бы сообщают.
• ❌ Правка в периферийном узле с надеждой, что она «перебьёт» главный. В РИБ при одновременной правке главный узел выигрывает всегда.
• ❌ Массовая обработка в обеих базах. Групповое изменение реквизитов, запущенное в двух узлах, даёт коллизию по каждому затронутому объекту. Запускайте такие обработки в одной базе.
• ❌ Игнорирование предупреждений неделями. Список растёт, разобрать его потом трудно: часть версий удалит регламентная очистка истории.

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