Korus Axapta Retail: Потребительские свойства. Как можно отобрать номенклатуру с определенными значениями свойств?

[mazzy]

Вопрос родился отсюда: Поделитесь пожалуйста опытом - Расширеная номенклатура
и отсюда Поделитесь пожалуйста опытом - Расширеная номенклатура

Korus Axapta Retail: Потребительские свойства. Как можно отобрать номенклатуру с определенными значениями свойств?

например, я продвинутый пользователь. я хочу в списке номенклатуры отобрать номенклатуру с неким свойством, у которого значения из нумерованного списка.

У вас емкость бутыли - это нумерованный список?
Если да, то я например, хочу отобрать всю номенклатуру с свойством "емкость бутыли" = "0.5".

Как я отбираю? Каковы мои действия? Можно инструкцию? (Желательно со скриншотами).
Появляется ли у меня где-нибудь выпадающий список для названия свойств? Появляется ли у меня где-нибудь выпадающий список для значений свойств, а я бы из этого списка выбрал бы 0.5?
Будет ли где-нибудь в инструкции подразумеваться, что пользователь должен знать наизусть какие-то списки?

[mazzy]

по просьбе Ivanhoe дублирую свое высказывание здесь

Цитата:

Сообщение от mazzy

Во-во! Об подобном отстое я и говорю.
отобрать номенклатуру по этим свойствам нельзя.
остатков по этим свойствам нет.
в отчет фиг знает как выводить.
автоотчет не работает по ним по определению
lookup по свойствам - сущее издевательство над ядром (все вручную).
lookup для подстановки значений в свойства - только программно.
rls - фиг настроишь.
шаблоны записей - не работают.
экспортировать/импортировать - повесится можно.
стандартный функционал ни хрена о них не знает.
индексов по ним нормальных нет, тормоза страшные.

Как только начинаешь учить функционал понимать эти свойства, то сразу понимаешь, что было бы на порядок проще просто добавить пару-тройку специализированных полей в inventTable.


Точно-точно... Об этом я и говорю - программисты считают, что пользователям будет удобно... А им ни фига не удобно с этим геморроем.

См. Программистский подход.

[Ivanhoe]

Из того, что я видел:
В справочнике номенклатур есть дерево, в котором есть ветка "Потребительские свойства", в нем перечисляются текущие свойства, например, вес, емкость бутыли, материал, цвет и т.п.
Выбираем "емкость бутыли" - отображаются возможные значения емкости, выбираем "0,5" - видим все номенклатуры с емкостью бутыли 0,5 и дополнительно можнм продолжить отбор по оставшимся потребительским свойствам.

Выглядит примерно так:

1 . Потребительски свойства
1.1. Цвет
1.2. Размер бутыли
1.2.1. 0,3
1.2.2. 0,5
1.2.2.1. Цвет
1.2.2.2. Материал
1.2.3. 0,7
1.2.4. 1
1.3. Материал

[DSPIC]

как грязный анализ можно предложить использовать "Агент данных" (from DAX 4.0) "Основное"-->"Настройка"-->"Агент данных"-->"Агент данных".
Это функция глобального поиска ("Ctrl+F") по заранее настроенному списку таблиц и полей (в любом сочетании). После отработки поиска, можно пробежаться по его результату (откроется боковая панель глобального поиска справа) и прыгнуть в найденную запись таблицы.
Т.е. по запросу "0.5" поиск покажет все записи, поля которых содержат текст с 0.5 (нестрогое соответствие).
Список таблиц и полей, по которым нужно искать находится там же "Основное"-->"Настройка"-->"Агент данных"-->"Настройка таблиц"

[ViV]

Цитата:

Сообщение от mazzy

"Как только начинаешь учить функционал понимать эти свойства, то сразу понимаешь, что было бы на порядок проще просто добавить пару-тройку специализированных полей в inventTable."

Вы вдумайтесь в само название - "потребительские" свойства. Как вы верно привели пример " емкость бутыли" - но разве в прайсе мы эту емкость бутыли не хотим отобразить для клиента? И если нет - то 99%, что это не потребительское свойство, а какое то служебное ("параметры для контейнерных перевозок, параметры для растаможки, дополнительные производственные параметры, допустимость отгрузки без документов" (С)). Т.е. то, что клиенту неинтересно, и то что лучше добавлять отдельным полем в inventTable с отдельной логикой. А то что интересно клиенту - это вынесено в потребительское свойство - и в соответственно название. Ну а поиск, как вы уже догадались, идет просто по названию. "*0.5 л*" - примерно так.

Если к корусовским потребительским свойствам относится с этой точки зрения - то очень удобная штука. Пользователь уже не сможет написать "емкость поллитра", "емкость большая" и т.д.

[mazzy]

Цитата:

Сообщение от Ivanhoe

В справочнике номенклатур есть дерево

Какое дерево?
А можно скриншоты?

Цитата:

Сообщение от Ivanhoe

Выбираем "емкость бутыли" - отображаются возможные значения емкости, выбираем "0,5" - видим все номенклатуры с емкостью бутыли 0,5 и дополнительно можнм продолжить отбор по оставшимся потребительским свойствам.

что значит "дополнительно можем"?
Я могу поискать по двум значениям одного свойства? Например, хочу найти бутыли "0.5" и "0.7"? А "0.5" или "0.7"? А поискать все емкости бутыли, кроме "0.5"?

А могу я выполнять поиск по нескольким свойствам? И, или, не...

А могу я комбинировать поиск/отбор по свойствам с поиском/отбором по другим полям?

Правильно ли я понимаю, что предлагаемый вами механизм отличается от стандартного и совместно со стандартным не работает?

Цитата:

Сообщение от DSPIC

как грязный анализ можно предложить использовать "Агент данных" (from DAX 4.0)

Это хороший пример того, как один изврат порождает другой.

[mazzy]

Цитата:

Сообщение от ViV

Вы вдумайтесь в само название - "потребительские" свойства. Как вы верно привели пример " емкость бутыли" - но разве в прайсе мы эту емкость бутыли не хотим отобразить для клиента?

Хотим.
Я правильно понимаю, что в прайс пойдет не само свойство, а наименование, которое сформировано на основании свойств?

Если так, то я правильно понимаю, что не работает функционал наименований на разных языках? Что не работает функционал специализированных наименований для клиентов/поставщиков?

Цитата:

Сообщение от ViV

Т.е. то, что клиенту неинтересно, и то что лучше добавлять отдельным полем в inventTable с отдельной логикой.

Это почему же?

Цитата:

Сообщение от ViV

Ну а поиск, как вы уже догадались, идет просто по названию. "*0.5 л*" - примерно так.

Давайте подробнее.
Во-первых, почему "0.5 л", если свойство равно "0.5"
Во-вторых, откуда я продвинутый пользователь знаю что надо вводить "0.5", а не "поллитра"? Я ведь не зря спрашивал - должны ли пользователи помнить наизусть что-либо.
В-третьих, хочу обратить внимание, что фильтр, начинающися со звездочки неизбежно приведет к FullScan таблицы. Я об этом говорил в своем возмущении производительностью

Цитата:

Сообщение от ViV

Если к корусовским потребительским свойствам относится с этой точки зрения - то очень удобная штука. Пользователь уже не сможет написать "емкость поллитра", "емкость большая" и т.д.

как это не сможет? В поиске сколько угодно
И не найдет. И ему будет неудобно.
Об этом я и говорю.

[mazzy]

Те, кто говорят о поиске обычным текстом, пожалуйста, перечитайте проблемы 1Совских характеристик номенклатуры! http://1c.mazzy.ru/articles/smartquery/

Начиная со слов "Существенно также и то, что для рубашек и отверстий есть совершенно одинаковые для пользователя характеристики "Р40, Белый" с совершенно разным смыслом. Для рубашек - это белые 40го размера, а для отверстия - белое радиуса 40 мм."

Обратите внимание на дату публикации - 10.05.03
Бли-и-ин... Ну сколько ж можно на одни и те же грабли то наступать?!

[Ivanhoe]

Цитата:

Сообщение от mazzy

Во-во! Об подобном отстое я и говорю.
отобрать номенклатуру по этим свойствам нельзя..

Можно - отписался.

Цитата:

Сообщение от mazzy

остатков по этим свойствам нет.

Мне кажется это подпадает, под простую доработку, которую можно сделать на проекте. Причем, есть пример дерева по свойствам - прикруть его к форме запасов в наличии по аналогии, думаю, не составит труда.

