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

Основные принципы при внедрении КИС.

Организационные мероприятия

1. Снабдить пакетами типовой документации отделы, в которых проходит внедрение.
2. Необходима схема документооборота внутри каждого отдела с ответственными за каждый документопоток.

Модификация типовых решений (Конфигурирование)

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

Прежде чем браться за Конфигуратор, специалист должен задать себе два вопроса:

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

И только если ответом будет «нет, нельзя», необходимо задать себе третий вопрос:

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

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

Можно выделить несколько универсальных правил, следование которым позволит существенно облегчить жизнь разработчику (фирме франчайзи).

1)      Использовать механизм подсистем. Перед тем как приступить к внесению в конфигурацию изменений и доработок, необходимо создать корневую подсистему НовыеФункции и две подчиненные подсистемы МодифицированныеОбъекты и НовыеОбъекты (имена подсистем, разумеется, могут быть любыми). К первой из подчиненных подсистем следует отнести все объекты прикладного решения, которые в ходе работ подверглись модификации, ко второй — объекты, которые были добавлены в конфигурацию. Для чего это нужно? Это позволит в любой момент (в том числе и при сравнении и объединении с новой конфигурацией поставщика) быстро выделить из конфигурации все объекты, которые были изменены или добавлены.

2)      Использовать префиксы в именах добавляемых объектов. Имя любого объекта, добавляемого в конфигурацию, должно начинаться с префикса (например, мы хотим добавить регистр сведений для хранения информации о прогнозе погоды, он должен получить имя вида преф_ПрогнозПогоды). Разумеется, в синонимах объектов никаких префиксов не требуется. Для чего это нужно? Мы получаем гарантию, что имена «наших» объектов и имена объектов, добавляемых в конфигурацию поставщиком, ни при каких обстоятельствах не совпадут. Это правило применяется абсолютно ко всем объектам, свойствам и реквизитам, в том числе и к подсистемам.

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

4)      Не модифицировать роли (наборы прав доступа), созданные поставщиком. С ролями нужно поступать так же, как с экранными формами: либо вносить изменения только в скопированные объекты поставщика, либо создавать свои собственные. Изменить набор ролей, доступных конкретному пользователю информационной базы, намного проще, чем проверить и восстановить десяток опций доступа для нескольких сотен объектов конфигурации.

5)      Не вносить никаких изменений в те обработчики объектов, к которым можно получить доступ через механизм подписки на события. Например, если требуется изменить логику формирования движений документа (скажем, добавить движения по вновь созданным регистрам накопления), не нужно модифицировать код модуля документа. Вместо этого необходимо создать новую подписку на событие, в качестве источника указать искомый документ и событие ОбработкаПроведения, а управляющий движениями документа код поместить в привязанный к подписке обработчик. Для чего это нужно? При установке обновлений поставщика не придется забивать себе голову настройкой режима объединения модулей объектов, а после обновления рыскать по обновленным модулям в поисках волшебного ключевого слова «//{{MRG[».

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

7)      Использовать: Внешние отчеты, Внешние обработки, Внешние печатные формы

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

Основные принципы поддержки и доработки прикладных тиражных конфигураций «1С:Предприятие 8». Итак:

* если есть возможность вообще обойтись без внесения изменений в типовую конфигурацию, ее нужно использовать. «Изменения ради изменений» — верный путь к проблемам;

* если все-таки требуется изменить типовую конфигурацию, нужно постараться спроектировать решение таким образом, чтобы объекты типовой конфигурации остались нетронутыми. Не стоит брать в руки скальпель без веской на то причины;

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

АВТОР: Никита Зайцев Дата публикации: 19.05.2008

Материал переработал: Фасоля Олег  Дата публикации: 27.08.2009

http://pcmag.ru/solutions/detail.php?ID=15107

Дополнение.

Демонстрационная конфигурация "Библиотека стандартных подсистем" – является Образцом:

1. разработки объектов конфигурации
2. назначения свойств объектам конфигурации
3. оформления модулей (стилистика исходного кода, оформление комментариев)
4. нетиповую конфигурацию необходимо начинать разрабатывать на базе конфигурации "Библиотека стандартных подсистем"

Технологические вопросы крупных внедрений – позволят реализовать оптимальное решение по производительности.

http://kb.1c.ru/

Стандарты с диска ИТС: «Система стандартов и методик разработки конфигураций для платформы 1С:Предприятие 8»

Материал дополнил: Фасоля Олег  Дата публикации: 29.10.2011