Ситуация, когда информационная база 1С значительно отстала от актуальных релизов (например, УТ 11 образца 2013 года), а бизнес требует внедрения электронного документооборота (ЭДО) из-за давления поставщиков или требований законодательства, встречается довольно часто. Полное обновление сильно кастомизированной «древней» базы может стоить колоссальных ресурсов, сопоставимых с внедрением новой системы. Однако работать с ЭДО в таких условиях можно. Разберем по шагам доступные стратегии, технические нюансы и «подводные камни», с которыми придется столкнуться.
В типовых конфигурациях 1С за работу с электронными документами отвечает специализированная подсистема — Библиотека электронных документов (БЭД). В старых релизах УТ 11.1 часто установлены версии БЭД 1.1 или даже более ранние. Рассмотрим, как можно модернизировать этот блок без затрагивания основной логики программы.
Для начала проанализируем текущее состояние базы. Нам необходимо выяснить версию установленной подсистемы. Это можно сделать, заглянув в РегистрСведений.ВерсииПодсистем. Если мы видим версию 1.1.x, у нас есть шанс обновить её до последнего патча в рамках этой ветки.
Процесс обновления подсистемы выглядит следующим образом:
Библиотека электронных документов).ЭлектронныеДокументы. Сюда входят справочники, обработки, общие модули и макеты.РеализацияТоваровУслуг), чтобы они корректно вызывали обновленные процедуры библиотеки.Выясним причину, почему это может не сработать. Если ваша платформа 1С ниже версии 8.3.12, современные версии БЭД (начиная с 1.3 и выше) просто не запустятся, так как они используют новые возможности встроенного языка и расширений.
Если обновление внутреннего кода кажется слишком рискованным, рассмотрим использование внешних обработок, которые предоставляют операторы (например, Диадок от СКБ Контур или СБИС от Тензор). Это один из самых популярных способов «оживить» ЭДО в старой базе.
Проанализируем преимущества этого подхода:
Однако здесь мы можем налететь на технические ограничения платформы. Современные модули ЭДО часто пишутся с использованием технологии Расширений конфигурации (.cfe), которая появилась в платформе 8.3.6 и полноценно заработала еще позже. Если ваша база работает на платформе 8.2 или ранних 8.3, вам придется искать старые версии обработок, работающих через COM-соединение, или обновлять саму платформу (что гораздо проще и безопаснее, чем обновление всей конфигурации).
Когда база настолько «древняя», что в ней отсутствуют механизмы, необходимые для современных требований (например, маркировка товаров или прослеживаемость), лучшим решением станет создание промежуточного звена. Рассмотрим, как это работает по шагам:
Разберем, почему это выгодно. Во-первых, вы получаете полную юридическую чистоту документов. Во-вторых, вы не тратите сотни часов программиста на «скрещивание ежа с ужом» в старой конфигурации. В-третьих, это решает проблему Машиночитаемых доверенностей (МЧД).
Выясним, на что можно налететь, если пытаться «допиливать» старую БЭД 1.1 вручную. С недавних пор законодательство требует использования МЧД при подписании документов сотрудниками. Старые библиотеки ЭДО (до 2021-2022 года выпуска) принципиально не знают о существовании МЧД. Они не умеют прикреплять идентификатор доверенности к пакету данных.
Кроме того, ФНС регулярно обновляет форматы электронных документов. Например, переход на формат УПД 5.03 требует жесткого соблюдения структуры XML-файла. В старой БЭД 1.1.11 логика формирования файла «зашита» в общих модулях и макетах. Чтобы переписать её под 5.03, потребуется глубокое знание XSD-схем и много часов отладки.
Посмотрим на пример кода, который может встретиться при попытке интеграции. В старых системах часто использовался прямой вызов функций формирования:
// Пример старого вызова в БЭД 1.1
ПараметрыОтправки = ЭлектронныеДокументы.СформироватьПакетДокументов(ДокументСсылка);
ЭлектронныеДокументы.ОтправитьЭлектронныйДокумент(ПараметрыОтправки);
В современных реалиях этот код обрастет огромным количеством проверок на наличие МЧД, проверку сертификата через облачные сервисы и соответствие формату прослеживаемости. Именно поэтому путь с внешней обработкой или буферной базой считается наиболее рациональным для бизнеса.
Проанализировав ситуацию, мы можем сделать следующие выводы для принятия решения:
ВерсииПодсистем и убедиться, что все связанные объекты (общие картинки, стили, константы) перенесены корректно, иначе формы ЭДО будут открываться с ошибками.Помните, что ЭДО — это не только технический обмен файлами, но и юридически значимый процесс. Использование устаревших инструментов может привести к тому, что налоговая не примет ваши документы из-за неверного формата или отсутствия актуальных реквизитов подписи.