При настройке обмена данными между двумя идентичными конфигурациями «Бухгалтерия предприятия 3.0» (БП 3.0) часто возникает задача создания «зеркальной» базы для стороннего пользователя. Основная цель — ограничить доступ внешнего контрагента или аудитора только данными одной организации и только за определенный период (например, текущий год), сохранив при этом актуальность данных в реальном времени. Разберем, почему стандартная синхронизация через универсальный формат может выдавать ошибки и как правильно использовать механизм РИБ (распределенных информационных баз) для решения этой задачи.
Рассмотрим ситуацию, когда при попытке выполнить начальную выгрузку через «Синхронизацию данных через универсальный формат» (Enterprise Data) система выдает ошибку: «Значение не является значением объектного типа (Данные выгружены)». Проанализируем причины этого сбоя:
EnterpriseData. Если в одной базе выбрана версия 1.8, а в другой 1.10, программный код БСП (Библиотеки стандартных подсистем) при обработке структуры результата может получить Неопределено вместо ожидаемого объекта.Temp, формирование файла обмена прерывается, а вызывающая функция пытается обратиться к свойству несуществующего объекта.Для решения этой проблемы рекомендуется проверить справочник Настройки синхронизации данных и убедиться, что версии формата идентичны. Однако, как показывает практика, для идентичных баз БП 3.0 гораздо эффективнее использовать механизм РИБ по организации.
Механизм РИБ (Распределенная Информационная База) по организации — это штатный инструмент 1С, который позволяет автоматически фильтровать данные. В отличие от универсального формата, который передает данные через XML на уровне бизнес-логики, РИБ работает на уровне таблиц БД, что обеспечивает более высокую надежность и полноту передачи данных.
Рассмотрим преимущества этого метода:
Если основная база имеет огромный объем данных (миллионы объектов), создание «начального образа» штатными средствами может занять несколько суток. Разберем по шагам «хитрый» способ, как превратить уже готовую копию базы в полноценный узел РИБ.
Шаг 1. Подготовка в главной базе
В основной рабочей базе создадим новый узел в плане обмена По организации. Присвоим ему префикс (например, «СП» — сторонний пользователь). Настроим фильтр по нужной организации. Важно: запомните код этого узла.
Шаг 2. Подготовка в базе-копии (периферийной)
Возьмем копию базы, где уже выполнена свертка данных. Нам необходимо «объяснить» этой базе, что она теперь является подчиненной. Для этого воспользуемся встроенными средствами платформы. Проанализируем программный код, который необходимо выполнить в копии базы (например, через внешнюю обработку):
// Сначала сбросим текущий статус базы, чтобы она не считала себя главной
ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
// Найдем узел, который соответствует нашей главной базе
// Обычно это узел с кодом, который был у главной базы изначально
ГлавныйУзел = ПланыОбмена.ПоОрганизации.НайтиПоКоду("ГБ");
Если Не ГлавныйУзел.Пустая() Тогда
ПланыОбмена.УстановитьГлавныйУзел(ГлавныйУзел);
Сообщить("База успешно привязана к главному узлу.");
Иначе
Сообщить("Узел главной базы не найден!");
КонецЕсли;
Шаг 3. Синхронизация идентификаторов
Для того чтобы обмен заработал, GUID узла ЭтаБаза в подчиненной базе должен совпадать с GUID узла-корреспондента в главной базе. Это критически важный момент. Если вы создали узлы вручную, воспользуйтесь обработкой для замены ссылок или напрямую подмените идентификаторы в таблицах планов обмена.
Важный аспект: автор темы выполнил свертку в базе-копии. Выясним причину, почему это может быть опасно при включении синхронизации. Если вы удалили документы прошлых периодов в подчиненной базе, при первом же обмене система может зарегистрировать эти удаления и попытаться «удалить» эти же документы в главной базе.
Чтобы избежать катастрофы, выполним следующие действия:
Дата запрета загрузки. Также в правилах отправки укажем дату начала текущего года.Регистрация изменений для обмена данными.Отменить регистрацию всех объектов.Если создание второй базы кажется слишком трудоемким, проанализируем ситуацию с ограничением прав. Автор утверждает, что RLS (Record Level Security) не дает ограничить отчеты по дате. Однако в БП 3.0 можно использовать механизм Профилей групп доступа и Даты запрета изменения.
Для более жесткого контроля можно внедрить небольшое расширение, которое будет модифицировать запросы отчетов. Посмотрим на логику работы такого расширения:
В расширении перехватывается событие ПриКомпоновкеРезультата в модулях отчетов. Программно добавляется условие: ГДЕ Период >= &ДатаНачалаПросмотра. Это гарантирует, что даже если пользователь сформирует ОСВ за прошлый год, отчет вернется пустым, так как данные будут отсечены на уровне SQL-запроса платформой.
Для стабильной синхронизации двух одинаковых баз БП 3.0 на платформе 8.3.15 рекомендуется отказаться от универсального формата в пользу РИБ по организации. Использование метода «привязки копии» сэкономит время на создание начального образа, а тщательная очистка таблиц регистрации изменений предотвратит нежелательное удаление данных в основной базе после свертки периферийной.