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

[Vals]

Цитата:

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

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

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

А в "тройке" была галка "конфигурируемый" и она за всё отвечала )))

[EVGL]

Цитата:

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

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

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

[Raven Melancholic]

Опять же, чтобы не противоречить в терминах, нужно определиться.
Уже не раз были фразы типа «отличия продукта (Product) от мастер-продукта (Product-master)», «создаем либо продукт, либо мастер-продукт» и т. п.
Ну нельзя создать просто «Продукт», можно создать либо «Мастер-продукт» (в русском переводе «Шаблон продукта»), либо то, что вызывает вопросы в терминологии – в интерфейсе это действительно Product (в русском переводе «Продукт»), а вот в названии таблицs более корректное DistinctProduct (в руссом переводе почему-то «Товары», хотя в это что-то есть).
Предлагаю в дальнейшем использовать термины Product-master (пусть будет «Шаблон продукта») и Product-Distinct (тут пока непонятно для русского термина, возможно пусть как в метке «Товары» или что-то подобное «отдельный», «определенный» продукт).

[Raven Melancholic]

Понятно, что рассуждения, что Product-Distinct это что-то общее, что потом будет конвертировано в Product-master ошибочные – нет такой конвертации, как нет и обратной. Общее/частное можно рассуждать в понятиях Product-Master/Product variant (Шаблон продукта/Вариант продукта) ну и далее при создании используемого продукта (в русском переводе, ставящее всех в тупик «Элементы»).
В стандарте как создали, так с этим и живем, даже если ни разу не использовали. С точки зрения AOT это даже разные таблицы, в RTM и физически это были разные таблицы в базе данных.
Конечно, можно самостоятельно написать (думаю, что уже кто-то и написал) конвертацию, но тут явно придется обновление делать прямыми запросами, меняя InstanceRelationType и затем либо создавать, либо очищать кучу связанных данных (это уже можно делать на X++).

[Raven Melancholic]

Цитата:

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

Ничего в этом отношении не изменилось. Преобразование "Свой" и теперь можно использовать только для номенклатуры без аналитик продукта (ранее номенклатурных аналитик), то есть в новых терминах для Product-distinct. Несмотря на то, что EcoRec* и связанные таьлицы общие и явно во всех компаниях есть варианты одного продукта, попытка использовать "Свой" для используемого продукта, если оно сделан на основе Master-product, при работе даст RunTime ошибку, что "Нельзя использовать Свой для вариантного продукта".

[Raven Melancholic]

Да, еще при конвертации помимо замены InstanceRelationType при конвертации из Distinct в Master нужно будет в некоторых полях заменить null на какое-то подходящее значение (возможно даже тоже пустое, но с точки зрения Аксапты), а при обратном преобразовании наоборот заменить на null (хотя нужно ли это не проверял, может быть будет работать и то, если там остались какие-то значения - оставление null при конвертации из Distinct в Master точно дает проблемы).

[Raven Melancholic]

Цитата:

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

Не, не получится. Точнее пока работаем с MDM (EcoRes*) то можем делать глубокомысленное задумчивое лицо, что это так и нужно. Но только понадобится начать использовать это и потребуется создать используемый продукт в какой-то компании, то получим ошибку, что в общем-то нечего использовать.