← На главную

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

Разберем подробнее механизм возникновения этой коллизии и рассмотрим все практические способы изменения системных идентификаторов для устранения конфликта.

Почему возникает ошибка повторного определения процедур?

Проанализируем внутреннее устройство объектов платформы 1С. Каждый объект метаданных, созданный в конфигурации или расширении, помимо видимого разработчику имени (свойства Имя и Синоним), обладает скрытым системным уникальным идентификатором — UUID (Universally Unique Identifier). При этом уникальный идентификатор присваивается не только самой обработке, но и всем ее подчиненным компонентам:

1. Основным и дополнительным формам.
2. Реквизитам объекта и реквизитам форм.
3. Табличным частям и их колонкам.
4. Командам обработки.
5. Модулям (модулю объекта, модулям форм, модулю менеджера).

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

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

Способ 1. «Чистое» создание обработки с ручным переносом структуры

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

Разберем по шагам последовательность действий:

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

Такой подход полностью разрывает связь с исходной заготовкой и предотвращает любые коллизии при параллельной работе нескольких расширений.

Способ 2. Сравнение и объединение с пустой обработкой

Если структура обработки сложная и включает множество реквизитов, команд и макетов, ручной перенос может занять много времени. В этом случае применяют сравнение и объединение конфигураций или обработок.

Рассмотрим, как обновить привязку идентификаторов через механизм объединения:

1. Создаем в расширении совершенно пустую обработку с требуемым именем и сохраняем расширение.
2. Открываем меню Сравнить и объединить с внешней обработкой-шаблоном.
3. В окне сравнения и объединения снимаем сопоставление по внутренним идентификаторам, оставляя сопоставление исключительно по именам объектов.
4. Отмечаем галочками нужные подчиненные элементы (реквизиты, макеты, формы) и выполняем объединение.

При таком сценарии платформа переносит состав реквизитов и код в существующий пустой объект с уже выделенным новым UUID, что снижает риск конфликта с исходным шаблоном.

Способ 3. Выгрузка в файлы и ручная замена UUID

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

Разберем алгоритм пакетной замены идентификаторов:

1. В Конфигураторе открываем нужное расширение и выполняем команду меню Конфигурация — Выгрузить конфигурацию в файлы.
2. В полученном каталоге переходим к описанию нашей обработки и подчиненных ей объектов (каталог DataProcessors).
3. Открываем файлы с расширением .xml в текстовом редакторе.
4. Находим строки с атрибутами uuid="...".
5. С помощью генератора GUID генерируем новые уникальные шестнадцатеричные значения и заменяем старые UUID в манифестах обработки, ее форм и реквизитов.
6. Выполняем обратную операцию в Конфигураторе: Конфигурация — Загрузить конфигурацию из файлов.

Этот способ позволяет гарантированно переопределить идентификаторы без риска потерять верстку сложных управляемых форм или параметры команд.

Способ 4. Обязательная очистка кэша метаданных

После корректировки идентификаторов или пересоздания объектов разработчики нередко продолжают наблюдать прежнюю ошибку. Причиной служит кэширование скомпилированных модулей платформой 1С.

Проанализируем обязательные шаги по очистке рабочего окружения:

1. Завершаем все активные клиентские сеансы пользователей в информационной базе.
2. Очищаем локальный кэш пользователя (каталоги %LOCALAPPDATA%\1C\1cv8 и %APPDATA%\1C\1cv8).
3. В случае работы в клиент-серверном варианте перезапускаем рабочий процесс службы сервера 1С:Предприятия или удаляем кэш сервера метаданных для сброса скомпилированных версий расширений.

Альтернативное архитектурное решение: вынос логики в общий модуль

Чтобы избежать регулярного тиражирования тяжелых шаблонов обработок в разные расширения, рассмотрим изменение общей архитектуры:

1. Использование общего модуля: универсальные алгоритмы (разбор табличных документов Excel, подготовка проводок и операций) целесообразно вынести в отдельный общий модуль в базовом расширении со свойствами Сервер и Вызов сервера. Тогда в каждой конкретной обработке будет содержаться только уникальная логика, вызывающая универсальные методы общего модуля.
2. Подсистема дополнительных отчетов и обработок (БСП): универсальные заготовки можно подключать через стандартный справочник дополнительных обработок Библиотеки стандартных подсистем без непосредственного включения в состав метаданных расширений.