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