gifts2017

Советы по внесению изменений в типовые конфигурации 1С

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

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

Сокращения:
УП - Управляемое Приложение
ОП - Обычное Приложение
ТЧ - Табличная Часть
РН - Регистр Накопления
ПФ - Печатная Форма

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

  • Подписки на события
  • Внешние обработки
  • Внешние обработки заполнения ТЧ
  • Внешние отчеты
  • В ОП Свойства / категории / характеристики
  • В УП "дополнительные реквизиты" и "дополнительные сведения"

* УТ 10.3 Клиент решил использовать значения точки заказа для установки минимальных остатков номенклатуры, но пугается процесса установки значений точки заказа для каждого элемента по каждому складу.
Простое решение. Это случай из практики. Программист снимает всю конфигурацию с поддержки. Добавляет ТЧ "Остатки" в справочник "Номенклатура", назначает использование "Для группы". Модифицирует форму группы, выводя на неё эту ТЧ с колонками "Склад" и "Минимальный остаток". Кроме того создаётся отчёт, который показывает, для номенклатуры по каждому складу установленный минимальный остаток, фактический остаток на дату выдачи отчёта и необходимое количество к заказу (отклонение).
Результат. Это решение не предусматривает разные остатки номенклатуры в одной группе, не реализует возможность формирования заказов поставщикам. Самое интересное - с поддержки снята вся конфигурация целиком. Даже если бы программист приложил мозговые усилия, пришлось бы снимать с поддержки справочник номенклатуры и его форму группы.
Более оптимальное решение. Пример не типичный в том, что показывает не только разные способы реализации, но и разный уровень знания конфигурации. Итак, у нас есть стандартный механизм установки значений точки заказа - одноимённый документ и отчёт "Анализ точки заказа", в котором есть кнопка "Сформировать заказы". Выходит, надо всего лишь оптимизировать процесс заполнения ТЧ документа "Установка значений точки заказа". Сначала пытаемся создать внешнюю обработку заполнения ТЧ документа, но из кода документа следует, что внешние обработки заполнения ТЧ он не поддерживает. Ок, создаём внешнюю обработку, куда интегрируем механизм произвольных отборов на базе построителя отчётов и табличное поле для вывода результата. Отборы работают с запросом, который выдаёт нужную номенклатуру по нужному складу с текущими значениями точки заказа. Т.о. мы предоставляем пользователю мощный механизм любых отборов. Осталось только добавить функции групповой установки для отобранных позиций значений колонок "Склад" и "Точка заказа". Завершаем всё кнопкой "Создать документ", по нажатию которой создаётся и заполняется стандартный документ "Установка значений точки заказа".
Результат. Ни один объект не снят с поддержки. Задействован стандартный и мощный механизм работы с точкой заказа: теперь клиент может не только формировать отчёт по текущему состоянию дел, но и производить из него заказ позиций в необходимом количестве на нужные склады.
Тут стоит ещё пояснить, что в форме "Настройка поддержки" можно включать редактирование не только для конфигурации целиком, как это часто делают, но и для конкретных объектов выборочно. Для создания новых объектов необходимо перевести в режим "Редактирование с сохранением поддержки" саму конфигурацию (корневой элемент), но без подчинённых.

* УТ 10.3 Необходимо, чтобы документ "Чек ККМ" проводился по продажам. Стандартно это делает документ "Отчет о розничных продажах", собирающий в себя все чеки ККМ за смену.
Простое решение. Переводим в режим "Редактирование с сохранением поддержки" РН "Продажи" и документ "Чек ККМ". Добавляем его регистратором к РН "Продажи" и в обработчик проведения добавляем код формирования движений по этому регистру.
Результат. Каждый раз при обновлении конфигурации придётся переносить в новую версию модуля документа свой код.
Более оптимальное решение. Перевести в режим "Редактирование с сохранением поддержки" регистр и документ всё же придётся для добавления его в регистраторы РН "Продажи". Создаём подписку на событие "При проведении" документа "Чек ККМ". Создаём общий модуль, в котором реализуем обработчик подписки. В обработчике пишем код для движений по РН "Продажи". Теперь при каждом обновлении можно смело обновлять и документ, и РН, не забывая перед тем как нажать F7, добавить документ "Чек ККМ" в регистраторы регистра.

