Как настроить двусторонний обмен 1С в формате XML и избежать коллизий

Ссылки объектов в 1С (ГУИДы)

В 1С у каждого объекта есть свой уникальный идентификатор (GUID). Этот GUID не видно пользователю напрямую, он служит только для внутреннего связывания объектов. При обмене данными этот идентификатор помогает определить, какие записи в разных базах соответствуют друг другу. Если вы включите в правилах конвертации опцию «Искать по уникальному идентификатору», 1С сначала попытается найти объект в базе-приемнике по тому же GUID, что и в базе-источнике. Но так как внутренние идентификаторы в разных базах обычно разные, часто во вторую итерацию поиска используют поиск по полям — например, по коду или номеру документа. Так удается избежать дублирования одних и тех же объектов. Для надежного обмена рекомендуется задействовать регистр сведений «Соответствие объектов информационных баз» — встроенный механизм, где 1С запоминает пары GUID одного и того же объекта из разных баз. Благодаря этому система «помнит», какой объект в базе-источнике какому соответствует в базе-приемнике. Если в базе-приемнике есть свойство «ВнешнийИД» (или «ВнешнийКод»), в него записывают GUID из источника. При загрузке обмена поиск по этому полю гарантирует нахождение правильного объекта.

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

Роли «источника» и «приёмника» данных

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

Кстати, даже в других системах распространена идея мастерской и подчинённой базы. Когда выделены главная база и филиал, конфликты данных решаются проще — одна система принимает, другая отправляет.

Приоритеты изменений и контроль версий

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

Теперь поговорим о коллизиях.

Как избежать «петель» обмена 1С XML

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

Представьте себе ситуацию: изменения играют в прятки между базами. Каждую итерацию они пытаются «догнать» друг друга, если правила обмена поставлены неверно.
После того как мы решили петли, следует уделить внимание коллизиям.

Предотвращение коллизий при синхронизации

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

Планы обмена 1C и узлы планов обмена

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

В план обмена уже не в конфигураторе, а в пользовательском режиме добавляют узлы — это разные базы или роли в обмене. Для каждого узла задают код, название и настройки подключения. Например, план может называться «Головная–Филиал», с узлами «Головная» и «Филиал». Узел «Головная» привязывают к главной базе, «Филиал» — к филиальной. Внутри каждого узла ведётся учёт обменных сообщений: хранится номер последнего отправленного и принятого файла обмена. Это позволяет системе отслеживать, какие изменения уже обработаны, а какие ещё нет. По сути, план обмена вместе с узлами выступает регистром «контроля версий» самого обмена: однажды отправленные и принятые данные не повторяются. Кроме того, для узлов плана доступны обработчики событий: например, «Перед выгрузкой», «После загрузки» и другие. Они позволяют запускать ваш код при отправке или приёме обменного файла. С помощью этих обработчиков можно валидировать данные, заполнять дополнительную информацию или логировать процесс обмена.

Теперь о составе плана.

Состав объектов плана обмена 1С

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

Выбирая объекты, убедитесь, что всё необходимое попало в состав плана: изменения только этих объектов будут передаваться. Например, не забудьте включить в план обмена такие обязательные объекты, как справочник «Валюта» и регистр «Курсы валют», если обмен требует пересчёта цен. Если же забыть синхронизировать некоторые зависимые объекты (например, типы цен или ставки налогов), то при обмене возможны ошибки расчётов. Остальные объекты не участвуют в обмене и останутся локальными.

Кстати, даже самый идеальный план обмена не отменяет здравого смысла — всегда проверяйте результаты синхронизации и ведите лог. Обмен может неожиданно пойти не так, как планировалось!

Разработка правил обмена XML (правил КД 2 или использование готовых правил обмена 1С)

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

Правила обмена XML можно разрабатывать самостоятельно в конфигурации 1С:Конвертация данных 2.0 или 3.0, а можно сэкономить время и приобрести готовые правила конвертации данных XML разработки компании MoscowSoft: