Недавние обновления 1С:Бухгалтерии предприятием (БП 3.0) принесли значительные изменения в подсистему электронного документооборота (ЭДО). Разработчики 1С практически полностью переписали механизмы формирования и отправки документов, что вызвало немало вопросов у программистов, занимающихся кастомизацией этих процессов. В рамках данной статьи мы проведем детальный анализ новой архитектуры, разберем причины появления «странных» имен полей и выясним, как правильно вносить изменения в логику работы ЭДО в новых реалиях.
Главная причина масштабного рефакторинга — стремление фирмы «1С» к унификации. Процесс перехода на актуальные версии Библиотеки электронных документов (БЭД) позволил сделать механизмы ЭДО одинаковыми для всех типовых решений, будь то 1С:ERP, 1С:УТ или 1С:БП. Однако для программиста «на местах» это означает полную смену парадигмы.
Ранее многие процессы были линейными и исполнялись в контексте текущего сеанса пользователя. Теперь же мы наблюдаем массовый отказ от модальных окон и переход к динамическим формам. Ключевая особенность новой архитектуры — вынос процессов формирования, подписания и отправки в фоновые задания. Это значительно повышает отзывчивость интерфейса для пользователя, но усложняет отладку. Разберем, почему так происходит: когда код исполняется на сервере в отдельном сеансе фонового задания, обычная точка останова может не сработать. Для анализа таких процессов нам необходимо использовать средства отладки фоновых заданий или расширенное логирование в «Журнал регистрации».
Многие разработчики при взгляде на новый код ЭДО испытывают культурный шок от имен переменных и полей объектов, таких как СвДокПТПрКроме, СодФХЖ1 или ИнфПолФХЖ1. На первый взгляд это кажется хаотичным набором символов, однако здесь скрыта строгая логика.
Проанализируем ситуацию: 1С перешла на автоматическую генерацию объектов на основе XSD-схем, утвержденных ФНС (например, приказы №820 или №189). Эти аббревиатуры — прямая транслитерация тегов из официальных форматов электронных документов. Рассмотрим подробнее структуру одного из таких полей:
Файл.Документ.СвДокПТПрКроме.СвДокПТПр.СодФХЖ1.ИнфПолФХЖ1.ТекстИнф
Каждая часть этой цепочки соответствует определенному узлу в XML-файле документа. Использование таких имен гарантирует, что сформированный документ будет на 100% валиден с точки зрения приемных шлюзов налоговой службы. При написании своих обработчиков или расширений нам крайне важно придерживаться именно этих структур, не пытаясь упростить их, иначе документ не пройдет форматный контроль.
В обновленном ЭДО была внедрена жесткая валидация «на лету». Это означает, что система блокирует отправку документа, если он не соответствует внутренним правилам или схемам, даже если раньше такие документы успешно уходили. Типичный пример — блокировка отправки документа с нулевой суммой.
Рассмотрим пример кода, который позволяет обойти подобную проверку, если бизнес-логика предприятия требует отправки специфических документов. Часто это реализуется через расширение в модулях, отвечающих за валидацию перед подписанием. Посмотрим на пример аннотации и изменения логики:
// В расширении для модуля ЭДО
&После("ПроверитьДокументПередОтправкой")
Процедура Имя_ПроверитьДокументПередОтправкой(ДокументОбъект, Отказ)
// Осуществляем поиск проверки на нулевую сумму
// Если нам нужно разрешить такие документы, принудительно сбрасываем Отказ
Если ДокументОбъект.СуммаДокумента = 0 Тогда
// Осипов — отключаем ошибку нулевой суммы для специфических типов документов
Отказ = Ложь;
КонецЕсли;
КонецПроцедуры
Важно понимать, что такие правки — это крайняя мера. Проанализируем последствия: при отключении встроенных проверок ответственность за корректность XML ложится полностью на разработчика. Если структура ИнфПолФХЖ1 будет заполнена неверно, оператор ЭДО вернет ошибку уже после попытки отправки.
Одной из главных причин переписывания кода стала необходимость глубокой интеграции с системой «Честный знак» (ГИС МТ). В новой версии ЭДО механизмы работы с маркируемым товаром встроены в ядро подсистемы. Выясним, как это работает: теперь при формировании электронного УПД система в реальном времени обращается к модулям интеграции, чтобы проверить статусы кодов маркировки и владельца.
Для программиста это означает, что при добавлении новых полей в документ через расширение, нужно учитывать механизмы подсистемы «Работа с кодами маркировки». Логика обработки теперь разделена:
После рефакторинга многие старые методы в общих модулях 1С:Бухгалтерии были помечены как устаревшие (имеют суффикс _Старый). Если ваше расширение перестало работать после обновления БП 3.0, необходимо выполнить следующие шаги:
ИнтеграцияЭДОПереопределяемый.Подводя итог, можно сказать, что новый ЭДО в БП 3.0 стал сложнее в освоении для разработчика, но гораздо стабильнее в плане соблюдения законодательных норм. Использование автосгенерированных структур по XSD-схемам — это неизбежная плата за соответствие требованиям ФНС в условиях постоянно меняющихся форматов.