свернуть

Почему нужно составлять индивидуальные конфигурации?

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

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

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

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

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

Значит иногда всё-таки можно сделать собственную конфигурацию под свой бизнес-процесс. Это особенно актуально, если затраты по изменению стандартной конфигурации соизмеримы с затратами на новую конфигурацию, при этом не следует забывать, что при обновлении измененной стандартной конфигурации изменения придется, либо отлаживать по новой, либо делать заново! Написанная же "от и до" собственная конфигурация проще в обновлении и модернизации, т.к. пользователь сам составил схему бизнес процесса, который будет в ней отражен. Официальные же бланки и различные отчеты, вышедшие в обновленной стандартной конфигурации можно легко перенести в собственную, по трудозатратам это сопоставимо с частичным обновлением измененной стандартной конфигурации. Но главное преимущество переноса состоит в том, что собственная конфигурация лишена той "универсальности" из-за которой часто бывает "не читаем" код функций и процедур стандартных конфигураций. Проще говоря конфигурация заточенная под конкретный бизнес-процесс обычно (почти всегда, если грамотный автор) содержит легко читаемый и понятный код, в который легко внедрить долгожданные обновления. Причем трудозатраты будут только по изменениям, остальной же код будет не тронут, и выяснять какие конфликты вызовет обновление не нужно, т.к. это будет сделано сразу, при внедрении обновления. Причём при внедрении очередного обновления не нужно заново восстанавливать уже сделанные. Потому что обновление внедряется в конфигурацию, поэтому именно оно подвергается изменению, а не вся конфигурация подгоняется под изменение, как это нужно делать при частичном обновлении измененной стандартной конфигурации, поэтому скорость отладки в собственной конфигурации в разы меньше. При этом не нужно ждать очередного релиза, как только назрела необходимость в изменении - можно сразу приступать к реализации.

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

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