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

[Ievgenii]

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

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


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

[DSPIC]

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

[Ievgenii]

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

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

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

[Vals]

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

Zitat:

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

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

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]

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

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

[blokva]

Zitat:

Zitat von Ievgenii

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

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

[mazzy]

Zitat:

Zitat von George Nordic

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

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

Zitat:

Zitat von Ievgenii

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

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

[sukhanchik]

Zitat:

Zitat von Ievgenii

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

Zitat:

Zitat von mazzy

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

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

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

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

[mazzy]

Zitat:

Zitat von sukhanchik

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

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

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

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

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

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

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

[Ievgenii]

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

Zitat:

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

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

mazzy, George Nordic, blokva

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

Zitat:

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

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

-Женя

[mazzy]

Zitat:

Zitat von 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]

Zitat:

Zitat von sukhanchik

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

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

[mazzy]

Zitat:

Zitat von Zabr

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

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

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

Zitat:

Zitat von Zabr

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

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

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

[Ievgenii]

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

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


Спасибо.

-Женя

[Zabr]

Zitat:

Zitat von mazzy

.
отобрать номенклатуру по этим свойствам нельзя.

Отобрать можно.

Zitat:

Zitat von mazzy

.
остатков нет.

В стандартной Аксапте масса других свойств номенклатуры, по которым тоже не ведутся остатки.

Zitat:

Zitat von mazzy

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

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

[sukhanchik]

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

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

[mazzy]

Zitat:

Zitat von Ievgenii

Не переживайте .

Уф... Спасибо. Утешили.
А то бывают случаи... Потом волосы на ж... начинаешь рвать, но уже поздно.

Чтобы подойти к вопросу серьезно, то может расскажете зачем вам это нужно?

На моей памяти есть два типа добавляемых полей:
1. влияющие на отбор
1.1. необязательные (таких большинство): производитель, отрасль, "дефицитность", параметры самой номенклатуры для отбора (тип экрана, тип чернил, напольный/настольный и т.п.)
1.2. обязательные (таких меньшинство): артикул, производитель.

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

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

[mazzy]

Zitat:

Zitat von Zabr

Отобрать можно.

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

Zitat:

Zitat von Zabr

В стандартной Аксапте масса других свойств номенклатуры, по которым тоже не ведутся остатки.

И это повод добавлять еще один "универсальный механизм"?

[Ivanhoe]

2 mazzy: если уж вынесли обсуждение о KORUS | Retail в отдельную ветку, стоит туда перенести и ваши комментарии по нему, нет? И там уже по списку пройтись. А то как-то голословно получается..