В практике поддержки и доработки интеграционных модулей, таких как обработка СБИС (Saby) для 1С, мы часто сталкиваемся с неочевидным поведением платформы. Ситуация, описанная в теме, является классическим примером двух наслоившихся проблем: специфики работы Библиотеки Стандартных Подсистем (БСП) с внешними файлами и особенностей компиляции кода в глобальном контексте.
Рассмотрим подробно, почему исправленная обработка работает при открытии через «Файл — Открыть», но продолжает выдавать ошибки при запуске через кнопку в документе, и как правильно разрешать конфликты имен переменных.
Часто возникает ситуация, когда мы вносим изменения в файл обработки (например, Sbis1C.epf), сохраняем его на диске и проверяем работу. Все кажется корректным. Однако, когда пользователи пытаются выполнить то же действие через подключенную кнопку в интерфейсе документа (например, «Отправить через СБИС»), 1С ведет себя так, будто никаких изменений не было, или выдает старую ошибку.
Давайте разберемся, почему так происходит. Причина кроется в архитектуре справочника Дополнительные отчеты и обработки.
В момент, когда пользователь нажимает кнопку печати или заполнения в документе, платформа не обращается к вашему файлу на рабочем столе. Она извлекает сохраненную версию из базы во временную папку (Temp) и исполняет её. Получается, что вы тестируете одну версию кода, а пользователи работают с другой — устаревшей.
Чтобы изменения вступили в силу для всех пользователей и кнопок интерфейса, нам необходимо принудительно обновить двоичные данные в справочнике. Проделаем следующие шаги:
epf.Только после этого действия версия в базе данных синхронизируется с вашей версией на диске. Важно помнить: БСП не умеет автоматически отслеживать изменения файлов на диске, это всегда ручная операция.
Вторая, более сложная техническая проблема, затронутая в обсуждении, касается ошибки компиляции кода. Автор столкнулся с ситуацией, когда доработать обработку через внешние расширения невозможно из-за ошибки: «используется переменная, наименование которой уже занято общим модулем». Чтобы предотвратить такие ситуации еще на этапе разработки, полезно применять статический анализатор кода проектов, который помогает выявить подобные пересечения.
Давайте проанализируем, почему это происходит. В платформе 1С существует Глобальный контекст. Если в конфигурации есть Общий модуль, у которого в свойствах стоит галочка Глобальный, то его имя становится зарезервированным словом во всей системе. К методам этого модуля можно обращаться напрямую, но и создавать переменные с таким же именем нельзя. Своевременный анализ конфигурации на наличие ошибок в вызовах общих модулей позволяет избежать таких конфликтов в кастомизированных базах.
Представим, что в вашей старой конфигурации есть глобальный общий модуль с именем Обмен. А разработчики СБИС в своей обработке внутри какой-то процедуры назвали переменную тоже Обмен.
// Пример конфликта
Процедура ИнициализацияОбмена()
// Если в конфигурации есть глобальный модуль "Обмен",
// следующая строка вызовет ошибку компиляции:
Обмен = Новый Структура;
// Платформа "думает", что вы пытаетесь присвоить значение общему модулю,
// который доступен только для чтения.
КонецПроцедуры
Такая ошибка возникает на этапе компиляции. Именно поэтому использование внешних файлов настроек не поможет — основная обработка просто не сможет запуститься.
В данном случае единственным рабочим решением является прямое вмешательство в код обработки. Рассмотрим варианты действий.
Это самый надежный способ. Нам нужно заменить имя переменной во всем модуле обработки на уникальное. Чтобы автоматизировать этот процесс и привести код к стандартам, можно использовать Code formatter 1C — инструмент для редактирования и анализа структуры модулей.
Обмен).Ctrl + H (Найти и заменить).ЛокальныйОбмен или сбисОбмен.После этого код будет выглядеть так:
Процедура ИнициализацияОбмена()
// Конфликт устранен
сбисОбмен = Новый Структура;
КонецПроцедуры
Иногда, если переменная является реквизитом обработки, можно попробовать обратиться к ней явно через контекст объекта. Однако вариант с рефакторингом остается единственно верным для локальных переменных.
Не стоит забывать и о кэшировании. После обновления обработки в базе, если странное поведение сохраняется, выполним очистку. Постоянно перезапускать среду для проверки изменений утомительно, поэтому для ускорения процесса разработки и тестирования часто применяется помощник отладки, который минимизирует время на настройку среды после каждого запуска.
В контексте СБИС существует два вида кэша:
AppData.Для успешного решения задачи необходимо действовать комплексно: сначала мы исправляем код обработки, устраняя конфликт имен переменных с глобальными модулями. Затем мы обязательно загружаем исправленный файл в справочник «Дополнительные отчеты и обработки» через кнопку «Обновить из файла», чтобы изменения применились к печатным формам. И, наконец, при необходимости чистим кэш.