ax2012: Чем отличаются "product" и "product master"?

[mazzy]

ax2012: Чем отличаются "product" и "product master"?

не путать с "product" и "released product"!

да, я знаю какие функции и кнопки включаются и выключаются.
но хотелось бы понять смысл этого различия. Зачем сделали именно так? Чего хотели то?

https://www.youtube.com/watch?v=BLXF0abCwuI

ветку Культура работы с номенклатурами в AX2012R2
читал.

[EVGL]

"Master" могут быть конфигурированы. Имеется в виду, что может быть несколько вариантов. Зачем отдельный тип городили мне тоже непонятно. Наверное потому, что в те времена разработчики в Копенгагене очень увлекались наследованием таблиц и пихали это везде, где им это приходило в голову.

[mazzy]

Цитата:

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

"Master" могут быть конфигурированы. Имеется в виду, что может быть несколько вариантов.

Это то понятно. Это описание через функции.

Но в Майкрософте каждую фичу сначала должен описать Program manager (консультант), это описание должны одобрить Архитекторы и Начальники, потом Engineer (программист) должен закодить, затем Program manager должен протестить получившееся.

Причем если функционал отсутствует, то можно предположить, что "забыли".
Но на функционал product master потратили достаточно много сил и времени (судя по коду).

Я сильно сомневаюсь, что изначально эта фича формулировалась в виде "могут быть сконфигурированы". Наверняка была другая бизнес-цель.

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

Зачем они вообще это создали? Как обосновывали? Может кто в презентациях или в документации видел?

[Stitch_MS]

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

[mazzy]

Цитата:

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

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

я работал там как раз во времена этого "Agile".
не настолько "могли".

как бы ни начиналось, все равно сначала надо обосновать и пройти triage Архитекторами и Начальниками. Собственно triage и определяет продукт, что в продукте важно, а что не важно, как продукт будет выглядеть для внешнего мира.

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

Я абсолютно уверен, что цель "могут быть сконфигурированы" не прошла бы triage. Должно быть какое-то другое обоснование.

[S.Kuskov]

Разве это не новая реализация старого функционала ConfigTable?

[mazzy]

Цитата:

Сообщение от S.Kuskov

Разве это не новая реализация старого функционала ConfigTable?

исходный вопрос: ax2012: Чем отличаются "product" и "product master"?
как связан ваш ответ с исходным вопросом?

если вы хотели сказать, что "product master" (и вся безумная обвязка вокруг "product master") сделан чтобы реализовать старый функционал ConfigTable...
то не думаю, поскольку легче было тупо повторить ConfigTable.
А здесь явно старались что-то сделать.

Да, согласен, что видимое проявление различия - у "product" нет Вариантов, а у "product master" есть варианты. Но зачем?

===============
для примера я попытаюсь дать ответ на другой вопрос: чем отличаются "product" и "released product"?
product - это записи о продукте на уровне всех компаний холдинга (общая таблица EcoResProduct).
released product - это записи о продукте на уровне каждой отдельной компании (номенклатура InventTable)

released product создаются на основании product.
released product могут быть разными в разных компаниях - в одной это BOM, в другой это товар, лежащий на складе в ячейках, в третьей это может быть вообще продаваемая услуга.
Аксапта может понять что разные released product являются одним и тем же продуктом, проанализировав ссылку на product.
Product помогает Аксапте автоматически создавать интеркомпани цепочки закупок-продаж в разных компаниях одного холдинга.

раньше для интеркампани использовались "Внешние коды", которые надо было настраивать для каждой компании отдельно (топология Граф).
теперь для интеркампани используется набор таблиц с топологией "Звезда", где в центре Зведы находится "product".

===============
если попытаться дать подобное декларативное описание product и product master, то получится примерно так:

product - это записи о продукте на уровне всех компаний холдинга (общая таблица EcoResProduct).
product master - это записи о ???? на уровне всех компаний холдинга (таблица EcoResProductMaster, которая наследует от EcoResProduct)
функционально product и product master никак не связаны - это просто две реализации какого-то другого понятия. ???Какого???

для product нельзя задать аналитику номенклатуры и нельзя задать "Варианты"
для product master можно задать аналитику номенклатуры и можно задать "Варианты".
???зачем???

т.е. это какое-то бредовое описание.
либо я чего-то базового не понимаю.

собственно поэтому и вопрос:
ax2012: Чем отличаются "product" и "product master"?

[fed]

Цитата:

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

если попытаться дать подобное декларативное описание product и product master, то получится примерно так:

product - это записи о продукте на уровне всех компаний холдинга (общая таблица EcoResProduct).
product master - это записи о ???? на уровне всех компаний холдинга (таблица EcoResProductMaster, которая наследует от EcoResProduct)
функционально product и product master никак не связаны - это просто две реализации какого-то другого понятия. ???Какого???

для product нельзя задать аналитику номенклатуры и нельзя задать "Варианты"
для product master можно задать аналитику номенклатуры и можно задать "Варианты".
???зачем???

т.е. это какое-то бредовое описание.
либо я чего-то базового не понимаю.

собственно поэтому и вопрос:
ax2012: Чем отличаются "product" и "product master"?

Честно говоря - неоднократно задавался тем же вопросом но как-то времени разобраться не было. После твоего описания, начал подозревать что:
Product - это не самом деле идея или прототип продукта (просто микрософт нормальный PLM пока не сделал). То есть - регистрируем продукт "брюки мужские, стиль карго, больших размеров". Потом над ним маркетологи и дизайнеры работают, и в итоге получаем Product Master, у которого конкретные доступные размеры, стили и цвета указаны.

[mazzy]

Цитата:

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

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

Заманчивая идея. Когда вышла 2012 я так в своей голове и представлял. до тех пор пока не пришлось разбираться досконально.

Реальность:
Product Master нельзя создать на основании Product.
Product нельзя создать на основании Product Master.
Нужно создать или Product, или Product Master.

Теоретически между Product и Product Master можно сделать связь через Related Product.
Но это совсем не то.

[EVGL]

Цитата:

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

собственно поэтому и вопрос:
ax2012: Чем отличаются "product" и "product master"?

Контр-вопрос: сколько ангелов помещаются на острие иглы?

[Raven Melancholic]

Ну связать это можно не только продукт-мастер продукт, а и продукт-продукт, мастер продукт - мастер продукт и кроме как в каталоге для ритейла нигде не видел использования этого.
Зачем сделано разделение непонятно, но мешать может здорово.
Только, ради точности смотреть нужно не различие между просто Product и MasterProduct, а между DistinctProduct и MasterProduct.
Почему это разделение, а не используется просто Product с настройками типа "Конфигурируется ли и как" ну и есть/нет аналитики продукта?
Тем более, что DistinctProduct вообще ничего не добавляет к Product, а MasterProduct как раз добавляет только конфигурируемость (если не считать немного для ритейла).
В общем на вопрос "зачем" кроме авторов ответить никто не сможет.

[Raven Melancholic]

Можно предположить, что при начале работы были большие планы расширения MDM части и, возможно, что планировалось реализовать какие-то вещи, для которых это разделение было важно, но планы остались планами.
Хотя опять же это просто одно из предположений, таких гаданий можно придумать немало.

[mazzy]

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

• product - продукт
• product master - конфигурируемый продукт
• released product - номенклатура

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

кстати, и сам модуль можно назвать "Продукты и номенклатура"

буду рад вашим замечаниям и предложениям.

[mnt_dx]

Цитата:

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

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

• product - продукт
• product master - конфигурируемый продукт
• released product - номенклатура

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

кстати, и сам модуль можно назвать "Продукты и номенклатура"

буду рад вашим замечаниям и предложениям.

Так и что же стало лучше?

[Владимир Максимов]

Цитата:

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

Так и что же стало лучше?

Лично для меня "Шаблон" = "Образец", "Трафарет"

По моему, в данном случае, термин "Шаблон" скорее вводит в заблуждение относительно содержимого. Привыкнуть-то можно, конечно...

Но вообще-то, и "product master" также неудачный термин. Какой же он "master", если все с точностью наоборот. Он как раз зависимый, подчиненный, относительно product. В общем, странными путями у них мысли бродят Хотя, да, "бродят" же...

[mazzy]

Цитата:

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

Так и что же стало лучше?

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

Свел в таблицу для тех, кто слабо знаком с ax2012:

[EugeneZ]

Вариант 1: Продукт, который мы с течением времени собираемся развивать (например, ПО для разных стран). Изначально выпускаем версию 1.01, которую продаем в 3 странах, на эту версию определяем срок поддержки с/по и один язык. При этом понимаем, что будут новые релизы, когда они будут, и сколько мы их буде поддерживать, на данный момент не известно. Создаем Master product с одной конфигурацией и релизим его в 3 компании. С течением времени появляются новые версии (каждый релиз - новая конфигурация, новый distinct product). К версии 1.хх появилось еще 2 языка - создали новую конфигурацию - зарелизили их еще в 2 компании.

Т.е. с т.з. управления MDM, нам нужна объединяющая сущность (Master product), к нему будут привязаны картинки, маркетинговые материалы, ссылки на статьи для операторов кол-центров, ряд каких-то атрибутов, а есть его чем-то отличающиеся с т.з. потребителя реализация (не технологии производства - это были бы версии спецификаций) - версия, срок окончания поддержки, специфическая документация.
Для пищевой промышленности мы можем со временем заменять ингредиенты, что для потребителя, возможно, и не будет важным, но мы должны будем настроить новые значения атрибутов (например, калорийность, содержание белков, жиров..), документацию (технико-технологические карты, которые еще и для разных стран будут на разных языках). А поскольку модуль позиционируется не как Inventory management, а как Product information management, делается некий задел под возможную интеграцию с внешними системами, где может потребоваться новый ItemId со своим внешним кодом.

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

Получается так, что если мы понимаем с самого начала, что продукт будет иметь не один жизненный цикл, а будет видоизменяться, развиваться, то делаем product master и по мере надобности релизим.
Если еще проще - продукты собственного производства делаем product master, сырье, материалы, полуфабрикаты - product

[mazzy]

Цитата:

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

...Master product...

принимается.

Цитата:

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

Получается так, что если мы понимаем с самого начала, что

а если не понимаем, то что делать?

Цитата:

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

продукты собственного производства делаем product master, сырье, материалы, полуфабрикаты - product

а зачем так?
почему не использовать product master для всех случаев?

в чем смысл и прикол использовать именно product, когда есть product master?

[EugeneZ]

Цитата:

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

принимается.

а зачем так?
почему не использовать product master для всех случаев?

в чем смысл и прикол использовать именно product, когда есть product master?

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

[mazzy]

Цитата:

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

Не везде же нужны продуктовые аналитики.

не везде, согласен.
если они не нужны, то их можно не заполнять в product master.
product не нужен.

Цитата:

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

Поэтому там, где нет необходимости с разными вариантами, мастер обходим стороной.

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

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

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

Анекдот:
- ты понимаешь что просиходит?
- я тебе сейчас объясню
- объяснить то и я могу