gifts2017

Как привязать свои реквизиты к объекту, не изменяя сам объект (на примере корректировок заказов УПП)

Опубликовал Андрей Конев (Infector) в раздел Программирование - Практика программирования

Вводим нетиповую информацию в типовой документ.

Извечная проблема измененных конфигураций - необходимость их обновления. Пользуясь решением, находящимся на поддержке мы почти всегда встаем перед дилеммой: сделать так, как хочет пользователь или так, что бы проблем с поддержкой было меньше. Что мы делаем обычно? Правильно, взвешиваем все за и против внесения изменений в конфигурацию по сравнению с конфигурацией поставщика: отбрасываем нелепые желания пользователей, анализируем можно ли угодить пользователю и удобству поддержки одновременно, оцениваем масштабы вероятного вмешательства в конфигурацию и решаем - правим или нет. Очень часто и даже почти всегда одна и таже задача может иметь несколько решений различной степени изящества. Попробуем рассмотреть решение, которое на днях пришлось пройти мне.

Изначальная задача заключается в желании руководства отслеживать заказы покупателей и изменения в них. Однако помимо, прочего, имеется непреодалимое желание видеть причины, по которым заказы изменяются. По условию Это должен быть классификатор причины, плюс комментарий от пользователя касательно причины (итого два реквизита). Изменения заказов фиксируются вводом "корректировок заказа покупателя", однако указания причин корректировки стандартная система не предусматривает.

Есть несколько решений, которые наверняка промелькнули у кого-то в голове:

№1 - не вмешиваться в конфигурацию вообще, воспользоваться механизмом "Свойства Объектов" и обучить пользователя работе с ним.

Преймущества: конфигурация не тронута вообще; аналитика отчетов может использовать "Свойства Объектов"

Недостатки: указать и прокомментировать построчно причины корректировок пользователь не может, чему совсем не рад; при значительном количестве "дополнительных свойств" у объекта работа с ними не очень удобна.

№2 - Если пользователь так хочет построчно вводить свои причины добавляем реквизиты к табличной части, добавляем на форму прямо или динамически

Преймущества: просто сделать; для пользователя при вводе данных все предельно понятно.

Недостатки: Еще один объект при "сравнении - объединении" будет регулярно светиться как нестандартный, а общая картина как раз складывается из таких мелочей.

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

Вспоминаем как типовые конфигурации хранят "Значения свойств объектов" - регистр сведений с двумя измерениями и одним ресурсом, который связывает в одно целое сами свойства, их значения и объекты которым эти значения принадлежат.

Что же мешает нам создать собственный регистр сведений? А в том-то и дело, что ничто. 

Нам нужно знать по какому заказу, какому количеству, какой номенклатуры, по какой причине были корректировки. Отсюда вырисовываем структуру регистра сведений:

Измерения: Номенклатура, ХарактеристикаНоменклатуры, Причина, Заказ, ДокументДвижения (т.е. корректировка). 

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

Ресурсы: Количество, Комментарий

Для хранения причин изменения меня устроил справочник "ПричиныЗакрытияЗаказов", но завести собственный тоже никто не мешает.

Итак, регистр у нас есть, но как в него положить данные? На выручку нам придут "Обработки заполнения табличных частей" (кто сказал, что использовать их нужно именно для того и только для того, чтобы заполнять табличные части?)

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

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

Так это выглядит на демо-базе УПП:

После первого открытия формы (еще ничего не заполнено)

После частичного заполнения данных и повторного открытия:

 

Прилагаю пару файлов:

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

2. обработку, позволяющуюю заполнять данные в нем. Конструктивная критика приветствуется.

Скачать файлы

Наименование Файл Версия Размер
Пример обработки (заполнение данных в связанном с объектом регистре) 12
.epf 13,25Kb
14.02.14
12
.epf 13,25Kb Скачать
Пример регистра сведений для хранения дополнительной информации (файл конфигурации) 10
.cf 13,46Kb
14.02.14
10
.cf 13,46Kb Скачать

См. также

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

Комментарии

