При работе с распределенными информационными базами (РИБ) системные администраторы и разработчики 1С нередко сталкиваются с парадоксальной ситуацией: в центральной информационной базе выполнено тестирование и исправление, регламентная процедура Закрытие месяца проходит идеально, экспресс-проверка не выявляет проблем. Однако сразу после создания начального образа и разворачивания подчиненного узла попытка повторно закрыть тот же самый период в периферийной базе завершается аварийно. Программа выдает ошибки неуникальности записей в регистрах сведений (например, по плановым начислениям), кадровые документы искажают связи физических лиц и сотрудников, а формы регламентированной отчетности оказываются недоступными для создания.
Разберем детально, почему так происходит, в чем заключается скрытая специфика штатного механизма создания начального образа и как правильно инициализировать узел РИБ, чтобы полностью сохранить целостность данных.
Главное заблуждение заключается в предположении, что платформенный метод СоздатьНачальныйОбраз переносит в подчиненную базу абсолютно всю информацию. На самом деле платформа выгружает в образ только те объекты, которые явно включены в состав используемого плана обмена.
Рассмотрим ключевые факторы, приводящие к расхождениям:
РегламентированныеОтчеты в периферийной базе часто оказывается незаполненным или неактуализированным. Механизмы конфигурации не позволяют создать отчет локально, пока перечень форм не будет обновлен или пока готовый отчет не придет пакетом синхронизации из центра.Чтобы гарантировать стопроцентное совпадение таблиц, регистров и системных настроек между центральной и подчиненной базами, наиболее надежно отказаться от выгрузки штатного образа и применить технологию клонирования рабочей базы с последующей привязкой узла РИБ.
Разберем по шагам алгоритм создания периферийной базы через полную копию:
1С:Предприятие, перейдем в используемый план обмена и добавим новый элемент узла для будущей периферийной базы (зададим наименование и уникальный код узла)..dt)./РегламентныеЗаданияЗапрещены) и программно укажем для нее вышестоящий узел. Для этого запустим внешнюю обработку со следующим кодом:
// Устанавливаем ссылку на узел, который должен стать главным для текущей базы
УзелЦентральнойБазы = ПланыОбмена.Полный.НайтиПоКоду("ЦБ");
Если ЗначениеЗаполнено(УзелЦентральнойБазы) Тогда
ПланыОбмена.УстановитьГлавныйУзел(УзелЦентральнойБазы);
Сообщить("Главный узел успешно назначен: " + Строка(УзелЦентральнойБазы));
Иначе
ВызватьИсключение "Узел центральной базы с указанным кодом не найден!";
КонецЕсли;
// Удаляем всю накопившуюся регистрацию для центрального узла
ПланыОбмена.УдалитьРегистрациюИзменений(УзелЦентральнойБазы);
Сообщить("Регистрация изменений в подчиненном узле очищена.");
0.При таком подходе периферийная база содержит абсолютно те же самые записи регистров сведений, расчетные итоги и вспомогательные таблицы, что и центральная база. Ошибки при закрытии месяца в таком узле полностью исключены.
Если начальный образ уже был развернут и требуется устранить ошибки на месте без повторного клонирования, выполним следующий комплекс действий:
РегламентированныеОтчеты и нажмем кнопку Обновить в командной панели формы списка. Программа перечитает внутренние макеты конфигурации и восстановит список доступных форм отчетности.Конфигуратор и выполним операцию Администрирование > Тестирование и исправление. В списке проверок обязательно отметим пункты Реструктуризация таблиц информационной базы и Пересчет итогов. Это устранит внутренние несоответствия индексов и уникальности записей в периодических регистрах.1cv8 внутри %LocalAppData% и %AppData%).