Как исправить ошибку «Реквизит недоступен для группы» при синхронизации РИБ в 1С?

Программист 1С v8.3 (Управляемые формы) 1C:Бухгалтерия Бухгалтерский учет IT и автоматизация бизнеса
← На главную

Синхронизация данных в распределенных информационных базах (РИБ) — один из наиболее критичных процессов в архитектуре 1С. Сбой на любом этапе обмена может парализовать совместную работу головного офиса и удаленных филиалов. Часто технические специалисты сталкиваются со следующей системной ошибкой при выгрузке пакета обмена:

Ошибка записи данных в файл сообщения обмена: {Обработка.КонвертацияОбъектовРаспределенныхИнформационныхБаз.МодульОбъекта(270)}: Ошибка при вызове метода контекста (ЗаписатьИзменения)... по причине: Ошибка при выполнении обработчика - 'ПриОтправкеДанныхПодчиненному'... по причине: Ошибка при установке значения атрибута контекста (ФайлХранилище) ЭлементДанных.ФайлХранилище = Новый ХранилищеЗначения(Неопределено); по причине: Реквизит недоступен для группы.

В этой статье мы подробно разберем, почему возникает эта проблема, детально проанализируем внутренние механизмы Библиотеки стандартных подсистем (БСП) и рассмотрим четыре практических способа устранения этой ошибки.

Выясняем техническую причину сбоя

Для того чтобы эффективно решить проблему, разберем физику процесса выгрузки данных. Ошибка проявляется, когда пользователи (чаще всего бухгалтеры при подготовке деклараций по НДС или отправке отчетности) активно используют вложенные папки (группы) в справочниках присоединенных файлов (например, ДоговорыКонтрагентовПрисоединенныеФайлы, РегламентированныеОтчетыПрисоединенныеФайлы и т. д.) для классификации отсканированных документов.

При обмене данными РИБ платформа пытается оптимизировать объем XML-файла сообщения обмена. Чтобы не перегружать каналы связи тяжелыми бинарными данными файлов, стандартные механизмы БСП в общем модуле РаботаСФайламиСлужебный перехватывают выгрузку этих справочников. Перед сериализацией в XML система принудительно очищает реквизит ФайлХранилище (где хранится сам двоичный файл), заменяя его на пустое хранилище значений:

ЭлементДанных.ФайлХранилище = Новый ХранилищеЗначения(Неопределено);

Однако в метаданных справочников присоединенных файлов свойство «Использование» для реквизита ФайлХранилище настроено в режиме «Для элемента». Это абсолютно логично: группа справочника (папка) не может физически содержать двоичные данные файла. Когда бухгалтеры создают новую иерархию папок в интерфейсе, эти группы регистрируются к обмену. При старте синхронизации код БСП циклически обходит все зарегистрированные объекты справочника. Дойдя до группы (папки), система пытается принудительно присвоить пустое значение несуществующему реквизиту ФайлХранилище, что приводит к аварийному завершению транзакции обмена.

Рассмотрим детально 4 способа устранения этой ошибки в зависимости от ваших возможностей изменения конфигурации.

Способ 1. Исправление ошибки через механизм расширений (Рекомендуемый)

Это самый безопасный и технологически верный способ, который позволяет устранить проблему без снятия типовой конфигурации с поддержки. Мы перехватим выполнение процедуры в общем модуле РаботаСФайламиСлужебный и добавим проверку на тип объекта.

Выполним следующие шаги:

  1. Откроем базу в режиме Конфигуратор.
  2. Перейдем в меню Конфигурация — Расширения конфигурации и создадим новое расширение (например, с именем ИсправлениеОбменаФайлов). Снимем флажки «Безопасный режим» и «Защита от опасных действий».
  3. В дереве основной конфигурации найдем общий модуль РаботаСФайламиСлужебный, нажмем на него правой кнопкой мыши и выберем пункт Добавить в расширение.
  4. В модуле расширения перехватим процедуру, в которой происходит очистка данных (обычно это обработчик отправки данных, вызываемый при обмене). Используем аннотацию &ИзменениеИКонтроль или создадим процедуру-обертку с аннотацией &Вместо.

Внутри перехваченного метода добавим логическую проверку, которая будет пропускать очистку реквизита, если обрабатываемый объект является группой справочника:


