При работе с распределенными информационными базами (РИБ) одной из самых неприятных проблем является ситуация, когда после создания начального образа подчиненного узла обнаруживается расхождение остатков. На первый взгляд всё кажется правильным: документы (например, ПеремещениеТоваров или РеализацияТоваровУслуг) перенеслись, но при проверке движений выясняется, что записи в регистрах накопления (таких как ПартииТоваровНаСкладах) отсутствуют. В итоге — документы в базе есть, а остатки «пустые».
В этой статье мы подробно разберем причины возникновения такой проблемы на примере конфигурации «Управление ювелирным предприятием» (базируется на «Управление торговлей 10.3») и рассмотрим пошаговый алгоритм её решения.
Для начала важно понимать, что создание начального образа РИБ — это не простое копирование файлов базы данных или таблиц SQL. Это сложный процесс, в ходе которого система 1С:Предприятие анализирует состав плана обмена и последовательно выгружает объекты, на которые установлена «Авторегистрация» или которые были принудительно зарегистрированы для узла.
Если документ переносится, а его движения — нет, значит, на этапе миграции данных произошел разрыв связи между объектом (документом) и его набором записей в регистре. Проанализируем основные причины, почему это происходит.
Самая очевидная причина — отсутствие регистра накопления в составе плана обмена. Рассмотрим, как это проверить:
Полный или ПоОрганизациям).ПартииТоваровНаСкладах (или тот, по которому расходятся остатки).Разрешить.Важный момент: Если для документа авторегистрация включена, а для регистра — выключена, то при создании узла приедет только «шапка» документа. Движения появятся только в том случае, если вы вручную перепроведете документ уже в подчиненном узле, что крайне не рекомендуется делать массово в РИБ.
В отраслевых решениях, таких как «Управление ювелирным предприятием», часто внедряются дополнительные проверки, чтобы не передавать лишние данные в торговые точки. Нам необходимо проверить программный код, который управляет выгрузкой.
Проанализируем модуль плана обмена, а именно процедуру ПриОтправкеДанныхПодчиненному. Именно здесь разработчики часто ставят «заглушки». Посмотрим на пример кода, который может блокировать движения:
Процедура ПриОтправкеДанныхПодчиненному(ЭлементДанных, ОтправкаЭлемента)
// Если мы отправляем набор записей регистра накопления
Если ТипЗнч(ЭлементДанных) = Тип("РегистрНакопленияНаборЗаписей.ПартииТоваровНаСкладах") Тогда
// Проверяем, есть ли в движениях склад, не относящийся к этому узлу
Для Каждого Запись Из ЭлементДанных Цикл
Если Запись.Склад <> УзелПолучатель.ОсновнойСклад Тогда
ОтправкаЭлемента = ОтправкаЭлементаДанных.Игнорировать;
Возврат;
КонецЕсли;
КонецЦикла;
КонецЕсли;
КонецПроцедуры
Если в коде присутствует подобная логика, и при этом в основной базе склад в движениях по какой-то причине не заполнен (или заполнен некорректно), фильтр просто «отсечет» эти движения при создании начального образа. Проверьте этот модуль на наличие условий Игнорировать или Удалить.
В УТ 10.3 и её производных движения по партиям критично зависят от настроек партионного учета. Если при создании узла настройки учетной политики (регистры сведений) не передались первыми, то система может вести себя непредсказуемо.
Рассмотрим ситуацию: в главной базе включен режим «Списывать партии при проведении документов», а в подчиненном узле эта константа или запись регистра сведений еще не активна. При попытке системы «подтянуть» движения при обмене могут возникнуть коллизии. Убедитесь, что все константы и параметры учета включены в план обмена и мигрируют в первую очередь.
В ювелирной торговле часто используется механизм отложенного проведения по партиям. Это означает, что документ ПеремещениеТоваров может быть оперативно проведен (сделает движения по регистру ТоварыНаСкладах), но движения по ПартииТоваровНаСкладах сформируются позже специальной обработкой.
Если вы создаете начальный образ базы в момент, когда документы проведены, но партии еще не «допроведены» обработкой, в подчиненный узел уйдут пустые наборы записей. Перед созданием РИБ обязательно выполните регламентную операцию «Проведение по партиям» за весь актуальный период.
Если узел уже создан и вы обнаружили нехватку движений, выполните следующие действия для восстановления целостности данных:
ПартииТоваровНаСкладах и добавьте в него движения по проблемным документам.ТиИ в главной базе с включенным пунктом «Проверка логической целостности».Проанализируем специфику конфигурации «Управление ювелирным предприятием». В отличие от стандартной УТ, здесь регистр партий имеет гораздо больше измерений: Проба, Вес, Размер, Группа вставок. Если вы добавляли свои реквизиты или характеристики, проверьте, не нарушена ли их уникальность или тип данных. Иногда при сериализации (превращении данных в XML для передачи) специфические типы данных вызывают ошибку, которую система может «проглотить», просто не передав конкретную запись регистра.
Чудес в 1С не бывает: если документ есть, а движений нет — значит, они либо не были зарегистрированы к обмену, либо были отсечены программным фильтром ПриОтправкеДанных. Начните диагностику с проверки состава плана обмена и ручной регистрации одного документа. Если после ручной регистрации и обмена движения появились — проблема в настройках авторегистрации. Если не появились — ищите преграду в программном коде модуля плана обмена.