Краткая инструкция по внесению изменений в конфигурацию
Оглавление
Краткая инструкция по внесению изменений в конфигурацию
Порядок внесения изменения в разрабатываемую конфигурацию
Именование добавляемых объектов конфигурации
Включение объектов в служебные подсистемы
Создание или доработка Печатных форм, обработок, отчетов
Включение объектов в состав типовых подсистем командного интерфейса
Комментирование изменений в коде
Внесение изменений в общие модули
Внесение изменений в обработчики событий форм
Внесение изменений в обработчики событий объектов и менеджеров
Внесение изменений в состав источников типовых подписок на события
Постоянные значения конфигурации
Работа с хранилищем конфигурации
Рекомендации по базе разработки
Общие положения
При разработке руководствоваться рекомендациями с сайта ИТС 1С
- Методическая поддержка для разработчиков и администраторов
- Система стандартов и методик разработки конфигураций
Общие требования к написанию кода:
- При любом наборе входных данных программа не должна зацикливаться.
- При любом наборе входных данных программа не должна выдавать синтаксические ошибки.
- Доработка должна иметь какой-то «выход» - если она не нашла данные для обработки, то должна выдать соответствующее сообщение.
- В панель сообщений должны выводиться только «значащие» сообщения – то есть следующая информация:
- Сообщение о завершении обработки (в случае, если создается обработка, которая каким-то образом изменяет данные)
- Сообщения, которые требуют реакции пользователя.
- Информационные сообщения о невозможность обработать какие-то данные (например, не заполнен нужный реквизит в справочнике).
- Обработки, которые выполняются более 1 минуты ( обрабатывают большой массив данных ) должны выводить окно состояния выполнения, а процедура обработки должна быть выполнена с помощью фонового задания.
- Во всех доработках при использовании «связанных» справочников должна происходить их корректная обработка. Например, если на форме или в табличной части используются справочники «контрагент» и «договор контрагента», то при выборе другого контрагента (очистке реквизита «контрагент») должен быть очищен и договор контрагента. При выборе договора контрагента должен быть установлен отбор по его владельцу.
- Надо помнить, что если пользователю разрешено какое-то действие в системе, то программа должна уметь корректно это действие отработать. Например, если в документе разрешено вводить отрицательные значения в табличную часть, то эти значение должны быть записаны в регистры.
- Любые изменения конфигурации должны быть максимально реализованы с помощью Расширений конфигураций :
- В расширении нельзя использовать объекты, не поддерживаемые версией платформы, которая установлена в режиме совместимости Конфигурации.
- При расширении общих модулей и модулей объектов приоритетно использовать вариант расширения «После»
- Разные расширения должны иметь разные префиксы, чтобы избежать конфликтов совместимости расширений
Порядок внесения изменения в разрабатываемую конфигурацию
При разработке руководствоваться рекомендациями с сайта:
- Методическая поддержка для разработчиков и администраторов
- Система стандартов и методик разработки конфигураций
Так как наши внедрения рассчитаны на работу большого числа пользователей, то особое внимание обратить на разделы:
- Типичные причины избыточных блокировок и методы оптимизации
- Типичные причины неоптимальной работы запросов и методы оптимизации
- Реализация обработки данных
Именование добавляемых объектов конфигурации
Добавление новых объектов должно быть реализовано с помощью расширений конфигурации. При невозможности использовать расширения все добавляемые объекты конфигурации должны именоваться, начиная с префикса «ВашПрефикс_». К таким объектам относятся:
- Объекты метаданных (общие модули, справочники, документы, подсистемы и т.п.)
- Реквизиты объектов метаданных (включая: реквизиты, табличные части, измерения регистров, команды и т.п.)
Если добавляемый реквизит принадлежит уже добавленному объекту, имеющий префикс «ВашПрефикс_» то у таких реквизитов добавлять префикс не надо. - Предопределенные значения (включая: значения перечислений, предопределенные значения справочников и т.п.)
- Реквизиты форм
Если добавляется реквизит формы с колонками префикс устанавливается для самого реквизита формы, но не для его колонок.
- Элементы форм к типовым объектам необходимо добавлять динамически с помощью расширений. При невозможности добавления или изменения элементов формы с помощью расширений, изменение формы должно быть реализовано через код .
- Процедуры и функции
Если процедура/функция добавляется в модуль объекта/формы (или общий модуль), который уже имеет префикс «ВАШПРЕФИКС_», то в имени такой процедуры/функции префикс указывать не нужно.
Наименование добавляемых объектов должно иметь осмысленный синоним
В поле комментарий (добавляемых в конфигурацию объектов) должна содержаться следующая информация:
[Номер задачи], [Дата изменения]
Пример: Ф-037, 07.01.2020
Включение объектов в служебные подсистемы
В конфигурацию добавить подсистему «ВАШПРЕФИКС_Доработки». По желании с двумя подчинёнными подсистемами «НовыеОбъекты» и «ИзмененныеОбъекты», соответственно все новые объекты системы помещаются в них по правилу:
- все созданные новые объекты метаданных помещаются в «НовыеОбъекты»
- измененные объекты (даже если у типового объекта меняется форма) помещаются в «ИзмененныеОбъекты»
Создание или доработка Печатных форм, обработок, отчетов
Все доработки печатных форм создаются как «внешние», при необходимости переопределения стандартных команд, делаются соответствующие настройки уже в рабочей среде.
При создании или изменении отчетов системы, которые невозможно сделать настройкой варианта отчета. Создается внешний отчет и подключается к системе.
При создании обработок или модификации стандартных необходимо руководствоваться общим принципом – все, что можно надо делать внешними обработками, если это сделать нет возможности, то изменения вносятся с помощью расширений конфигурации
Включение объектов в состав типовых подсистем командного интерфейса
Если необходимо включить объект в состав типовой подсистемы командного интерфейса, то необходимо добавить в состав типовой подсистемы новую (если отсутствует) подсистему с префиксом «ВАШПРЕФИКС_». Дальнейшая настройка размещения объекта в командном интерфейсе должна выполняться в рамках добавленной подсистемы.
Комментирование изменений в коде
Изменения кода модулей должны реализовываться с помощью расширений модулей с вариантов процедуры «После» или «Вместо». Все изменения, вносимые в код модулей конфигурации должны обрамляться комментарием вида:
// + [Компания], [Программист] [Дата изменений]
// Задача: [Номер тех.задания или заявки], [Краткое описание изменений]
// Было:
// [закомментированный старый код]
// Стало:
[новый код]
// - [Компания], [Программист] [Дата изменений]
Например:
// + 1С, Иванов И.И. 07.01.2020
// Задача: Ф-037, Заполнение реквизитов формы по новому алгоритму
// Было:
// ПриЧтенииСозданииНаСервере();
// Стало:
ВАШПРЕФИКС_ПриЧтенииСозданииНаСервере();
// - 1С, Иванов И.И. 07.01.2020
Не нужно комментировать изменение, если код не типовой. Комментарий должны быть только для изменений относительно типового кода. При изменении ранее измененного куска кода необходимо изменить только дату изменения в комментарии.
Изменение ролей
Недопустимо изменение типовых ролей базовой конфигурации, при необходимости добавления/изменения настроек прав доступа, необходимо создать дополнительную роль с префиксом «ВАШПРЕФИКС_» и выполнить необходимые настройки прав для нее.
Если функционал, для которого настраиваются права доступа, имеет аналоги в базовой конфигурации, то рекомендуется создавать новые роли путем копирования существующих и затем настраивать в них права по аналогии с существующим функционалом.
В дальнейшем допускается модификация созданных ролей при необходимости.
Также при создании ролей необходимо придерживаться принципа «атомарности» ролей, т.е. не рекомендуется смешивать в одной роли права на не связанный друг с другом по смыслу функционал.
Назначение прав пользователей должно выполняться с использованием функционала профилей доступа из библиотеки стандартных подсистем.
Внесение изменений в общие модули
Если необходимо внести изменения в общие модули, то по возможности следует вносить изменения только в модули с суффиксом «*Переопределяемый».
Внесение изменений в обработчики событий форм
При необходимости внесения изменений в поведение обработчиков событий типовой формы, такие изменения необходимо вносить в общих модулях:
- МодификацияКонфигурацииВызовСервераПереопределяемый
- МодификацияКонфигурацииКлиентПереопределяемый
- МодификацияКонфигурацииКлиентСерверПереопределяемый
- МодификацияКонфигурацииПереопределяемый
в соответствующих процедурах-обработчиках.
При этом рекомендуется в процедурах обработчиках прописывать только вызовы процедур-обработчиков, добавленных в новые общие модули.
Добавление процедур необходимо реализовать в соответствующих расширениях, в которых уже расширен модуль.
Внесение изменений в обработчики событий объектов и менеджеров
В общем случае не допускается внесение изменений в типовые обработчики событий объектов и менеджеров.
Для таких изменений необходимо создавать соответствующие подписки на события.
Внесение изменений в состав источников типовых подписок на события
В общем случае не допускается внесение изменений в состав источников типовых подписок на события.
Вместо изменения типовой подписки необходимо:
- Создать новую подписку (можно скопировать существующую) с наименованием «ВАШПРЕФИКС_[ИмяТиповойПодписки]»
- Указать в качестве источника те объекты, которые необходимо добавить
- В качестве обработчика указать ту же процедуру, что и в типовой подписке или ссылаться на новую процедуру ( в которой будет ссылка на типовую).
Постоянные значения конфигурации
В коде конфигурации недопустимы прямые ссылки на наименования, коды и т.п. данных ИБ.
В большинстве случаев, когда требуется хранить и определять ссылку на условно-постоянные или постоянные данные, или набор данных в системе будет использоваться справочник «ВАШПРЕФИКС_НастройкиЗначений» (или Регистр сведений). Данный справочник будет состоять из элементов, с реквизитом «Имя для разработчика», по которому будет выполняться поиск элемента в коде (поиск реализовать через функцию модуля менеджера справочника). В режиме предприятия у каждого элемента можно будет задать значение или список значений (за счет наличия у элемента реквизита и ТЧ) в дальнейшем использовать значение элементов в коде программы.
Новые значения в Справочник.рздСпецНастройки описать и запрограммировать создание в форме списка справочника в команде [Заполнить по умолчанию].
Значение получать через Общий модуль повторного использования (На время сеанса) ОбщийМодуль.рздСпецНастройки.ПолучитьЗначение(...) по реквизиту ИмяДляРазработчика. И в самом справочнике ПриЗаписи обновляем кеш, если создается или меняется элемент ОбновитьПовторноИспользуемыеЗначения();.
Например: «Основной склад», «Направление деятельности по умолчанию», «Список приоритетных пользователей», «Дата перехода на новую номенклатуру» и т.п.
Работа с хранилищем конфигурации
Разработка ведется с использованием технологии хранилища конфигурации. С ней необходимо ознакомиться на сайте: http://its.1c.ru/db/metod8dev#content:2287:hdoc
При необходимости захвата коренного объекта хранилища, его необходимо удерживать как можно меньше.
При помещении изменений в хранилище не допускается помещать не работающий код или не компилируемую конфигурацию. Пример: помещение новой подписки на событие с не назначенной процедурой обработки события.
Рекомендуется при помещении измененных объектов в хранилище в соответствующем диалоге конфигуратора указывать в комментарии краткое описание характера изменений с точки зрения пользователя.
Создать общий чат разработчиков для решения вопросов захвата объектов.
Рекомендации по базе разработки
Разработку приоритетно вести в клиент-серверной базе. При разворачивании базы для разработки необходимо установить Блокировки регламентных заданий и/или отключить регламентные задания.
Ссылка на компетенции по 1С:ERP - команда со знаниями, умениями и успешными проектами.
