При работе с локальными версиями (коробочными решениями) «1С:Бухгалтерии 8» программисты и администраторы привыкли к гибкости настроек синхронизации данных. Мы можем зайти в регистр сведений ПравилаДляОбменаДанными, подгрузить свои правила регистрации, созданные в «1С:Конвертации данных 2.0», и четко определить, какие объекты должны уходить в узел обмена, а какие — нет. Однако при переходе в облачный сервис «1С:Фреш» (1cfresh.com) пользователи обнаруживают, что привычные настройки недоступны, а попытки обратиться к правилам напрямую через интерфейс или по ссылке e1cib/list/РегистрСведений.ПравилаДляОбменаДанными заканчиваются сообщением о недостатке прав доступа.
В этой статье мы подробно разберем, почему архитектура облачного сервиса накладывает такие ограничения, и какие существуют легальные и технические способы реализовать индивидуальную логику обмена в условиях модели разделения данных.
Рассмотрим ситуацию с точки зрения безопасности облачной инфраструктуры. В традиционных правилах обмена (КД 2.0) логика регистрации объектов описывается на языке 1С непосредственно внутри XML-файла правил. Это так называемые обработчики событий: «Перед обработкой», «При регистрации», «После регистрации». Когда система загружает такие правила, она должна выполнить этот произвольный программный код.
В модели сервиса (SaaS) выполнение произвольного кода из данных базы является критической уязвимостью. Если бы администраторы сервиса разрешили редактирование правил регистрации, любой пользователь мог бы написать в обработчике код, который получает доступ к данным соседних областей (других клиентов), удаляет файлы на сервере или дестабилизирует работу всей кластерной системы. Проанализируем ключевые механизмы защиты:
Выполнить() или Вычислить() в контексте загруженных правил блокируется платформой.EnterpriseData. Здесь логика преобразования и регистрации жестко прописана в модулях конфигурации, а не во внешних файлах, что делает систему более стабильной и безопасной.Если нам необходимо изменить логику регистрации объектов (например, запретить выгрузку документов определенного вида или добавить фильтр по реквизиту, которого нет в типовых настройках), мы можем воспользоваться механизмом расширений. Во «Фреше» расширения разрешены, но они проходят обязательный аудит со стороны специалистов 1С.
Разберем алгоритм реализации кастомной регистрации через расширение:
Создадим расширение и добавим в него подписку на событие ПриЗаписи для нужного нам объекта (например, документа ТребованиеНакладная). В обработчике подписки мы можем программно управлять регистрацией в плане обмена. Проанализируем пример кода:
// В модуле расширения
&После("ПриЗаписи")
Процедура Расш_ПриЗаписиДокумента(Источник, Отказ)
// Проверяем, не выполняется ли уже обмен, чтобы избежать зацикливания
Если Источник.ОбменДанными.Загрузка Тогда
Возврат;
КонецЕсли;
// Определяем нужный узел обмена
УзелИнтеграции = ПланыОбмена.СинхронизацияДанныхЧерезУниверсальныйФормат.НайтиПоНаименованию("НашУзел");
// Реализуем свою логику фильтрации
Если Источник.СуммаДокумента > 1000 Тогда
// Регистрируем объект на узле программно
ПланыОбмена.ЗарегистрироватьИзменения(УзелИнтеграции, Источник.Ссылка);
Иначе
// Удаляем регистрацию, если условие не выполнено
ПланыОбмена.УдалитьРегистрациюИзменений(УзелИнтеграции, Источник.Ссылка);
КонецЕсли;
КонецПроцедуры
Важный нюанс: Любое расширение во «Фреше» должно соответствовать требованиям безопасности. Использование методов типа ПланыОбмена.ЗарегистрироватьИзменения допустимо, но аудит может отклонить расширение, если оно массово перерегистрирует данные, создавая избыточную нагрузку на сервера облака.
Рассмотрим еще один мощный инструмент — создание автономного рабочего места. АРМ — это фактически локальная копия вашей базы из облака, которая синхронизируется с сервером «1С:Фреш» автоматически.
Как это помогает решить проблему с правилами обмена?
ПравилаДляОбменаДанными.Этот путь позволяет обойти ограничения на выполнение кода, так как фактически код правил выполняется на вашем локальном железе, а не на серверах 1С.
Если ваша задача — выгрузить документ, который в принципе отсутствует в типовом составе обмена EnterpriseData (например, специфический производственный документ), вам придется расширять сам формат. Рассмотрим шаги:
Проанализируем состав плана обмена СинхронизацияДанныхЧерезУниверсальныйФормат. Если объекта там нет, его нужно добавить в состав плана обмена через расширение. Далее, используя механизмы БСП, необходимо переопределить модули менеджера обмена. В расширении создаются обработчики:
ППО_ПриОтправкеДанных — для описания логики выгрузки.ППО_ПриПолученииДанных — для описания логики загрузки.Это самый трудозатратный, но и самый «правильный» с точки зрения архитектуры 1С способ. Он требует глубоких знаний устройства БСП и формата XDTO.
Отсутствие настроек правил регистрации в 1С:Фреш — это не «недосмотр админов», а фундаментальное требование безопасности многопользовательской среды. Для решения задач кастомного обмена в облаке мы рекомендуем:
1. Использовать расширения конфигурации для программной регистрации объектов в типовых планах обмена.
2. Использовать автономные рабочие места, если требуется применение правил «Конвертации данных 2.0».
3. Применять универсальный формат EnterpriseData и расширять его возможности через модули менеджера обмена в расширении.
Помните, что во «Фреше» синхронизация данных часто включена принудительно (функциональная опция ИспользоватьСинхронизациюДанных установлена в Истина), чтобы обеспечить бесперебойную работу связанных сервисов, таких как «1С:Касса» или мобильные приложения.