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

[Ievgenii]

Добрый день,
Поделитесь пожалуйста опытом

Как часто вы сталкивались (если вообще сталкивались) с необходимостью добавлять различные поля к Номенклатуре, которые бы являлись частью "определения номенкларуты" (like itemId, item model group). Например - логотип, некие дополнительные обязательные (mandatory) атрибуты продукта, описания, коды, имена и т.д. Или возможно вам встречались решения (например в product lifecycle management) с расширеной номенклатурой? А если еще можете пример привести - было бы просто супер.


Спасибо!
Женя

[DSPIC]

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

[Ievgenii]

DSPIC,
Большое спасибо за скорый ответ, но скорее всего вы меня не так поняли .

Интересует не техническая реализация, а категория атрибутов которые добавляються к номенклатуре. Вполне очевидно что имеет смысл ассоциировать меры длины/веса к продукту, другими словами указывать вес/глубину/высоту при создании и тд. Также вполне вполне понятно ассоциировать различные атрибуты в зависимости от бизнес процесса, другими словами у номенклатуры может быть RFID код поставщика тогда товар находиться у нас на складе ибо поставщик желает видеть наличие своего товара у нас на складе чтобы лучше прогнозировать свое производство для удолетворение возможного заказа. При этом тот же товар совершенно не нуждается в указании RFID когда мы его закупаем. Возможные атрибуты номенклатуру довольно абстрактная тема для разговора - поэтому интересуют иммено те категории атрибутов и поля с которыми вы сталкивались.

Заранее спасибо.
Женя

[blokva]

Цитата:

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

DSPIC,
...
Вполне очевидно что имеет смысл ассоциировать меры длины/веса к продукту, другими словами указывать вес/глубину/высоту при создании и тд.
Также вполне вполне понятно ассоциировать различные атрибуты в зависимости от бизнес процесса, другими словами у номенклатуры может быть RFID код поставщика тогда товар находиться у нас на складе ибо поставщик желает видеть наличие своего товара у нас на складе чтобы лучше прогнозировать свое производство для удолетворение возможного заказа. При этом тот же товар совершенно не нуждается в указании RFID когда мы его закупаем. Возможные атрибуты номенклатуру довольно абстрактная тема для разговора - поэтому интересуют иммено те категории атрибутов и поля с которыми вы сталкивались.

Да какая разница, Вы можете создавать огромное количество атрибутов, проводя их категоризацию, классификацию и т.д. Сиравно сущность будет одна - "конкретная номенклатура"! Вы можете вести также коды этой конкретной номенклатуры для каждого поставщика или клиента, но в вашей системе код будет один единственный. В зависимости от бизнес процесов, Вы можете манипулировать любыми атрибутами или их группами, но однозначная идентификация будет только Ваша внутренняя. Для поставщиков или клиентов, Вы можете показывать ВАШУ номенклатуру в любом ее состоянии (остатки, планы и т.д.) но интерфейсно отображая ИХ коды.

[Vals]

Пропустив Ваш вопрос об атрибутах, попробую рассмотреть, как можно организовать данную процедуру в Axapta (DAX всех мастей)

Цитата:

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

Здесь можно поднять большой пласт возможностей реализации данной функции. И сама реализация будет зависеть от степени интеграции с поставщиком и вашего желания.

1. Наверно самый простой вариант: даём доступ поставщику к нашей системе и показываем ему форму В наличии. Простой для нас, но сложный для поставщика.


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

2. Простой вариант: вы даёте доступ поставщика к сводному планированию (спланированные заказы и т.д.) таким образом повышаете его информированность о движении товара (сырья)

Следующие варианты более интересны для производства.
3. Сложнее вариант назовём его "Подрядчик должен произвести и поставить": в спецификациях включаете номенклатуру поставщика с типом строки Поставщик и тем самым жёстко указываете кто её будет поставлять. Система формирует закупку.
Здесь нюанс в том, что Поставщик должен держать запас у себя, чтобы отгрузить по вашему требованию или же вы можете указать срок поставки. То есть, сводное планирование не учитывает время на производство поставщика (только время поставки + времена упреждения), а производственно просто требует поставить его к указанному сроку.

4. Продвинутый. Его можно назвать как "Мы знаем, когда Подрядчик должен произвести". Включаем номенклатуру поставщика как спецификацию, указываем тип поставщик, указываем подрядчика. В маршруте спецификации указываем операции и время производства, которое затратит поставщик, указывая в качестве РЦ - поставщика. Здесь есть некоторая проблема с загрузкой РЦ поставщика, но при желании она решаема. В этом случае, система может рассчитать, за какое время поставщик сможет изготовить полуфабрикат.

5. Для особо продвинутых: "Отслеживаем работу поставщика". Это из области фантазии конечно, но можно включить данные по производству поставщика в нашу систему и отслеживать отклонения от графика.

Вот такой расклад.

Идеально эта штука будет работать, когда у всех стоит одинаковая система, что, кстати, в современном мире не редкость

Узнать об этом можно в тренингах 8787A Спецификация (BOM) в Microsoft Dynamics ™ AX 4.0;8791 Производство I (Работа с субподрядными заказами); 8639A Intercompany in Microsoft Dynamics AX 4.0; 8792 Сводное планирование в Microsoft Dynamics AX 4.0 (в части планирования по компаниям).

[ViV]

Дополнительные реквизиты номенклатуры. DAX2009.
почитайте эту ветку

[George Nordic]

Это одна из самых частых модификаций. Почитайте про наборы атрибутов.

С Уважеинем,
Георгий

[mazzy]

Цитата:

Сообщение от George Nordic

Это одна из самых частых модификаций. Почитайте про наборы атрибутов.

Это именно модификации. Не надо делать под эту задачу универсальное решение, которое усложнит задачу внедрения, сопровождения, оптимизации производительности.

Цитата:

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

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

Не надо.
Пожалуйста, не надо выдумывать решения для выдуманных задач.

[sukhanchik]

Цитата:

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

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

Цитата:

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

Не надо.
Пожалуйста, не надо выдумывать решения для выдуманных задач.

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

Я склоняюсь больше ко второму варианту.
В этом случае могу сказать, что нам требовалось дополнительные поля:
Бренд (лукап со справочником)
Категория товара (очередная группировка, лукап со справочником)
Преимущества товара (большое текстовое поле)

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

[mazzy]

Цитата:

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

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

Я склоняюсь больше ко второму варианту.
В этом случае могу сказать, что нам требовалось дополнительные поля:
Бренд (лукап со справочником)
Категория товара (очередная группировка, лукап со справочником)
Преимущества товара (большое текстовое поле)

Не надо! Пожалуйста.

Посмотрите в модуль CRM в Аксапте. Там таких "справочников" пруд-пруди.
Из-за них модуль CRM становится труднообъясняемым.

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

Если уж и создавать дополнительные поля, то вместе с дополнительной логикой.

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

[Ievgenii]

Всем - спасибо за коментарии, большая часть по делу или просто полезно знать.

Цитата:

Sukhanchik, Я склоняюсь больше ко второму варианту.
В этом случае могу сказать, что нам требовалось дополнительные поля:
Бренд (лукап со справочником)
Категория товара (очередная группировка, лукап со справочником)
Преимущества товара (большое текстовое поле)

Sukhanchik, Спасибо за Ваш ответ .

mazzy, George Nordic, blokva

Может Вы сталкивались с неоходимостью добавить какие нибудь поля или какая логика нужна бы еще для номенклатуры?

Цитата:

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

Согласен. но об этом речь не идет

-Женя

[mazzy]

Цитата:

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

Может Вы сталкивались с неоходимостью добавить какие нибудь поля?

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

истинная необходимость с огромной вероятностью кроется в группировках и отборах
http://axapta.mazzy.ru/lib/tree/
http://axapta.mazzy.ru/lib/tree2/
http://axapta.mazzy.ru/lib/tree3/

а универсальный подчиненный справочник сильно затруднит решение основной задачи - быстрый отбор.

Скажу даже больше - если вы задумали повторить 1Совский механизм характеристик номенклатуры, то ОДУМАЙТЕСЬ. ни в коем случае не надо. Потому что по этим характеристикам захочется получать остатки.
http://1c.mazzy.ru/articles/smartquery/

Не надо дублировать функционал складских аналитик.
А для отбора поля легко добавить самостоятельно.

[Zabr]

Цитата:

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

а) для того чтобы сделать универсальное решение для выдуманных задач

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

[mazzy]

Цитата:

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

В KorusAxaptaRetail сделана такая штука, как "Потребительские свойства", N:1 к карточке товара.

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

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

Цитата:

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

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

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

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

[Ievgenii]

mazzy,
Не переживайте . Вы меня опять не правильно поняли ибо делаете ошибочные выводу. Проблема которую Вы сформулировали ясна.

Переформулируем вопрос -
Как часто добовляються новые поля или ассоциируються mandatory отношения на Номенклатуру и какие? На вопрос какие вроде как частично ответили.
1. Всегда
2. Часто
3. Иногда
4. Очень редко


