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

02.12.14

Разработка - Механизмы типовых конфигураций

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

Скачать файл

ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.

Наименование По подписке [?] Купить один файл
Пример обработки (заполнение данных в связанном с объектом регистре)
.epf 13,25Kb
12
12 Скачать (1 SM) Купить за 1 850 руб.
Пример регистра сведений для хранения дополнительной информации (файл конфигурации)
.cf 13,46Kb
10
10 Скачать (1 SM) Купить за 1 850 руб.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

Доработки конфигурации поддержка обновление

См. также

СКД Механизмы типовых конфигураций Запросы Программист Платформа 1С v8.3 1С:Зарплата и кадры государственного учреждения 3 1С:Зарплата и Управление Персоналом 3.x Россия Бесплатно (free)

Работая с типовыми отчетами в конфигурациях «Зарплата и управление персоналом, редакция 3», «Зарплата и кадры государственного учреждения, редакция 3» и подобных, в схемах компоновки данных можно встретить конструкции запросов, которые обращаются к некоторым виртуальным таблицам.

20.08.2024    1222    PROSTO-1C    0    

17

Механизмы типовых конфигураций Программист Платформа 1С v8.3 1С:Комплексная автоматизация 2.х Россия Бесплатно (free)

Эта ошибка была обнаружена мной в типовой конфигурации 1С:Комплексная автоматизация 2 (2.5.16.115), БСП версия 3.1.9.302. Возникает она после того, как вы добавляете в расширение бизнес-процесс или задачу, выполняете обновление идентификаторов метаданных расширений, но ошибка при записи любого элемента справочника "Профили групп доступа" всё равно остаётся.

01.07.2024    1334    Vidz    0    

10

Механизмы типовых конфигураций Программист Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

Очень часто в написании кода требуется обращаться к предопределённым значениям. Если идёт обращение к типовым предопределённым значениям, то проблем не возникает.

24.06.2024    962    olja-ljaaa    0    

3

Механизмы типовых конфигураций Программист Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Статистическая выборка сценариев и точек изменения отчетов на общей форме ФормаОтчета в типовых конфигурациях. Примеры кода.

03.06.2024    4150    Serg2000mr    32    

104

Механизмы типовых конфигураций Ценообразование, анализ цен Программист Пользователь Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 Россия Абонемент ($m)

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

1 стартмани

11.04.2024    948    tango    5    

3

Механизмы типовых конфигураций Программист Платформа 1С v8.3 1С:Управление торговлей 11 Россия Абонемент ($m)

Какому-либо элементу списка сопоставляется числовое значение, зависящее от других значений, причем эта зависимость изменяется от элемента к элементу. Так, в справочнике "Валюты" курс какой-либо валюты может быть задан формулой (или даже запросом) от значения другой валюты. А в справочнике "Виды цен" формула определяет расчет цены для товарной позиции, т.е. элементов справочника "Номенклатура", у которых в карточке указан этот вид цены. А в 1С:ERP, например, этот механизм используется в ресурсной спецификации.

10 стартмани

11.04.2024    803    tango    5    

4

Механизмы типовых конфигураций Программист Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 Россия Бесплатно (free)

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

08.04.2024    1083    tango    0    

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

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

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

Слава 1С!
Прикрепленные файлы:
7. kauksi 217 21.02.14 11:58 Сейчас в теме
В БиТ: финанс давно подобное реализовано, америку открыл...
8. MaiorovYury 10 21.02.14 12:05 Сейчас в теме
Очень гибкое решение!
Сам до этого дошел и уже давно этим пользуюсь.
Жаль только, что без табличной части "обработку табличных частей" не прикрутить к документу...
Надо требовать "обработки документов" по аналогии с "обработкой табличных частей"
11. AlX0id 23.02.14 23:48 Сейчас в теме
Однако помимо, прочего, имеется непреодалимое желание видеть причины, по которым заказы изменяются.

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