Цитата:

Сообщение от mazzy

в отчет фиг знает как выводить.

Что имеется в виду? Пример настраиваемого отчета - печать ценников.

Цитата:

Сообщение от mazzy

автоотчет не работает по ним по определению

автоотчет по определнию мало что умеет и в стандарте все меньше вменяемых автоотчетов!

Цитата:

Сообщение от mazzy

lookup по свойствам - сущее издевательство над ядром (все вручную).
lookup для подстановки значений в свойства - только программно.

Можно подробнее, что имеется в виду?

Цитата:

Сообщение от mazzy

rls - фиг настроишь.

Согласен, неудобно.

Цитата:

Сообщение от mazzy

шаблоны записей - не работают.

Хм.. трудно представить себе штук 100 шаблонов ради заполнения нескольких свойств по умолчанию.. К тому же при создании номенклатуры, свойства автоматически создаются на основании ассортиментного классификатора.. но это уже другой "универсальный механизм"

Цитата:

Сообщение от mazzy

экспортировать/импортировать - повесится можно.

Интересно, в чем отличие от экспорта/импорта стандартных связанных таблиц по номенклатуре? Например записей в Местоположении номенклатуры?

Цитата:

Сообщение от mazzy

стандартный функционал ни хрена о них не знает.

Стандартный функционал сам не всегда знает, что лежит правее или левее. Можно подробнее, что нужно?

Цитата:

Сообщение от mazzy

индексов по ним нормальных нет, тормоза страшные.

Чего не знаю, того не знаю. Но если уж высказано замечание, просьба сказать в какой версии продукта, при каких исходных данных, на каком оборудовании тормозит страшно? Желательно фактические подтверждения, надо же знать на что можно напороться

Цитата:

Сообщение от mazzy

Как только начинаешь учить функционал понимать эти свойства, то сразу понимаешь, что было бы на порядок проще просто добавить пару-тройку специализированных полей в inventTable..

Уважаемый mazzy, я так понимаю, вам приходилось учить функционал понимать эти свойства (речь про KORUS | Retail) - поделитесь, плиз, опытом?

[AndyD]

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

[DSPIC]

Цитата:

Цитата:
Сообщение от ViV Посмотреть сообщение
Вы вдумайтесь в само название - "потребительские" свойства. Как вы верно привели пример " емкость бутыли" - но разве в прайсе мы эту емкость бутыли не хотим отобразить для клиента?
Хотим.
Я правильно понимаю, что в прайс пойдет не само свойство, а наименование, которое сформировано на основании свойств?

Тут проблем нет. к LanguageTxt цепляется любая таблица. Оттуда и выводить в отчетности, как это и сделано штатно. Можно и имя и значение туда толкать

[ViV]

Цитата:

Сообщение от mazzy

Давайте подробнее.
Во-первых, почему "0.5 л", если свойство равно "0.5"
Во-вторых, откуда я продвинутый пользователь знаю что надо вводить "0.5", а не "поллитра"? Я ведь не зря спрашивал - должны ли пользователи помнить наизусть что-либо.

Ну я образно привела "л" - это может быть любая единица измерения принятая в вашей компании и забитая в настройки потрбительских свойств.
"должны ли пользователи помнить наизусть что-либо" - пользователи как минимум знают свой ассортимент. и то что эти бутыли в литрах - знать должны. Более того засчет "стандартизации" наименования - все запоминается быстро.

Цитата:

Сообщение от mazzy

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

Не спорю. Критичность этого зависит от объема ассортимента.

[ViV]

Цитата:

Сообщение от mazzy

Начиная со слов "Существенно также и то, что для рубашек и отверстий есть совершенно одинаковые для пользователя характеристики "Р40, Белый" с совершенно разным смыслом. Для рубашек - это белые 40го размера, а для отверстия - белое радиуса 40 мм."

А кто мешает развести текстовку свойств или там добавить единицу измерения так, чтобы они все таки различались? Зачем создавать лишние проблемы?

[mazzy]

Цитата:

Сообщение от Ivanhoe

Можно - отписался.

э-э-э... не понял.

Цитата:

Сообщение от Ivanhoe

Цитата:

Сообщение от mazzy

остатков по этим свойствам нет.

Мне кажется это подпадает, под простую доработку, которую можно сделать на проекте. Причем, есть пример дерева по свойствам - прикруть его к форме запасов в наличии по аналогии, думаю, не составит труда.

остатки - простая доработка?... ну-ну.

Цитата:

Сообщение от Ivanhoe

Что имеется в виду? Пример настраиваемого отчета - печать ценников.

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

Но как добавить колонки со свойствами, при условии, что они произвольные (где-то есть, где-то нет)?
Другими словами, я хочу отчет следующего формата:
Код, Наименование, Емкость, Свойство2, Кол-во.

Первая сложность, с которой сталкивается программист - вывести наименование в заголовок отчета. Придется программировать.
Вторая сложность, с которой сталкивается программист - выводить разные свойства, в разном количестве. А для этого придется дать пользователю интерфейс для управления выводимыми свойствами, а для этого придется...
Третья сложность, с которой столкнется программист - обеспечить безопасность выводимых свойств (кто-то не имеет права видеть некоторые свойства). Программисту придется наворачивать свою систему прав.

и т.д. и т.п.
В результате вместо простого drag-n-drop'а поля из inventTable в отчет получаем неимоверный объем доработок непонятно зачем. С сомнительными удобствами для пользователей

Цитата:

Сообщение от Ivanhoe

автоотчет по определнию мало что умеет и в стандарте все меньше вменяемых автоотчетов!

И это конечно же является поводом создавать еще универсальные механизмы, для которых автоотчет не работает

Цитата:

Сообщение от Ivanhoe

Цитата:

Сообщение от mazzy

lookup по свойствам - сущее издевательство над ядром (все вручную).
lookup для подстановки значений в свойства - только программно.

Можно подробнее, что имеется в виду?

ниже andy дал скриншот - там и объясню.

Цитата:

Сообщение от Ivanhoe

Хм.. трудно представить себе штук 100 шаблонов ради заполнения нескольких свойств по умолчанию.. К тому же при создании номенклатуры, свойства автоматически создаются на основании ассортиментного классификатора.. но это уже другой "универсальный механизм"

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

шаблонов не должно быть много. пару десятков максимум.
даже такое количество шаблонов должно быть ограничено rls'ом.

Цитата:

Сообщение от Ivanhoe

Интересно, в чем отличие от экспорта/импорта стандартных связанных таблиц по номенклатуре? Например записей в Местоположении номенклатуры?

Ни в чем. Обе одинаково сложно экспортировать/импортировать.
Обе таблицы экспортировать/импортировать одинаково сложнее, нежели одну inventTable

Цитата:

Сообщение от Ivanhoe

Стандартный функционал сам не всегда знает, что лежит правее или левее. Можно подробнее, что нужно?

я говорил о стандартных группах, например, группа инвентаризации, группа нумерации. стандартный функционал их использует
а... как хотите... если вам не понятно, ну и фиг с ним.

Цитата:

Сообщение от Ivanhoe

Чего не знаю, того не знаю. Но если уж высказано замечание, просьба сказать в какой версии продукта, при каких исходных данных, на каком оборудовании тормозит страшно? Желательно фактические подтверждения, надо же знать на что можно напороться

Я не работал с Korus Axapta Retail. Я ж потому изначально и задал вопросы, а не начал говорить.
Но если вы думаете, что кроме коруса такой изврат никто не делал, то вы ошибаетесь
Судя по ответам... Что клиентские поделки, что корусовское решение - одинакового уровня проработанности. Щас еще andyD помучаю, вдруг ошибаюсь...

Цитата:

Сообщение от Ivanhoe

Уважаемый mazzy, я так понимаю, вам приходилось учить функционал понимать эти свойства (речь про KORUS | Retail) - поделитесь, плиз, опытом?

Нет, корусовские свойства - не пришлось, слава богу.
А вот подобные доделки у клиентов - неоднократно.

[mazzy]

Цитата:

Сообщение от AndyD

Можно воспользоваться расширенным фильтром - присоединить таблицу потребительских свойств. И добавить фильтрацию по двум полям - "Свойство" и "Значение".

Замечательно!!!!

