В работе с системами 1С:Предприятие 8.3 часто возникает необходимость адаптировать типовую конфигурацию под специфические требования бизнеса. Однако внесение изменений в конфигурацию, находящуюся на поддержке, является ответственной задачей, требующей тщательного подхода. Некорректные действия могут значительно усложнить дальнейшие обновления и сопровождение системы. Давайте вместе рассмотрим основные подходы к решению этой задачи, их преимущества, недостатки и особенности реализации.
Это наиболее рекомендуемый и безопасный способ внесения изменений, позволяющий сохранить типовую конфигурацию нетронутой. Расширения представляют собой отдельные объекты, которые "накладываются" поверх основной конфигурации, добавляя или изменяя функциональность без модификации исходных файлов.
Как это работает? Мы создаем отдельное расширение и вносим в него необходимые доработки: добавляем новые формы, реквизиты, отчеты, обработки или модифицируем существующие объекты основной конфигурации. После создания расширения оно публикуется в информационной базе и начинает действовать поверх базовой конфигурации.
Преимущества:
Типовая конфигурация остается неизменной, что значительно упрощает и ускоряет процесс ее обновления. Обновления поставщика устанавливаются стандартным образом, а наше расширение продолжает работать поверх обновленной конфигурации.
Существенно снижается риск ошибок при обновлении, поскольку нет необходимости в трудоемком сравнении и объединении изменений. Расширение просто применяет свои изменения к новой версии типовой конфигурации, и только в случае конфликтов (например, если поставщик изменил тот же элемент, который мы изменили в расширении) может потребоваться его доработка.
Расширения легко подключать и отключать, что удобно для тестирования или временного использования функционала. Мы можем быстро активировать или деактивировать набор доработок, не затрагивая основную конфигурацию.
Применяется к существующей конфигурации без ее снятия с поддержки, что позволяет соблюдать лицензионные условия и получать регулярные обновления.
Ограничения:
Не все объекты и свойства могут быть расширены. Например, существуют определенные ограничения на изменение некоторых модулей объектов (например, модулей менеджеров некоторых системных объектов) или логики базовых операций, которые могут потребовать прямого изменения конфигурации. Мы не можем напрямую изменить произвольный код в модуле типового объекта, но можем подписаться на его события.
Некоторые сложные доработки могут быть неудобны или невозможны для реализации исключительно через расширения. Например, если нам требуется кардинально изменить структуру данных или основные алгоритмы работы системы, расширение может оказаться недостаточным инструментом.
Важно помнить, что расширение, в основном, ориентировано на добавление новой функциональности или небольшие корректировки. Если нам нужно изменить стандартный алгоритм, мы, скорее всего, будем использовать подписки на события или создавать собственные процедуры, которые будут вызываться из расширения, а не напрямую модифицировать типовой код.
Этот метод позволяет вносить прямые изменения в типовую конфигурацию, при этом формально сохраняя ее на поддержке. Он используется в случаях, когда функциональность расширений недостаточна, но полное снятие с поддержки крайне нежелательно.
Как это делается?
В конфигураторе, мы открываем окно "Настройка поддержки" (меню "Конфигурация" -> "Поддержка" -> "Настроить поддержку..."). Для корневого объекта конфигурации (или для отдельных объектов, которые мы хотим изменить) устанавливаем режим "Изменяемая" или "Разрешить изменение". Важно не снимать конфигурацию с поддержки полностью, а оставить ее в режиме "На поддержке с возможностью редактирования". Это означает, что система будет отслеживать изменения поставщика, но позволит нам вносить свои.
Вносим необходимые изменения: добавляем реквизиты, изменяем модули, формы, макеты и т.д., непосредственно в типовую конфигурацию.
После завершения доработок, при необходимости распространить изменения в другие базы или создать свой "комплект поставки", мы можем сохранить текущую конфигурацию. Для этого используем меню "Конфигурация" -> "Сохранить конфигурацию в файл..." для получения файла .cf. Этот файл будет содержать нашу измененную конфигурацию. Или, для создания файла обновления, мы воспользуемся функционалом "Конфигурация" -> "Поставка конфигурации" -> "Создать файлы поставки и обновления...", что позволит сформировать файл .cfu для перехода с одной версии нашей измененной конфигурации на другую. Подробные инструкции по созданию таких файлов можно найти в документации 1С:ИТС.
Обновление после прямых изменений:
Это наиболее критичная часть данного метода, требующая особого внимания и квалификации. При каждом выходе нового релиза типовой конфигурации, нам придется выполнять процесс "Сравнение/Объединение конфигураций".
Сравнение и объединение: Когда мы применяем файл обновления поставщика (.cfu) или полную конфигурацию поставщика (.cf), система автоматически выявит все различия между нашей текущей (измененной) конфигурацией и конфигурацией нового релиза поставщика. Нам потребуется вручную анализировать каждый конфликт, который может возникнуть (например, если мы изменили ту же процедуру, что и поставщик), и принимать решения: какие изменения сохранить (наши доработки), а какие принять из обновления (изменения поставщика). Этот процесс может быть очень трудоемким, особенно при большом количестве доработок или частых изменениях в типовой конфигурации. Мы должны быть готовы потратить значительное время на каждый процесс обновления.
Файл обновления поставщика (не "комплект поставки" в широком смысле, а именно обновление): Если мы распространяем свои изменения в виде обновления для других баз, то для обновления наших измененных конфигураций нам также придется применять этот файл через механизм сравнения и объединения. Это означает, что каждая база, использующая нашу измененную конфигурацию, будет проходить аналогичный ручной процесс обновления при выходе нового релиза поставщика.
Недостатки этого метода:
Высокая трудоемкость и риск ошибок при каждом обновлении. Чем больше доработок и чем чаще они пересекаются с типовым функционалом, тем сложнее и дольше становится процесс обновления. Ошибка на этом этапе может привести к неработоспособности системы.
Потенциальные конфликты, когда наши доработки затрагивают те же участки кода или объекты, что и изменения поставщика. Разрешение таких конфликтов требует глубокого понимания логики как типовой конфигурации, так и наших доработок. Неправильное разрешение конфликта может привести к скрытым ошибкам и нестабильной работе системы.
Усложняет работу других сопровождающих организаций. Конфигурация выглядит как типовая, но содержит неочевидные доработки. Это может привести к тому, что другие специалисты по сопровождению по незнанию повредят базу, либо потратят много времени на поиск причин некорректной работы, вызванной нашими изменениями.
Этот метод заключается в полном отказе от поддержки со стороны фирмы "1С" и ее партнеров. Он крайне не рекомендуется, если у нас нет абсолютной необходимости и достаточных ресурсов (высококвалифицированных специалистов) для полного самостоятельного сопровождения и обновления конфигурации.
Последствия:
Автоматические обновления типовой конфигурации становятся невозможными. Каждое обновление придется устанавливать полностью вручную, что представляет собой крайне сложный и трудоемкий процесс, требующий глубоких знаний структуры конфигурации и понимания всех изменений между релизами. Мы буквально будем сравнивать два больших файла конфигурации (нашу измененную и новую типовую) и вручную переносить изменения.
Мы лишаемся всех преимуществ поддержки, таких как своевременное обновление регламентированной отчетности, учет изменений законодательства, исправление ошибок разработчика. Всю эту работу нам придется выполнять самостоятельно, что сопряжено с большими временными и финансовыми затратами.
Существенно возрастают риски потери работоспособности системы при попытке ручного обновления или при возникновении ошибок в нашей самостоятельно доработанной конфигурации. Без официальной поддержки и автоматизированных средств обновления, вероятность критических сбоев значительно выше.
Независимо от выбранного метода, существуют общие подходы и рекомендации, которые помогут нам в работе и минимизируют риски:
Отраслевые решения: Некоторые отраслевые решения, например, CRM от Рарус, часто "встраиваются" в типовую конфигурацию. Они поставляются как отдельные конфигурации, которые объединяются с типовой. При этом механизм поддержки предусматривает обновления как для типовой части, так и для отраслевой. Это более контролируемый процесс, чем "самовольные" изменения, так как разработан вендором и имеет свой механизм поддержки. Мы можем изучить опыт таких решений, чтобы понять принципы интеграции.
Документация 1С:ИТС: Всегда обращаемся к официальным источникам информации. Разделы на 1С:ИТС, посвященные разработке и тиражированию решений на платформе "1С:Предприятие", содержат детальные инструкции по работе с конфигурациями на поддержке, созданию файлов поставки и обновления. В частности, мы рекомендуем изучить материалы по "Настройке поставки и созданию файлов поставки и обновления" и "Механизмы объединения и сравнения конфигураций". Эти материалы являются наиболее полным и авторитетным источником информации.
Тщательное тестирование: Вне зависимости от выбранного метода, всегда необходимо проводить тщательное тестирование всех внесенных изменений и процесса обновления на тестовой базе перед применением их к рабочей информационной базе. Это поможет выявить потенциальные ошибки и конфликты до того, как они затронут реальную работу предприятия. Создаем точную копию рабочей базы и на ней проверяем все доработки и процесс обновления.
Документирование изменений: Обязательно документируем все внесенные изменения. Это критически важно для дальнейшего сопровождения, особенно если над проектом будут работать другие специалисты или нам потребуется вернуться к ним через продолжительное время. В документации указываем, какие объекты были изменены, что именно было изменено, зачем это было сделано и какие особенности есть у этих изменений. Отсутствие документации может привести к тому, что другие сопровождающие организации будут воспринимать нашу конфигурацию как типовую, что, как показывает опыт, приводит к серьезным проблемам и большим временным затратам на их решение.