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

Обновление в режиме «поддержка с возможностью изменения» выполняется путем сопоставления двух конфигураций: основной конфигурации информационной базы (в которую пользователь вносил изменения непосредственным редактированием объектов метаданных) и конфигурации поставщика (в которую внес изменения поставщик при помощи файла поставки обновления). При сопоставлении этих двух конфигураций механизм обновления руководствуется правилами поддержки конфигурации. Что это за правила и как они работают? Правила поддержки настраиваются пользователем отдельно для каждого объекта метаданных. Существует три режима поддержки объекта метаданных:

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

2) «объект поставщика редактируется с сохранением поддержки». В этом режиме пользователь может вносить в объект любые изменения. При обновлении конфигурации для такого объекта необходимо вручную настроить правила обновления: пользователь должен явно указать, какие именно изменения, сделанные поставщиком, необходимо принять для объекта;

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

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

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

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

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

Поставщиком конфигурации может быть не только фирма «1С». Классификация тиражных решений.

1) Типовые решения, разработчиком которых является фирма «1С».

2) Отраслевые решения, построенные на базе типовых конфигураций «1С». Разработчиком таких конфигураций являются фирмы-партнеры «1С».

3) Отраслевые решения, построенные «с нуля», разработчиком которых также являются фирмы- партнеры «1С».

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

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

Каждый специалист, работающий с платформой «1С: Предприятие 8», не раз слышал и не раз сам повторял аксиому: «Бывают типовые конфигурации, но не бывает типовых предприятий». Это действительно так, но отнюдь не означает, что на любое требование конечного пользователя у специалиста должен мгновенно срабатывать рефлекс «хватай и кодируй». Прежде чем браться за Конфигуратор, специалист должен задать себе вопрос (мы исходим из предположения, что требования конечных пользователей взяты не с потолка, как это иногда случается, а обоснованы производственной необходимостью и спецификой