При попытке программного взаимодействия с проектами Visual Basic for Applications (VBA) в Microsoft Excel из 1С, особенно когда код 1С выполняется на сервере, мы можем столкнуться с ошибкой: "Программный доступ к проекту Visual Basic не является доверенным". Эта проблема возникает из-за настроек безопасности Excel, которые по умолчанию блокируют автоматизированный доступ к объектной модели VBA. Давайте разберем эту ситуацию подробнее и найдем эффективное решение.
Часто в практике разработки на 1С возникает необходимость автоматизировать работу с внешними офисными приложениями, такими как Microsoft Excel или Word. Это может быть полезно для формирования сложных отчетов, прайс-листов с индивидуальным форматированием, картинок, использования формул или сводных таблиц, а также для создания интерактивных моделей, где пользователь может изменять параметры в Excel и видеть пересчеты. Одним из распространенных способов является использование COM-объектов.
Рассмотрим типовой сценарий, который приводит к нашей ошибке. У нас есть код 1С, который создает экземпляр Excel, добавляет новую книгу, импортирует в нее VBA-модуль из файла и затем запускает макрос. Пример такого кода:
Application = Новый COMОбъект("Excel.Application");
Workbook = Application.Workbooks.Add();
Workbook.VBProject.VBComponents.Import(ИмяФайла);
Application.ScreenUpdating = Ложь;
Application.Run(ИмяМакроса);
Application.ScreenUpdating = Истина;
Application.Visible = 1;
В данном примере ИмяФайла — это путь к файлу с VBA-модулем, который мы хотим импортировать, а ИмяМакроса — имя макроса, который нужно запустить. Например, в файле может быть такой простой макрос:
Sub Macros1()
MsgBox 1
End Sub
Автор исходного сообщения отмечает, что этот код прекрасно работает в файловом варианте базы 1С. Однако, при переносе его на серверный вариант (когда код 1С выполняется с директивой &НаСервере), появляется упомянутая ошибка: "Программный доступ к проекту Visual Basic не является доверенным". Пользователь также отмечает, что галка "Доверять доступ к объектной модели проектов VBA" в настройках Экселя была установлена.
В чем же причина такого поведения и куда следует "копать"?
Ключевым моментом в понимании этой ошибки является то, что настройка безопасности Excel является индивидуальной для каждого пользователя и каждого приложения Office. Когда вы запускаете 1С в файловом режиме, код выполняется под учетной записью пользователя, который вошел в систему на своем компьютере. Если этот пользователь вручную настроил Excel на доверие к программному доступу VBA, то все работает корректно.
Однако в серверном варианте ситуация меняется. Код 1С, помеченный директивой &НаСервере, исполняется на сервере 1С Предприятия. Процесс, который фактически запускает экземпляр Excel через COM-объект, это процесс сервера 1С, обычно rphost.exe. Этот процесс выполняется от имени определенной системной или доменной учетной записи на сервере. И именно для этой учетной записи необходимо установить соответствующие настройки безопасности в Excel.
Таким образом, когда автор темы проверил галку "Доверять доступ к объектной модели проектов VBA", он, вероятно, сделал это под своей пользовательской учетной записью на сервере или на клиентской машине. Однако это не влияет на поведение Excel, когда он запускается процессом rphost под другой учетной записью.
Суть проблемы: Настройка доверия к VBA должна быть выполнена для того пользователя операционной системы, под которым запущен процесс rphost сервера 1С.
Чтобы решить проблему, нам необходимо выполнить следующие шаги на сервере 1С:
Определяем пользователя сервера 1С: Прежде всего, выясним, под какой учетной записью запускается процесс rphost (или аналогичный процесс сервера 1С, например, rmngr.exe). Вы можете сделать это, открыв "Диспетчер задач" на сервере, перейдя на вкладку "Подробности" (или "Процессы" в старых версиях), найдя процесс rphost.exe и посмотрев столбец "Имя пользователя".
Вход под учетной записью пользователя сервера: Нам нужно войти в операционную систему сервера под этой же учетной записью пользователя. Если это системная учетная запись (например, "Local System" или "Network Service"), то вам может потребоваться изменить пользователя службы сервера 1С на доменную учетную запись с соответствующими правами, чтобы иметь возможность интерактивно войти под ней. В большинстве случаев администраторы 1С настраивают службу 1С на запуск от имени специальной доменной учетной записи, что упрощает такую настройку.
Запуск Excel под нужным пользователем: После входа под нужной учетной записью, запустите Microsoft Excel.
Настройка параметров безопасности Excel:
Перейдите в меню "Файл".
Выберите "Параметры" (Options).
В открывшемся окне "Параметры Excel" выберите раздел "Центр управления безопасностью" (Trust Center).
Нажмите кнопку "Параметры центра управления безопасностью..." (Trust Center Settings...).
В новом окне "Центр управления безопасностью" выберите раздел "Параметры макросов" (Macro Settings).
Установите флажок (галку) напротив опции "Доверять доступ к объектной модели проектов VBA" (Trust access to the VBA project object model).
Нажмите "ОК" во всех открытых окнах, чтобы сохранить изменения.
Для старых версий Excel путь может отличаться. Например, это может быть: "Сервис" -> "Макрос" -> "Безопасность" -> вкладка "Надежные издатели" (или аналогичное). Главное найти опцию, отвечающую за доверие к программному доступу VBA.
Перезапуск Excel и сервера 1С: После изменения настроек безопасности Excel рекомендуется закрыть все открытые экземпляры Excel. Для надежности также может потребоваться перезапустить службу сервера 1С (процесс rphost), чтобы изменения в среде пользователя вступили в силу. Это обеспечит, что новый экземпляр Excel, запущенный через COM-объект из 1С, будет использовать обновленные настройки безопасности.
После выполнения этих шагов ваш код 1С на сервере должен успешно взаимодействовать с VBA-проектами в Excel.
Давайте подробнее проанализируем, почему серверный режим 1С так критичен для данной настройки:
Контекст выполнения кода: Директива &НаСервере означает, что весь код, находящийся под этой директивой, выполняется не на компьютере пользователя (клиента), а на компьютере, где установлена и работает серверная часть 1С:Предприятия. Это может быть отдельный физический или виртуальный сервер.
Процесс сервера 1С: На сервере 1С за выполнение кода отвечают процессы сервера приложений 1С, главным из которых является rphost.exe (рабочий процесс). Именно этот процесс инициирует создание COM-объекта Excel.Application. Соответственно, все настройки безопасности и окружения для запускаемого экземпляра Excel берутся из профиля пользователя, под которым работает сам процесс rphost.
Изоляция пользователей: Операционные системы, такие как Windows Server, обеспечивают строгую изоляцию пользовательских профилей и их настроек. Настройки Excel, сделанные для одного пользователя, абсолютно не влияют на то, как Excel будет вести себя, будучи запущенным от имени другого пользователя, даже если это происходит на одной и той же физической машине.
Отсутствие GUI: Часто серверы работают без активного пользовательского интерфейса или графической оболочки. Это означает, что если Excel запустится и попытается отобразить диалоговое окно с предупреждением о безопасности (в случае, если опция доверия не включена), это окно не будет видно, и процесс может просто зависнуть или завершиться ошибкой, не дожидаясь ответа пользователя.
Таким образом, понимание того, что Excel запускается в невидимом режиме под профилем системного пользователя, помогает осознать критичность правильной настройки безопасности именно для этого профиля.
Включение опции "Доверять доступ к объектной модели проектов VBA" хотя и решает проблему, но является достаточно серьезным шагом с точки зрения безопасности. Давайте рассмотрим его риски и возможные альтернативы.
Эта настройка изначально предназначена для предотвращения создания самовоспроизводящегося вредоносного кода. Когда мы ее включаем, мы фактически сообщаем Excel, что доверяем любому программному клиенту автоматизации управлять средой VBA. Это означает, что если на сервере каким-либо образом окажется документ Excel, содержащий макровирус или вредоносный код, и какая-либо программа (необязательно 1С) попытается его открыть и взаимодействовать с его VBA-проектом, этот код может получить несанкционированный доступ к системе, выполнять действия без ведома пользователя или распространяться дальше.
Поэтому, принимая решение о включении этой опции на сервере, мы должны быть абсолютно уверены в безопасности всех файлов Excel, с которыми будет взаимодействовать 1С, и иметь адекватные меры защиты от вредоносного ПО на сервере.
Если есть возможность, мы рекомендуем рассмотреть более безопасные альтернативы или дополнительные меры:
Надежные расположения: Вместо того чтобы разрешать программный доступ к объектной модели VBA глобально, более безопасным подходом является добавление папки с файлами, содержащими макросы, в список "Надежных расположений" в Центре управления безопасностью Excel. Макросы из файлов, находящихся в таких расположениях, будут запускаться без дополнительных предупреждений. Это снижает риски, так как доверие распространяется только на конкретные папки, а не на все программные взаимодействия с VBA.
Для настройки надежного расположения также потребуется войти под учетной записью пользователя rphost на сервере и в Excel перейти в "Файл" -> "Параметры" -> "Центр управления безопасностью" -> "Параметры центра управления безопасностью" -> "Надежные расположения". Добавьте путь к папке, где хранятся ваши Excel-файлы с макросами.
Цифровые подписи: Другим методом повышения безопасности является разрешение выполнения макросов только в том случае, если они имеют цифровую подпись надежного разработчика. Это требует дополнительных настроек и процесса подписания ваших VBA-проектов, но значительно повышает уровень контроля и безопасности.
Групповые политики: В крупных корпоративных средах параметры безопасности макросов, включая доступ к объектной модели VBA, часто могут быть ограничены или централизованно управляемы с помощью групповых политик безопасности (Group Policy). Если вы работаете в такой среде, самостоятельное изменение настроек может быть невозможно или отменено системой. В этом случае необходимо обратиться к вашему ИТ-администратору.
В контексте обсуждения "Табличного документа" 1С (сообщения 6, 7, 8, 9, 10, 11, 12), стоит отметить, что для многих задач формирования отчетов и простых таблиц, встроенный в 1С объект ТабличныйДокумент является предпочтительным. Он работает нативно, не требует установки Excel на сервере и не имеет проблем с безопасностью Excel. Пример записи табличного документа:
ТабДок = Новый ТабличныйДокумент;
// Заполняем ТабДок данными
ТабДок.Записать("C:\Отчет.xlsx", ТипФайлаТабличногоДокумента.XLSX);
Однако, как справедливо отмечается в дискуссии (сообщение 12), ТабличныйДокумент имеет свои ограничения. Он не позволяет:
Именно для таких сложных сценариев, где требуется весь функционал Microsoft Office, использование COM-объектов Excel (или Word) из 1С остается актуальным и во многих случаях единственно возможным решением. В этих случаях необходимо тщательно подходить к настройкам безопасности, как мы рассмотрели выше.
Итак, мы выяснили, что ошибка "Программный доступ к проекту Visual Basic не является доверенным" при работе с Excel из 1С на сервере обусловлена настройками безопасности Excel для учетной записи пользователя, под которым выполняется процесс сервера 1С (rphost). Чтобы решить эту проблему, нам необходимо:
Определить учетную запись пользователя, от имени которого работает процесс rphost.
Войти на сервер под этой учетной записью.
Запустить Excel и в его параметрах безопасности (Центр управления безопасностью -> Параметры макросов) установить флажок "Доверять доступ к объектной модели проектов VBA".
Закрыть Excel и, возможно, перезапустить службу сервера 1С.
Не забывайте, что включение этой опции сопряжено с определенными рисками для безопасности. Мы настоятельно рекомендуем тщательно оценить эти риски и, по возможности, использовать более точечные меры защиты, такие как "Надежные расположения" или цифровые подписи для макросов. Всегда проводите тщательное тестирование изменений в среде сервера перед внедрением их в рабочую эксплуатацию.
Таким образом, наша проблема успешно решена, и мы можем продолжить использовать мощные возможности интеграции 1С с Microsoft Excel для выполнения самых разнообразных задач автоматизации.