Расширения вместо правки конфигурации
Самый дорогой способ доработать 1С — залезть в типовую конфигурацию. Дорого не в момент разработки, а через год, когда приходит очередное обновление.
Типовая конфигурация — это не наш код и не ваш. Её обновляет вендор, и обновления приходят регулярно: меняется законодательство, форматы обмена, требования площадок. Пока конфигурация типовая, обновление — рутинная операция. Как только в неё внесены изменения, каждое обновление превращается в проект: разработчик заново сравнивает версии и переносит правки.
Практический признак того, что вы уже в этой ловушке: обновление обсуждается как событие, к нему готовятся, его боятся и переносят на «после сезона». Дальше начинается накопление — учёт живёт на версии двухлетней давности, потому что перейти дороже, чем терпеть.
Что даёт расширение
Расширение — отдельный объект, который меняет поведение конфигурации, не трогая её код. Типовая часть остаётся обновляемой, доработка живёт рядом и переносится между версиями осознанно. Появляется возможность выключить доработку и посмотреть, как система ведёт себя без неё — это важно при разборе инцидентов.
Второе следствие менее очевидно: расширение заставляет формулировать, что именно меняется. Вместо «поправили в документе» появляется «переопределено заполнение реквизита при таком-то сценарии». Через год, когда автор уже не работает в компании, это единственное, что спасает.
Обновляемость — не техническая деталь, а стоимость владения системой на годы вперёд.
Где предел
Расширения не всесильны. Часть механизмов не переопределяется, часть — переопределяется настолько неудобно, что решение становится хрупким. Если задача требует другой модели данных, а не другого поведения, честный ответ — не расширение, а отдельный объект метаданных или внешний сервис, связанный обменом.
Мы в таких случаях предлагаем разделить: то, что относится к учёту, остаётся в 1С; то, что относится к процессу вокруг учёта — кабинет, портал, обработка заявок, интеграция с площадками — уезжает в отдельный сервис. Учёт остаётся типовым и обновляемым, а бизнес-логика развивается в своём темпе.
Что делать, если правки уже внутри
Начинать не с переписывания, а с инвентаризации: какие доработки есть, какие из них реально используются, какие можно выключить. По опыту, значимая часть изменений — следы задач, которых больше нет. Дальше — переносить в расширения то, что нужно, начиная с самого болезненного при обновлении.
Это работа не на один спринт, но она конечна, и после неё обновление снова становится рутиной. Мы делаем такие переносы поэтапно, вместе с сопровождением, чтобы бизнес не останавливался.
Похожая задача у вас?
Расскажите ситуацию — скажем, что делали в подобных проектах и с чего начать.