Администрирование · 11 мин
Коллизии при синхронизации 1С: что значит «приняты данные» и как их разобрать
Что означает статус «приняты данные» при коллизии в синхронизации 1С, как найти и разобрать конфликтные объекты, настроить приоритет и избежать потери данных.
При обмене между двумя базами 1С — например, между «Управлением торговлей» и «Бухгалтерией» или между центральной базой и периферийной — система фиксирует коллизии. Это ситуации, когда один и тот же объект (документ, элемент справочника) был изменён в обеих базах до очередного сеанса обмена. Платформа не может сама решить, какая версия верная, и помечает объект как конфликтный.
Статус «приняты данные» означает, что коллизия разрешена автоматически: при загрузке была применена версия объекта из полученного сообщения обмена, а локальные изменения в текущей базе были перезаписаны. Иными словами, «победила» та сторона, откуда пришли данные. Противоположный вариант — «не приняты данные», когда сохранена локальная версия объекта, а входящие изменения проигнорированы.
Важно понимать: автоматическое разрешение коллизии не всегда означает правильное с точки зрения бизнеса. Если в обеих базах меняли один и тот же договор контрагента, «победившая» версия может оказаться устаревшей. Поэтому коллизии нужно не просто принимать, а периодически просматривать и разбирать вручную.
Что такое коллизия и почему она возникает
Коллизия возникает, когда объект изменён в обеих узлах обмена в период между сеансами синхронизации. Платформа отслеживает версии объектов по механизму регистрации изменений: каждый узел плана обмена знает, какие данные уже отправлял и получал. Если при загрузке выясняется, что объект менялся и локально, и в источнике сообщения, фиксируется конфликт.
Типичные сценарии появления коллизий:
- менеджер отредактировал карточку контрагента в торговой базе, а бухгалтер — ту же карточку в бухгалтерии;
- документ провели, отменили проведение и изменили в разных базах до очередного обмена;
- синхронизация долго не выполнялась, и за это время накопились правки с обеих сторон;
- пользователь вручную изменил объект, который по правилам должен редактироваться только в одной базе.
Чем реже выполняется обмен и чем больше пользователей работают с одними и теми же объектами в разных базах, тем выше вероятность коллизий. Это нормальное штатное явление, а не ошибка программы.
Что конкретно означает статус «приняты данные»
В типовых конфигурациях на БСП (Библиотека стандартных подсистем) результат автоматического разрешения коллизии виден в регистрации результатов обмена. Статус «приняты данные» присваивается объекту, когда при загрузке применена версия из сообщения обмена. То есть в текущей базе объект стал таким, каким он был в другой базе на момент выгрузки.
Какая сторона «побеждает» по умолчанию, зависит от настроек плана обмена и типовых правил. Во многих конфигурациях действует принцип приоритета главного узла: в распределённой базе (РИБ) данные центрального узла принимаются безусловно, а изменения периферийного узла при конфликте отклоняются. В обменах между типовыми конфигурациями через универсальный формат приоритет может определяться настройкой «Кто главнее» в параметрах синхронизации.
Обратная ситуация — статус «не приняты данные»: локальная версия объекта сохранена, входящие изменения отклонены. При следующем сеансе обмена локальная версия, как правило, будет отправлена в другую базу и перезапишет данные там.
Варианты разрешения коллизии
Загружена версия из входящего сообщения, локальные изменения в текущей базе перезаписаны. Типично для подчинённого узла или при приоритете источника.
Сохранена локальная версия объекта, входящие изменения проигнорированы. При следующем обмене локальная версия уйдёт в другую базу.
Пользователь просмотрел конфликтные версии и сам выбрал, какую применить, либо исправил объект после загрузки.
Где посмотреть коллизии и их результат
В типовых конфигурациях журнал коллизий находится по пути: Администрирование → Синхронизация данных → Результаты обмена данными. Откроется список, где на вкладке «Предупреждения» или в разделе коллизий отображаются конфликтные объекты, дата обмена, узел и принятое решение.
По каждому объекту доступны действия:
- открыть объект и посмотреть его текущее состояние;
- сравнить версии — в некоторых конфигурациях доступен показ отличий версии из сообщения и версии в базе;
- изменить решение по коллизии: принять другую версию, если сеанс обмена ещё актуален;
- пометить коллизию как просмотренную, чтобы она не висела в списке неразобранных.
В распределённых базах (РИБ) дополнительно можно смотреть зарегистрированные изменения через «Администрирование → Обмен данными → Настройка синхронизации» и обработку «Регистрация изменений для обмена данными».
- 1Откройте Администрирование → Синхронизация данных → Результаты обмена данными.
- 2Найдите записи со статусом о коллизии за нужную дату и узел обмена.
- 3Откройте конфликтный объект и проверьте, какая версия применена.
- 4Сравните с данными во второй базе или с версией из сообщения, если доступен просмотр.
- 5Если применена неверная версия — исправьте объект вручную или измените решение по коллизии.
- 6Отметьте коллизию как разобранную и проверьте, что при следующем обмене объект ушёл корректно.
Как настроить приоритет и уменьшить число коллизий
Полностью исключить коллизии при живой работе в двух базах нельзя, но их количество резко снижается за счёт правильной организации обмена. Первый шаг — определить для каждого типа данных «хозяина»: базу, в которой объект создаётся и редактируется. Например, номенклатура ведётся в торговой базе, а счета и акты — в бухгалтерии. Это правило закрепляется регламентом и, где возможно, правами доступа.
Второй шаг — настройка приоритета в самой синхронизации. В типовых обменах через универсальный формат (EnterpriseData) в настройках синхронизации есть параметр, определяющий, чьи данные принимаются при конфликте. В РИБ приоритет центрального узла встроен в механизм: изменения из центра всегда «сильнее».
Третий шаг — регламент обмена. Чем чаще выполняется синхронизация, тем меньше окно, в котором объект может быть изменён с двух сторон. Автоматический обмен по расписанию каждые 15–60 минут заметно сокращает число конфликтов по сравнению с ручным обменом раз в день.
Риски и типичные ошибки при работе с коллизиями
Главный риск статуса «приняты данные» — незаметная потеря локальных изменений. Пользователь редактировал документ, а после обмена его правки перезаписаны версией из другой базы. Если коллизии никто не просматривает, о потере узнают поздно, когда восстановить данные сложно.
Другая ошибка — массовое «принятие» всех коллизий без разбора ради очистки журнала. Журнал очищается, а расхождения между базами остаются и накапливаются. Третья типичная проблема — попытка исправить ситуацию ручной регистрацией объектов к обмену без понимания направления: объект выгружается не в ту сторону и затирает актуальные данные в приёмнике.
Отдельно стоит выделить работу с движениями документов. Если конфликтный документ был проведён в обеих базах с разными данными, после разрешения коллизии проводки в одной из баз могут не соответствовать ожиданиям. После разбора коллизии по проведённому документу имеет смысл перепроверить отчёты, которые он затрагивает.
Как проверить, что коллизия разрешена корректно
После разбора коллизии выполните контрольный сеанс обмена и убедитесь, что объект в обеих базах пришёл к одинаковому состоянию. Для документов проверьте дату, сумму, контрагента и статус проведения; для справочников — ключевые реквизиты, которые менялись.
Полезно сверить итоги по затронутым участкам: если конфликт касался документов реализации или поступления, сравните обороты за период в обеих базах. Расхождение после успешного обмена — признак того, что коллизия разрешена не в пользу актуальной версии или объект не выгрузился.
Если одна и та же группа объектов регулярно попадает в коллизии, это сигнал пересмотреть процесс: назначить единственную базу для редактирования этих данных или ограничить права пользователей в одном из узлов.
Как проверить результат
Реквизиты, суммы и статус проведения совпадают
Объект различается или в одной базе не обновился
Коллизия помечена как разобранная, новых конфликтов по объекту нет
Тот же объект снова попадает в коллизии каждый сеанс
Обороты и остатки в базах сходятся
Есть расхождения по суммам или количеству
Как выбрать действие
FAQ по коллизиям при синхронизации 1С
«Приняты данные» — это ошибка или штатная ситуация?
Это штатный результат автоматического разрешения конфликта версий, а не сбой программы. Система сообщает, что при коллизии применила версию из входящего сообщения. Тревожиться стоит, только если таких записей много или конфликтуют одни и те же объекты.
Можно ли отменить автоматическое решение по коллизии?
Да, пока актуальны данные сеанса обмена: в журнале результатов обмена по конфликтному объекту можно изменить решение и принять другую версию. Если сеанс устарел, объект исправляют вручную и дожидаются, пока изменения уйдут в другую базу при следующем обмене.
Почему одни и те же объекты постоянно попадают в коллизии?
Чаще всего потому, что объект реально редактируют в обеих базах между сеансами обмена. Реже причина в особенностях правил конвертации, когда при загрузке объект программно изменяется и считается модифицированным. В первом случае помогает регламент и распределение прав, во втором — анализ правил обмена.
Что будет, если вообще не разбирать коллизии?
Автоматика продолжит разрешать конфликты по настройке приоритета, и базы формально останутся синхронизированными. Но часть правок пользователей будет периодически перезаписываться, что со временем приведёт к расхождениям в учёте и потере актуальных данных.
Отличается ли механизм коллизий в РИБ и в обмене через универсальный формат?
Да. В РИБ приоритет жёстко задан: данные главного узла всегда принимаются, конфликты фиксируются в момент обмена сообщениями. В обмене через универсальный формат (EnterpriseData) поведение определяется настройками синхронизации и правилами конвертации, а разбор коллизий ведётся через журнал результатов обмена.
Что важно запомнить
Статус «приняты данные» означает автоматическое разрешение коллизии в пользу версии из входящего сообщения обмена: локальные изменения перезаписаны. Коллизии просматривают в журнале «Результаты обмена данными», разбирают вручную по важным объектам, а их количество снижают за счёт регламента редактирования, настройки приоритета и частого обмена по расписанию. Перед изменением настроек приоритета и массовой регистрацией объектов делайте резервные копии баз.