1С:Комплексная автоматизация 1.х
1С:Управление торговлей 10
1С:Управление производственным предприятием
1С:Управление нашей фирмой
Платформа 1С v8.x (все механизмы)
Комментарии
Избранное
Подписка
Сортировка:
Древо
(4) Ёпрст, обработка судит о присутствии того или иного свойства у номенклатуры по наличию этой номенклатуры в табличной части "Назначение свойства". Если табличная часть пуста, то обработка считает, что это свойство не относится ни к одной номенклатуре, хотя на самом деле это свойство относится ко всем элементам справочника номенклатуры. Поэтому "Назначение свойства" и подгоняется под "удобство" работы с ним обработке.
(7) Ёпрст, "дырка от бублика" будет в любом случае. В вашем - будут свойства, но их значения не будут заполнены. В случае моей обработки: добавили номенклатуру, поставили у неё галки для нужных свойств (галку можно даже не ставить, достаточно заполнить значение свойства и оно автоматически "прикрепится" к этой номенклатуре).
(5) Думаю, такое решение (насчет заполнения "Назначения свойства" всеми элементами номенклатуры), мягко говоря, не слишком удачное. По следующим причинам:
1. Если "Назначение свойства" пустое, то свойство (в типовой функциональности) относится не только ко всем СУЩЕСТВУЮЩИМ элементам справочника Номенклатура, но и ко всем, которые будут созданы впоследствии. Аналогично, если в "Назначении свойства" указана папка справочника - свойство относится не только ко всем существующим элементам, входящим в иерархию этой папки, но и ко всем, которые будут созданы здесь в будущем, либо перемещены сюда из других папок справочника. Ваша обработка, чтобы работали ее алгоритмы, ломает эту типовую функциональность. В результате придется за такими свойствами постоянно следить - перезаполнять назначение свойств после каждого добавления/перемещения элементов номенклатуры.
2. (На самом деле, это продолжение п.1) Те базы, где реально могла бы помочь Ваша обработка, будут иметь очень большой справочник номенклатуры. И очень интенсивно меняющийся. Соответственно, количества строк "Назначение свойства" будут порядка тысяч, десятков тысяч. Чтобы следить за этим хозяйством, придется либо подписки на события делать, либо регламентным заданием перезаполнять, либо что-то еще придумывать.
3. Кроме того, открытие свойств в типовых формах хоть немного, но замедлится - т.к. будут постоянные проверки на вхождение данной ссылки в перечень, содержащий тысячи или более ссылок.
Предлагаю обдумать все это. Может быть, Вашей обработке не так уж необходимо именно такое заполнение "Назначений свойств"?
1. Если "Назначение свойства" пустое, то свойство (в типовой функциональности) относится не только ко всем СУЩЕСТВУЮЩИМ элементам справочника Номенклатура, но и ко всем, которые будут созданы впоследствии. Аналогично, если в "Назначении свойства" указана папка справочника - свойство относится не только ко всем существующим элементам, входящим в иерархию этой папки, но и ко всем, которые будут созданы здесь в будущем, либо перемещены сюда из других папок справочника. Ваша обработка, чтобы работали ее алгоритмы, ломает эту типовую функциональность. В результате придется за такими свойствами постоянно следить - перезаполнять назначение свойств после каждого добавления/перемещения элементов номенклатуры.
2. (На самом деле, это продолжение п.1) Те базы, где реально могла бы помочь Ваша обработка, будут иметь очень большой справочник номенклатуры. И очень интенсивно меняющийся. Соответственно, количества строк "Назначение свойства" будут порядка тысяч, десятков тысяч. Чтобы следить за этим хозяйством, придется либо подписки на события делать, либо регламентным заданием перезаполнять, либо что-то еще придумывать.
3. Кроме того, открытие свойств в типовых формах хоть немного, но замедлится - т.к. будут постоянные проверки на вхождение данной ссылки в перечень, содержащий тысячи или более ссылок.
Предлагаю обдумать все это. Может быть, Вашей обработке не так уж необходимо именно такое заполнение "Назначений свойств"?
(10) kapustinag, спасибо за подробный комментарий, но не убедили.
Единственное с чем согласен - это "открытие свойств в типовых формах хоть немного, но замедлится" - "немного" будет не заметное, но будет.
Моя обработка "не ломает" типовую функциональность, она улучшает механизм работы с этой "типовой функциональностью" и попросту не использует часть этого "типового функционала".
Про подписки на события я, в принципе тоже согласен, но делать их нужно не для моей обработки, а для "типового функционала". Что будет с заполненными свойствами номенклатуры, если её (номенклатуру) перенести в другую группу (к которой эти свойства не относятся)? Правильно - свойства всё равно будут отображаться в форме номенклатуры, хотя в "Назначении свойств" не будет ни этой номенклатуры, ни её родителей. Тогда да, "В результате придется за такими свойствами постоянно следить - перезаполнять назначение свойств после каждого добавления/перемещения элементов номенклатуры".
Поэтому всё, что Вы описали, с теоретической точки зрения, возможно, верно. С практической - нет. Именно поэтому я выложил данную обработку.
Единственное с чем согласен - это "открытие свойств в типовых формах хоть немного, но замедлится" - "немного" будет не заметное, но будет.
Моя обработка "не ломает" типовую функциональность, она улучшает механизм работы с этой "типовой функциональностью" и попросту не использует часть этого "типового функционала".
Про подписки на события я, в принципе тоже согласен, но делать их нужно не для моей обработки, а для "типового функционала". Что будет с заполненными свойствами номенклатуры, если её (номенклатуру) перенести в другую группу (к которой эти свойства не относятся)? Правильно - свойства всё равно будут отображаться в форме номенклатуры, хотя в "Назначении свойств" не будет ни этой номенклатуры, ни её родителей. Тогда да, "В результате придется за такими свойствами постоянно следить - перезаполнять назначение свойств после каждого добавления/перемещения элементов номенклатуры".
Поэтому всё, что Вы описали, с теоретической точки зрения, возможно, верно. С практической - нет. Именно поэтому я выложил данную обработку.
В поддержку (10) kapustinag, Регистр сведений Назначение свойств - носит ограничительный характер. Его есть смысл использовать только когда действительно надо спрятать некоторые свойства. Но если не ошибаюсь, при открытии элемента справочника в типовых конфигурациях не включается проверка на иерархическое вхождение, как следствие Свойство становится недоступным для ввода у Новых элементов (Однозначно, если в регистре перечислены Элементы)!!!
Если свойство имеет тип значения отличный от "Значение свойств объектов", то "Список значений свойств" не отображается, т.к. подразумевается, что пользователь вводит произвольное значение вручную, а не выбирает его из заранее предопределённого списка.
А если в качестве свойства указывается элемент из другого справочника? Почему Априори запрещается изменять состав допустимых значений свойства?
Даже если пользователю недостаточно прав на пополнение списка допустимых значений, то всё равно удобнее видеть эти допустимые значения для более осмысленного выбора...
(12) V.Nikonov,
Пожалуйста, указывайте, обработка это позволяет. При непосредственном выборе значения свойства у конкретного объекта откроется форма списка справочника, из которого можно будет выбрать нужное значение.
А если в качестве свойства указывается элемент из другого справочника?
Пожалуйста, указывайте, обработка это позволяет. При непосредственном выборе значения свойства у конкретного объекта откроется форма списка справочника, из которого можно будет выбрать нужное значение.
(15) Да. Видеть список допустимых значений облегчает задачу выбора правильного значения. Уменьшает вероятность образования Дублей...
Т.к. в качестве значения Свойства может быть не только Справочник.СвойстваОбъектов но и другие справочники, то желательно попытаться вывести эти справочники... (сложнее будет если справочник значений окажется иерархическим!)
Т.к. в качестве значения Свойства может быть не только Справочник.СвойстваОбъектов но и другие справочники, то желательно попытаться вывести эти справочники... (сложнее будет если справочник значений окажется иерархическим!)
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
Вакансии
Ведущий программист 1С (с функцией наставничества)
Екатеринбург
зарплата от 100 000 руб.
Полный день
Екатеринбург
зарплата от 100 000 руб.
Полный день