gifts2017

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

Опубликовал Melis Kim (melis) в раздел Программирование - Практика программирования

Способы минимизации трудозатрат на обновление нетиповых конфигураций, созданных на основе типовых

Для средних и крупных предприятий типовые конфигурации 1С часто требуют значительных доработок под особенности ведения различных видов учетов на данных предприятиях. Внесение большого числа изменений со временем ведет к значительному увеличению времени подготовки обновлений, а в ряде случает и невозможности обновлений таких конфигураций. Хорошо, если в такой базе ведется только, например, торговый учет, который менее чувствителен к изменению законодательства, но, если в одной базе ведется и полный бухгалтерский и налоговый учет с нормальным расчетом заработной платы, то картина становится менее радужной. Можно ли, все-таки, сохранить разумные трудо-временные затраты при обновлении таких баз? Я думаю, что это возможно при соблюдении некоторых рекомендаций при внесении изменений в конфигурации, хотя, рано или поздно, может возникнуть такая ситуация, когда придется переходить на новую версии базу, перенося остатки.

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

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

 

Общие правила внесения изменений объектов конфигурации:

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

 

Особенности изменения ролей (роли в 1С имеют приоритет доступа над запретом и доступ к объектам и реквизитам формируется через сложение набора предоставляемых ролей):

  • По возможности не нужно изменять типовые роли, а лучше добавлять новые: либо на основе типовой и отразить это в имени роли, либо как дополнительную к уже имеющейся типовой роли, но «раздающую» права на добавленные нами объекты конфигурации;
  • При настройке вновь создаваемых ролей лучше придерживаться правил создания ролей для типовых конфигураций – это установка галочек для роли «Устанавливать права для реквизитов и табличных частей по умолчанию» и «Независимые права подчиненных объектов», если у вас, конечно, нет каких-то ОЧЕНЬ весомых аргументов простив установки этих галочек. Если вы вдруг создаете свою роль с полными правами, то удобно установить галочку «Устанавливать права для новых объектов», НО следует помнить, что интерактивная роль «Интерактивное удаление» также будет устанавливаться  для новых объектов по умолчанию (!) и ее нужно будет снять вручную.
  • Бывает, что требуется забрать права на некоторые объекты у типовой роли, например, «Пользователь» - такие действия должны иметь серьезное обоснование и следует понимать, что это значительно увеличит время обновления ролей – нужно будет каждый раз сравнивать эту роль и вручную настраивать доступ по объектам. Как альтернатива предложенного решения можно рассмотреть создание, например, регистра сведений, по записям которого мы будем определять доступ к объектам конфигурации того или иного пользователя, но это требует написания значительного объема кода.

 

Особенности изменения интерфейсов:

  • При изменении интерфейсов следует учитывать, что типовой механизм сравнения конфигураций не позволяет определить, что именно было изменено. Для пользователей с узким набором выполняемых функций лучше создавать свои интерфейсы.
  • В случае, когда ни один из типовых интерфейсов не подходит пользователю для работы, то возможно создание нового путем копирования типового интерфейса и его настройки. Удобно в имени вновь созданного интерфейса отразить часть имени прототипа.
  • Если требуется что-то вывести для всех пользователей базы, то можно создать дополнительный общий интерфейс и со своим подменю, в котором и будем размещать новые пункты.

Есть еще один способ решения для работы пользователей с ограниченным интерфейсом без изменения типовых – создание специализированных рабочих столов и панелей, но разработка подобного рабочего места может занять не один месяц.

 

Изменение форм:

Не следует изменять типовые формы, непосредственно изменяя элементы формы – очень многое можно легко добавить программно, обработчики новых элементов формы также могут быть описаны программно. В случае же, если форма требует значительных изменений и сделать их все программно становить ОЧЕНЬ сложно, то можно копированием создать свою форму добавив к ней, например, префикс «гу» и выбрав ее основной формой объекта. При этом удобно код типовой и вновь созданной форм держать одинаковым, а изменения на форме делать только для вновь созданной – это позволит снизить временные затраты при подготовке обновлений таких объектов.

 

Изменение макетов:

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

 