Во-первых, спасибо за первый скриншот корусовского решения.
Во-вторых, я не зря изначально написал, что я продвинутый пользователь. Я как раз рассчитывал, что кто-то расскажет про добавление таблиц.

Теперь собственно вопросы к скриншоту:
1.
Когда я задаю критерий для поля "Свойство", то мне выпадающий список предлагается?
Если да, то какие свойства в нем перечислены? Можно ли на этот список наложить RLS? Будет ли список хоть как-то ограничен, если я укажу в критериях код номенклатуры? А два кода? (это про lookup по свойствам)
2.
Когда я задаю критерия для поля Значение, то мне предлагается выпадающий список?
Если да, то какие значения в нем перечислены? Только значения тех свойств, которые я ограничил в критерии для поля Свойства? Можно ли наложить rls на этот список? (а это про lookup для подстановки значений в свойства)
3.
Как задать фильтр на несколько свойств? С условиями "И", "или", "не"? (я об этом здесь говорил)

ЕЩЕ РАЗ вопрос: Будет ли где-нибудь в инструкции подразумеваться, что пользователь должен знать наизусть какие-то списки?

Цитата:

Сообщение от ViV

Ну я образно привела "л" - это может быть любая единица измерения принятая в вашей компании и забитая в настройки потрбительских свойств.

А я откуда должен помнить такие детали?
Это я и называю: пользователям неудобно

Цитата:

Сообщение от ViV

"должны ли пользователи помнить наизусть что-либо" - пользователи как минимум знают свой ассортимент. и то что эти бутыли в литрах - знать должны.

Пользователи должны знать свой ассортимент, согласен.
Но пользователи не должны знать особенности кодировки ассортимента в Аксапте!!!
Обратите внимание, как вы подменяете одно другим

То, что бутыли в литрах - не факт. Они могут быть в милиграммах или в lbs, если продажа идет в Америку.

Цитата:

Сообщение от ViV

Более того засчет "стандартизации" наименования - все запоминается быстро.

Я говорю, что подобные универсальные свойства, построенные на подчиненных таблицах (любые: хоть разработанные у клиента, хоть корусовское, хоть 1Совские характеристики) будут обладать одними и теми же неудобствами для пользователей.

Стандартизация наименования не делает механизм универсальных свойств удобным, а просто заметает проблему под коврик.

Цитата:

Сообщение от ViV

А кто мешает развести текстовку свойств или там добавить единицу измерения так, чтобы они все таки различались? Зачем создавать лишние проблемы?

А кто будет следить за различием?
Я правильно понимаю, что для работоспособности "универсального механизма" предлагаете кому то ввести новую обязанность - следить за уникальностью текстовки "универсальных свойств"? Вы хоть представляете последствия подобного решения для боль-мень крупной огранизации с развитой системой подразделений?

Типичный консультантский подход в худшем своем проявлении
Про консультантский подход

[mazzy]

Цитата:

Сообщение от DSPIC

Тут проблем нет. к LanguageTxt цепляется любая таблица. Оттуда и выводить в отчетности, как это и сделано штатно. Можно и имя и значение туда толкать

DSPIC, твой комментарий говорит об одном - с подобными доработками тебе не приходилось работать. И слава богу - есть же счастливые люди на свете.

[AndyD]

Цитата:

Сообщение от mazzy

Замечательно!!!!

Во-первых, спасибо за первый скриншот корусовского решения.
Во-вторых, я не зря изначально написал, что я продвинутый пользователь. Я как раз рассчитывал, что кто-то расскажет про добавление таблиц.

Теперь собственно вопросы к скриншоту:
1.
Когда я задаю критерий для поля "Свойство", то мне выпадающий список предлагается?
Если да, то какие свойства в нем перечислены? Можно ли на этот список наложить RLS? Будет ли список хоть как-то ограничен, если я укажу в критериях код номенклатуры? А два кода? (это про lookup по свойствам)
2.
Когда я задаю критерия для поля Значение, то мне предлагается выпадающий список?
Если да, то какие значения в нем перечислены? Только значения тех свойств, которые я ограничил в критерии для поля Свойства? Можно ли наложить rls на этот список? (а это про lookup для подстановки значений в свойства)
3.
Как задать фильтр на несколько свойств? С условиями "И", "или", "не"? (я об этом здесь говорил)

