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