Изменение подсистем:

Не нужно менять типовые подсистемы, можно только добавлять новые. Боевого опыта работы с конфигурациями, разработанными для управляемого приложения, пока нет – поэтому мое мнение может вполне совпасть с мнением сообщества.

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

 

Изменение кода модулей:

Общеизвестно правило, что свой код нужно комментировать. Можно разработать собственные маркеры кода и разместить их в шаблонах текста. Пример:

//@@@   началоБлока

//Описание изменения

//

//@@@ Код до изменения: |

 

И шаблон комментирующий новый блок кода:

//@ Добавленный код:

 

//@@@  окончаниеБлока

 

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

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

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

Для частей кода, требующего доработки, и кода «заглушек» удобно придумать свой комментарий, по которому легко было бы находить эти строки, НО, как известно, ничего не бывает более постоянного, чем временное.

Обработчики событий изменить не всегда удастся, но возможно организовать перехват обработчиков событий форм с использованием оператора Выполнить (примерно как опсано здесь: http://kb.mista.ru/article.php?id=268). Конечно, потребуется написать код для организации такого перехвата, весь код может быть размещен в общем глобальном модуле с установленными флагами «Клиент» и «Глобальный». Процедуры перехвата событий правильно будет именовать как и процедуру самого события, только добавив, например, префикс «гу». Из опыта – затраты на написание такого перехвата окупают себя однозначно.

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

Будет приятно получить отзывы сообщества, и надеюсь на ценные замечания, возможно что-то еще можно оптимизировать, о чем мы не догадались.

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Александр Лыткин (TrinitronOTV) 09.04.13 06:40
Спасибо большое автору, очень полезная информация для меня, как начинающему осваивать новую платформу
2. Александр (aet) 09.04.13 06:48
Из отличий от подобных публикаций заметил только упоминание 1С:Совместимо.
Еще забыта Система стандартов и методик разработки конфигураций.
3. Tsaregorodtsev (TSSV) 09.04.13 08:10
При изменении интерфейсов следует учитывать, что типовой механизм сравнения конфигураций не позволяет определить, что именно было изменено. Для пользователей с узким набором выполняемых функций лучше создавать свои интерфейсы.


Хочу обратить Ваше внимание на методику получения более подробной информации о различии объектов при сравнении / объединении с помощью отчета о сравнении объектов. Методика описана в статьеhttp://infostart.ru/public/180040/ С помощью нее все же можно получить кое - какую дополнительную информацию о том, что конкретно было изменено в интерфейсе, но не всю что хотелось бы.
help1Ckr; wowik; MarSeN; +3 Ответить
4. Melis Kim (melis) 09.04.13 15:30
Да, есть, но изменения (и особенно, если их много) неудобно анализировать, как и изменения формы.... А так, спасибо за замечания... И за ссылку aet спасибо, написано много, но, почему-то, когда начинают вносить изменения о многих вещах забывают, мы у себя часть правил решили регламентом закрепить - есть уже результат: база до 2011 года имела даже меньше изменения, но была уже в необновляемом состоянии.
5. Жорж Милославский (Жорж) 10.04.13 02:56
Обработчики событий изменить не всегда удастся, но возможно организовать перехват обработчиков событий с помощью оператора Выполнить. Конечно, потребуется написать код для организации такого перехвата, весь код может быть размещен в общем глобальном модуле с установленными флагами «Клиент» и «Глобальный». Процедуры перехвата событий правильно будет именовать как и процедуру самого события, только добавив, например, префикс «гу». Из опыта – затраты на написание такого перехвата окупают себя однозначно.

Не совсем понятно. Можно подробнее?
6. Melis Kim (melis) 10.04.13 06:11
(5) Жорж, хорошо - добавлю в статью в ближайшее время описание как мы сделали...
http://kb.mista.ru/article.php?id=268
7. Александр (МимохожийОднако) 10.04.13 06:57
Статья понятна. Однако более интересна практика и примеры. А еще лучше расписать задачку по каждой темке и возможный алгоритм решения.
8. Сергей Марченко (MarSeN) 10.04.13 09:29
(5) Жорж
Вот статья где опубликовано решение при котором всегда можно перехватить и переопределить все обработчики формы http://infostart.ru/public/171514/
(0) melis
"... перехват обработчиков событий с помощью оператора Выполнить..."
Не подскажете каким образом можно "перехватить" выполнение процедуры, да и еще вне контекста формы. Думаю что вы ошиблись в пояснении
9. Денис (Den_D) 10.04.13 10:05
Такие статьи тут уже были, по этому не вижу различия.
10. Дмитрий Глеков (glek) 10.04.13 10:43
С созданием "своей" формы - не согласен. Если, изменив штатную форму, есть шанс вычислить, что менялось, то "создав" свою форму - такая возможность теряется. Таким образом, или менять диалог програмно, или с помощью мышки, но менять надо штатную форму.
11. Юленька (s_uu) 10.04.13 11:48
Спасибо за статью. С картинками было бы понятнее!
12. Melis Kim (melis) 10.04.13 11:51
(10) glek, Свои формы однозначно созданы, например, для элемента справника договоры для размещения болка "Управление договорами", плюс еще добавлены закладки "Связанных договоров", "Доп.соглашений" и реализовано хранение истории по плановым, фактическим, календарным, датам различных оплат по авансам м резервам - форма получается ОЧЕНЬ сложной, и каждый раз при обновлении проще сравнить изменения внесенные разработчиками на типовую форму... Кончно это нужно делать без фанатизма - если требуется добавить небольшое количестов реквизитов - то это можно сделать программно, не создавая дубля формы.
13. Melis Kim (melis) 10.04.13 11:55
(8) MarSeN, имелись ввиду обработчики событий форм... Понятно, что, например, обработку при проведении не перехватываем... просто организуется точка входа для выполения нетиповго кода.
14. aspirator 23 (aspirator23) 14.04.13 16:05
Статью прочитал. Так и не понял, что такое "гу"?
15. Melis Kim (melis) 15.04.13 08:03
(14) aspirator23, - "гу" просто такой префикс.... Чаще всего префикс отражает название предприятия или компании-внедренца
16. Анна Денисова (aimerlive) 15.04.13 15:18
спасибо за статью. правила которым нужно следовать но они часто забываются. особенно если надо быстро что от сделать.
17. dmb2006vesna (for_sale) 25.04.14 09:00
Про подсистемы не согласен.
Вернее, для обычного приложения согласен, а для управляемого - подсистемы используются для отображения элементов в интерфейсе, поэтому зачастую требуется впихнуть свой отчёт или документ куда-то среди типовых и добавленными подсистемами тут не отделаться. Как вариант можно создавать свою подчинённую подсистему, чтобы состав типовой не изменять.
18. Елена Пименова (Bukaska) 25.04.14 10:07
(14) aspirator23, Например например вы работаете в автопрарке, и чтобы не менять типовой документ, вы создаете свой с именем АПМойДокумент(насколько я знаю, имена переменных не должны совпадать, а добавление типа префикса решает данную проблему)
19. Елена Пименова (Bukaska) 25.04.14 10:15
(5) Жорж, Например, вам нужно поменять процедуру при открытии документа, наприммер Реализация товаров услуг
ВЫ вместо того чтобы перепиливать модуль документа(чтобы не мучаться потом с обновлением) делаете так:
Создаете свой модуль с галками сервер и вызов сервера(чтобы можно было обратиться с клиента)
делаете процедуру в данном модуле ПриОткрытии()
После чего создаете подписку на событие, где ставите свой нужный документ(для которого надо обработчик), и указываете обработчик, который у вас в вашем общем модуле)
PS: У общего модуля для данных целей ОБЯЗАТЕЛЬНО должна быть галка сервер, чтобы вы могли выбрать данный обработчик для нужного объекта.
Как всегда, итог, что лучше по вашему?
Перепиленные модули объектов, где каждое изменение ищешь по "MRG" или же когда у вас в изменениях один общий модуль и подписка(которая не сносится)
В основном рекомендуется так... чтобы не мучаться с перепиливанием объектов)))
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа