Почему в центральной базе учет закрывается без ошибок, а в периферийной базе РИБ возникают сбои?

Программист 1С v8.3 (Управляемые формы) 1C:Бухгалтерия Бухгалтерский учет IT и автоматизация бизнеса
← На главную

При работе с распределенными информационными базами (РИБ) системные администраторы и разработчики 1С нередко сталкиваются с парадоксальной ситуацией: в центральной информационной базе выполнено тестирование и исправление, регламентная процедура Закрытие месяца проходит идеально, экспресс-проверка не выявляет проблем. Однако сразу после создания начального образа и разворачивания подчиненного узла попытка повторно закрыть тот же самый период в периферийной базе завершается аварийно. Программа выдает ошибки неуникальности записей в регистрах сведений (например, по плановым начислениям), кадровые документы искажают связи физических лиц и сотрудников, а формы регламентированной отчетности оказываются недоступными для создания.

Разберем детально, почему так происходит, в чем заключается скрытая специфика штатного механизма создания начального образа и как правильно инициализировать узел РИБ, чтобы полностью сохранить целостность данных.

Выясним причину: почему начальный образ не равен полной копии базы

Главное заблуждение заключается в предположении, что платформенный метод СоздатьНачальныйОбраз переносит в подчиненную базу абсолютно всю информацию. На самом деле платформа выгружает в образ только те объекты, которые явно включены в состав используемого плана обмена.

Рассмотрим ключевые факторы, приводящие к расхождениям:

  1. Неполнота типового плана обмена «Полный». Даже если план обмена называется «Полный», разработчики типовых конфигураций (в частности, «1С:Бухгалтерия предприятия») намеренно исключают из него ряд служебных регистров сведений, регистров соответствия объектов, кэши поставляемых данных и некоторые классификаторы. В результате развернутая база изначально лишена части служебных таблиц.
  2. Коллизии движений при повторном проведении документов. Документы начислений и кадровых изменений переносятся в подчиненную базу, но часть периодических регистров сведений переносится без полной предыстории либо инициализируется стандартными процедурами первого запуска. При попытке перезакрыть месяц алгоритмы проведения пытаются заново сформировать записи, наталкиваясь на уже существующие ключи записей или несоответствия в измерениях, что вызывает ошибку нарушения уникальности.
  3. Недоступность регламентированных отчетов. Справочник РегламентированныеОтчеты в периферийной базе часто оказывается незаполненным или неактуализированным. Механизмы конфигурации не позволяют создать отчет локально, пока перечень форм не будет обновлен или пока готовый отчет не придет пакетом синхронизации из центра.
  4. Фоновые процессы первого запуска БСП. При первом входе в созданный узел стартуют процедуры обновления Библиотеки Стандартных Подсистем. Если параллельно запускаются регламентные задания или пользователь сразу начинает выполнять перепроведение, происходит конфликт параллельной записи данных.

Вариант 1. Разворачивание периферийного узла из полной копии базы (рекомендуемый способ)

Чтобы гарантировать стопроцентное совпадение таблиц, регистров и системных настроек между центральной и подчиненной базами, наиболее надежно отказаться от выгрузки штатного образа и применить технологию клонирования рабочей базы с последующей привязкой узла РИБ.

Разберем по шагам алгоритм создания периферийной базы через полную копию:

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

При таком подходе периферийная база содержит абсолютно те же самые записи регистров сведений, расчетные итоги и вспомогательные таблицы, что и центральная база. Ошибки при закрытии месяца в таком узле полностью исключены.

Вариант 2. Исправление ошибок в уже созданном стандартном образе

Если начальный образ уже был развернут и требуется устранить ошибки на месте без повторного клонирования, выполним следующий комплекс действий:

  1. Обновление справочника регламентированной отчетности. Чтобы бухгалтер мог создавать отчеты в периферийной базе без предварительной синхронизации, откроем справочник РегламентированныеОтчеты и нажмем кнопку Обновить в командной панели формы списка. Программа перечитает внутренние макеты конфигурации и восстановит список доступных форм отчетности.
  2. Тестирование и исправление таблиц. Запустим периферийную базу в режиме Конфигуратор и выполним операцию Администрирование > Тестирование и исправление. В списке проверок обязательно отметим пункты Реструктуризация таблиц информационной базы и Пересчет итогов. Это устранит внутренние несоответствия индексов и уникальности записей в периодических регистрах.
  3. Очистка пользовательского и серверного кэша. Некорректные ссылки сотрудников на чужие физические лица в динамических списках зачастую обусловлены повреждением кэша представлений. Полностью удалим каталоги кэша на рабочей станции пользователя (папки 1cv8 внутри %LocalAppData% и %AppData%).
  4. Проверка прав доступа и функциональности. Перейдем в раздел Главное > Функциональность и сверим настройки с центральной базой. Если функциональные опции были перенесены некорректно, часть реквизитов документов кадрового учета может не учитываться при проведении, провоцируя системные ошибки.
← На главную