При работе в распределенной информационной базе (РИБ) конфигурации 1С:Розница 2.3 (особенно на платформе 8.3.15 и выше) пользователи часто сталкиваются с критической ошибкой при попытке печати документов поступления или реализации. Система выдает сообщение: «Справочник.МаршрутыПодписания.ОднойДоступнойПодписью. Предопределенный элемент отсутствует в данных». Ситуация кажется парадоксальной: предприятие может даже не использовать электронный документооборот (ЭДО), но ошибка блокирует стандартную печатную форму. Разберем детально причины этого сбоя и рассмотрим пошаговые методы его устранения.
Прежде всего проанализируем, почему механизм печати обращается к справочникам ЭДО. В современных версиях «1С:Розницы», построенных на базе Библиотеки стандартных подсистем (БСП), подсистема печати тесно интегрирована с модулем «Электронное взаимодействие». При открытии общей формы печати программный код инициализирует настройки, чтобы проверить, не требуется ли вывести статус подписания документа или предложить пользователю отправить его контрагенту. В этот момент происходит обращение к справочнику МаршрутыПодписания. Если связь между метаданными (описанием в конфигураторе) и данными (записью в таблице базы данных) разорвана, платформа выбрасывает исключение.
В РИБ эта проблема обостряется. После обновления конфигурации или создания нового начального образа ссылки (GUID) предопределенных элементов в периферийной базе могут не совпадать с центральной базой или вовсе не создаться. Система «видит» имя элемента в конфигураторе, но метод Справочники.МаршрутыПодписания.ОднойДоступнойПодписью возвращает Неопределено или пустую ссылку, так как в базе данных нет записи, помеченной как предопределенная с таким внутренним именем.
Рассмотрим самый простой «административный» способ решения, который не требует написания кода. Если в центральной базе (ЦБ) элементы справочника МаршрутыПодписания присутствуют и корректно работают, мы можем принудительно перенести их в периферийную базу (ПБ).
Маршруты подписания.После этой операции записи в ПБ получат те же уникальные идентификаторы (GUID), что и в ЦБ, и связь с метаданными должна восстановиться. Проанализируем ситуацию: если после загрузки ошибка сохраняется, значит, платформа не смогла автоматически сопоставить загруженные данные с именами предопределенных. В этом случае перейдем к следующему методу.
Разберем более продвинутый метод, который часто является единственным спасением. Платформа 1С предоставляет встроенный метод УстановитьИмяПредопределенногоДанного(), который позволяет принудительно связать существующий элемент справочника с его «именем» из конфигуратора. Напишем небольшую обработку или выполним код во внешней консоли:
// Пример кода для восстановления связи в ПБ
Элемент = Справочники.МаршрутыПодписания.НайтиПоНаименованию("Одной доступной подписью");
Если Не Элемент.Пустая() Тогда
Объект = Элемент.ПолучитьОбъект();
Объект.УстановитьИмяПредопределенногоДанного("ОднойДоступнойПодписью");
Объект.Записать();
Сообщить("Связь для элемента 'Одной доступной подписью' успешно восстановлена.");
Иначе
Сообщить("Элемент не найден в базе данных. Создайте его вручную и запустите код снова.");
КонецЕсли;
Этот метод гарантированно назначает записи в таблице базы данных статус предопределенной. Рассмотрим важный нюанс: имя, передаваемое в метод (в нашем примере "ОднойДоступнойПодписью"), должно в точности соответствовать имени элемента в конфигураторе, а не его синониму или наименованию.
Посмотрим на проблему с точки зрения логики БСП. Иногда предопределенные данные не инициализируются из-за того, что система «считает» обновление базы данных завершенным, хотя некоторые процедуры провалились. Мы можем инициировать процедуру обновления вспомогательных данных вручную.
Для этого можно запустить базу с параметром командной строки: /C ЗапуститьОбновлениеИнформационнойБазы. Также в составе многих конфигураций есть скрытая обработка «Обновление вспомогательных данных» (через «Все функции» — «Обработки»). Запуск полной проверки справочников в этой обработке может заставить систему пересоздать недостающие записи в служебных справочниках ЭДО.
Проанализируем ситуацию, когда ошибка возвращается после следующей синхронизации. Если вы исправили данные вручную, но справочник Маршруты подписания исключен из состава плана обмена РИБ, то при очередном обмене конфигурация может обновиться, а данные — нет, что приведет к повторному разрыву связей.
Важно проверить: в конфигураторе найдите ваш план обмена (обычно ПоМагазину) и убедитесь, что в списке состава объектов у справочника МаршрутыПодписания стоит галочка «Авторегистрация». Если её нет, то любые изменения этого справочника в центре не будут доходить до узлов автоматически.
Если все вышеперечисленные методы не помогают, стоит обратить внимание на специфику платформы 8.3.15. В ней наблюдались проблемы с кэшированием предопределенных данных. Рассмотрим шаги по очистке:
ПланыОбмена.УстановитьГлавныйУзел(Неопределено)), вручную исправить данные и снова привязать узел к центральной базе.Подводя итог, отметим, что ошибка Справочник.МаршрутыПодписания.ОднойДоступнойПодписью — это типичный симптом «рассинхрона» данных в РИБ. Чаще всего она лечится именно программной установкой имени предопределенного данного, так как это действие напрямую исправляет корень проблемы в таблицах СУБД. Помните, что аналогичные проблемы могут возникнуть и с другими справочниками ЭДО, такими как ВидыЭлектронныхДокументов или НастройкиПотокаСканирования, поэтому при исправлении одного справочника рекомендуем проверить и остальные элементы подсистемы Электронного взаимодействия.