Доработка проведения типовых документов в УТ 11.4, КА 2.4, ЕРП 2.4

Публикация № 1026226

Программирование - Практика программирования

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

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

Проведение всех документов в конфигурациях УТ 11, КА 2.4, ЕРП 2.4 построено по одному и томе же принципу, который хорошо описан тут: https:// /ut11-articles/2017-09-07-documents-posting-scheme/

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

Оглавление

  1. Типовой механизм проведения документов
  2. Добавление новых движений по регистрам
  3. Добавление движений по новым регистрам, используя механизм локализации и расширений
  4. Внесение изменений в существующие движения
  5. Механизм локализации в типовых документах

 

Типовой механизм проведения документов

Общая схема проведения документов

ПроведениеСерверУТ.ИнициализироватьДополнительныеСвойстваДляПроведения - настройка и инициализация дополнительных параметров, которые необходимы для создания движений по регистрам.

Документы.<Имя документа>.ИнициализироватьДанныеДокумента - обращение к модулю менеджера документа, для формирования структуры с таблицами движений. Поля таблиц четко соответствуют полям таблиц регистров.

  • ЗаполнитьПараметрыИнициализации – формирование запроса к основной таблице документа, обход выборки и установка значений параметров по всем необходимым реквизитам документа.
  • ТекстЗапросаТаблица<Имя регистра> - формирование текстов запросов для заполнения всех таблиц движений, которые будут перенесены в регистры.
  • <Имя документа>Локализация.ДополнитьТекстыЗапросовПроведения – процедура, в которой можно дополнить тексты запросов и задать дополнительные параметры.
  • ПроведениеСерверУТ.ИнициализироватьТаблицыДляДвижений – компонуется текст запроса, формируется результат, создаются таблицы движений.

 

ПроведениеСерверУТ.ПодготовитьНаборыЗаписейКРегистрацииДвижений – процедура, необходимость которой у меня вызывает много вопросов. В первую очередь происходит очистка наборов записей движений документа, что актуально только для «толстого» клиента. Далее происходит выборочная установка свойства «Записывать = Истина» для всех регистров, по которым будут сформированы движения. Это действие избыточное, так как в последующих процедурах данное свойство будет установлено отдельно для всех необходимых регистров.

<Имя общего модуля>.Отразить<Имя регистра> - перенос данных из сформированных таблиц в наборы записей регистров. Также устанавливается свойство наборов записей «Записывать = Истина».

СформироватьСписокРегистровДляКонтроля - формируется и записывается в дополнительные свойства документа массив с регистрами, по которым требуется выполнять контроль результатов проведения.

<Имя документа>Локализация.ОбработкаПроведения - процедура, в которой можно до заполнить какие-либо наборы записей регистров или заполнить новые наборы.

ПроведениеСерверУТ.ЗаписатьНаборыЗаписей – запись всех наборов записей регистров в базу данных, в которых установлено свойство «Записывать = Истина». Для всех регистров из списка регистров для контроля устанавливается дополнительное свойство набора записей «РассчитыватьИзменения». Далее в модулях наборов записей регистров происходит формирование временных таблиц с изменениями записей до и после записи набора. Дополнительно, в структуру «СтруктураВременныеТаблицы» заносятся данные о наличие записей во временных таблицах с изменениями.

ЗапасыСервер.СформироватьРезервыПоТоварамОрганизаций – (для документов, которые участвуют в товародвижении) расчет необходимых резервов и формирование записей в регистре «Резервы товаров организаций», для работы механизма Интеркампани. Более подробно о работе данного механизма смотрите здесь и здесь.  

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

СообщитьОбОшибкахПроведенияПоРегистру<Имя регистра>(Объект, Отказ, Результат);

ПроведениеСерверУТ.ОчиститьДополнительныеСвойстваДляПроведения – очищается менеджер временных таблиц:

ДополнительныеСвойства.ДляПроведения.СтруктураВременныеТаблицы.МенеджерВременныхТаблиц.Закрыть();

 

Добавление новых движений по регистрам

Добавление новых движений в проведение типовых документов можно выполнить несколькими, различными способами:

Добавление движений по новым регистрам

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

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

Во-первых, это достаточно трудоемко. Во-вторых, может получиться дублирование выполнения некоторых операций. Например, заполнение параметров инициализации для запроса или формирование движений по регистру «Активы и пассивы».

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

 

Добавление движений по новым регистрам, используя механизмы локализации и расширений

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

Первая процедура, которая нам необходима:

<Имя документа>Локализация.ДополнитьТекстыЗапросовПроведения (Запрос, ТекстыЗапроса, Регистры);

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

Внимание. Если требуется задать дополнительные параметры для результирующего запроса, необходимо дополнительно добавить в расширение процедуру модуля менеджера документа «ЗаполнитьПараметрыИнициализации». Если не использовать расширения, придется вносить изменения в модуль менеджера документа.

Вторая процедура локализации, которую требуется доработать:

Имя документа>Локализация.ОбработкаПроведения (ЭтотОбъект, Отказ, РежимПроведения);

Процедура вызывается перед записью сформированных таблиц движений в наборы записей регистров. В ней можно перенести новые сформированные таблицы движений в новые регистры:

Таблица = ДополнительныеСвойства.ТаблицыДляДвижений.Таблица<Имя регистра>;

Если Отказ ИЛИ Таблица.Количество() = 0 Тогда
    Возврат;
КонецЕсли;

Движения.<Имя регистра>.Записывать = Истина;
Движения.<Имя регистра>.Загрузить(Таблица);

Внимание. Следует не забывать включать новые регистры в список движений документа. Начиная с версии платформы 8.3.12 – это можно выполнить в расширении конфигурации.

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

Дополнить массив регистров для контроля в той же процедуре локализации:

ДополнительныеСвойства.ДляПроведения.РегистрыДляКонтроля. Добавить(Движения.<Имя регистра>);

Обработать событие «ПриЗаписи» в модуле записей регистра, для формирования таблицы изменений:

СтруктураВременныеТаблицы = ДополнительныеСвойства.ДляПроведения.СтруктураВременныеТаблицы;

Запрос = Новый Запрос;
Запрос.УстановитьПараметр("Регистратор", Отбор.Регистратор.Значение);
Запрос.МенеджерВременныхТаблиц = СтруктураВременныеТаблицы.МенеджерВременныхТаблиц;

Запрос.Текст = «
…
|ПОМЕСТИТЬ Движения<Имя регистра>Изменение
…»;

Выборка = Запрос.ВыполнитьПакет()[0].Выбрать();
Выборка.Следующий();
СтруктураВременныеТаблицы.Вставить("Движения<Имя регистра>Изменение", Выборка.Количество > 0);

Дополнить процедуру:

ПроведениеСерверУТ.ВыполнитьКонтрольРезультатовПроведения (ЭтотОбъект, Отказ);

по следующему шаблону:

ПакетЗапросов   = Новый Запрос;
МассивКонтролей = Новый Массив;
ТекстЗапроса    = "";

Если ЕстьИзмененияВТаблице(ДанныеТаблиц," Движения<Имя регистра>Изменение") Тогда
    МассивКонтролей.Добавить(Врег("<Имя регистра>"));
    ТекстЗапроса = ТекстЗапроса +   "<Текст контроля>";
КонецЕсли;

Если МассивКонтролей.Количество() = 0 Тогда
    Возврат;
КонецЕсли;

ПакетЗапросов.Текст = ТекстЗапроса;
ПакетЗапросов.МенеджерВременныхТаблиц = ДанныеТаблиц.МенеджерВременныхТаблиц;
МассивРезультатов = ПакетЗапросов.ВыполнитьПакет();

Итератор = -1;
Для Каждого Результат Из МассивРезультатов Цикл
    Итератор = Итератор + 1;

    Если Результат.Пустой() Тогда
        Продолжить;
    КонецЕсли;

    ИмяКонтроля = МассивКонтролей[Итератор];
    Если ИмяКонтроля = Врег("<Имя регистра>") Тогда
        СообщитьОбОшибкахПроведенияПоРегистру<Имя регистра> (Объект, Отказ, Результат);
    КонецЕсли;
КонецЦикла;
    
Если Отказ Тогда
    Если Объект.ДополнительныеСвойства.РежимЗаписи = РежимЗаписиДокумента.Проведение Тогда
        ТекстСообщения = НСтр("ru = 'Проведение не выполнено %ПредставлениеОбъекта%'");
    Иначе
        ТекстСообщения = НСтр("ru = 'Отмена проведения не выполнена %ПредставлениеОбъекта%'");
    КонецЕсли;

    ТекстСообщения = СтрЗаменить(ТекстСообщения, "%ПредставлениеОбъекта%", Строка(Объект));
    ОбщегоНазначенияКлиентСервер.СообщитьПользователю(ТекстСообщения, Объект);
КонецЕсли;

Примечание. Все выше перечисленные действия, также можно выполнить в расширении конфигурации.

 

Внесение изменений в существующие движения

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

Исходя из общего описания типового алгоритма проведения документов, можно сделать вывод, что вносить изменения в механизм формирования движений можно либо на этапе формирования текстов запросов. Это процедуры модуля менеджера документа «ТекстЗапросаТаблица<Имя регистра>». Либо в таблицах сформированных движений до их переноса в наборы записей регистров «ДополнительныеСвойства.ТаблицыДляДвижений.Таблица<Имя регистра>».

Рассмотрим более подробно различные варианты корректировки:

Корректировка существующих записей регистров

 

Полная замена функции, формирующей текст запроса

Для этого нужно добавить в расширение функцию «ТекстЗапросаТаблица<Имя регистра>» модуля менеджера документа с аннотацией «Вместо».

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

 

Дополнение или изменение сформированного текста запроса

Для этого нужно добавить в расширение процедуру «<Имя документа>Локализация.ДополнитьТекстыЗапросовПроведения» с любой аннотацией.

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

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

Необходимо написать следующий код:

ТекстыЗапроса[«СвободныеОстатки»] = СтрЗаменить(ТекстыЗапроса[«СвободныеОстатки»],
«ЗНАЧЕНИЕ(Перечисление.ТипыНоменклатуры.МногооборотнаяТара)»,
«NULL»);

 

Изменение данных в уже сформированной таблице движений до ее переноса в набор записей регистра

Для этого нужно добавить в расширение процедуру «ПроведениеСерверУТ.ИнициализироватьТаблицыДляДвижений» с аннотацией «После».

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

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

Необходимо реализовать следующий код:

Для Каждого СтрокаРасчетов Из Таблицы.ТаблицаРасчетыСКлиентами Цикл
    СтрокаРасчетов.ДатаПлатежа = Запрос.Параметры.Период;
КонецЦикла

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

 

Механизм локализации в типовых документах

В конце статьи, хочу обратить Ваше внимание на то, что используя механизм локализации, можно вносить изменения не только в алгоритмы проведения документов. Можно дополнять все основные обработчики модуля объекта документа: «ОбработкаЗаполнения», «ПередЗаписью», «ПриЗаписи»,… а также некоторые процедуры модуля менеджера документа.

На заметку. Если Вы используете расширения, имеет смысл использовать только выше описанные и приведенные ниже процедуры, так как остальные можно заменить непосредственным добавлением в расширение требуемого события или метода:

  • ОбработкаУдаленияПроведения
  • СформироватьКомплектПечатныхФорм

 

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

 

Другие мои статьи по описанию различных механизмов УТ 11, КА 2, ЕРП 2»

  1. Исправление отрицательных остатков по организациям, механизм формирования резервов для работы Интеркампани

  2. Учет товаров по сериям

  3. Контроль отрицательных остатков

  4. Интеркампани, новая методика учета

  5. Новая концепция учета по видам запасов

  6. Партионный учет товаров в конфигурациях УТ, КА, ЕРП

93

См. также

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. Vladimir Litvinenko 1717 22.03.19 12:19 Сейчас в теме
Общим минусом первого и второго вариантов является то, что необходимо повторить в подписке на событие или расширении всю типовую последовательность процедур.
Во-первых, это достаточно трудоемко. Во-вторых, может получиться дублирование выполнения некоторых операций. Например, заполнение параметров инициализации для запроса или формирование движений по регистру «Активы и пассивы».


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

Ведь в большинстве случаев при допроведении через подписки/расширения программисты используют метод Записать() отдельных наборов записей, а не метод Записать() коллекции всех движений. Один записал наборы записей в одном порядке. Потом пришел другой и в подписке/расширении доработал проведение другого документа по тем же регистрам но в другом порядке. Мало того, что время проведения увеличивается, повышая риск блокировок. Так и дедлоки весьма вероятны.

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

Запись движений в конфигурациях семейства ERP в подавляющем большинстве случаев происходит в типовом обработчике проведения по вполне обоснованным и описанным здесь правилам, которые обеспечивают минимальное время транзакции и отсутствие взаимоблокировок. Хорошо бы их придерживаться. А для этого правильно аккуратно вписаться непосредственно в модули объектов, подготовив все данные для записи до того, как впервые вызван метод Записать() коллекции движений. Тогда и запись будет проводиться в один приём и контроль остатков.



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

Поменялась структура типового регистра? Изменился типовой запрос, который мы переопределяли в расширении/подписке? Алгоритм формирования проводок переехал из модулей менеджеров и объектов в общие модули? При обновлении мы будем думать что мы молодцы, ведь типовые модули не тронули, замочек даже висит. Но это самообман. О проблемах узнаем только после того как запустим её в пользовательском режиме. А о части из них сообщат пользователи и потребуют перепрвести все документы корректно, ведь это не их косяк, а наш. После чего придется сравнивать объединять модули, но уже не с помощью удобных инструментов, а ручками. Потому что нет инструментов, позволяющих удобно сравнить доработки в расширении и исходные методы в самой конфигурации. И не будет, ввиду природы расширений.

Конечно покрытие тестами могло бы здесь помочь. Но автоматизация регрессионного тестирования в 1С сейчас в зачаточном состоянии и ещё не распространена широко. Да и зачем скрывать от самих себя необходимость адаптации наших изменений к новым релизам типовой конфигурации? Поменяли логику работы - надо это глазами увидеть при обновлении. Инструменты для быстрой адаптации тоже есть. Зачем искусственно себя их лишать?


С рашсирениями в последнее время нездоровый хайп. Вот как раз сейчас разбираюсь с одной конфигурацией КА 2 и наблюдаю, как расширения вообще убили возможность обновить эту конфигурацию. 10 расширений созданных для сохранения обновляемости. Но при обновлении невозможно сказать, какие из доработанных механизмов требуют адаптации, какие отвалятся. Даже если сделать фильтр "Измененные и добавленные в расширении" система иногда отображает в том числе не измененные, а просто заимствованные, формы. Да и если мы видим действительно измененный объект, то как быстро понять, нуждается ли он в адаптации? Можем ли мы быстро понять соответствует ли наш код новому коду типовой конфигурации? Нет, мы это скрыли от себя. В итоге эта конфигурация более года не обновляется. Не уверен, что использование одного расширения вместо 10 могло бы здесь помочь. Проблемы остались бы теми же.


ПроведениеСерверУТ.ПодготовитьНаборыЗаписейКРегистрацииДвижений – процедура, необходимость которой у меня вызывает много вопросов. В первую очередь происходит очистка наборов записей движений документа, что актуально только для «толстого» клиента.

Не только для "толстого" клиента. Точнее говоря не только для обычных форм. Движения могут быть выведены на форму из данных формы объекта и тогда они будут заполнены в начале обработки проведения. Движения могут быть считаны в обработчиках ПередЗаписью или ПриЗаписи. Конечно это плохая практика, но такая ситуация вполне возможна, особенно учитывая массовую "квалификацию" программистов. Поэтому очистка движений - хороший подход. К тому же очищаются не все движения, а только необходимые в соответствии с правилами типовой конфигурации.


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

Это действие необходимо для записи очищенных движений, которые должны быть записаны в базу при повторном проведении документа согласно логике работы типовой конфигурации, и которые обычно записываются не оперативно, а в процессе отложенного проведения. После вызова метода ПодготовитьНаборыЗаписейКРегистрацииДвижений в обработчике проведения для таких движений свойство Записывать может быть не установлено в Истина.
mivari; FreeArcher; bug256; m_aster; Crazy_kz; user811769; rabbishaman; A_Max; fancy; jif; ASDF2; borodatii; Brawler; Sley; Dach; +15 Ответить
2. Vladimir Litvinenko 1717 22.03.19 13:02 Сейчас в теме
(1) Собственно описанный в публикации подход позволяет решить первую проблему со временем транзакции и блокировками. Но не вторую. Поэтому кажется применимым при небольших легко контролируемых доработках конфигураций. Главное вовремя понять, когда следует сменить замочек "Объект поставщика не редактируется" на быстрое выявление необходимости адаптации нашего кода под изменения типовой и применять удобные для этого инструменты.

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

то эффект от расширений будет обратным.
6. smilebringer 22.03.19 18:27 Сейчас в теме
(2) Абсолютно согласен по поводу расширений, в ERP/УТ/КА довольно хорошая декомпозиция по методам и функциям, и гораздо удобнее для поддержки изменять типовые модули, имея при обновлении (3х стороннем сравнении) полный контекст, нежели переопределять или дополнять процедуры с помощью расширений, думая, что ты в безопасности.

Также общий модуль менеджерОбменаУниверсальногоФормата я предпочитаю дорабатывать типовой, нежели вручную проверять изменения через расширения. Некоторые просто создают отдельный общий модуль, который тоже легко теряется из виду при обновлении
Vladimir Litvinenko; +1 Ответить
7. ids79 2544 23.03.19 08:23 Сейчас в теме
(6)Еще раз говорю, все зависит от конкретной ситуации.
Расширения - это не панацея, как фирма 1С старается преподнести.
Есть случаи, когда их применение не рационально и даже вредно (см. большой комментарий Владимира).
Но есть случаи, когда они очень даже полезны. И отбрасывать их сразу,
считая в априори вредным путем - не правильно.
Я за разумное использование расширений.
FreeArcher; A_Max; +2 Ответить
3. ids79 2544 22.03.19 14:46 Сейчас в теме
Владимир, спасибо за развернутый комментарий.

(1)
Один записал наборы записей в одном порядке. Потом пришел другой и в подписке/расширении доработал проведение другого документа по тем же регистрам но в другом порядке

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

Согласен в Вами, применение расширений далеко не всегда обосновано.
Если конфигурация дорабатывается серьезно, и значительно затронуты типовые механизмы, правильнее вести доработку в основной и сравнивать доработки при обновлении.
Но, если доработки не значительны (в 90% случаев не потребуется корректировка при обновлении), или создаются движения по новым регистрам, по-моему расширения очень удобны.
Нужно смотреть по месту и применять решение, без фанатизма.

На счет процедуры ПодготовитьНаборыЗаписейКРегистрацииДвижений, не до конца понял то, что Вы пишите, но соглашусь. Возможны ситуации, когда движения были, а при перепроведении их нет. В этом случае, флаг "Записывать" нужно устанавливать заранее.

(1)
Движения могут быть считаны в обработчиках ПередЗаписью или ПриЗаписи

Не разу не встречал такого

(1)
К тому же очищаются не все движения, а только необходимые в соответствии с правилами типовой конфигурации

В типовом методе очищаются именно все.
4. Vladimir Litvinenko 1717 22.03.19 15:29 Сейчас в теме
(3)
Но, если доработки не значительны (в 90% случаев не потребуется корректировка при обновлении), или создаются движения по новым регистрам, по-моему расширения очень удобны.
Нужно смотреть по месту и применять решение, без фанатизма.

Да, когда инструмент применяется осмысленно и есть понимание, когда пришла пора его заменить, тогда его применение оправдано. Выше много написал потому что несколько раз сталкивался с неосмысленным применением. И вот недавно ещё раз пришлось увидеть, как инструмент предназначенный для упрощения обновления, приводит к противоположным последствиям. Даже не столько наболело, сколько не хотелось бы чтобы это распространялось. А ведь распространяется )) Сам когда-то на УПП с таким же фанатизмом бездумно подписки применял ради сохранения типовых модулей нетронутыми, а по факту "маскировки" изменений алгоритмов )) Сейчас понимаю что спасала стабильность УПП. С ERP сейчас всё сложнее и изменения логики нельзя пропускать.


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


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


Не разу не встречал такого

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


В типовом методе очищаются именно все.

Очищаются в оперативной памяти все. Потом флаг записи не для всех устанавливается. Там есть массив исключений. Правильно ли очищать движения, которые попадают в массив исключений? Вот здесь можно подумать. Но в целом такое поведение метода ПодготовитьНаборыЗаписейКРегистрацииДвижений кажется обоснованным. Есть регистры зависящие от других и записываемые из модулей наборов записей "базовых" для них регистров. Есть отложенные движения. Вот для всех них такой механизм и придуман.
user811769; +1 Ответить
5. ids79 2544 22.03.19 16:17 Сейчас в теме
(4)
Есть регистры зависящие от других и записываемые из модулей наборов записей "базовых" для них регистров. Есть отложенные движения. Вот для всех них такой механизм и придуман.

Все, понял, что Вы имеете в виду.

Еще расширения конечно нужно грамотно создавать.
Например плохо, когда на каждую задачу создается новое расширение.
Я видел, когда обработка проведения одного документа добавлена в 6 расширений.
Вообще черт голову сломит!
По хорошему на один объект одно расширение.
8. ids79 2544 23.03.19 08:27 Сейчас в теме
(4)А почему бы не совместить два подхода?
Те доработки которые сильно связаны с типовыми механизмами - делать в основной и сравнивать при обновлении.
А те, что связаны слабо или совсем не связаны - выносить в расширение.
Мне кажется, так будет оптимально.
9. Vladimir Litvinenko 1717 23.03.19 13:40 Сейчас в теме
(8) Да, тоже кажется что это было бы хорошим решением. В этом случае расширение выступает как плагин с независимым функционалом. Если при этом предполагается коллективная разработка, то хорошо, чтобы расширение было одно и было подключено к хранилищу (поддерживать несколько мелких хранилищ по одному на каждое расширение неудобно). Но это становится возможным только сейчас, когда расширения поддерживают почти все объекты метаданных и возможно его подключение к отдельному хранилищу.

Тут еще вопрос целесообразности этого. Ведь свои новые объекты и так не мешают обновлению конфигурации. Если изменения конфигурации незначительные и замочек на корне представляет какую-то ценность, то целесообразность понятна. Тогда мы не лишаем возможности пользователя провести обновление без программиста. (Бывает ли вообще такое на ERP или КА? Скорее это относится к БП и ЗУП.) Или если мы делаем независимый плагин для распространения отдельно от основной конфигурации (на Инфостарте есть много примеров таких решений). Если же какие-то изменения в основную конфигурацию всё-равно придётся вносить, то мы получим просто два или больше хранилищ конфигурации вместо одного и два или больше источника кода вместо одного. Примерно как с дополнительными отчетами и обработками, с которыми коллективная разработка и версионирование кода также осложняется (обычно это решается через разбор на исходники и выгрузку в Git, то есть опять же получаем два репозитория).

Ещё бы платформа не ошибалась показывая просто заимствованные, но не измененные формы. Недавно на 8.3.12 натолкнулся на такое поведение. Платформа показывает несколько заимствованных типовых форм как измененные. Визуально отличий нет, код тоже не изменен. Выгружаю в XML, сравниваю содержимое BaseForm (сохраненная форма) и Form (измененная форма) - они идентичны. Тот же результат был после обновления сохраненной формы из основной конфигурации. И здесь во всю проявляется проблема с тем, что нет трехстороннего сравнения-объединения и нельзя быстро сделать вывод о том, что же поменялось. Но это наверняка поправят. На 8.3.14 эту же конфигурацию ещё не проверял.
10. Brawler 437 23.03.19 23:38 Сейчас в теме
(9) Поддержу.
Использовать расширения нужно без фанатизма.
Уже не однократно натыкались на грабли, когда действительно типовой функционал вынужденно приходится перекрывать в расширении и при обновлении типовой конфигурации просто не замечаешь, что вот, ошибки подвезли.
Благо мы мало вмешиваемся в типовой функционал, больше достраиваем свой, отчеты, печатные формы, документы, справочники...
Типовая к слову сказать снята с замочка только из-за одной единственной правки дающей возможность использовать ERP с большим режимом совместимости нежели ей его назначает 1С.
user872488; +1 Ответить
11. lefthander 25.03.19 09:19 Сейчас в теме
(8)Я придерживаюсь немного другой логики... типовые механизмы адаптирую через расширение, а свой функционал добавляю в типовое решение. При обновлении мой добавленный функционал не будет меняться, а типовой, если не использовать методы "вместо" можно будет отследить на тестировании. ИМХО. однако
12. FreeArcher 84 11.07.19 09:19 Сейчас в теме
При обновлении сильно доработанной УТ11 мы прошли путь от изменений в конфигурации к переходу к расширениям. Поделюсь практикой.

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

Когда перешли на расширения у нас 6 не пересекающихся по функционалу расширений. Обновление ускорилось. Укладываемся за одну неделю. Главная экономия конечно на доработках форм.
Реквизиты составного типа все равно приходится помнить или записывать.
расширения хотим объединить в одно, т.к. тоже есть неудобства. И раздражает подключать все их к хранилищу.

Большим плюсом периода, когда доработки были в конфигурации было то, что при переносе доработок много кода чистилось. Т.е. выявлялись доработки не актуальные на данный момент. (типа 5-ти летней давности, уже никто не помнит зачем делали).
Сейчас в расширении такое не вычищается и накапливается.

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

В личной практике мелких доработок, расширения конечно дают только плюсы.

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

Ну и ждем 15-ю платформу там обещают внедрение изменений внутрь кода.
Оставьте свое сообщение