Спасибо.

-Женя

[sukhanchik]

2mazzy: Как раз модуль CRM я успел хорошо посмотреть. И он мне как раз понравился... обилием справочников.
Почему он становится трудно объясняемым? Может из-за того, что люди, которые объясняют не знают, что имеется из информации у менеджеров по продаже?
Да, безусловно - в этом модуле есть свои грехи (типа запросов в статистике продаж). Но как раз с т.з. справочников - он сделан наиболее полно. Просто при объяснении модуля нужно заренее настроить (=взять из демо-данных) весь перечень справочников. И это правильно. У каждой организации - свой набор справочников. Делать жестким енумом то, что должно быть справочником - неправильно.

Я более того скажу - вся вкусность аксаптийного модуля CRM (на мой взгляд) в механизме хранения информации+ведения кампаний. Всякие там корреспонденции+телемеркетинг - это так... чисто для красоты. А остальное - вполне жизнеспособно. Единственное - в чем можно упрекнуть разработчиков - это в попытке сделать "универсальный" конструктор запросов с графиками.

[mazzy]

Цитата:

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

2mazzy: Как раз модуль CRM я успел хорошо посмотреть. И он мне как раз понравился... обилием справочников.
Почему он становится трудно объясняемым? Может из-за того, что люди, которые объясняют не знают, что имеется из информации у менеджеров по продаже?

Эк, ты на меня стрелки перевел.

Нет, как раз те, кто объяснял, отлично знал что за информация у менеджеров.
Проблема в том, что у них меньше информации, чем хочет Аксапта

Цитата:

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

Но как раз с т.з. справочников - он сделан наиболее полно.

тогде тебе стоит посмотреть отдельный MS CRM

Цитата:

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

Я более того скажу - вся вкусность аксаптийного модуля CRM (на мой взгляд) в механизме хранения информации+ведения кампаний.

Согласен.

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

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

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

[Zabr]

Цитата:

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

Возвращаясь к теме данной ветки.
.

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

[Ievgenii]

Цитата:

Zabr
Давно пора. Давайте дадим возможность человеку получить ответ именно на тот вопрос...

mazzy,
Какой функционал обычно добавляется к Номенклатуре и как часто?
1. Всегда
2. Часто
3. Иногда
4. Очень редко

Спасибо
-Женя

[mazzy]

Цитата:

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

mazzy,
Какой функционал обычно добавляется к Номенклатуре и как часто?
1. Всегда
2. Часто
3. Иногда
4. Очень редко

Спасибо
-Женя

Часто:

• распределение накладных расходов по весу/объему и другим признакам
• распределение накладных расходов на разные закупки от одного/нескольких поставщиков с одинаковыми/разными номенклатурами.
• печать разных номенклатур в разные документы (например, если заказ содержит номенкл1 и номенкл2, И они должны попасть в разные документы, то будет напечатано две накладных)
• отбор по номенклатурным признакам принятым в организации (номенклатурные признаки могут быть произвольными и необязательными)
• запрет резервирования некоторых номенклатур или ввод ограничений для резервирования.
• ограничение скидок + возможность одобрения этих скидок ответственными менеджерами
• ограничение изменения цен для некоторых номенклатур (простое)
• ограничение изменения цен и скидок для некоторых номенклатур, чтобы чистая сумма не была меньше "себестоимости" (под себестоимостью может пониматься разные вещи )
• более развитый функционал для автоустановки складской цены (которая нужна для складских журналов). Сейчас есть только галочка Последняя цена закупки.

Иногда:

• распределение отгрузки во времени. например, номенклатуру1 отгружаем по понедельникам, а номенклатуру2 отгружаем по вторникам и т.п. (зачастую дополнительно добавляются группы у клиентов и пересекается с производственными свойствами).
• запрет продажи некоторых номенклатур некоторым клиентам/филиалам
• более развитый механизм поиска альтернатив (это большая тема), в том числе резервирования альтернатив
• более развитый функционал для развертывания спецификаций в заказах. Сейчас только ручная команда
• поиск сопутствующих товаров.
• поиск совместимых номенклатур. Например, поискать зарядку для iPhone, если чел купил его, или поискать зарядное устройство для КПК или поискать зарядное устройство для заданной модели телефонов (Внимание! некоторые зарядные устройства могут подходить для разных моделей). Задача сильно перекликается с задачей отбора по разным номенклатурным признакам.

Редко:

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

Думаю, что часто добавляемый функционал еще накидают другие.