Для средних и крупных предприятий типовые конфигурации 1С часто требуют значительных доработок под особенности ведения различных видов учетов на данных предприятиях. Внесение большого числа изменений со временем ведет к значительному увеличению времени подготовки обновлений, а в ряде случает и невозможности обновлений таких конфигураций. Хорошо, если в такой базе ведется только, например, торговый учет, который менее чувствителен к изменению законодательства, но, если в одной базе ведется и полный бухгалтерский и налоговый учет с нормальным расчетом заработной платы, то картина становится менее радужной. Можно ли, все-таки, сохранить разумные трудо-временные затраты при обновлении таких баз? Я думаю, что это возможно при соблюдении некоторых рекомендаций при внесении изменений в конфигурации, хотя, рано или поздно, может возникнуть такая ситуация, когда придется переходить на новую версии базу, перенося остатки.
В этой статье хотелось бы обобщить личный опыт внесения изменений и быстрого определения этих изменений, а также познакомится с опытом коллег по будущим комментариям.
Соответствие требованиям «1С:Совместимо» позволяет получить хорошее представление о том что и как правильно нужно создавать в изменяемой конфигурации, чтобы потом любой другой программист мог легко разобраться в Вашем коде. Требование отсутствия в конфигурации неиспользуемых объектов, панелей инструментов, элементов меню и кнопок, только сознательная «раздача» права интерактивного удаления имеет очевидное значение. Именование объектов, процедур и функций, переменных должно отражать смысл их создания и т.п.. Требования 1С совместимости описывают разумные правила разработки новых и изменения имеющихся конфигураций, и несомненно с ними следует ознакомиться, даже если вы не планируете получать сертификат «1С:совместимо». Более чем 10-летний опыт внесения изменений в конфигурации 1С позволил выработать правила, неописанные в выше упомянутом документе, но используемые, думаю, многими опытными программистами 1С. Конечно, следует помнить, что любые правила не абсолютны.
Общие правила внесения изменений объектов конфигурации:
- создавать собственные объекты конфигурации, минимально изменяя типовые и предварительно изучив методику и работу типовых объектов;
- Вновь создаваем объектам, реквизитам, формам, макетам, значениям перечислений, предопределенным элементам и т.п., а также процедурам, функциям и переменным присваивать свой собственный префикс или постфикс, например, «гу» (мне больше нравится префикс);
- Не следует изменять порядок следования типовых объектов конфигурации, чтобы потом при обновлении конфигурации не получить неоправданно большой список измененных объектов, который придется внимательно просматривать;
- Не следует удалять типовые объекты конфигурации, элементы форм и табличных частей, элементы стиля, картинки и т.п.
- Доработки, касающиеся заполнения табличных частей желательно производить с помощью внешних обработок (для заполнения табличный частей) и подключать их к документам с помощью справочника «Внешние обработки»;
- Дополнительны печатные формы также правильно разрабатывать как внешние и подключать через справочник «Внешние обработки»;
Особенности изменения ролей (роли в 1С имеют приоритет доступа над запретом и доступ к объектам и реквизитам формируется через сложение набора предоставляемых ролей):
- По возможности не нужно изменять типовые роли, а лучше добавлять новые: либо на основе типовой и отразить это в имени роли, либо как дополнительную к уже имеющейся типовой роли, но «раздающую» права на добавленные нами объекты конфигурации;
- При настройке вновь создаваемых ролей лучше придерживаться правил создания ролей для типовых конфигураций – это установка галочек для роли «Устанавливать права для реквизитов и табличных частей по умолчанию» и «Независимые права подчиненных объектов», если у вас, конечно, нет каких-то ОЧЕНЬ весомых аргументов простив установки этих галочек. Если вы вдруг создаете свою роль с полными правами, то удобно установить галочку «Устанавливать права для новых объектов», НО следует помнить, что интерактивная роль «Интерактивное удаление» также будет устанавливаться для новых объектов по умолчанию (!) и ее нужно будет снять вручную.
- Бывает, что требуется забрать права на некоторые объекты у типовой роли, например, «Пользователь» - такие действия должны иметь серьезное обоснование и следует понимать, что это значительно увеличит время обновления ролей – нужно будет каждый раз сравнивать эту роль и вручную настраивать доступ по объектам. Как альтернатива предложенного решения можно рассмотреть создание, например, регистра сведений, по записям которого мы будем определять доступ к объектам конфигурации того или иного пользователя, но это требует написания значительного объема кода.
Особенности изменения интерфейсов:
- При изменении интерфейсов следует учитывать, что типовой механизм сравнения конфигураций не позволяет определить, что именно было изменено. Для пользователей с узким набором выполняемых функций лучше создавать свои интерфейсы.
- В случае, когда ни один из типовых интерфейсов не подходит пользователю для работы, то возможно создание нового путем копирования типового интерфейса и его настройки. Удобно в имени вновь созданного интерфейса отразить часть имени прототипа.
- Если требуется что-то вывести для всех пользователей базы, то можно создать дополнительный общий интерфейс и со своим подменю, в котором и будем размещать новые пункты.
Есть еще один способ решения для работы пользователей с ограниченным интерфейсом без изменения типовых – создание специализированных рабочих столов и панелей, но разработка подобного рабочего места может занять не один месяц.
Изменение форм:
Не следует изменять типовые формы, непосредственно изменяя элементы формы – очень многое можно легко добавить программно, обработчики новых элементов формы также могут быть описаны программно. В случае же, если форма требует значительных изменений и сделать их все программно становить ОЧЕНЬ сложно, то можно копированием создать свою форму добавив к ней, например, префикс «гу» и выбрав ее основной формой объекта. При этом удобно код типовой и вновь созданной форм держать одинаковым, а изменения на форме делать только для вновь созданной – это позволит снизить временные затраты при подготовке обновлений таких объектов.
Изменение макетов:
Не следует изменять макеты, нужно использовать механизм подключения внешних печатных форм, в крайнем случае просто добавить свой измененный макет как новый задав ему, например, префикс "гу".
Изменение подсистем:
Не нужно менять типовые подсистемы, можно только добавлять новые. Боевого опыта работы с конфигурациями, разработанными для управляемого приложения, пока нет – поэтому мое мнение может вполне совпасть с мнением сообщества.
Как вариант можно создать свою подсистему, не включенную в командный интерфейс, и вести в ней список измененных типовых объектов. Минус: потребуется время на ее актуализация, при постоянном отслеживании это время будет незначительным.
Изменение кода модулей:
Общеизвестно правило, что свой код нужно комментировать. Можно разработать собственные маркеры кода и разместить их в шаблонах текста. Пример:
//@@@ началоБлока
//Описание изменения
//
//@@@ Код до изменения: |
И шаблон комментирующий новый блок кода:
//@ Добавленный код:
//@@@ окончаниеБлока
Подобный шаблон удобен потому, что легко искать свои изменения по строкам «@@@» или имени пользователя, причем зная примерно год или месяц внесения изменений и добавив их с троку поиска легко получаем ссылки на измененные строки. Простановка даты в комментариях видится скорее плюсом – всегда легко определить период внесения изменений и в случае изменений методологии 1С для типовой конфигурации можно понять необходимость глубокого анализа ранее сделанных изменений.
Удобно сделать разные комментарии для нового кода и для измененного, отдельно обрамлять комментариями добавляемые процедуры и функции. Общие процедуры и функции следует выносить, по возможности, в свои, специально созданные, общие модули, именованные, например, с префиксом «гу». В типовые общие модули изменение нужно вносить по минимуму, желательно ограничиваясь только точкой входа во вновь созданные процедуры.
Для добавляемых процедур и функций удобно делать описание основного назначения и их передаваемых параметров. Блоки добавленного кода в типовых модулях нужно размещать в одном общем блоке, например, внизу и обрамлять общим комментарием в начале и конце общего блока.
Для частей кода, требующего доработки, и кода «заглушек» удобно придумать свой комментарий, по которому легко было бы находить эти строки, НО, как известно, ничего не бывает более постоянного, чем временное.
Обработчики событий изменить не всегда удастся, но возможно организовать перехват обработчиков событий форм с использованием оператора Выполнить (примерно как опсано здесь: http://kb.mista.ru/article.php?id=268). Конечно, потребуется написать код для организации такого перехвата, весь код может быть размещен в общем глобальном модуле с установленными флагами «Клиент» и «Глобальный». Процедуры перехвата событий правильно будет именовать как и процедуру самого события, только добавив, например, префикс «гу». Из опыта – затраты на написание такого перехвата окупают себя однозначно.
В результате соблюдения этих нехитрых правил нашу большую конфигурацию с двумя большими докупленными отдельно блоками и значительным изменениями кода под нужды предприятия возможна подготовка обновления за одну-две недели один программистом, который тратит на это примерно половину своего рабочего времени. При этом конфигурация остается обновляемой, что не мало, важно и является отраслевым решением на основе УПП.
Будет приятно получить отзывы сообщества, и надеюсь на ценные замечания, возможно что-то еще можно оптимизировать, о чем мы не догадались.