* Изменить роль "МенеджерПоПродажам".
Простое решение. Снимаем роль с поддержски и вносим в неё изменения.
Результат. Роли - достаточно часто изменяемый объект и теперь каждый раз при обновлении надо ручками вносить в неё нужные изменения.
Более оптимальное решение. Создаём копированием новую роль. Вносим в неё изменения и назначаем пользователям вместо оригинальной.
Результат. Теперь обновления можно смело накатывать, не забывая в конце сверить роли в механизме "Все роли". Даже если полениться и не сделать этого, мы просто не получим доступа к какому-нибудь новому объекту, но старый функционал вероятнее всего будет работать.
С интерфейсами дело обстоит аналогичным образом.

* УТ 10.3 Необходимо модифицировать рабочее место кассира. РМК является формой документа "Чек ККМ".
Простое решение. Снимаем с поддержки документ "Чек ККМ" и форму "ФормаРегистрацииПродаж". Вносим в неё изменения.
Результат. Документ стал необновляемым даже в полуавтоматическом режиме - надо вручную интегрировать изменения в эту форму.
Более оптимальное решение. Снимаем с поддержки сам документ и его форму. Да, это уже второй описываемый случай, когда в оптимальном решении вроде бы снимаются с поддержки те же объекты. Смотрите дальше. Снимаем с поддержки мы эту форму для того, чтобы переименовать. Зачем? Из глобального модуля есть обращение по имени формы в случае, если у пользователя установлен интерфейс и роль кассира.
Называем её "ФормаРегистрацииПродажСтарая". Копированием создаём форму и называем её старым именем "ФормаРегистрацииПродаж". Вносим в неё изменения.
Результат. Напротив старой формы остался квадратик поддержки с возможностью внесения изменений. Это означает, что при обновлении конфигурации платформа всё равно определит соответствие форм, хоть мы её и переименовали. Смело обновляем документ целиком.

* УТ 10.3, КА и прочие конфигурации на ОП. Необходимо создать механизм для учёта пола контрагентов (М/Ж).
Простое решение. Снимаем с поддержки справочник "Контрагенты" и его форму элемента. Добавляем перечисление "Пол" со значениями "М" и "Ж", добавляем реквизит "Пол" с типом свежесозданного перечисления в справочник. Выводим его на форму.
Результат. Снят с поддержки частообновляемый справочник "Контрагенты". Теперь каждое обновление придётся интегрировать ручками.
Более оптимальное решение. А на что нам дан механизм свойств? Создаём свойство "Пол" с типом "Значения свойств объектов", создаём значения "М" и "Ж".
Результат. Несколько действий в режиме пользователя, без внесения каких-либо изменений. Если клиент будет настаивать на отображении свойства в форме элемента, то необходимо будет по аналогии с предыдущим примером перевести в режим "Редактирование с сохранением поддержки" справочник "Контрагенты". Далее создать новую форму элемента копированием (старую оставим как есть на поддержке) и назначить её формой элемента. Я не обнаружил среди общих модулей функции, возвращающей значение свойства для объекта и в новом общем модуле реализовал её. Теперь на форме смело размещаем поле со списком или обычное поле с кнопкой выбора из списка - кому как удобней и при открытии формы заносим в список значений все значения свойства и устанавливаем текущее его значение. А при записи формы записываем выбранное значение. Это кажется сложнее, но как я уже замечал, новая форма - сторонний объект, который никак не задевает процесс обновления конфигурации. Максимум что может случиться, если в новом релизе в форме реализованы какие-либо новые механизмы, а вы обновляете конфигурацию с закрытыми глазами, то вы просто пропустите этот новый механизм, который в любой момент позже сможете добавить.

Почему более простые в реализации решения не так просты на самом деле? Нередко встречаю типовые конфигурации, сильно модифицированные и с релизами полутора-двухгодичной давности. Иногда даже с избирательной реализацией ручками каких-либо стандартных механизмов, которые появились в более поздних релизах. Как такое произошло? А всё очень просто. Программист без оглядки на будущее ломится снимать всё с поддержки и модифицировать. Через месяц ему говорят - "вышла новая версия со счетами-фактурами по постановлению 1137, которой мы так ждали; давай нам ПФ этого образца". Программер, если сильно прижмут, делает внешнюю печатную форму ручками и прилепляет к старому релизу. Так с годами изменений в типовой конфигурации накапливается целый вал и программеру машут рукой.

Уверен, не все мной предложенные решения являются наиболее оптимальнымы. Буду чуток к комментариям.

См. также

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

Комментарии

1. Константин - (Kosstikk) 05.09.13 09:01
а. Проектирование может быть разным.
б. Оптимальность проектирования оценивается по разным параметрам.

Что касается внесения изменений в типовую конфигурацию:

1. Либо совсем не вносим, используя внешние обработки/отчеты, допреквизиты, допсвойства, и обновляемся по типовому.
2. Либо вносим и обновляемся с небольшими затратами.