&Вместо("ПриОтправкеДанныхПодчиненному")
Процедура Расш1_ПриОтправкеДанныхПодчиненному(ЭлементДанных, ОтправкаЭлемента, ИсходныйНомерСообщения)
    
    // Проверяем, поддерживает ли объект иерархию и является ли он группой
    Если ЭлементДанных.Метаданные().Иерархический И ЭлементДанных.ЭтоГруппа Тогда
        // Для групп справочника присоединенных файлов очистка хранилища не требуется
        Возврат;
    КонецЕсли;
    
    // Вызов оригинального кода для обычных элементов
    ПродолжитьВызов(ЭлементДанных, ОтправкаЭлемента, ИсходныйНомерСообщения);
    
КонецПроцедуры

Такой подход полностью решает проблему: группы корректно выгружаются в XML-пакет без вызова исключений платформы.

Способ 2. Изменение свойств метаданных в Конфигураторе

Если в вашей организации не используются расширения, либо конфигурация уже снята с поддержки (находится в режиме редактирования с сохранением поддержки), можно скорректировать метаданные самого справочника присоединенных файлов.

Разберем этот процесс по шагам:

  1. В дереве метаданных найдем проблемный справочник присоединенных файлов (например, ДоговорыКонтрагентовПрисоединенныеФайлы).
  2. Раскроем ветку Реквизиты и дважды кликнем по реквизиту ФайлХранилище для открытия палитры его свойств.
  3. Найдем свойство Использование (по умолчанию там установлено значение Для элемента).
  4. Изменим его значение на Для группы и элемента.
  5. Сохраним конфигурацию базы данных и запустим обновление (клавиша F7).

Важный нюанс: Данный способ устраняет ошибку выполнения кода БСП, так как у группы физически появляется реквизит ФайлХранилище, и платформа больше не падает с ошибкой доступа. Однако при обновлении конфигурации на новые релизы от поставщика вам придется контролировать это свойство вручную, чтобы оно не затерлось стандартными настройками 1С.

Способ 3. Корректировка правил регистрации объектов (ПРО)

Если вам не требуется передавать саму структуру папок присоединенных файлов в подчиненную (периферийную) базу РИБ, можно настроить правила регистрации объектов так, чтобы группы справочников игнорировались при регистрации изменений.

Для реализации этого метода выполним следующее:

  1. Откроем конфигурацию «Правила регистрации объектов» для вашего плана обмена (обычно редактируется в специальной конфигурации «Конвертация данных 2.0/3.0»).
  2. В правилах регистрации для справочника присоединенных файлов добавим обработчик события ПередРегистрациейОбъекта.
  3. Пропишем условие отмены регистрации для групп:

Если Объект.ЭтоГруппа Тогда
    Отказ = Истина;
КонецЕсли;

Минус метода: Если вы примените этот способ, файлы на принимающей стороне будут выгружаться в корень справочника без сохранения логической структуры папок, созданной бухгалтерами в головной базе. Это может вызвать неудобство у конечных пользователей, которым придется ориентироваться в "плоском" списке файлов.

Способ 4. Временный обход проблемы в пользовательском режиме (Костыль)

Если синхронизацию нужно запустить «здесь и сейчас», а времени на доработку конфигурации или расширения нет, можно воспользоваться стандартным инструментом администратора.

Выполним оперативные действия в режиме «1С:Предприятие»:

  1. Перейдем в раздел Администрирование — Синхронизация данных.
  2. Откроем окно настроек обмена и нажмем на кнопку Параметры синхронизации данных — Регистрация изменений для обмена данными (или воспользуемся внешней обработкой «Регистрация изменений для обмена»).
  3. В появившемся дереве зарегистрированных объектов найдем проблемный справочник присоединенных файлов.
  4. Раскроем список зарегистрированных элементов, найдем среди них объекты, у которых пиктограмма отображает папку (группу).
  5. Выделим эти папки и нажмем кнопку Отменить регистрацию.
  6. Запустим процесс синхронизации заново.

Синхронизация успешно завершится, так как проблемные группы будут исключены из текущей сессии обмена. Помните, что это временная мера: при первом же изменении папки или создании новой бухгалтером, она снова зарегистрируется к обмену, и при следующей синхронизации ошибка повторится.

Используйте предложенные методы для стабилизации обменов в вашей базе 1С. Наиболее надежным и системным решением является Способ №1 (использование расширения), так как он локализует ошибку непосредственно в кодовой базе, не нарушая типовую поддержку программного продукта.

← На главную