ЕЩЕ РАЗ вопрос: Будет ли где-нибудь в инструкции подразумеваться, что пользователь должен знать наизусть какие-то списки?

1. Да. Свойства задаются в отдельной таблице (Потребительские свойства товаров) - сколько их там будет, столько и увидишь. RLS включить можно.
Да - сделать еще один расширенный фильтр по лукапу (хоть по ассортиментному классификатору)
2. Нет. Rls настроить можно
3. Мы же в расширенном фильтре - с помощью его расширенных возможностей

[mazzy]

Цитата:

Сообщение от AndyD

1. Да. Свойства задаются в отдельной таблице (Потребительские свойства товаров) - сколько их там будет, столько и увидишь. RLS включить можно.

Т.е. я увижу все существующие в системе свойства? Даже если я хочу отобрать номенклатуру, у которой некоторых свойств нет?

Цитата:

Сообщение от AndyD

2. Нет. Rls настроить можно

2.1. Т.е. я должен сам помнить какие значения там есть?
2.2. Я должен сам помнить разрешенные сочетания "емкость"/"0.5", "процент жирности"/"12"?
2.3. Я должен сам контролировать ошибки неправильного указания типа "емкость"/"12"?
Я об этом и говорил - "неудобно". И это неудобство заложено изначально в саму технологию "свойств", "характеристик"

А RLS на что настраивается? на таблицу значений? или на таблицу возможных значений?
Другими словами, у коруса есть только одна таблица {Номенклатура, Свойство, ФактическоеЗначение} или есть еще вторая таблица {Свойство, ВозможноеЗначение}?

Если только одна, то как контролируется правильность заполнения значений?

Цитата:

Сообщение от AndyD

3. Мы же в расширенном фильтре - с помощью его расширенных возможностей

Ну, например? Скобками? Можно показать просто скриншотом.

Если скобками, то пользователям не просто неудобно...
Если скобками, то это недопустимое решение даже для продвинутых пользователей.

[mazzy]

попробую подвести предварительные итоги для руководителей проектов, которые захотят внедрить у себя подобный "универсальный механизм".

замечательный универсальный механизм неизбежно потребует создания универсальных механизмов для:

• печати свойств в отчетах
• выбор выводимых в отчете свойств пользователем
• ограничения прав к свойствам
• интеллектуального lookup по свойствам
• интеллектуального lookup по значениям свойств
• поиска и отбора свойств с логическими операторами. Как одного свойства, так и нескольких свойств. Как в форме номенклатур, так и в других формах.
• обеспечения правильности значений свойств
• обеспечения уникальности кодов/наименований свойств (скорее всего здесь потребуется изменение штатного расписания и/или должностных инструкций у заказчика)
• стандартизации наименований и свойств (обратите внимание: не желательно, а именно ПОТРЕБУЕТ!)
• оптимизацию производительности для запросов с первой звездочкой. Например, "*0.5*"

Т.е., уважаемые руководители проектов, если вы начнете внедрять этот замечательный (на первый взгляд простой и дешевый в изготовлении и сопровождении) универсальный механизм, то будьте готовы к тому, что неизбежно вам придется портатить время на перечисленные задачи. Даже если вы не планировали такие работы изначально.

см. Про консультантский подход

[AndyD]

Цитата:

Сообщение от mazzy

Т.е. я увижу все существующие в системе свойства? Даже если я хочу отобрать номенклатуру, у которой некоторых свойств нет?

Хм. Раньше ты писал, что хочешь выбрать значение определенного свойства. Какая разница, есть у нужных номенклатур другие свойства или нет?
Или тебя смущает, что список может быть большим?

По поводу архитектуры

Таблиц свойств две:

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

Т.е. "Потребительские свойства товаров" и номенклатуры связаны отношением много-ко-многим через таблицу "Значения потребительских свойств для номенклатуры"

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

При вводе значения свойства можно выбрать его из списка доступных значений. При сохранении проверяется соответствие значения списку или диапазону


По поводу универсальности или нет - Корус не заявлял, что это универсальное решение.
Его предназначение - стандартизация заведения наименований товаров на основе некоторых правил. Эти правила и задаются потребительскими свойствами
То, что можно дополнительно фильтровать - это уже побочное явление, связанное с базовым функционалом Аксапты, а не с этим решением