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

[Raven Melancholic]

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

[mazzy]

Цитата:

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

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

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

Цитата:

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

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

Конечно.

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

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

[AndyD]

Про ввод в критерий поиска я уже написал - нельзя.

По поводу универсальности - это вопрос к Zabr, а не ко мне. Я могу лишь привести цитату из корусовского руководства

Цитата:

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

Я же в этой теме отвечал на твой вопрос - Как можно отобрать номенклатуру с определенными значениями свойств?

[ViV]

Цитата:

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

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

[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

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

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

[lev]

прочитал с интересом тему... вот какие посетили мысли
первое: работал в компании (не буду публично говорить в какой) в которой было внедрено розничное решение Коруса. Там за заведение номенклатуры, её свойств и все что с ней было связано отвечал специальный отдел ФТП (Формирование Торгового Портфеля). Они знали все свойства и т.п. подобное, поэтому не испытывали каких либо затруднений с использованием функционала Потребительских свойств. Остальная масса пользователей видела только название номенклатуры, и остальное её мало интересовало. Поэтому про удобство пользователям, как мне кажется, вопрос больше административный, нежели технический.
второе: здесь ведется обсуждения исходя из догадок о том "а удобно ли это пользователям?"... Хочу подойти к вопросу немного с другой стороны. Бывает пользователи приходят, и просят сделать что-то, некий механизм, для автоматизации какого нибудь процесса... Ты с ними долго споришь, доказываешь что им это будет неудобно, что они не будут пользоваться этим, что это "велосипед" и т.п. После долгих споров все таки побеждают пользователи и подключенные "большие" начальники. Когда все сделано и внедрено, как не странно, на удивление, пользователи пользуется этим механизмом активно, и благодарны за то что он есть!
Так что трудно спорить, о том что хорошо, а что плохо. Везде есть плюсы и минусы.

[mazzy]

Цитата:

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

Да. Такие поля конечно есть - и они продублированы в InventTable - правда их всего 3 штуки.

Очень похоже на то, как у других/
И количество, и перенес в InventTable

Цитата:

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

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

Ап-солютно согласен.

Цитата:

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

Везде есть плюсы и минусы.

Тоже согласен.

Только в стандарт такое решение переносить не надо.