При реализации механизмов интеграции между двумя базами 1С часто используется COM-соединение. Это удобный инструмент, позволяющий программно обращаться к данным другой информационной системы. Однако разработчики нередко сталкиваются с ситуацией, когда под правами администратора код работает идеально, а под учетной записью обычного пользователя (например, «Главного бухгалтера») система выдает критическую ошибку прав доступа. Рассмотрим подробнее, почему это происходит в современных конфигурациях, таких как Бухгалтерия предприятия 3.0, и как решить эту проблему несколькими способами.
Типичный текст ошибки при попытке записи документа через COM-соединение выглядит следующим образом: "Ошибка при получении значения атрибута контекста (КлючДанныхПовторногоИспользования) Нарушение прав доступа!". Ссылка при этом ведет в МодульМенеджера справочника ИдентификаторыОбъектовМетаданных.
Давайте выясним причину такого поведения системы. Современные конфигурации 1С построены на базе Библиотеки стандартных подсистем (БСП). В БСП реализован строгий механизм контроля метаданных. При создании или записи любого объекта (будь то справочник или документ) через внешнее соединение, система инициирует проверку актуальности идентификаторов объектов метаданных. Для оптимизации этой проверки платформа использует специальный параметр сеанса — КлючДанныхПовторногоИспользования.
Проблема заключается в том, что в типовых ролях (включая роль «Главный бухгалтер») доступ к этому параметру сеанса на чтение или запись закрыт. Платформа считает это системной операцией, доступной только пользователям с полными правами. В итоге, даже если у пользователя есть право на создание самого документа «Реализация товаров и услуг», запись прерывается из-за невозможности инициализировать системный кэш БСП.
Первый и самый простой путь — расширить права пользователя, под которым устанавливается соединение в базе-приемнике. Разберем по шагам, какие роли необходимо добавить, чтобы избежать ошибки Нарушение прав доступа:
ИдентификаторыОбъектовМетаданных. Включение этой роли часто решает проблему с доступом к параметру сеанса КлючДанныхПовторногоИспользования.Важно помнить, что если конфигурация базы-приемника была недавно обновлена, справочник идентификаторов может быть не заполнен до конца. Рекомендуем выполнить первый вход в базу под пользователем с полными правами в режиме «Предприятие», чтобы система завершила все фоновые процедуры обновления метаданных.
Если политика безопасности не позволяет расширять права пользователя в базе-приемнике, мы можем использовать архитектурно более правильный подход. Вместо того чтобы напрямую вызывать создание объекта через COM, мы создадим «посредника» на стороне приемника.
Проанализируем ситуацию: код, выполняемый в привилегированном общем модуле, игнорирует проверку прав доступа. Это именно то, что нам нужно. Мы можем передать данные для создания документа в функцию такого модуля, и она успешно выполнит запись, несмотря на ограничения прав пользователя COM-соединения.
Рассмотрим пример реализации. В базе-приемнике создайте общий модуль (например, ВнешняяИнтеграцияПривилегированный) со следующими свойствами: Сервер, Вызов сервера, Привилегированный.
В этом модуле опишем экспортную функцию:
Функция СоздатьРеализациюНаСервере(СтруктураДанных) Экспорт
НовыйДокумент = Документы.РеализацияТоваровУслуг.СоздатьДокумент();
// Заполняем реквизиты из структуры
ЗаполнитьЗначенияСвойств(НовыйДокумент, СтруктураДанных);
Попытка
НовыйДокумент.Записать(РежимЗаписиДокумента.Запись);
Возврат НовыйДокумент.Ссылка;
Исключение
ЗаписатьЛогОшибки(ОписаниеОшибки());
Возврат Неопределено;
КонецПопытки;
КонецФункции
Теперь на стороне базы-источника, после установки соединения, вызывайте не стандартные методы объекта, а вашу функцию:
// Соединение - это объект COM-соединения
ДанныеДляДокумента = Новый Структура("Организация, Контрагент, Склад", СсылкаОрг, СсылкаКонтр, СсылкаСклад);
// Передаем структуру (предварительно преобразовав ссылки в GUID или строки)
Результат = Соединение.ВнешняяИнтеграцияПривилегированный.СоздатьРеализациюНаСервере(СтруктураДанных);
Важный нюанс: при передаче параметров через COM-соединение объекты типов СправочникСсылка или ДокументСсылка одной базы не будут поняты другой базой. Используйте передачу через уникальные идентификаторы (UUID) или коды/артикулы.
Если COM-соединение продолжает вызывать сложности с правами доступа или производительностью, стоит рассмотреть современные альтернативы, которые предлагает платформа 1С.
Использование HTTP-сервисов или Web-сервисов:
Этот метод считается более надежным и масштабируемым. Вы публикуете сервис на стороне базы-приемника. В коде сервиса вы также можете установить выполнение в привилегированном режиме. Основное преимущество здесь в том, что вам не нужно поддерживать COM-библиотеки на сервере, что особенно актуально для систем на Linux.
Механизм OData:
В 1С существует встроенный REST интерфейс. Вы можете включить необходимые документы в состав OData и отправлять POST-запросы для их создания. В этом случае аутентификация также проходит под пользователем, но логика обработки прав доступа через REST иногда более гибкая, чем при «тяжелом» COM-подключении.
Подводя итог, можно сказать, что ошибка «Нарушение прав доступа» в COM-соединении — это не баг платформы, а следствие работы механизмов защиты БСП. Для решения проблемы мы рекомендуем:
Удаленный доступ, Синхронизация данных).Применяя эти подходы, вы сможете создавать документы в смежных базах без необходимости давать пользователям опасные «Полные права», сохраняя при этом безопасность и стабильность системы.