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

[pitersky]

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

[Narayana]

Цитата:

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

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

Так я и пытаюсь работать над конкретным проектом по продаже запчастей для автомобильных агрегатов.
В справочнике продуктов мне нужны дополнительное поле "Manafacturer".
Получить это поле в виде атрибута на данном этапе разработки прототипа Аксапты 2012, запущенным Майкрософтом в коммерческую эксплуатацию, не представляется возможным по двум причинам. Во-первых, даже если завести атрибут в таблицах атрибутов, типов атрибутов и т.д., атрибут все-равно не доступен ни в форме продуктов, ни в форме реализованных продуктов. Типа, нажимаешь пиктограмму "атрибуты", возникает форма с недоступными грустными серыми полями.
Во-вторых, потому что, уж коли есть атрибут для товара, отображаться он должен среди полей на главном поле товара, а не лежать где-то за щекой. Просто представьте себе ситуацию, когда пользователь листает записи номенклатур и чтобы посмотреть производителя, всякий раз открывает дополнительную форму.
Значит, нужно дорабатывать таблицы и формы, внося свои поля и протаскивая через весь алгоритм программной обработки в Catalog FrameWork.
И это в системе, которая еще десять раз поменяется и, вообще, непонятно, выживет или нет.

[Narayana]

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

[pitersky]

Цитата:

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

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

и

Цитата:

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

Взялись мы с приятелем сделать тестовый пример некоторого цикла работы по умозрительному бизнес-процессу по торговле запчастями

несколько отличны по смыслу. ну да ладно.
Мне с атрибутами тоже не понравилось работать. Аналогичную по смыслу задачу решил, добавив в InventTable поле Manufacturer со ссылкой на VendTable. Там, правда, не было проблем с названием, всех только код интересовал.

[Narayana]

Цитата:

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

и

несколько отличны по смыслу. ну да ладно.
Мне с атрибутами тоже не понравилось работать. Аналогичную по смыслу задачу решил, добавив в InventTable поле Manufacturer со ссылкой на VendTable. Там, правда, не было проблем с названием, всех только код интересовал.

м-м-м... проект конкретный, но перед тем, как вводить рабочие данные, пробуем полный цикл оборота данных...

Вы добавили новое поле только в InventTable?
То есть, пропустили весь процесс перехода данных из EcoResProduct в InventTable? А данные в InventTable импортируете из внешнего источника или как?

[R.Safianov]

Цитата:

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

? А данные в InventTable импортируете из внешнего источника или как?

Насколько мне известно шаблон в ECO. Но после распределения по юр.лица он перетягивается в Invent. Типа релизинг продуктов из общей портянки.

[Narayana]

Цитата:

Сообщение от R.Safianov

Насколько мне известно шаблон в ECO. Но после распределения по юр.лица он перетягивается в Invent. Типа релизинг продуктов из общей портянки.

Это, как бы, предписанный алгоритм работы, но, если речь идет о добавлении поля в InventTable и недобавлении его в EcoResProduct, то "перетягивание" шаблона из EcResProduct в InventTable становится некорректным из-за потери данных в новом поле.

[Ivanhoe]

Цитата:

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

Это, как бы, предписанный алгоритм работы, но, если речь идет о добавлении поля в InventTable и недобавлении его в EcoResProduct, то "перетягивание" шаблона из EcResProduct в InventTable становится некорректным из-за потери данных в новом поле.

Но тут нужно понимать, для каких целей вы используете шаблон EcoRes? Формально он сделан для консолидации данных по номенклатурам между несколькими компаниями и в нем есть только те поля, которые по задумке авторов не зависят от компании. Остальные поля - это уже конкретика конкретной компании.

По полю Производитель можно, наверное, разные аргументы приводить и за, и против добавления в шаблон. Но в целом у меня вопрос: у вас несколько компаний? Если нет - создавайте всегда "Используемый продукт" и добавляйте такие поля в InventTable. Намного проще будет во всех формах этим пользоваться.

P.S. чтобы пользоваться аттрибутами, надо настроить категории через модуль Ритейл - там задаются аттрибуты / группы аттрибутов по веткам, после этого аттрибуты будут создаваться для номенклатуры автоматически и можно будет задать их значения.

[R.Safianov]

Цитата:

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

Это, как бы, предписанный алгоритм работы, но, если речь идет о добавлении поля в InventTable и недобавлении его в EcoResProduct, то "перетягивание" шаблона из EcResProduct в InventTable становится некорректным из-за потери данных в новом поле.

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

Соответственно как было замечено ниже вам важно ответить на следующие вопросы:
1) Параметр "производитель" общий для всех компаний?
2) Лицо заполняющее шаблон может однозначно определить этот параметр?
3) Не будет ли изменяться этот параметр?
Если ответы на эти вопросы утвердительные, то в вашем случае можно добавить и в Eco и Invent. В противном случае только в Invent. И уже работать с параметром в разрезе конкретного юр. лица.

[Мартынов Дмитрий]

Цитата:

Сообщение от R.Safianov

Насколько мне известно шаблон в ECO. Но после распределения по юр.лица он перетягивается в Invent. Типа релизинг продуктов из общей портянки.

Кстати DysplayProductNumber 70 символов.
А при подтверждении получаем ItemId длинной 20

Я слышал мнение, что модуль EcoRes - это модуль купленный у какого то интегратора. Едва ли... Когда интегратор пишет модуль он обычно пишет его под конкретный проект (фиксированная сумма - надо уложиться) или впрок, тогда бюджет еще меньше...

Здесь же случай явно иной. Здесь явно задача была раздуть бюджет... Такое огромное количество бессмысленного когда, как бы, на все случаи жизни. Формы с небоскребами dataSource. Везде где можно сделать связь через дополнительную таблицу, она сделана и там где нельзя (бессмысленно) тоже... "Как бы" потому, что жизнь вполне предсказуема а случаи, видимо, взяты из любых вселенных только не из нашей. Элементарные правила графических интерфейсов не соблюдены, случайный клик мышки без переспрашивания удаляет группу атрибутов у кучи товаров -- и иди потом их восстанавливай из бекапа. Горы кода на формах и т.д.

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

[R.Safianov]

Цитата:

Сообщение от Мартынов Дмитрий

Кстати DysplayProductNumber 70 символов.
Мы конечно не лыком шиты, и глаз у нас пристрелявши... вошь заморскую куем.. куем.. и подкуем... Но уж больно тянет обложить ее и этим самым куем и другими регулярными выражениями...

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