Где хранить внешние обработки 1С

Внешние обработки и отчеты в 1С — это файлы с расширением .epf и .erf, которые расширяют функциональность конфигурации без её изменения. Вопрос их хранения напрямую влияет на безопасность базы, удобство обновления и скорость работы пользователей. Файл, лежащий «на рабочем столе у бухгалтера», рано или поздно приводит к потере версии, запуску устаревшего кода или заражению через подменённый файл.

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

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

Способы хранения внешних обработок: сравнение вариантов

Прежде чем выбирать место, полезно увидеть всю картину. Каждый способ отличается по доступности для пользователей, поведению при обновлении и рискам безопасности.

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

Сравнение вариантов

Внутри базы (БСП)

Подходит для всех рабочих обработок пользователей; ограничение — нужна подсистема БСП в конфигурации

Сетевой каталог

Подходит как архив и точка обмена между базами; ограничение — нет контроля версий и прав внутри 1С

Git-репозиторий

Подходит для команды разработки и истории изменений; ограничение — требует выгрузки в исходники и навыков работы с Git

Хранение внутри базы: справочник «Дополнительные отчеты и обработки»

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

Чтобы включить механизм, перейдите в раздел «Администрирование» → «Печатные формы, отчеты и обработки» и установите флаг «Дополнительные отчеты и обработки». После этого в интерфейсе появится одноимённый справочник, куда администратор добавляет файлы .epf и .erf через кнопку «Добавить из файла». При добавлении система читает сведения из модуля обработки: наименование, версию, безопасный режим и команды.

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

Ограничение тоже есть: каждая обработка увеличивает размер базы, а при большом количестве тяжёлых файлов это сказывается на времени выгрузки .dt. На практике десятки типовых обработок по несколько сотен килобайт не создают заметной нагрузки.

1. 1
   Откройте «Администрирование» → «Печатные формы, отчеты и обработки» и включите опцию «Дополнительные отчеты и обработки»
2. 2
   Откройте справочник «Дополнительные отчеты и обработки» и нажмите «Добавить из файла»
3. 3
   Выберите файл .epf или .erf, проверьте заполнение наименования и версии
4. 4
   Укажите разделы командного интерфейса, где обработка будет доступна, и настройте права
5. 5
   Сохраните элемент и проверьте запуск от имени обычного пользователя

Безопасность: профили групп доступа и безопасный режим

Загрузка внешней обработки — это выполнение произвольного кода в базе. Поэтому в типовых конфигурациях право добавления обработок по умолчанию есть только у администратора, а при открытии файла пользователь видит предупреждение безопасности. Отключать это предупреждение глобально не следует.

Для разграничения доступа используйте профили групп доступа: роль «Добавление и изменение дополнительных отчетов и обработок» выдаётся только доверенным сотрудникам. Само выполнение конкретных обработок настраивается на закладке «Быстрый доступ» элемента справочника — там указывается, кому доступна каждая команда.

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

Файловое хранилище: когда оправдан сетевой каталог

Сетевой каталог остаётся рабочим вариантом в двух сценариях: как архив-источник, откуда администратор берёт файлы для загрузки в базы, и как точка обмена, когда одна и та же обработка используется в нескольких базах, не связанных между собой.

Организуйте каталог с понятной структурой: разделяйте папки по назначению (печатные формы, загрузка данных, сервисные обработки) и храните рядом с файлом краткое описание версии. Права на запись в каталог должны быть только у администраторов и разработчиков, остальным — чтение. Это исключает случайную подмену файла.

Типичная проблема файлового хранения — рассинхронизация версий: в одной базе лежит обработка версии 1.2, в другой давно обновили до 1.5, а в каталоге вообще третий файл. Чтобы этого избежать, назначьте одного ответственного за обновление и фиксируйте версии в имени файла или в журнале изменений рядом с каталогом.

Репозиторий для разработки: Git и хранение исходников

Если обработки пишутся или дорабатываются внутри компании, бинарные .epf-файлы плохо подходят для совместной работы: их нельзя сравнить между версиями. Правильная практика — хранить обработки в виде исходных файлов в Git-репозитории. Выгрузить обработку в исходники можно штатной командой конфигуратора или инструментами вроде EDT и сторонних утилит для разборки epf-файлов.

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

Связка получается двухуровневая: Git — для разработки и истории, справочник дополнительных обработок в базе — для эксплуатации пользователями. Обновление в базу попадает только после проверки на копии.

Удобный приём — хранить в репозитории файл README на каждую обработку с описанием назначения, требуемых прав и параметров командной строки. Через полгода это экономит часы на восстановлении контекста, особенно если обработку писал другой человек.

Обновление и контроль версий обработок

Независимо от места хранения нужен порядок обновления. Для обработок внутри базы механизм прост: откройте элемент справочника, загрузите новую версию файла — пользователи получат её при следующем запуске. Старая версия при этом перезаписывается, поэтому архив предыдущих файлов ведите отдельно в сетевом каталоге или Git.

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

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

Контрольные точки

Как проверить результат

Обработка в списке дополнительных отчетов

Норма

Версия совпадает с последней в репозитории или каталоге

Тревожный признак

Версия отличается или поле пустое

Запуск от имени пользователя

Норма

Обработка открывается и выполняет команду без ошибок прав

Тревожный признак

Ошибка доступа или обработка не видна в интерфейсе

Поведение после обновления платформы

Норма

Обработка работает как раньше

Тревожный признак

Ошибки совместимости — нужна проверка кода

Типичные ошибки при организации хранения

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

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

Как выбрать схему под свою задачу

Итоговый выбор сводится к нескольким условиям: количество баз, число обработок, наличие разработчика и требования к безопасности. Ориентируйтесь на маршрут ниже.

Маршрут решения

Как выбрать действие

Одна-две базы на типовой конфигурации с БСП, обработок меньше десяткаХраните всё в справочнике «Дополнительные отчеты и обработки», файловый архив ведите для страховки

Несколько баз, обработки общие, штатного разработчика нетСетевой каталог как мастер-копия плюс загрузка в каждую базу через справочник

Есть разработчик или команда, обработки регулярно дорабатываютсяGit-репозиторий с исходниками как источник, публикация в базы после теста на копии

Обработка используется ежедневно как часть процессаПеренесите функциональность в расширение конфигурации вместо внешнего файла

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

Частые вопросы

Чем внешняя обработка отличается от расширения конфигурации?

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

Можно ли хранить обработки в облачном диске вроде OneDrive или Яндекс.Диска?

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

Почему обработка не открывается у пользователя, хотя у администратора работает?

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

Нужно ли конвертировать обработки при переходе на новую версию платформы?

Формат .epf обычно совместим между версиями платформы 8.3, конвертация не требуется. Однако код внутри может использовать устаревшие методы, поэтому после смены версии платформы прогоните ключевые обработки на тестовой копии и проверьте журнал регистрации на ошибки.

Как узнать, какие внешние обработки реально используются в базе?

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

Безопасно ли отключать предупреждение при открытии внешних обработок?

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