У клиента в бухгалтерии есть небольшая доработка формирования типовой печатной формы. На данный момент она реализована через изменение модуля менеджера документа, из которого производится печать. Баз несколько, поэтому для экономии время на обновление решено реализовать доработку через расширение.
Изменена процедура наполнения табличного документа и решить ее через &Перед не удается. По крайней мере пока я не нашел решение.
Если использовать замену типовой функции, тогда при каждом обновлении есть риск, что стандартный функционал поменялся и часть данных не будет выводиться (без выдачи ошибки), например.
Так или иначе вопрос для меня актуален, когда есть маленькая доработка посередине процедуры или функции. Как через расширение встроить ее так, что бы потом не пришлось постоянно перепроверять.
Кто как выкручивается в подобной ситуации?
С расширениями пока мало работал. Может, есть некое сравнение\объединение между типовой функцией и доработанной, на манер процедуры при обновлении нетиповой конфигурации? Тогда можно было бы довольно быстро при обновлении сверяться, не поменялась ли типовая функция.
(1) Есть инструменты от сторонних разработчиков: скрипт diff3cf для OneScript. Он как раз составляет отчет по процедурам и функциям основной конфигурации, которые были доработаны в расширении (с любой директивой), и при этом изменены в новой конфигурации поставщика.
После небольшой доработки напильником инструментом остались довольны.
(1) в платформе 8.3.15 появилась новая аннотация ИзменениеИКонтроль с инструкциями препроцессора #Вставить - #КонецВставить и #Удалить - #КонецУдалить
Для того, чтобы основное «содержание» метода менялось бы вместе с изменениями конфигурации, и в то же время в нём сохранялись ваши небольшие изменения, добавили новую аннотацию &ИзменениеИКонтроль. Она позволяет вам добавить собственные изменения в метод, сохраняя, при этом, его исходный текст.
И, про вопрос контроля изменений. Дело в том, что при использовании аннотации &ИзменениеИКонтроль метод, заимствованный в расширение должен абсолютно совпадать с методом в основной конфигурации. Если не совпадает, то при проверке возможности применения расширения будет выдана ошибка. По этой ошибке будет сразу понятно, что в этот модуль при обновлении были внесены изменения.
(9) Учту! Еще подскажите, пожалуйста, как действовать, когда при замещении одной процедуры проверка начинает ругаться, что вызываются другие процедуры, которых нет в модуле расширения. я так по цепочке могу половину модуля типового перекопировать, пока перестанет ругаться...
(10) и подобная ситуация при обращении к реквизитам объекта из модуля объекта. если самих реквизитов вместе с объектом нет в расширении, то ошибки. добавлять всё?
(1) Сравнение расширения с конфигурацией базы данных пока не работает, хотя такой пункт в меню есть. Скорее всего этот функционал добавится в следующих версиях платформы.
(2) Как вариант. По ним у меня подобные опасения, правда =)
А если забыть про данную конкретную задачу и принять за факт, что доработку можно сделать только вносом нескольких строк в середину модуля объекта? Например, для изменения процедуры создания на основании. Типовой функционал, ради которого делать внешнюю обработку странно.