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