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

[mazzy]

Цитата:

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

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

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

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

Цитата:

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

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

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

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

Цитата:

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

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

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

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

[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. "Значения потребительских свойств для номенклатуры" - это таблица содержит сами значения и связь их с "Потребительскими свойствами товаров" и номенклатурами

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

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

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


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

[Raven Melancholic]

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

[mazzy]

Цитата:

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

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

Т.е. отобрать/поискать я могу только по одному свойству?
Я ж хоть и продвинутый пользователь, но не знал, что это принципиально.
Если честно, то для меня это полная неожиданность.

Цитата:

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

Или тебя смущает, что список может быть большим?

Конечно.

Цитата:

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

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

А при вводе в критерий поиска?

Цитата:

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

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

"Минуточку! У меня все ходы записаны" (С)
вот:

Цитата:

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

В KorusAxaptaRetail сделана такая штука, как "Потребительские свойства", N:1 к карточке товара. Свойства могут быть со значениями разных типов (строка, число, нумерованный список). Для разных групп номенклатуры можно задать разные наборы допустимых (и обязательных для заполнения) свойств: например, для алкоголя крепость и емкость бутылки, для молочных товаров процент жирности, и т.п. По сути, получился универсальный механизм.
К тому же, можно настроить свойства так, чтобы из их значений автоматически формировалось название номенклатуры, что позволяет стандартизировать названия и не дает пользователям забыть указать в названии важные параметры товара.

Т.е. не "потребительские свойства", а всего лишь "стандартизация названия"...

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

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