Рассмотрим ситуацию, с которой часто сталкиваются разработчики при работе с конфигурациями: реквизиты документа в его форме отображаются корректно, однако в списке документов (динамическом списке) мы видим совершенно другие значения. Особенно часто это проявляется при программном создании документов через внешние мобильные решения, такие как «МобиС».
Первое, что необходимо понять: Динамический список не всегда считывает данные напрямую из таблицы самого документа. В современных типовых решениях разработчики часто используют механизмы вывода данных, которые опираются на вспомогательные структуры.
РегистрыСведений или РегистрыНакопления, а не напрямую из реквизитов документа. Если при записи документа через внешнее API или мобильное устройство данные в этих регистрах не обновляются, список будет показывать старую или неверную информацию.ОбменДанными.Загрузка = Истина), обработчики событий, отвечающие за синхронизацию данных, не срабатывают. В итоге, база данных «видит» документ, но служебные таблицы остаются в прежнем состоянии.Склад, а в списке — СтруктурнаяЕдиница, которая в бизнес-логике может не совпадать с полем Склад.Давайте пошагово разберем, как найти причину несовпадения значений:
Запрос у основного динамического списка. Посмотрите, какие таблицы в нем используются и есть ли там соединения (ЛЕВОЕ СОЕДИНЕНИЕ) с регистрами. Именно там, скорее всего, берется неверное значение.ПриЗаписи или ОбработкаПроведения, которые обновляют данные для списков. Если документ создается программно, убедитесь, что вызов этих процедур происходит корректно.КонсолиЗапросов для проблемного документа. Это позволит увидеть «сырые» данные, которые платформа получает из базы данных до того, как они попадают в интерфейс.После того как мы выяснили, что данные расходятся из-за отсутствия актуализации регистров, можно применить следующие решения:
Вариант 1: Актуализация при записи. Если документ создается программно, обеспечьте вызов процедур, которые отвечают за запись в регистры. Для этого необходимо вызывать не просто метод Записать(), а, при необходимости, программно проводить документ или вызывать экспортные процедуры из модулей менеджера.
Вариант 2: Перенастройка динамического списка. Если данные в списке выводятся через регистр, который не всегда актуален, рассмотрите возможность изменения запроса так, чтобы он считывал данные непосредственно из реквизитов самого документа. Это исключит проблему «разрыва данных» между объектом и списком.
Вариант 3: Использование регламентных заданий. Если поток документов очень велик и запись происходит через внешние системы, настройте РегламентныеЗадания, которые будут проверять и исправлять данные (например, перепроводить документы за прошлые сутки), обеспечивая целостность информационной базы.
Пример программной записи, которая часто приводит к подобным ошибкам:
// Пример некорректной записи, при которой могут не отработать механизмы обновления регистров
ДокументОбъект = СсылкаНаДокумент.ПолучитьОбъект();
ДокументОбъект.ОбменДанными.Загрузка = Истина;
ДокументОбъект.Склад = НовыйСклад;
ДокументОбъект.Записать();
В данном случае, если логика отображения завязана на записи в РегистрСведений, такой код не вызовет пересчет этого регистра. Чтобы исправить ситуацию, необходимо либо явно вызвать запись в регистр после Записать(), либо убрать флаг Загрузка, если это допустимо бизнес-логикой, чтобы сработали все обработчики проведения.
Помните: перепроведение документа вручную «лечит» проблему только потому, что при проведении система принудительно вызывает все обработчики записи в регистры. Это подтверждает теорию о том, что проблема кроется в неактуальности вспомогательных данных, а не в самом реквизите документа.