Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
(1) Собственно описанный в публикации подход позволяет решить первую проблему со временем транзакции и блокировками. Но не вторую. Поэтому кажется применимым при небольших легко контролируемых доработках конфигураций. Главное вовремя понять, когда следует сменить замочек «Объект поставщика не редактируется» на быстрое выявление необходимости адаптации нашего кода под изменения типовой и применять удобные для этого инструменты.
Потому что если вот такого будет много:
то эффект от расширений будет обратным.
Владимир, спасибо за развернутый комментарий.
(1)
Так я и описываю основной вариант, где доработка выполняется точечно, и запись наборов выполняется одни раз в основном обработчике.
Если доработка выполняется в подписке на событие, то нужно повторять типовую логику и также записывать все наборы одновременно.
Согласен в Вами, применение расширений далеко не всегда обосновано.
Если конфигурация дорабатывается серьезно, и значительно затронуты типовые механизмы, правильнее вести доработку в основной и сравнивать доработки при обновлении.
Но, если доработки не значительны (в 90% случаев не потребуется корректировка при обновлении), или создаются движения по новым регистрам, по-моему расширения очень удобны.
Нужно смотреть по месту и применять решение, без фанатизма.
На счет процедуры ПодготовитьНаборыЗаписейКРегистрацииДвижений, не до конца понял то, что Вы пишите, но соглашусь. Возможны ситуации, когда движения были, а при перепроведении их нет. В этом случае, флаг «Записывать» нужно устанавливать заранее.
(1)
Не разу не встречал такого
(1)
В типовом методе очищаются именно все.
(4)
Все, понял, что Вы имеете в виду.
Еще расширения конечно нужно грамотно создавать.
Например плохо, когда на каждую задачу создается новое расширение.
Я видел, когда обработка проведения одного документа добавлена в 6 расширений.
Вообще черт голову сломит!
По хорошему на один объект одно расширение.
(2) Абсолютно согласен по поводу расширений, в ERP/УТ/КА довольно хорошая декомпозиция по методам и функциям, и гораздо удобнее для поддержки изменять типовые модули, имея при обновлении (3х стороннем сравнении) полный контекст, нежели переопределять или дополнять процедуры с помощью расширений, думая, что ты в безопасности.
Также общий модуль менеджерОбменаУниверсальногоФормата я предпочитаю дорабатывать типовой, нежели вручную проверять изменения через расширения. Некоторые просто создают отдельный общий модуль, который тоже легко теряется из виду при обновлении
(6)Еще раз говорю, все зависит от конкретной ситуации.
Расширения — это не панацея, как фирма 1С старается преподнести.
Есть случаи, когда их применение не рационально и даже вредно (см. большой комментарий Владимира).
Но есть случаи, когда они очень даже полезны. И отбрасывать их сразу,
считая в априори вредным путем — не правильно.
Я за разумное использование расширений.
(4)А почему бы не совместить два подхода?
Те доработки которые сильно связаны с типовыми механизмами — делать в основной и сравнивать при обновлении.
А те, что связаны слабо или совсем не связаны — выносить в расширение.
Мне кажется, так будет оптимально.
(8) Да, тоже кажется что это было бы хорошим решением. В этом случае расширение выступает как плагин с независимым функционалом. Если при этом предполагается коллективная разработка, то хорошо, чтобы расширение было одно и было подключено к хранилищу (поддерживать несколько мелких хранилищ по одному на каждое расширение неудобно). Но это становится возможным только сейчас, когда расширения поддерживают почти все объекты метаданных и возможно его подключение к отдельному хранилищу.
Тут еще вопрос целесообразности этого. Ведь свои новые объекты и так не мешают обновлению конфигурации. Если изменения конфигурации незначительные и замочек на корне представляет какую-то ценность, то целесообразность понятна. Тогда мы не лишаем возможности пользователя провести обновление без программиста. (Бывает ли вообще такое на ERP или КА? Скорее это относится к БП и ЗУП.) Или если мы делаем независимый плагин для распространения отдельно от основной конфигурации (на Инфостарте есть много примеров таких решений). Если же какие-то изменения в основную конфигурацию всё-равно придётся вносить, то мы получим просто два или больше хранилищ конфигурации вместо одного и два или больше источника кода вместо одного. Примерно как с дополнительными отчетами и обработками, с которыми коллективная разработка и версионирование кода также осложняется (обычно это решается через разбор на исходники и выгрузку в Git, то есть опять же получаем два репозитория).
Ещё бы платформа не ошибалась показывая просто заимствованные, но не измененные формы. Недавно на 8.3.12 натолкнулся на такое поведение. Платформа показывает несколько заимствованных типовых форм как измененные. Визуально отличий нет, код тоже не изменен. Выгружаю в XML, сравниваю содержимое BaseForm (сохраненная форма) и Form (измененная форма) — они идентичны. Тот же результат был после обновления сохраненной формы из основной конфигурации. И здесь во всю проявляется проблема с тем, что нет трехстороннего сравнения-объединения и нельзя быстро сделать вывод о том, что же поменялось. Но это наверняка поправят. На 8.3.14 эту же конфигурацию ещё не проверял.
(9) Поддержу.
Использовать расширения нужно без фанатизма.
Уже не однократно натыкались на грабли, когда действительно типовой функционал вынужденно приходится перекрывать в расширении и при обновлении типовой конфигурации просто не замечаешь, что вот, ошибки подвезли.
Благо мы мало вмешиваемся в типовой функционал, больше достраиваем свой, отчеты, печатные формы, документы, справочники…
Типовая к слову сказать снята с замочка только из-за одной единственной правки дающей возможность использовать ERP с большим режимом совместимости нежели ей его назначает 1С.
(8)Я придерживаюсь немного другой логики… типовые механизмы адаптирую через расширение, а свой функционал добавляю в типовое решение. При обновлении мой добавленный функционал не будет меняться, а типовой, если не использовать методы «вместо» можно будет отследить на тестировании. ИМХО. однако
При обновлении сильно доработанной УТ11 мы прошли путь от изменений в конфигурации к переходу к расширениям. Поделюсь практикой.
Когда доработки были в конфигурации у нас обновление занимало 3 недели. Основная сложность была в переносе форм и состава реквизитов в составного типа (например, ДокументОснование).
Перенос доработок по модулям, была больше механической работой. Делался поиск в копии конфигурации по комментарию и далее просто переносились доработки в новую.
Когда перешли на расширения у нас 6 не пересекающихся по функционалу расширений. Обновление ускорилось. Укладываемся за одну неделю. Главная экономия конечно на доработках форм.
Реквизиты составного типа все равно приходится помнить или записывать.
расширения хотим объединить в одно, т.к. тоже есть неудобства. И раздражает подключать все их к хранилищу.
Большим плюсом периода, когда доработки были в конфигурации было то, что при переносе доработок много кода чистилось. Т.е. выявлялись доработки не актуальные на данный момент. (типа 5-ти летней давности, уже никто не помнит зачем делали).
Сейчас в расширении такое не вычищается и накапливается.
Проблема, которую озвучили выше, когда не контролируется код с директивой &Вместо есть и с каждым обновлением она встает острее. Ошибки выявляются порой уже в процессе эксплуатации.
В личной практике мелких доработок, расширения конечно дают только плюсы.
Как вывод можно сказать, что идеально бы было доработки модулей оставлять в конфигурации, а в расширение забирать только доработку форм, как визуальной части, так и логики. В основном используя вызов функций До или После типовой.
Ну и ждем 15-ю платформу там обещают внедрение изменений внутрь кода.
(12) А если перейти на полное программное изменение форм у вас вообще проблем не должно было возникать.
(13)Да, программное изменение форм в расширениях, это уже что-то типа стандарта.