Где в УПП 1.3 находится код заполнения документа Установка цен номенклатуры при вводе на основании

При доработке типовых конфигураций на обычных формах разработчики часто сталкиваются с неожиданным поведением платформы: требуется изменить или отключить алгоритм заполнения реквизитов нового документа при вводе на основании, разработчик комментирует стандартный обработчик ОбработкаЗаполнения в модуле объекта, но документ все равно открывается полностью заполненным. Проанализируем, почему так происходит в конфигурации «Управление производственным предприятием 1.3» на примере связки документов Поступление товаров и услуг и Установка цен номенклатуры, и выясним причину такого поведения.

В какой процедуре выполняется заполнение

Разберем архитектурную особенность документа Установка цен номенклатуры. В типовой УПП 1.3 табличная часть документа на экранной форме формируется динамически: состав и количество колонок с типами цен зависят от выбранных пользователем настроек и состава типов цен. По этой причине разработчики конфигурации вынесли основной код переноса данных из документа-основания непосредственно в модуль формы документа.

Алгоритм заполнения расположен в обработчике события ПередОткрытием формы документа. При интерактивном вводе на основании платформа инициализирует форму нового объекта и передает ссылку на документ-основание через специальное платформенное свойство ПараметрОснование (или структуру параметров). Процедура ПередОткрытием проверяет наличие этого параметра и, если он заполнен ссылкой на Поступление товаров и услуг, запускает внутренние процедуры чтения табличной части поступления, заполнения шапки и построения колонок цен.

Посмотрим на упрощенную схему того, как это работает в модуле формы:

Процедура ПередОткрытием(Отказ, СтандартнаяОбработка)

    Если ЭтоНовый() И ЗначениеЗаполнено(ПараметрОснование) Тогда
        // Вызов процедур заполнения документа по документу-основанию
        ЗаполнитьПоОснованию(ПараметрОснование);
    КонецЕсли;

КонецПроцедуры

Именно поэтому комментирование стандартного события ОбработкаЗаполнения в модуле объекта никак не влияет на интерактивное создание документа через интерфейс программы: модуль объекта отрабатывает первым, а затем форма переопределяет и заполняет данные заново.

Ограничения и риски типовой реализации

Рассмотрим подробнее проблемы, которые порождает размещение бизнес-логики заполнения внутри модуля формы:

1. Невозможность корректного программного создания: если документ создается программно в коде (например, в регламентном задании, при интеграции через веб-сервисы или при обмене данными через вызовы Документы.УстановкаЦенНоменклатуры.СоздатьДокумент() и метод Заполнить(Основание)), модуль формы не инициализируется вовсе. В результате созданный программно документ остается пустым.
2. Сложность сопровождения и дублирование кода: пытаясь изменить состав переносимых полей в модуле объекта, программист не увидит изменений в пользовательском интерфейсе. Попытка продублировать код и в модуле объекта, и в модуле формы приводит к двойному выполнению одних и тех же запросов при интерактивном вводе.

Как правильно доработать механизм заполнения

Разберем по шагам, как перенести логику заполнения на уровень модуля объекта с соблюдением стандартов разработки 1С:

1. Перенос логики выборки данных в модуль объекта: алгоритм извлечения номенклатуры, характеристик и цен из документа-основания необходимо разместить в процедуре ОбработкаЗаполнения модуля объекта ДокументОбъект.УстановкаЦенНоменклатуры (либо вызвать соответствующую процедуру общего модуля). В этом случае объект будет заполняться независимо от того, как он создается — интерактивно или программно.
2. Очистка обработчика формы: в модуле формы в процедуре ПередОткрытием следует убрать прямую логику заполнения реквизитов документа по ПараметрОснование, оставив исключительно интерфейсные действия: инициализацию динамических колонок табличного поля, настройку видимости элементов и обновление отображения цен на форме.
3. Управление параметрами при программном открытии: если открытие формы документа выполняется из сторонней обработки, ссылку на документ-основание необходимо корректно передавать в форму, чтобы визуальные алгоритмы формы понимали контекст инициализации.

Альтернативные штатные механизмы работы с ценами в УПП 1.3

Проанализируем методическую сторону вопроса. В типовой методологии УПП прямой ввод документа Установка цен номенклатуры на основании поступления используется не всегда. В конфигурации заложены более гибкие инструменты:

1. Регистрация цен поставщика: в классической цепочке сначала фиксируются закупочные цены контрагента через документ Регистрация цен номенклатуры контрагентов (который также может вводиться на основании поступления), а затем цены компании (оптовые, розничные) рассчитываются динамически на основании зарегистрированных базовых цен.
2. Обработка «Формирование цен»: специализированный штатный инструмент, позволяющий пакетно рассчитывать новые цены с учетом заданных формул наценки, округления и сразу по нескольким документам поступления или складским остаткам.
3. Меню «Заполнить» в самом документе: внутри документа Установка цен номенклатуры на командной панели доступны команды «Заполнить по поступлению цен» и «Добавить по поступлению цен». Это позволяет добавлять номенклатуру из нескольких приходных накладных в один документ без использования механизма ввода на основании.
4. Внешние обработки табличных частей: если требуется специфический алгоритм подбора или пересчета цен, его можно оформить через механизм дополнительных внешних обработок заполнения табличных частей, не снимая конфигурацию с поддержки.