Одна запись изменена в двух базах: как 1С выбирает победителя и как вернуть нужную версию
Содержание
Сообщение Приняты данные коллизии в 1С означает: при синхронизации один и тот же объект оказался изменён в обеих базах, и программа записала версию, пришедшую из другой базы, поверх вашей. Это не ошибка обмена, а отчёт о том, как разрешён конфликт. Проверить его можно в Администрирование → Синхронизация данных, в списке предупреждений синхронизации, и там же решить, какая версия остаётся.
Коллизия возникает в распределённой информационной базе (РИБ) и в обменах между разными программами, например между Бухгалтерией и Управлением торговлей. Правило выбора версии зависит от вида обмена, а «проигравшая» версия восстанавливается, если в базе включено версионирование объектов.
Откуда берётся конфликт версий в распределённых базах
Обмен в 1С построен на регистрации изменений. Когда вы записываете элемент справочника или документ, платформа помечает его как изменённый для каждого узла плана обмена. При следующем сеансе синхронизации все помеченные объекты уходят в другую базу.
Коллизия появляется, когда за время между двумя сеансами один объект успели поменять с обеих сторон. Пример:
- 🕘 в 10:00 прошла синхронизация, карточка контрагента «Альфа» одинакова в обеих базах;
- 🏢 в 11:15 бухгалтер в центральной базе исправил ИНН;
- 🏬 в 11:40 менеджер в филиале поменял в той же карточке телефон;
- 🔄 в 12:00 запустилась синхронизация — обе версии зарегистрированы к отправке, и база-получатель видит, что пришедший объект у неё тоже изменён.
Объекты 1С передаются целиком, а не по отдельным полям. Поэтому «склеить» ИНН из одной версии и телефон из другой программа не может. Она выбирает одну версию, вторая теряется для этой базы.
Чаще всего коллизии дают:
- 📇 справочники, которые правят все: контрагенты, номенклатура, договоры;
- 📄 документы, которые перепроводят задним числом в обеих базах;
- ⏱ обмены с редким расписанием — чем длиннее окно между сеансами, тем выше шанс;
- 🔁 сбойные сеансы: если выгрузка прошла, а подтверждение не вернулось, регистрация изменений не снимается, и объект уходит повторно.
Как 1С разрешает коллизию при обмене данными
Правило зависит от вида обмена.
Распределённая информационная база
В РИБ действует иерархия: главный узел старше подчинённого. Если объект изменён в обоих узлах:
- в подчинённом узле принимается версия из главного;
- в главном узле изменение из подчинённого отклоняется, а объект снова регистрируется к отправке в подчинённый, чтобы версии сошлись.
Итог: после двух сеансов обе базы содержат версию главного узла. Если правку делали в филиале, она пропадёт, а в филиале появится предупреждение о принятых данных коллизии.
Обмен между разными конфигурациями
В обменах через правила конвертации (например, Бухгалтерия ↔ Управление торговлей, Бухгалтерия ↔ ЗУП) приоритет задаётся настройкой синхронизации. В типовых обменах при настройке предлагают выбрать, чьи изменения считать главными при конфликте. Если не выбирали, работает значение по умолчанию из правил обмена.
Что делает платформа технически
В модуле плана обмена разработчик может обработать событие получения данных. Для подчинённого направления это ПриПолученииДанныхОтПодчиненного, для главного — ПриПолученииДанныхОтГлавного. В обработчик приходит параметр ПолучениеЭлемента, и код решает: принять объект, проигнорировать или оставить решение платформе.
Процедура ПриПолученииДанныхОтПодчиненного(ЭлементДанных, ПолучениеЭлемента, ОтправкаНазад, Отправитель)
// Объект изменён и у нас, и в узле-отправителе
Если ПланыОбмена.ИзменениеЗарегистрировано(Отправитель, ЭлементДанных) Тогда
// Здесь решаем: принять пришедшую версию или оставить свою
ПолучениеЭлемента = ПолучениеЭлементаДанных.Игнорировать;
ОтправкаНазад = Истина; // вернуть нашу версию отправителю
КонецЕсли;
КонецПроцедуры
В типовых конфигурациях на Библиотеке стандартных подсистем эта логика уже написана. Каждое такое решение программа фиксирует как предупреждение: «приняты данные коллизии» или, наоборот, «отклонены».
| Ситуация | Что сделает типовой обмен | Где окажется «проигравшая» версия |
|---|---|---|
| РИБ, конфликт в подчинённом узле | Примет версию главного | В истории версий подчинённого узла |
| РИБ, конфликт в главном узле | Отклонит версию подчинённого | Будет перезаписана в подчинённом при следующем обмене |
| Обмен разных программ | По приоритету из настроек синхронизации | В истории версий той базы, где её перезаписали |
«Проигравшая» версия сохраняется только если в базе включено версионирование объектов. Без него вернуть данные можно лишь из резервной копии или вручную.
Где найти, какие объекты затронула коллизия
Предупреждения синхронизации
Начните с формы синхронизации:
- Откройте
Администрирование → Синхронизация данных. - Перейдите к списку настроенных синхронизаций и выберите нужную.
- Если были проблемы, рядом с синхронизацией есть ссылка на предупреждения — откройте её.
- В списке отберите вид предупреждения «Конфликты» (в разных релизах название может отличаться: «Конфликты данных», «Конфликт при синхронизации»).
По каждой строке видно объект, дату и какая версия принята. Двойной щелчок открывает сам объект.
Журнал регистрации
Если предупреждений нет или нужны подробности, откройте журнал:
Администрирование → Обслуживание → Журнал регистрации.- Поставьте отбор по периоду сеанса обмена.
- В отборе по событию выберите события группы «Обмен данными» — загрузка и выгрузка.
- Посмотрите колонку «Данные» и комментарий: там указан объект и узел.
Журнал показывает и пользователей. По времени изменения объекта до сеанса обмена легко понять, кто правил карточку в своей базе.
История версий
Самый наглядный источник. Откройте объект и вызовите историю изменений (в карточке это команда «История изменений», обычно в меню «Ещё»). Версии, полученные при коллизии, помечены отдельно. Выделите две версии и сформируйте отчёт сравнения — увидите, какие поля различаются.
Как настроить правила разрешения конфликтов
В типовой синхронизации
Приоритет задают в параметрах конкретной синхронизации. Откройте её в Администрирование → Синхронизация данных и найдите настройку выгрузки и загрузки. В типовых обменах между разными программами там есть выбор, чьи данные главнее при одновременном изменении.
Как выбирать:
- 🏢 если справочник ведётся в одной программе (например, номенклатура — в Управлении торговлей), её и делайте главной;
- 📒 если учётные данные (счета, договоры для бухучёта) ведёт бухгалтерия, приоритет у Бухгалтерии;
- 🚫 по некоторым обменам можно вообще запретить загрузку изменений отдельных объектов, если они уже есть в базе. Тогда коллизий по ним не будет, но и правки из другой базы не придут.
В доработанной конфигурации
Если стандартного выбора мало, правило пишут в коде. Для РИБ — в обработчиках модуля плана обмена, как в примере выше. Для обменов через «Конвертацию данных» — в обработчиках правил конвертации объектов.
Типовые приёмы:
- Принимать данные по полю «дата изменения»: побеждает более поздняя правка. Требует, чтобы в объекте хранилось время последнего изменения.
- Делить объекты по ответственности: справочник контрагентов главный в одной базе, документы склада — в другой.
- Для части объектов включить отправку назад (
ОтправкаНазад = Истина), чтобы источник получил актуальную версию и базы сошлись.
Правки в модуле плана обмена или в правилах конвертации делают в копии базы и через расширение конфигурации, если это возможно. Ошибка в обработчике может молча отбрасывать все входящие данные.
Как вернуть потерянные изменения после коллизии
Решение по каждому объекту принимают отдельно. Порядок такой.
Шаг 1. Решить, какая версия правильная
Сравните версии в истории изменений. Иногда ответ очевиден (в одной ИНН исправлен, в другой старый). Иногда нужны обе правки — как с ИНН и телефоном из примера.
Шаг 2. Вернуть версию или объединить вручную
- ✅ Если правильна целиком отклонённая версия, в истории версий откройте её и выполните переход на эту версию. Объект перезапишется.
- ✍️ Если нужны поля из обеих версий, откройте объект и вручную внесите недостающие значения. Это надёжнее, чем откатываться.
- 📌 В списке предупреждений синхронизации можно отметить конфликт как разобранный или скрыть его, чтобы он не мешал.
Шаг 3. Отправить исправление в другую базу
После записи объект снова регистрируется к обмену. Запустите синхронизацию и убедитесь, что новый конфликт не возник. Не правьте этот объект во второй базе, пока исправление не дошло, иначе коллизия повторится.
Шаг 4. Проверить документы
Если конфликт был по документу, перепроверьте движения: сумма, склад, контрагент. Версия могла смениться на ту, где документ не проведён или проведён с другими данными. Для справочников проверьте документы, которые ссылаются на изменённый элемент, особенно за текущий открытый период.
При массовом конфликте после сбоя сначала отберите объекты по виду (документы отдельно от справочников) и по пользователю. Справочники обычно восстанавливаются быстро, документы требуют сверки остатков.
Профилактика: как работать, чтобы коллизий было меньше
Полностью убрать коллизии в двусторонней синхронизации нельзя. Сократить их до единичных — можно.
| Мера | Что даёт | Чего стоит |
|---|---|---|
| Один «хозяин» справочника | Правки идут только из одной базы | Нужен регламент для пользователей |
| Частая синхронизация (каждые 5–15 минут) | Короче окно для одновременных правок | Нагрузка на сервер и канал |
| Права на запись только в одной базе | Пользователь физически не может изменить объект «не там» | Настройка профилей групп доступа |
| Версионирование объектов | Потерянная версия восстанавливается за минуту | Рост объёма базы |
| Контроль сбоев обмена | Нет повторной отправки старых данных | Нужен ответственный за обмен |
Что ещё помогает:
- 🔒 настройте даты запрета изменения: закрытые периоды не будут переписываться документами из другой базы;
- 📅 не запускайте массовые обработки (перепроведение, групповое изменение реквизитов) одновременно в двух базах;
- 🔔 включите оповещение о проблемах синхронизации, чтобы ответственный видел конфликты в тот же день, а не через месяц;
- 🧾 договоритесь, кто и в какой базе правит контрагентов и номенклатуру, и закрепите это в правах доступа.
Когда коллизия говорит о поломке обмена
Единичные конфликты — норма. Насторожиться стоит, если:
- ❗ конфликты по одному объекту возникают в каждом сеансе — объект «качается» между базами. Обычно его переписывает обработка или регламентное задание в одной из баз;
- ❗ после сеанса в предупреждениях сотни строк, хотя пользователи почти ничего не правили — похоже на повторную отправку после сбоя или на сброс регистрации изменений;
- ❗ в обмене разных программ меняются поля, которые пользователи не трогали, — правила конвертации заполняют их по-разному в двух базах, и каждая запись объекта порождает новое изменение.
В последних двух случаях разбирать конфликты вручную бессмысленно, пока не найдена причина. Сначала выясните по журналу регистрации, кто или что записывает объект, затем исправьте правило или расписание. Если обмен в РИБ рассинхронизирован серьёзно, подчинённый узел иногда проще пересоздать из главного, но это решение администратора после выгрузки резервной копии и согласования: несинхронизированные данные филиала при этом пропадут.