Типичная ситуация для разработчика 1С: в типовую конфигурацию (например, 1С:Бухгалтерия 8) добавляется новая подсистема, включающая справочники, документы и регистры. Объекты включаются в состав плана обмена Полный, устанавливаются настройки авторегистрации, но при выполнении синхронизации данные в подчиненные узлы распределенной информационной базы (РИБ) упорно не передаются. Разберем детально, почему стандартные механизмы платформы «пасуют» перед логикой типовых решений и как заставить систему обмениваться вашими данными.
Прежде всего, нам необходимо понять фундаментальное различие между «чистым» РИБ на уровне платформы и тем, как этот механизм реализован в конфигурациях на базе БСП (Библиотеки стандартных подсистем). В чистом РИБ достаточно включить объект в состав плана обмена и разрешить авторегистрацию. Платформа сама будет фиксировать изменения при записи объекта.
Однако в современных типовых решениях разработчики 1С часто отключают автоматическую регистрацию (флаг «Запретить» в свойствах объекта в составе плана обмена). Это делается для того, чтобы полностью контролировать процесс программно. Рассмотрим, почему это важно:
Проанализируем ситуацию автора: «В полном обмене у каждого из добавленных стоит - запретить». Это явный признак того, что система ожидает программной регистрации изменений через подписки на события.
Перед тем как переходить к коду, убедимся в базовых настройках. Разберем по шагам:
Откроем дерево метаданных, перейдем в раздел ПланыОбмена и выберем нужный план (например, Полный). На вкладке «Состав» найдем наши новые объекты. Важно помнить: даже если мы используем программную регистрацию, объект обязательно должен быть отмечен галочкой в составе плана обмена. Если объекта там нет, платформа просто не создаст таблицу регистрации для этого типа данных, и программная попытка записи в нее вызовет ошибку.
Важный нюанс: Если вы используете расширение конфигурации, ваши новые объекты должны быть добавлены в план обмена именно внутри расширения. При этом убедитесь, что само расширение имеет соответствующие права на работу с планом обмена.
Выясним причину отсутствия данных в обмене через механизм подписок. В типовых конфигурациях за регистрацию отвечают специальные объекты метаданных — ПодпискиНаСобытия. Рассмотрим типичные названия таких подписок:
ОбменДаннымиПолныйРегистрацияОбменДаннымиПолныйРегистрацияДокументаОбменДаннымиПолныйРегистрацияСправочникаПроанализируем свойство «Источник» у этих подписок. Это список типов объектов, на которые реагирует подписка. Если вы создали новый документ ит_ЗаявкаНаРасход, его типа в этом списке не будет. Следовательно, при записи документа программный код БСП, отвечающий за регистрацию, просто не вызывается.
Чтобы исправить это, необходимо добавить тип вашего нового объекта в список источников соответствующей подписки. Рассмотрим, как это сделать правильно:
Источник добавим ваши новые справочники и документы.ОбменДаннымиСобытия.МеханизмРегистрацииОбъектаПередЗаписью.Совет: Если вы не хотите менять типовые подписки (чтобы не усложнять будущие обновления), создайте свои собственные подписки на события ПередЗаписью для ваших объектов и укажите в качестве обработчиков те же типовые процедуры, которые используются в системе для аналогичных объектов.
Часто программисты сталкиваются с тем, что «до обновления все работало, а после — перестало». Посмотрим на причину этого явления. При обновлении конфигурации через сравнение и объединение (особенно при использовании .cf файлов) список типов в свойстве Источник подписок на события часто сбрасывается к типовому состоянию.
Рассмотрим ситуацию: вы добавили свой документ в типовую подписку. Пришло обновление от 1С, где эта подписка была изменена. При объединении ваши изменения в списке типов могут быть затерты, так как это свойство хранится как единая строка/массив типов. Именно поэтому рекомендуется использовать Расширения для добавления своих типов в источники подписок — это гораздо более устойчивый метод к обновлениям.
Рассмотрим, как убедиться, что регистрация начала работать. Не обязательно каждый раз запускать полный обмен. Выясним это с помощью встроенных инструментов:
В открывшемся окне найдите свой новый объект. Попробуйте записать новый элемент справочника или документ. Если после записи он появился в этом списке — регистрация настроена верно. Если список пуст — проблема в подписках или составе плана обмена.
Даже если регистрация работает, данные могут не попасть в файл обмена, если платформа не знает, как превратить их в XML. В классическом РИБ это происходит автоматически на основе метаданных. Однако, если вы используете не «Полный» обмен, а обмены через универсальный механизм (на правилах), вам потребуется править Правила конвертации данных (ПКО/ПВД).
В случае с РИБ важно помнить: конфигурация в главном и подчиненном узлах должна быть идентичной. Если вы добавили объект в главном узле, он сначала должен «прилететь» в подчиненный узел в виде обновления конфигурации. Пока конфигурации не сравняются, данные по новым объектам передаваться не будут (либо будут вызывать ошибки сериализации).
В некоторых случаях может потребоваться ручная регистрация в коде модуля объекта. Рассмотрим пример:
Процедура ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
Если ОбменДанными.Загрузка Тогда
Возврат;
КонецЕсли;
// Получаем список узлов, куда нужно отправить данные
Узлы = ПланыОбмена.Полный.Выбрать();
Пока Узлы.Следующий() Цикл
Если Узлы.Ссылка <> ПланыОбмена.Полный.ЭтотУзел() Тогда
ПланыОбмена.ЗарегистрироватьИзменения(Узлы.Ссылка, ЭтотОбъект.Ссылка);
КонецЕсли;
КонецЦикла;
КонецПроцедуры
Однако помните, что это «костыльный» метод. Правильнее использовать механизмы БСП и подписки на события, так как они учитывают блокировки, транзакции и общие настройки синхронизации.
Подведем итоги. Чтобы ваши новые объекты начали синхронизироваться в РИБ типовой конфигурации, выполните следующие действия:
Следуя этой структуре, вы обеспечите корректную и стабильную работу обмена данными без нарушения логики типового решения.