При внедрении практически любой системы возникает потребность в её адаптации под нужды клиента. При этом требуется соблюсти требование поддержки в актуальном состоянии базового (типового) функционала в ходе выпуска вендором новых версий.
Рассмотрим те принципы, которые помогут в решении описанной задачи, на примере внедрения «1С:ERP Управление предприятием 2».
Адаптация на уровне конфигуратора может включать в себя следующие типы изменений:
- Изменение кода
- Изменение форм
- Изменение макетов
- Изменение ролей
- Различные изменения объектов метаданных
Изменение кода
В ходе адаптации, основным принципом, касающимся всех типов изменений, является минимизация пересечений нового функционала, разрабатываемого в ходе внедрения системы, с базовым. Отсюда следует, что необходимо стремиться располагать новый функционал в новых объектах конфигурации.
Если данный принцип удаётся соблюсти, то, как правило, при последующих обновлениях базового функционала не возникает сложностей, а само обновление проходит с минимальными трудозатратами.
Одним из факторов грамотно выполненной доработки системы является объем отчета об изменениях, выводимого платформой при сравнении конфигурации поставщика и основной конфигурации – отчет должен содержать как можно меньше строк.
Соответственно, весь новый код должен располагаться в добавленных общих модулях и обработках.
В случае, когда суть изменений вынуждает выполнять модификацию кода в типовых модулях, например, общем модуле или форме документа, ситуация чуть сложнее и требует придерживаться следующих критериев:
- Объем вносимых изменений должен быть минимальным. Например, если объем кода добавленного обработчика превышает некоторое пороговое значение (обычно 3-5 строк), то сам код располагается в добавленном общем модуле с вызовом метода из обработчика одной строкой.
- Вносимые изменения по возможности должны быть локализованы в модуле в минимальном числе мест. Например, если требуется добавить несколько дополнительных обработчиков элементов формы документа, то их следует располагать рядом друг с другом, а не рассредоточивать по модулю формы.
- Все вносимые изменения должны быть аккуратно прокомментированы и ограничены маркерами изменений. Комментирование призвано облегчить понимание того, для чего изменения были выполнены. А маркеры изменений должны однозначно обозначать границы изменений – весь код, который располагается вне маркеров, должен быть типовым. Приведем в качестве примера несколько маркеров:
Или
Особое внимание следует обратить на то, что открывающий и закрывающий маркеры должны различаться.
Как правило, в маркеры для удобства дополнительно добавляют информацию о:
- Дате внесения изменений
- Авторе изменений
- Номере задачи, в соответствии с которой изменения были внесены
- И т.п. информацию
А для формирования самих маркеров настраивают шаблоны текста.
Важным моментом является то, что в случае изменения или удаления типового кода он должен остаться на месте в исходном виде. Например:
Не следует допускать следующих явлений:
- Вкладывать один маркер изменений в другой
- Располагать маркеры изменений непосредственно друг за другом (в этом случае должен быть один общий маркер)
- Использовать маркеры изменений за пределами типовых модулей
Изменение форм
Частой ошибкой является подход, когда для модификации типовой формы создают ее копию, которую в последующем модифицируют под свои нужды. То же самое касается макетов, и даже целых документов. При таком подходе на обновляемости сразу можно ставить крест.
Если требуется модифицировать, скажем, форму документа «Заказ клиента», то изменяется именно типовая форма. Здесь можно пойти двумя путями:
- Либо изменить непосредственно саму форму в конструкторе, добавив новые или изменив типовые элементы формы
- Либо изменять форму программно в обработчике «ПриСозданииНаСервере»
На практике одинаково успешно применяются оба подхода, поскольку каждый из них имеет свои плюсы и минусы.
Модификация формы в конструкторе позволяет существенно ускорить процесс внесения изменений и сразу увидеть результат, но при необдуманных изменениях может усложнить процесс последующего обновления. Приведем несколько принципов:
- Нельзя удалять типовые элементы формы в конструкторе, можно их лишь скрывать, и лучше это делать программно
- Поля в таблицы формы следует добавлять только в конец, после типовых полей
- Изменение свойств типовых элементов формы следует также выполнять программно
Программная модификация формы упрощает процесс последующего обновления форм, однако на этапе внедрения может увеличить сроки, трудозатраты и вероятность возникновения ошибок.
Изменение макетов
С изменением макетов печатных форм и отчетов ситуация несколько сложнее. Программное изменение макетов, например, макета печатной формы документа, доступно далеко не всегда в нужной мере. С другой стороны, создание копий макетов нисколько не избавляет от последующих проблем с обновлением.
Здесь для печатных форм доступен замечательный механизм внешних печатных форм, позволяющий как изменять существующие, так и добавлять новые формы.
Для отчетов на системе компоновки данных (СКД):
- Изменения запросов маркируются аналогично изменениям кода
- Изменения структуры СКД можно выполнить в пользовательском режиме за счет настройки варианта отчета, либо же программно
Изменение ролей
Следует избегать какой-либо модификации типовых ролей, за исключением роли «ПолныеПрава». Особенно это касается ограничений доступа. Роли в «1С:ERP Управление предприятием 2» созданы по принципу атомарности и вполне позволяют подобрать в профиль пользователя требуемую конфигурацию.
Роли на добавленные объекты следует организовать аналогичным образом. Однако в ходе внедрения настройку ролей зачастую оставляют на последний этап. Поэтому вполне допустимо изначально создать минимально необходимое числе ролей, предоставляющих доступ к массивам объектов, с тем чтобы в последующем разбить их на атомарные роли.
Роль «ПолныеПрава» нуждается в модификации, поскольку изначально предоставляет все права на новые объекты, однако надо не забывать исключать право интерактивного удаления.
Изменения объектов метаданных
Добавление новых основных объектов метаданных, равно как и подсистем, ролей, общих модулей, общих макетов и форм, не является для последующего обновления какой-либо проблемой. Достаточно соблюсти следующие критерии:
- Все добавленные объекты должны быть включены в добавленные подсистемы
- Все добавленные объекты должны иметь префикс. Префикс применяется только для основных объектов конфигурации, подсистем, ролей, общих объектов, но ни в коем случае не для реквизитов, форм объектов, форм макетов и т.д.
Если возникает потребность нарастить реквизитный состав основного объекта, то можно пойти двумя путями:
- Либо добавить реквизиты непосредственно в объект
- Либо вынести реквизиты в отдельный, связанный с объектом регистр сведений
Второй подход имеет смысл в двух случаях:
- Когда объект возможно и хочется оставить на полной поддержке
- Когда состав добавляемых реквизитов широкий, но применяется для малого числа записей (элементов справочника, документов)
При необходимости изменить свойства реквизита, например, сделать его обязательным, изменить синоним, это вполне можно сделать непосредственно – функционал сравнения/объединения конфигураций корректно отображает и переносит данные изменения.
Что делать нельзя, так это удалять существующие реквизиты или сужать состав типов составного реквизита.
В качестве заключения
В статье рассмотрены основные принципы, соблюдение которых позволит сохранить внедренную систему обновляемой в короткие сроки и с минимальными ошибками. На практике, системы с высоким уровнем адаптации под клиента в ходе выполнения проектов, удавалось в последующем обновлять в течение суток с приостановкой работы исключительно на реструктуризацию таблиц базы данных.
Конечно, в процессе внедрения приходится сталкиваться с различными граничными случаями, со сменой парадигмы ролей и иными сложными нюансами. Подобные вопросы не менее важны и требуют уже индивидуального рассмотрения.