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