0. ids79 1858 22.03.19 11:20 Сейчас в теме

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

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

Перейти к публикации

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


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

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

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

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



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

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

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


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


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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


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

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


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

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

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

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

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

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

Вакансии

Автор новостных обзоров на тему 1С и бухучета
Санкт-Петербург
По совместительству

Программист 1С
Санкт-Петербург
зарплата до 120 000 руб.
Полный день

Работа от Инфостарт
Санкт-Петербург
Временный (на проект)

Руководитель отдела внедрения 1С
Новосибирск
зарплата от 60 000 руб. до 160 000 руб.
Полный день

Ведущий программист 1С
Сочи
зарплата от 82 500 руб. до 99 000 руб.
Полный день