Как правильно вносить изменения в типовые конфигурации 1С

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

Модификации типовых конфигураций я бы условно разделил на 3 группы:

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

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

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

Справочники, документы и регистры также могут существовать в конфигурации не мешая типовым объектам. Например, у вас возникла потребность автоматизировать планирование затрат организации в рамках конфигурации "Бухгалтерский учет". Вы создаете документ "Смета затрат", к нему регистр накопления и отчет по регистру. Этот функционал использует данные конфигурации (справочники "Статьи затрат", "Подразделения организаций", "Организации"), но он никак не нарушает работу типового функционала и не требует его изменения.

В общем, модификации первой группы - это "хорошие" модификации. Они дополняют функционал конфигурации и, в то же время, не мешают ее обновлению.

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

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

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

В качестве примера такой модификации можно взять случай, описанный ранее, когда создание альтернативного приходного документа в конфигурации "1С:Бухгалтерский учет 7.7" повлекло за собой необходимость изменения типовых объектов, отвечающих за формирование книги покупок (документы "Запись книги покупок", отчет "Книга покупок"). Хотя в том примере было сделано даже еще хуже - были созданные альтернативные документ и отчет.

К счастью, разработчики "1С:Предприятия" и типовых конфигураций понимают, что проблема обновления модифицированных конфигураций существует и требует решения. В последнее время немало сделано для того, чтобы потребность внесения изменений в типовые конфигурации возникала как можно реже. Конфигурации стали более гибкими. Например, в бухгалтерском учете документы раньше достаточно жестко были связаны со счетами. Добавление в плане счетов дополнительных субсчетов само по себе ничего не давало, если движения по этим субсчетам должны выполняться специальными документами. Приходилось вносить изменения в документы. Сейчас такая проблема практически отпала, поскольку документы обычно позволяют выбирать счета учета.

Тем не менее, поводов для внесения изменений пока еще достаточно. И это, в общем-то, не должно нас, программистов, сильно огорчать (вспоминаем тезис о палке о двух концах). Главное - вносить изменения правильно. Суть "правильности" изменений довольна проста и состоит в том, чтобы избегать модификаций типовых объектов и, по возможности, заменять их созданием новых объектов. Каким образом это можно сделать? Рассмотрим несколько инструментов, которые нам могут в этом помочь.

1. Внешние печатные формы. Печатные формы в типовых конфигурациях 1С всегда были какие-то "полузаполненные", что являлось (и является) предметов претензий со стороны пользователей. В ранних конфигурациях 1С печатные формы и процедуры их формирования были жестко связаны с конфигурацией. Чтобы дозаполнить форму, приходилось ломать документ. Появившийся позднее механизм подключения внешних печатных форм очень изящно решил проблему. Внешняя печатная форма, представляющая собой внешнюю обработку, созданную по определенным правилам, подключается к конфигурации. Пользователь пользуется ей так же, как встроенной.
2. Обработки табличных частей. Обработки табличных частей появились несколько позднее, чем внешние печатные формы. Технология их подключения и использования подобна внешним печатным формам. Это внешняя обработка, сделанная по определенным правилам и используемая, как следует из названия, для заполнения данными табличных частей документов и справочников. Такая возможность в ряде случаев оказывается достаточной, чтобы отказаться от изменения самого объекта. Следует отметить, что возможность подключения и использования обработок табличных частей и внешних печатных форм предоставляется типовыми конфигурациями, а не платформой "1С:Предприятие".
3. Подписки на события. Подписки на события - это общие объекты конфигурации. Они позволяют назначать обработчики для неинтерактивных событий одного или нескольких прикладных объектов. В качестве обработчика может быть задана экспортируемая процедура общего модуля, если модуль соответствует определенному набору условий. Мне лично пока не доводилось воспользоваться на практике возможностями механизма подписок на события. Но интуитивно я чувствую, что в некоторых случаях он может помочь избежать модификации объектов.
4. Разработка собственных подсистем. Если на каком-то участке учета вам катастрофически не хватает аналитики и функционала, скажем, для управленческих целей и напрашивается серьезная доработка типовых объектов, то можно подумать о разработке собственной небольшой подсистемы. Исходные данные для такой подсистемы обычно транслируются из типовых объектов. Причем это можно делать как оперативно, используя механизм ввода на основании, так и неоперативно, используя специальные обработки для трансляции данных. В собственной подсистеме затем уже можно доввести любую недостающую аналитику и использовать ее по своему усмотрению.

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

Ну, и в завершении - как обновлять релиз конфигурации после того, как часть ее объектов перестали быть типовыми. Если обновление релиза типовой конфигурации - процесс механический, сводящийся к нескольким щелчкам мышью, то обновление измененной конфигурации - процесс творческий. И я бы не доверил его никакому искусственному интеллекту. У меня достаточно богатый опыт обновления конфигурации "1С:Бухгалтерский учет" на платформе "1С:Предприятие 7.7". Я выработал для себя простую систему, которой готов поделиться с вами. Не претендую на истину в последней инстанции. Это всего лишь подход к решению задачи.

Итак, исходные данные: конфигурация Ai - типовая конфигурация i-го релиза; Aj - типовая конфигурация j-го релиза, причем j > i; Bi - модифицированная конфигурация, основанная на типовой конфигурации i-го релиза. Условие задачи: обновить конфигурацию Bi до релиза j, сохранив при этом все собственные наработки.

Теперь решение. С неизмененными объектами я поступаю очень просто - обновляю их простым замещением новыми объектами. С этим, думаю, все понятно, пояснений не требуется. С модифицированными объектами поступаю следующим образом. Сравниваю конфигурацию Ai с конфигурацией Aj. В окне сравнения конфигураций я вижу все изменения, сделанные разработчиком в новом релизе без учета собственных изменений, поскольку сравниваю "чистые" конфигурации. Далее в своей конфигурации Bi нахожу те участки кода, которые претерпели изменения в новом релизе. Обновления вношу, копируя их блоками из конфигурации Aj в конфигурацию Bi. Трудоемкость этой работы зависит от объема и сложности изменений в типовых объектах. Для меня такой подход наиболее безопасный и, в конечном итоге, наиболее эффективный.

Ну что же. Вот, пожалуй, все, о чем я хотел сегодня сказать. Есть вопросы? Пишите!