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