Как правильно изменить реквизит документа-основания при проведении подчиненного документа

← На главную

В практике разработки на платформе 1С:Предприятие часто возникает задача: при проведении документа (например, «Реализация товаров и услуг») необходимо автоматически изменить статус или какой-либо реквизит в документе-основании (например, в «Заказе клиента»). Несмотря на кажущуюся простоту, эта задача таит в себе множество подводных камней: от блокировок базы данных и проблем с закрытыми периодами до бесконечных циклов перепроведения. Рассмотрим подробнее, как реализовать этот функционал правильно, эффективно и с соблюдением стандартов разработки.

Проблема прямой записи документа в транзакции проведения

Разберем типичную ситуацию: разработчик прописывает код изменения документа-основания непосредственно в процедуре ОбработкаПроведения текущего документа. Почему это может быть плохим решением? Во-первых, проведение документа всегда происходит внутри транзакции. Если при записи документа-основания произойдет ошибка (например, сработает проверка заполнения или документ окажется заблокирован другим пользователем), транзакция проведения текущего документа также будет отменена. Во-вторых, если документ-основание находится в закрытом для редактирования периоде, обычная запись будет заблокирована платформой.

Проанализируем основные способы решения этой задачи, начиная от самых «чистых» с точки зрения архитектуры и заканчивая практическими приемами для работы с существующими реквизитами.

Решение 1: Использование Регистра Сведений (Архитектурно верный подход)

Наиболее правильным решением является вынос изменяемого реквизита из состава документа в отдельный Регистр Сведений. Вместо того чтобы менять значение внутри объекта документа, мы записываем состояние в регистр, где измерением является ссылка на документ-основание, а ресурсом — необходимое значение.

Преимущества этого метода:

Независимость от периода: Запись в регистр сведений не требует изменения самого документа, а значит, не нужно открывать период для бухгалтерии.
Отсутствие блокировок: Мы не блокируем объект документа для редактирования другими пользователями.
Скорость: Запись в регистр происходит значительно быстрее, чем перезапись всего объекта документа со всеми его табличными частями и проверками.

Для того чтобы пользователь мог видеть это значение в списке документов и выполнять по нему отборы, в 1С (особенно в обычных формах) можно использовать механизм Характеристик или соединение с таблицей регистра в динамическом списке (для управляемых форм). Рассмотрим пример кода для записи в регистр сведений при проведении:


Процедура ОбработкаПроведения(Отказ, РежимПроведения)
    
    // Подготовим структуру для записи в регистр
    МенеджерЗаписи = РегистрыСведений.СтатусыДокументовОснований.СоздатьМенеджерЗаписи();
    МенеджерЗаписи.ДокументОснование = ЭтотОбъект.ДокументОснование;
    МенеджерЗаписи.Статус = Перечисления.СтатусыЗаказов.Исполнен;
    МенеджерЗаписи.Период = ТекущаяДата();
    
    Попытка
        МенеджерЗаписи.Записать(Истина);
    Исключение
        Отказ = Истина;
        Сообщить("Не удалось обновить статус основания: " + ОписаниеОшибки());
    КонецПопытки;
    
КонецПроцедуры

Решение 2: Обновление реквизита документа через режим загрузки

Если архитектура конфигурации не позволяет использовать регистры (например, реквизит уже задействован в десятках отчетов и типовых механизмах), нам придется обновлять именно реквизит объекта. Чтобы избежать проблем с датами запрета и лишними проверками, используем свойство ОбменДанными.Загрузка = Истина.

Разберем по шагам, как это работает. Установка этого флага сообщает платформе, что запись объекта производится в режиме загрузки данных. В этом режиме пропускаются прикладные проверки в модулях (ПередЗаписью, ПриЗаписи), а также игнорируется проверка периода (в большинстве типовых конфигураций).

Посмотрим на пример реализации в подписке на событие или в модуле документа:


ОбъектОснование = ЭтотОбъект.ДокументОснование.ПолучитьОбъект();

// Проверяем, не является ли ссылка пустой и нужно ли вообще менять значение
Если ОбъектОснование <> Неопределено И ОбъектОснование.Статус <> Перечисления.Статусы.Проведено Тогда
    
    ОбъектОснование.Статус = Перечисления.Статусы.Проведено;
    
    // Включаем режим загрузки для обхода проверок и периодов
    ОбъектОснование.ОбменДанными.Загрузка = Истина;
    
    Попытка
        // Записываем только объект, не вызывая проведение документа-основания
        ОбъектОснование.Записать(РежимЗаписиДокумента.Запись);
    Исключение
        Инфо = ИнформацияОбОшибке();
        ЗаписьЖурналаРегистрации("ОбновлениеОснования", УровеньЖурналаРегистрации.Ошибка, , , ПодробноеПредставлениеОшибки(Инфо));
    КонецПопытки;
    
КонецЕсли;

Решение 3: Использование механизма ДополнительныеСвойства

Выясним причину, почему иногда использование записи «в лоб» приводит к конфликтам блокировок. Когда мы проводим документ «А» и внутри него записываем документ «Б», платформа накладывает блокировки на оба объекта. Если в этот момент другой процесс пытается сделать обратное, возникает Deadlock (взаимная блокировка).

Чтобы минимизировать время нахождения в транзакции и передать данные между обработчиками, используем структуру ДополнительныеСвойства. Мы можем пометить документ-основание как «требующий обновления» в модуле объекта, а саму запись произвести в подписке на событие ПриЗаписи или ОбработкаПроведения.

Рассмотрим, как это реализовать:

В модуле документа в процедуре ОбработкаПроведения добавляем флаг: ЭтотОбъект.ДополнительныеСвойства.Вставить("ОбновитьОснование", Истина);.
Создаем подписку на событие ПриЗаписи для этого типа документа.
В обработчике подписки проверяем наличие флага и выполняем обновление основания.

Это позволяет четко разделить логику проведения текущего документа и логику влияния на другие объекты системы.

Решение 4: Отложенное обновление (Очередь задач)

Проанализируем ситуацию, когда моментальное обновление реквизита не критично (например, задержка в 10–30 секунд допустима), но крайне важна стабильность проведения основного документа. В этом случае идеальным вариантом будет использование Очереди задач.

Вместо непосредственной записи документа-основания, мы фиксируем необходимость изменения в специальном регистре (назовем его «ОчередьОбновленияДокументов»).

Алгоритм работы:

При проведении документа в транзакции записывается только одна маленькая запись в регистр сведений: Ссылка на основание и новое значение реквизита.
Настроено регламентное задание, которое запускается раз в минуту (или чаще) и обрабатывает записи из этого регистра.
Регламентное задание по очереди считывает задачи, пробует записать документы-основания и, в случае успеха, удаляет задачу из очереди.

Этот подход гарантирует, что пользователь никогда не получит ошибку проведения своего документа из-за того, что кто-то другой в этот момент редактирует документ-основание.

Резюме

Подводя итог, можно выстроить следующую иерархию правильности решений:

Регистр Сведений — лучший выбор для сохранения целостности и производительности.
Запись с ОбменДанными.Загрузка = Истина — допустимый вариант для существующих реквизитов, позволяющий обойти запреты редактирования периодов.
Очередь задач через фоновое задание — оптимально для высоконагруженных систем, где важна скорость отклика интерфейса.

Никогда не забывайте про обработку исключений (блок Попытка...Исключение) при записи связанных объектов, так как это критическая точка, способная остановить работу пользователей в самый ответственный момент.