<img src="https://secure.leadforensics.com/133892.png" alt="" style="display:none;">

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

Рассмотрим те принципы, которые помогут в решении описанной задачи, на примере внедрения «1С:ERP Управление предприятием 2».

Адаптация на уровне конфигуратора может включать в себя следующие типы изменений:

  1. Изменение кода
  2. Изменение форм
  3. Изменение макетов
  4. Изменение ролей
  5. Различные изменения объектов метаданных

Изменение кода

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

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

Одним из факторов грамотно выполненной доработки системы является объем отчета об изменениях, выводимого платформой при сравнении конфигурации поставщика и основной конфигурации – отчет должен содержать как можно меньше строк.

Соответственно, весь новый код должен располагаться в добавленных общих модулях и обработках.

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

  1. Объем вносимых изменений должен быть минимальным. Например, если объем кода добавленного обработчика превышает некоторое пороговое значение (обычно 3-5 строк), то сам код располагается в добавленном общем модуле с вызовом метода из обработчика одной строкой.
  2. Вносимые изменения по возможности должны быть локализованы в модуле в минимальном числе мест. Например, если требуется добавить несколько дополнительных обработчиков элементов формы документа, то их следует располагать рядом друг с другом, а не рассредоточивать по модулю формы.
  3. Все вносимые изменения должны быть аккуратно прокомментированы и ограничены маркерами изменений. Комментирование призвано облегчить понимание того, для чего изменения были выполнены. А маркеры изменений должны однозначно обозначать границы изменений – весь код, который располагается вне маркеров, должен быть типовым. Приведем в качестве примера несколько маркеров:

Пример маркеров 1Или

Пример маркеров 2

Особое внимание следует обратить на то, что открывающий и закрывающий маркеры должны различаться.

Как правило, в маркеры для удобства дополнительно добавляют информацию о:

  • Дате внесения изменений
  • Авторе изменений
  • Номере задачи, в соответствии с которой изменения были внесены
  • И т.п. информацию

А для формирования самих маркеров настраивают шаблоны текста.

Важным моментом является то, что в случае изменения или удаления типового кода он должен остаться на месте в исходном виде. Например:

Изменение или удаление типового кода

Не следует допускать следующих явлений:

  • Вкладывать один маркер изменений в другой
  • Располагать маркеры изменений непосредственно друг за другом (в этом случае должен быть один общий маркер)
  • Использовать маркеры изменений за пределами типовых модулей

Изменение форм

Частой ошибкой является подход, когда для модификации типовой формы создают ее копию, которую в последующем модифицируют под свои нужды. То же самое касается макетов, и даже целых документов. При таком подходе на обновляемости сразу можно ставить крест.

Если требуется модифицировать, скажем, форму документа «Заказ клиента», то изменяется именно типовая форма. Здесь можно пойти двумя путями:

  1. Либо изменить непосредственно саму форму в конструкторе, добавив новые или изменив типовые элементы формы
  2. Либо изменять форму программно в обработчике «ПриСозданииНаСервере»

На практике одинаково успешно применяются оба подхода, поскольку каждый из них имеет свои плюсы и минусы.

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

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

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

Изменение макетов

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

Здесь для печатных форм доступен замечательный механизм внешних печатных форм, позволяющий как изменять существующие, так и добавлять новые формы.

Для отчетов на системе компоновки данных (СКД):

  • Изменения запросов маркируются аналогично изменениям кода
  • Изменения структуры СКД можно выполнить в пользовательском режиме за счет настройки варианта отчета, либо же программно

Изменение ролей

Следует избегать какой-либо модификации типовых ролей, за исключением роли «ПолныеПрава». Особенно это касается ограничений доступа. Роли в «1С:ERP Управление предприятием 2» созданы по принципу атомарности и вполне позволяют подобрать в профиль пользователя требуемую конфигурацию.

Роли на добавленные объекты следует организовать аналогичным образом. Однако в ходе внедрения настройку ролей зачастую оставляют на последний этап. Поэтому вполне допустимо изначально создать минимально необходимое числе ролей, предоставляющих доступ к массивам объектов, с тем чтобы в последующем разбить их на атомарные роли.

Роль «ПолныеПрава» нуждается в модификации, поскольку изначально предоставляет все права на новые объекты, однако надо не забывать исключать право интерактивного удаления.

Изменения объектов метаданных

Добавление новых основных объектов метаданных, равно как и подсистем, ролей, общих модулей, общих макетов и форм, не является для последующего обновления какой-либо проблемой. Достаточно соблюсти следующие критерии:

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

Если возникает потребность нарастить реквизитный состав основного объекта, то можно пойти двумя путями:

  • Либо добавить реквизиты непосредственно в объект
  • Либо вынести реквизиты в отдельный, связанный с объектом регистр сведений

Второй подход имеет смысл в двух случаях:

  • Когда объект возможно и хочется оставить на полной поддержке
  • Когда состав добавляемых реквизитов широкий, но применяется для малого числа записей (элементов справочника, документов)

При необходимости изменить свойства реквизита, например, сделать его обязательным, изменить синоним, это вполне можно сделать непосредственно – функционал сравнения/объединения конфигураций корректно отображает и переносит данные изменения.

Что делать нельзя, так это удалять существующие реквизиты или сужать состав типов составного реквизита.

В качестве заключения

В статье рассмотрены основные принципы, соблюдение которых позволит сохранить внедренную систему обновляемой в короткие сроки и с минимальными ошибками. На практике, системы с высоким уровнем адаптации под клиента в ходе выполнения проектов, удавалось в последующем обновлять в течение суток с приостановкой работы исключительно на реструктуризацию таблиц базы данных.

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

Обсудить

Вас может заинтересовать

О бизнес-процессах, что такое BPM Разговаривать о процессном подходе, методологии BPM и нотации BPMN невозможно без понятия бизнес-процесса.
Законодательство РФ меняется достаточно быстро, за последнее время был принят ряд законов, оказывающих существенное влияние на деятельность предприятий в стране. Сложность быстрого реагирования на вносимые изменения обусловлена многими факторами:
В последних версиях продуктов на платформе «1С:Предприятие» правила обмена между типовыми конфигурациями выполнены с использованием технологии обмена через универсальный формат EnterpriseData. Тот факт, что подобные технологии начали включать в типовые конфигурации говорит о том, что именно в этом направлении будет происходить дальнейшее развитие технологий обмена данными между информационными базами.
Данная статья является размышлениями автора на тему необходимости, целесообразности и обоснованности применения автоматизированных тестов, чем погружением в то, как именно их применять.
Подсистема складского учета в программном продукте «1С.Комплексная автоматизация 2» позволяет работать с моделью ордерного склада и использовать адресную схему хранения. С ее помощью появляется возможность реализовать следующие требования:
right-arrow share search phone phone-filled menu filter envelope envelope-filled close checkmark caret-down arrow-up arrow-right arrow-left arrow-down