← На главную

При работе с типовыми и, в особенности, с отраслевыми конфигурациями 1С, такими как «1С:Учет в управляющих компаниях ЖКХ, ТСЖ и ЖСК», мы часто сталкиваемся с ситуацией, когда некоторые общие модули помечены «замочком» и недоступны для прямого редактирования. Это вызывает справедливое желание снять с них защиту, чтобы внести необходимые изменения, например, для корректировки алгоритмов расчета формул. Однако при попытке установить правило поддержки «Редактируется с сохранением поддержки» система выдает предупреждение: «Для данных объектов поставщик запрещает устанавливать правило поддержки: Редактируется с сохранением поддержки». Давайте разберемся, почему так происходит, какие существуют ограничения и как можно решить задачу доработки конфигурации, сохраняя возможность получать обновления и поддержку.

Почему поставщик блокирует общие модули?

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

1. Защита интеллектуальной собственности: Закрытый исходный код предотвращает несанкционированное копирование и изменение уникальных алгоритмов, применяя обфускатор операционного кода, а также специфической бизнес-логики, разработанной поставщиком. Это ключевая составляющая конкурентного преимущества.
2. Поддержание логической целостности и стабильности: Заблокированные модули часто содержат критически важные алгоритмы, изменение которых может привести к некорректной работе всей системы. Это может выражаться в ошибках расчетов, нарушении взаимодействия между подсистемами, или даже потере данных. Поставщик гарантирует, что эти базовые алгоритмы будут работать так, как задумано.
3. Обеспечение поддержки и обновлений: Если основной код конфигурации изменяется пользователем, поставщику становится крайне сложно гарантировать корректное применение обновлений, исправление ошибок и предоставление технической поддержки. Блокировка модулей минимизирует риски при обновлении типовых решений, поскольку поставщик уверен, что базовые механизмы остались неизменными.
4. Сервисные функции: Зачастую закрытый код используется для работы с ключами защиты, внешними сервисами, интеграционными механизмами, реализующими алгоритмы шифрования, или другими служебными подсистемами, которые не предназначены для модификации конечным пользователем.

Легальные способы изменения защищенных модулей

Как мы уже выяснили из сообщения 2, «легальными способами – никак». Поставщик специально блокирует такую возможность на уровне метаданных, и система 1С:Предприятие не позволяет обойти это ограничение через стандартные механизмы поддержки. Попытка установить правило «Редактируется с сохранением поддержки» для таких объектов всегда будет блокирована предупреждением. Это означает, что прямое изменение кода в этих модулях без потери поддержки невозможно.

Решение проблемы: Расширения конфигурации

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

Что мы можем делать с помощью расширений:

1. Создавать собственные объекты: Мы можем добавлять в расширение свои общие модули, справочники, документы, отчеты, регистры и другие объекты. Это позволяет реализовывать новую логику, не вмешиваясь в типовую.
2. Добавлять новые реквизиты: Если нам нужно хранить дополнительную информацию, мы можем добавить новые реквизиты в существующие типовые объекты (справочники, документы) через расширение.
3. Перехватывать вызовы процедур и функций: Это ключевая возможность для нашей задачи, особенно если речь идет о переопределении расчетов формул, как в сообщении 10. Расширения позволяют «вклиниваться» в выполнение типового кода с помощью специальных аннотаций:
   • &Перед: Позволяет выполнить свой код перед вызовом типовой процедуры или функции. Если в вашем коде установлено значение параметра, который передается по ссылке, или возвращено значение функции, то типовой код может быть отменен (зависит от конкретной процедуры).
   • &После: Позволяет выполнить свой код после выполнения типовой процедуры или функции. Мы можем получить доступ к результатам выполнения типового кода и внести в них корректировки.
   • &Вместо: Позволяет полностью заменить выполнение типовой процедуры или функции своим кодом. Этот метод наиболее мощный, но и наиболее рискованный, так как при обновлениях типовой конфигурации нам придется вручную отслеживать изменения в замещенном коде.

Применение расширений для изменения расчета формул

Если нам необходимо переопределить расчет формул, как упоминалось в сообщении 10, мы можем сделать следующее:

1. Определим место вызова: Найдем в типовом коде общий модуль или модуль объекта, который отвечает за расчет формул. Предположим, это процедура РассчитатьФормулу в общем модуле ОбщиеРасчетыЖКХ.
2. Создадим свое расширение: Добавим новое расширение к нашей конфигурации.
3. Заимствуем модуль: В расширении мы можем заимствовать тот объект, где находится наша процедура (например, Общий модуль ОбщиеРасчетыЖКХ).
4. Напишем перехватчик: В заимствованном модуле расширения создадим процедуру с той же сигнатурой, что и типовая, но с одной из аннотаций, например, &После или &Вместо.
   • Использование &После:

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

     Скопировать код

     
     &После("РассчитатьФормулу")
     Процедура РассчитатьФормулуПосле(Параметр1, Параметр2, РезультатРасчета)
         // Получаем значение, рассчитанное типовым кодом
         // Допустим, РезультатРасчета передается по ссылке и уже содержит типовой расчет
         РезультатРасчета = РезультатРасчета * КоэффициентНадбавки;
         Сообщить("Расчет формулы скорректирован через расширение!");
     КонецПроцедуры
     

   • Использование &Вместо:

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

     Скопировать код

     
     &Вместо("РассчитатьФормулу")
     Процедура РассчитатьФормулуВместо(Параметр1, Параметр2)
         // Здесь пишем свою логику расчета, которая полностью заменит типовую
         МойРезультат = МойМодуль.ВыполнитьСвойРасчет(Параметр1, Параметр2);
         // Возвращаем результат, если процедура типовая была функцией
         // или записываем в нужные параметры/объекты, как это делала типовая процедура
         // Внимание: если типовая процедура была функцией,
         // необходимо имитировать ее возвращаемое значение.
         // Для примера, если типовая процедура возвращала значение через параметр по ссылке:
         Параметр2.ЗначениеРезультата = МойРезультат;
         Сообщить("Расчет формулы полностью переопределен через расширение!");
     КонецПроцедуры
     

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

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

Ограничения и важные моменты при работе с расширениями

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

1. Глобальные серверные модули: Мы не можем заимствовать или расширять глобальные серверные модули (например, МенеджерОбменаДаннымиКлиентСервер), так как они имеют специфичный режим работы.
2. Безопасный режим: Код из расширения по умолчанию выполняется в непривилегированном режиме, если иное не разрешено в профиле безопасности. При включенном «Безопасном режиме» для расширения существуют ограничения на расширение серверных методов и серверных общих модулей. Если вы столкнулись с ошибкой при попытке вынести что-то в расширение (как в сообщении 7), одной из причин может быть именно «Безопасный режим» расширения, который необходимо отключить, если требуется расширять серверные методы. Отключение «Безопасного режима» позволяет расширять клиентские и серверные методы без ограничений по их расположению, но требует более внимательного отношения к безопасности.
3. Аннотация &Вместо: Хотя она очень мощная, использование &Вместо часто заставляет нас копировать весь код типовой процедуры или функции, даже если нужно изменить лишь небольшую часть. Это значительно затрудняет анализ изменений при последующих обновлениях типовой конфигурации. Старайтесь по возможности использовать &Перед и &После, которые более устойчивы к изменениям в типовом коде.
4. Инструменты разработки: При создании собственных общих модулей в расширении, контекстная подсказка (Ctrl+Space) и переход по F12 могут не всегда корректно работать для этих модулей в основной конфигурации или других расширениях. Мы должны быть готовы к этому, проводя анализ состава расширений.
5. Типы объектов: Не все типы объектов могут быть расширены. Например, для некоторых динамических списков или запросов может потребоваться более сложный подход.

Риски прямого изменения защищенных модулей

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

1. Потеря поддержки: Конфигурация полностью теряет статус типовой, и поставщик прекращает официальную поддержку. Это означает, что при возникновении проблем или вопросов вам не к кому будет обратиться.
2. Сложности с обновлениями: Каждое последующее обновление типовой конфигурации будет требовать трудоемкого и затратного ручного анализа всех внесенных вами изменений и их переноса. Этот процесс крайне сложен, чреват ошибками и требует высокой квалификации разработчика.
3. Потенциальная нестабильность: Некорректное изменение защищенного кода может привести к нарушению логики работы программы, появлению невоспроизводимых ошибок, потере данных или значительному снижению производительности. Мы рискуем создать «бомбу замедленного действия».
4. Невозможность изменения: Некоторые модули могут поставляться без исходных кодов (в бинарном представлении, используя обфускатор байт-кода), что делает их изменение принципиально невозможным.

Заключение

Таким образом, для доработки конфигурации «1С:Учет в управляющих компаниях ЖКХ, ТСЖ и ЖСК» при наличии заблокированных общих модулей, наиболее безопасным, гибким и рекомендуемым способом является использование расширений конфигурации. Мы можем добавить необходимую функциональность, модифицировать логику расчетов или поведение типовых объектов, сохраняя при этом возможность получения обновлений и поддержки от поставщика. Если с расширениями возникают ошибки, как это было в сообщении 7, нам следует внимательно проверить их настройки (например, «Безопасный режим») и убедиться, что попытка изменения не затрагивает глобальные серверные модули или другие объекты, для которых расширения имеют ограничения. Правильное применение расширений позволяет нам добиться нужного результата без катастрофических последствий для нашей информационной системы.