1. rasswet (rasswet) 19.02.14 10:18
спасибо, хорошее описание, с различными вариантами, и изящное на мой взгляд решение! плюсую!
пишите и далее в таком стиле!
2. rasswet (rasswet) 19.02.14 10:21
номер строк не было нужды учитывать? если строку с номенклатурой удалил из документа что будет?
3. Андрей Конев (Infector) 19.02.14 11:02
К номеру строк специально не привязывался, т.к. желающие удалять строки или просто их сортировать в документе обязательно найдутся. Заполнение формы редактирования - в два этапа:
1. Читаем регистр и открываем записанные ранее строки
2. Добавляем строки с незаполненным целевым параметром, количество расчитывается как разница указанного количества в документе и количества, на которое целевой параметр уже заполнен. (т.е. того, что выводилось в п.1).

Теоретически возможна и ситуация, когда общее количество корректировки заказа складывается из нескольких причин, одна из которых увеличивает заказ, вторая уменьшает и т.д. В документе при этом будет указано итоговое количество корректировки. В разрезе причин этот механизм позволит указать каждую составляющую.
Например:
+4 причина 1
-3 причина 2
В сумме +1 (что и будет видно в самом документе)
Зеленоград; +1 Ответить 1
4. rasswet (rasswet) 19.02.14 14:54
5. Александр Зубцов (iov) 21.02.14 01:14
Плюс за разумность. Но я чуть иначе поступил - регистр и обработка и подписка. в которой сравниваю есть изменения табличных частей и если есть - обязательно причину изменения записать но причина - текстовое поле ибо манагеры придумали 1000 и 1 причину - справочник бы лопнул. - нет причины - нет изменений и шансов что кто-то забудет меньше.
6. Антон gendal (gendal) 21.02.14 11:41
В ERP 2.0 вопрос решен

Прицепил скрин, но что-то не показывается.
В документе "Заказ клиента" построчно можно поставить флаг "Отменено по причине" и выбрать из справочника причину.

Слава 1С!
Прикрепленные файлы:
7. Sergei (kauksi) 21.02.14 11:58
В БиТ: финанс давно подобное реализовано, америку открыл...
8. Юрий Майоров (MaiorovYury) 21.02.14 12:05
Очень гибкое решение!
Сам до этого дошел и уже давно этим пользуюсь.
Жаль только, что без табличной части "обработку табличных частей" не прикрутить к документу...
Надо требовать "обработки документов" по аналогии с "обработкой табличных частей"
9. Андрей Конев (Infector) 21.02.14 12:59
(5) iov, Но с другой стороны аналитика со справочником удобнее и больше порядка при вводе данных (уже много меньше вариантов написать слово целиком/сократить, пользуются тем что завели когда-то). При необходимости обработка поиска и замены дублирующих значений может объединить избыточные записи)
10. Владимир Клименко (KliMich) 22.02.14 10:41
(5) iov, тоже так обычно поступаю.
Но вариант автора удобнее, так как все будет в одной флаконе (внешней обработке) и не надого городить Подвиску на события... :)
11. Алексей 1 (AlX0id) 23.02.14 23:48
Однако помимо, прочего, имеется непреодалимое желание видеть причины, по которым заказы изменяются.

Для того, чтобы "видеть" причины вполне достаточно заполнения поля Комментарий в заказе. Если их надо анализировать - тогда да, может понадобиться регистр %)
12. Андрей Конев (Infector) 24.02.14 08:33
(11) AlX0id, При условии, что на каждую причину пользователи заводят отдельный документ. А для того чтобы анализировать в таком случае можно и "свойства объектов врубить". А вот если несколько причин в один документ загонять уже не работает.
13. Сергей Бурыка (BurSer) 25.02.14 15:13
Делал почти тоже самое. Изменений в конфигурации 0. Просто сливал информацию о заказе во внешний текстовый файл с номером заказа. Все файлы содержали информацию : дата изменения, автор изменения, комментарий изменения, табличную часть. Каждое изменение +1 новый файл. Анализ изменений : по-парно считывать файлы и анализировать изменения. В этом случае и порядок строк если изменён - видно.
Может кому пригодиться.
14. mikhailovaew (mikhailovaew) 03.03.14 10:24
Хороший анализ, интересное решение.
Опечатки по тексту: в слове "преимущество" не должно быть буквы "й"
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа