При работе с распределенными информационными базами (РИБ) в конфигурации «1С:Управление торговлей 11» (а также в «1С:ERP» и «1С:Комплексная автоматизация 2») администраторы и разработчики часто сталкиваются с крайне неприятной проблемой. После успешной синхронизации данных пользователи периферийного узла обнаруживают, что присланные из центрального офиса документы (например, поступления или реализации) полностью отсутствуют в специализированных журналах, таких как «Документы закупки все» или «Документы продажи все». При этом в общем журнале «Все торговые документы» или через стандартные функции технического специалиста эти документы прекрасно видны, открываются и даже проводятся.
В рамках этой статьи мы подробно разберем, почему возникает такое поведение системы, как устроена архитектура хранения списков документов в современных конфигурациях 1С, и рассмотрим практические шаги по восстановлению корректного отображения данных.
Для начала проанализируем внутреннее устройство конфигурации «1С:Управление торговлей 11». В старых версиях программных продуктов 1С динамические списки в журналах документов строились на основе прямых запросов к таблицам метаданных документов. В современных же конфигурациях, построенных на единой платформе ERP-решений, для повышения производительности системы при работе с большими объемами данных архитекторы 1С применили оптимизированный подход.
Специализированные журналы (все закупки, продажи, складские акты и другие) строятся не напрямую по таблицам документов, а используют вспомогательный регистр сведений РеестрДокументов. Этот регистр выступает в роли своеобразного индекса, аккумулирующего ключевые реквизиты документов (дату, номер, сумму, контрагента, организацию, склад и статус проведения) в одной плоской таблице. Общий журнал «Все торговые документы» может обращаться к метаданным напрямую, поэтому там документы отображаются, а специализированные журналы выводят пустоту, так как обращаются к незаполненному регистру РеестрДокументов.
При переносе данных через механизмы РИБ возникает следующая цепочка событий:
РежимЗагрузки = Истина): При приеме сообщения обмена в периферийной базе платформа 1С записывает объекты в режиме загрузки. В этом режиме временно отключаются стандартные обработчики событий (такие как ПередЗаписью, ПриЗаписи, ОбработкаПроведения), которые в обычном пользовательском режиме отвечают за фоновое формирование записей в регистре РеестрДокументов.РеестрДокументов часто исключен из состава планов обмена для уменьшения размера файлов выгрузки. Предполагается, что принимающая база должна автоматически актуализировать реестр при загрузке документов, однако из-за ошибок в коде конкретных релизов или сбоев этот механизм может не сработать.РеестрДокументов жестко привязана к аналитическому справочнику КлючиРеестраДокументов. Если при переносе документов сами объекты (склады, организации, партнеры) перенеслись, а соответствующие им элементы ключей аналитики не создались, система физически не сможет сформировать запись в реестре.Ниже мы рассмотрим четыре эффективных способа решения этой проблемы, начиная от использования встроенного функционала 1С и заканчивая написанием программного скрипта для принудительного заполнения регистра.
В современных релизах «1С:Управление торговлей 11» разработчики предусмотрели штатный инструмент для восстановления целостности данных реестра. Выполним следующие шаги для его запуска:
РеестрДокументов и предложит автоматически переформировать недостающие строки.Дополнительно рекомендуем проверить справочник КлючиРеестраДокументов. В форме списка этого справочника часто доступна гиперссылка «Запустить процедуру удаления дублей» или аналогичные сервисные функции, которые помогают пересчитать аналитические ключи для корректной привязки документов.
Если документов относительно немного или они относятся к ограниченному периоду, мы можем заставить систему заново выполнить обработчики записи объектов вне режима загрузки. Это спровоцирует автоматическое заполнение регистра РеестрДокументов.
Для этого воспользуемся стандартным инструментом группового изменения реквизитов:
Реализация товаров и услуг или Приобретение товаров и услуг. При необходимости настроим отбор по периоду или организации, чтобы не перегружать систему.Проведен. Выполним групповое изменение. Физическая перезапись объектов инициирует стандартные транзакционные механизмы платформы, и записи в регистре РеестрДокументов будут успешно созданы.Иногда записи в регистре не могут создаться из-за того, что «зависли» или заблокировались элементы справочника КлючиРеестраДокументов, привязанные к конкретным складам, кассам или партнерам. Выясним, как это исправить:
Такая простая манипуляция принудительно запускает механизмы обновления связанных аналитических ключей, после чего документы по этому объекту при следующей перезаписи начнут без проблем регистрироваться в реестре.
Если вышеперечисленные интерактивные методы не помогли или объем данных слишком велик для ручной обработки, мы можем прибегнуть к программному решению задачи. Для этого создадим внешнюю обработку и запустим специализированный метод, встроенный в саму конфигурацию «1С:Управление торговлей 11».
Рассмотрим пример кода, который выполняет принудительное заполнение регистра сведений РеестрДокументов по выбранному типу документов за определенный период:
ВыборкаДокументов = Документы.ПриобретениеТоваровУслуг.Выбрать(НачалоДня(ТекущаяДата() - 86400 * 30), КонецДня(ТекущаяДата()));
Пока ВыборкаДокументов.Следующий() Цикл
// Подготавливаем структуру дополнительных свойств
ДополнительныеСвойства = Новый Структура;
// Вызываем экспортный метод менеджера регистра для принудительного обновления записей
Попытка
РегистрыСведений.РеестрДокументов.ИнициализироватьИЗаписатьДанныеДокумента(
ВыборкаДокументов.Ссылка,
ДополнительныеСвойства,
Ложь
);
Исключение
ЗаписьЖурналаРегистрации(
"ОшибкаОбновленияРеестра",
УровеньЖурналаРегистрации.Ошибка,,,
"Не удалось обновить реестр для документа: " + ВыборкаДокументов.Ссылка + " " + ОписаниеОшибки()
);
КонецПопытки;
КонецЦикла;
Этот метод напрямую обращается к логике проведения документа по регистру сведений РеестрДокументов, минуя тяжелую процедуру полного перепроведения документа по всем регистрам накопления и бухгалтерии. Это позволяет оперативно восстановить видимость тысяч документов в журналах всего за несколько минут.
В процессе обсуждения данной проблемы часто возникает сопутствующий вопрос: можно ли для упрощения настройки установить одинаковые префиксы для разных узлов распределенной информационной базы?
Настоятельно не рекомендуем этого делать! Одинаковые префиксы номеров документов в разных базах неизбежно приведут к конфликтам нумерации и перезаписи документов. При синхронизации документы из разных узлов с одинаковыми номерами начнут "схлопываться" или вызывать критические ошибки уникальности на уровне платформы. Каждый узел РИБ должен обладать уникальным префиксом для обеспечения корректной сквозной нумерации объектов в рамках всей распределенной системы.
Используя предложенные методики, мы можем гарантировать стабильную работу пользователей в периферийных узлах и полное соответствие отображаемых данных во всех журналах документов системы.