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

[mazzy]

Цитата:

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

Вот именно! Я сейчас посмотрела ради интереса - у нас 323 (!) разных потребительских свойства.
По большинству даже поиска не требуется - они для стандартизации названия.

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

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

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

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

Цитата:

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

Mazzy, вы действительно считаете, что нам надо было добавить 323 поля в inventTable?

Теперь отвечаю на вопрос.

Нет, создать "323 поля в inventTable" - это тоже из разряда "простых универсальных решений". Только с другого полюса

Прежде всего, необходимо понимание потребностей пользователей!

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

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

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

==============
Небольшое отступление не для компании Zabr и Viv, а для производственных компаний. Zabr упомянул жирность молочных продуктов. Дело в том, что жирность молочных продкутов не является свойством номенклатуры. Жирность - это характеристика данноого конкретного лота молочных продуктов. Да, молокозаводы нормализуют жирность (добавляя сыворотку или сливки), чтобы розница получила молочные продукты со стандартизированными жирностями 3,2%, 3,5%, 15%, 20% и т.п. Но жирность не является свойством НОМЕНКЛАТУРЫ!

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

В общем, будьте внимательны и осторожны со свойствами НОМЕНКЛАТУРЫ
==============

Так вот. Возвращаясь к Axapta Retail.
У вас сейчас есть механизм, который призван упорядочить названия, но справляется со своей работой не на 100%.
У вас сейчас есть механизм, который практически нельзя использовать для отборов, потому что пользователь должен держать в памяти возможные значения.

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

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

У скольких был - ни на одном проекте результат внедрения подобнвх свойств не оправдывал затраченных на него усилий. У скольких был - ни на одном проекте не было полного набора инструментов для более-менее удобной работы со свойствами. Поэтому я категорически против появления подобного механизма в стандартной версии Поделитесь пожалуйста опытом - Расширеная номенклатура
Либо пусть в обязательном порядке дополнительно к свойствам делают полный набор инструментов для lookup'ов, вывода свойств в отчет, получения остатков, поиска дублей, анализа этих свойств и т.п.

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

[ViV]

Цитата:

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

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

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

[Zabr]

Цитата:

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

Ведь, собственно говоря, нужны не свойства или стандартизированное название.

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

Цитата:

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

Нужен функционал управления ассортиментом.

А это вообще другое, потому что понятие "ассортимент" очень существенно отличается от понятия "справочник номенклатуры". Я недавно отвечал на этот вопрос тут