<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» созданы по принципу атомарности и вполне позволяют подобрать в профиль пользователя требуемую конфигурацию.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обсудить

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

Потребность в адаптации программного обеспечения под конкретного клиента появилась, наверное, одновременно с самим программным обеспечением.
В AX есть широкий пул функций, касающихся управления изменениями. В заказах на покупку и заказах на продажу, в отдельном модуле по управлению продуктами и т.д., но со спецификациями используется несколько иной подход.
Каждый человек, причастный к бизнесу, привык ассоциировать продукты 1С с такими словами, как «простота», «доступность», «бухгалтерия». И они полностью соответствовали разработкам компании… лет пятнадцать назад. Сегодня 1С выводит на IT-рынок продукты очень высокого качества. Сомневаетесь? Мы развеем ваше недоверие.
В данной статье мы подробно рассмотрим, какие преимущества для бизнеса дает внедрение системы планирования производства DELMIA Ortems для компаний-производителей изделий из пластмассы.
Любая компания, перед которой встает задача по внедрению 1С:ERP, сталкивается с необходимостью сформировать план запуска - в этой статье мы осветим «best practices», полученные на основе реализации множества успешных проектов.
right-arrow share search phone phone-filled menu filter envelope envelope-filled close checkmark caret-down arrow-up arrow-right arrow-left arrow-down