Если вариант 2 - то принципиальны только те места, которые приносят трудности при обновлении, и как правило больше всего трудностей приносят изменения в имеющемся функционале, а не добавленные объекты метаданных, добавленные реквизиты и т.д.
При первом варианте так или иначе контролировать совместимость ваших доработок придется, т.к. меняется типовая конфигурация, которая может использоваться в "универсальных" механизмах. Так же минусом к первому варианту можно отнести некоторые трудности при переносе данных (взять те же допреквизиты, допсвойства), некоторые ограничения с использованием таких данных в отчетах и т.д.

Таким образом важно определить объем необходимых доработок и осознанно выбирать объем необходимой поддержки а не стремиться к процессу ради процесса.
2. Константин - (Kosstikk) 05.09.13 09:05
а. Проектирование может быть разным.
б. Оптимальность проектирования оценивается по разным параметрам.

Что касается внесения изменений в типовую конфигурацию и сложности дальнейшей поддержки:

1. Либо совсем не вносим, используя внешние обработки/отчеты, допреквизиты, допсвойства, и обновляемся по типовому.
2. Либо вносим и обновляемся с небольшими затратами.


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

Таким образом важно определить объем необходимых доработок и осознанно выбирать объем необходимой поддержки а не стремиться к процессу ради процесса.
3. Сергей Лесовой (Synoecium) 05.09.13 15:06
Где-то я уже подобное читал, в другой статье скорее всего. Предлагаю добавить ссылки на похожие публикации с кратким анализом, материал то не новый.
А вообще информация полезная и изложена лаконично, плюс)
4. Илья Олегович Червяков (amiralnar) 05.09.13 19:19
Снимать с поддержки не требуется, нужно только включить возможность изменения, и установить режим поддержки "Редактируемый" для необходимых объектов, или для всех сразу. В этом случае корректно производится штатное обновление с отображением дважды измененных объектов.
5. Евгений Сосна (pumbaE) 05.09.13 22:30
<qoute>Для создания новых объектов необходимо снять с поддержки саму конфигурацию (корневой элемент), но без подчинённых </qoute
6. Леонид Павлиенко (PLAstic) 06.09.13 19:50
Конечно, я подразумевал перевод в режим "Редактирование с сохранением поддержки". Поправил текст.
7. Саша Безымяный (help1Ckr) 11.09.13 10:28
Полезная статья, жаль многие ее не читают(
8. Тарас Будько (BudkoT) 11.09.13 16:31
Все правильно.
НО!
Зачастую правильные варианты более трудоемки (имеется ввиду не полная "стоимость владения" вариантом решения, с учетом будущих затрат, а текущая, "чисто" конкретные трудозатраты на текущее изменение конфигурации).
БОльшая трудоемкость = бОльшая стоимость.
Накладываем на ситуацию следующие условия:
1. Клиента интересует лишь мгновенный результат (на постсоветском пространстве бизнесмены зачастую, к сожалению, привыкли максимизировать свою прибыль в сверхкраткосрочном периоде). Этот результат будет одинаков при разных вариантах разработки (кривые руки разработчиков исключаем).
2. Жесткий демпинг братьев-1эсниГов.

Результат: "правильные" варианты с "красивыми" решениями не внедряются, а "внедряторы", загнанные демпингом в угол, начинают работать "пАнармальному", а не правильно:(
9. Леонид Павлиенко (PLAstic) 11.09.13 16:46
Моя практика показывает обратное. Проводится конкурс по небольшому ТЗ с фрагментами вроде "В документ такой-то добавить реквизит такой-то". По смыслу я понимаю, что задача может решаться иначе, без добавления реквизитов, и описываю, чем грозит подобная практика, добавив в конце, что всех, кто будет участвовать в этом конкурсе без изменения способа реализацации, следует гнать взашей.
Результат - приглашение на диалог к руководству клиента.
10. Тарас Будько (BudkoT) 13.09.13 17:24
(9) PLAstic,
это практика работы фрилансером на известном сайте.
Есть несколько но:
1. Это "небольшое ТЗ" (а не задача по автоматизации сети магазинов со структурой складов).
2. Это ТЗ (а не озвученная клиентом потребность в "облегчении труда логистов импортных поставок" или еще чо-нить не сильно похожее на документ, в котором перечислен перечень доработок). Т.е. задача хоть чуть-чуть, но конкретизирована - вернее обозначен возможный ход ее решения.
3. Это все-таки ТЗ (т.е. клиент малость владеет какими-то навыками и может понять Ваш текст, в котором Вы описываете минуса предложений "говнокодеров").

Если не срабатывают эти НО - то демпинг, демпинг, демпинг.
11. Леонид Павлиенко (PLAstic) 16.09.13 16:57
1. Существую я со своей практикой.
2. Существует куча других организаций, в т.ч. франчайзинговых, которые не присутствуют на фрилансе.

Как минимум это даёт возможность мыслить иначе и отстаивать позиции "правильного" программирования. Думаю, в серьёзных организациях спрашивают в первую очередь, видел ли ты когда-нибудь в глаза документ "Стандарты и методики разработки конфигураций" за авторством 1С, нежели "как быстро ты сможешь реализовать то или иное ТЗ".
Считаю, что битва на фрилансе обречена на вымирание, если будут побеждать те, кто делает быстрее, нежели правильнее. Опять же, спасибо участникам фриланса, т.к. после них иногда приходят и к нам.

PS: "фриланс" - здесь одноимённый сайт
12. Тарас Будько (BudkoT) 25.09.13 18:43
(11) PLAstic,
что есть "правильно"? правильно с точки зрения клиента? Ему все, что работает - то и правильно. А то, что через месяц...квартал...год при обновлении либо при появлении новых требований возникнут сложности - дак не каждый клиент может понять, что в этом виноват "говнокод" предыдущего (или даже текущего!) разработчика!.
Или клиенту звать стороннего эксперта и после выполнения каждой задачи контролировать "правильность" ее выполнения?

Вы купили телевизор, смотрели 2 передачи. Вроде бы все Вас устраивало. Начали смотреть третью, не показывает. Кто виноват: слабый сигнал, продавец телевизора, вы (неправильно используя телевизор) или кто-то еще?
Знаете какой будет ответ? Ответ Вам даст мастер, которого Вы вызовете (истина при этому будет где-то рядом). А если мастер и продавец работают в одной организации?...

ЗЫ: встречал кучу клиентов (которые захотели новый функционал, которые переходили с 7-ки на 8-ку - опять-таки для нового функционала...). В базе - полный ппц, говнокод и т.п.... но ... все работает!!! Пользователи привыкли открывать консервную банку ногой через левое ухо и им это стало "удобно". И когда им говоришь, что для нового функционала нужно это и это, они говорят:
1. А чо так много? Предыдущий товарищ (который им все наговнокодил) делал "почти такое же" намного быстрее и результат был!!
2. А нельзя ли просто вот тут создать новое поле и вот тут... и вот тут, а мы туда будем все писать и нормально... вот предыдущий так делал... А если что, мы потом еще поле одно закажем и вы сделаете.... А если потом печать - то шонить придумаем... нет, у нас не будет расхождений при поступлениях... Да, у нас только для клиента, у которого наименование начинается с буквы А такие скидки... да и этот клиент у нас один, других на букву А не будет...
13. Леонид Павлиенко (PLAstic) 25.09.13 19:13
Видимо, разница в том, что я позиционирую себя как "консультант по построению учётных систем", а не просто как "программист". И это определяет моего оппонента по разговору о стоимости и сроках - генеральный или финансовый директор. Они, как правило, считают деньги с заделом на будущее.
Того же и Вам желаю.
14. Павел Колмаков (Stim213) 26.09.13 11:46
Вы еще обновляете УТ 10.3?? Зачем?
15. Тарас Будько (BudkoT) 03.12.13 00:22
(13) PLAstic, участвовали недавно в тендере... электронная закупочная система... так вот, там не спрашивают, читали ли участники тендера стандарты и принципы разработок. Все хотят знать два ключевых параметра: бюджет и сроки.

Рад за Вас, что Ваше имя и бренд позволяют перебирать клиентов, отбирая только тех, которых интересуют качество, профессионализм и т.п. Я тоже всегда рад работать с такими клиентами... но их почему-то мало :(

(видимо компания, в которой я работаю, еще не заслужила таких клиентов...)
16. Александр Федоров (Sasha255n) 14.03.14 12:31
От себя могу добавить оратору выше .... что правильные варианты не только зачастую трудоемки но икак следствие более дороги.
17. Александр Федоров (Sasha255n) 14.03.14 12:32
От себя могу добавить оратору выше .... что правильные варианты не только зачастую трудоемки но и как следствие более дороги.
18. Леонид Павлиенко (PLAstic) 14.03.14 13:11
(17) Sasha255n, это равносильно утверждению, что линукс дешевле винды. Суммарную стоимость владения никто не отменял. Например, покупаем два принтера по одной цене: один требует картридж ежемесячно, другой - раз в три года. Принтер - конфигурация, картридж - плата за обновление. Аналогия ясна?
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа