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

[Narayana]

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

Взялись мы с приятелем сделать тестовый пример некоторого цикла работы по умозрительному бизнес-процессу по торговле запчастями.
Думаем, сейчас забьем данные в справочник номенклатур, а потом попробуем посоздавать заказы на покупку и на продажу. А вместе с тем, думаем, посмотрим, в какие таблицы ложатся данные..., но...
Че-то у нас не получается все гладко и понятно.
В 2009-ой, как раз, это все понятно. А в 2012... не то, чтобы совсем непонятно... а как-то все, мягко говоря, очень непривычно. Типа, открываешь таблицу EcoResProduct, а там DysplayProductNumber есть, а ProductName - нету... Оно, вроде бы, понятно, что имена разные на разных языках и лежат в отдельной таблице, но все-равно как-то неуютно.

Щас скажу одну вещь, которая может показаться глупостью, но все-таки скажу... )
Вот у нас есть какая-то конкретная номенклатура (или продукт - даже не знаю, как сейчас правильно говорить...) Вроде бы, мы должны иметь возможность просто эту штуку искать в системе. Причем, однозначно идентифицировать набор данных, относящихся к этой номенклатуре. Когда все поля, относящиеся к номенклатуре в одной таблице, у нас есть ощущение, что эти поля не перепутаются. Просто потому, что они объединены записью в одной таблице.
А вот когда данные, относящиеся к одной номенклатуре разнесены по разным таблицам, сразу возникает беспокойство, - а что, если что-то съедет на одну позицию в связях между таблицами, вся картина поплывет?
То есть, получается, что нет центральной записи, определяющей однозначно номенклатуру. Есть совокупность записей. Или все-таки плясать нужно от записи в EcoResProduct?

В связи с этим хотел бы задать вопрос, - а кто-нибудь уже освоился с этой парадигмой учета номенклатур в 2012R2?
Хотелось бы понять немного о разнесении смысловой нагрузки между таблицами и хотя бы как-то представить себе последовательность действий при работе с номенклатурами. В хелпе перечисляются поля, но и только....

[Ievgenii]

Бодрый день, Описано тут http://blogs.msdn.com/b/dynamicsaxsc...e-upgrade.aspx

Implementing the Item-Product Data Management Framework - Highlights the new patterns that are used to represent item-product master data. When detailing the new patterns, the document also describes the pattern that is being replaced and how developers should approach updating their code.

Также в последней книге об АX отдельная глава есть :0)

[Narayana]

Цитата:

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

Бодрый день, Описано тут http://blogs.msdn.com/b/dynamicsaxsc...e-upgrade.aspx

Implementing the Item-Product Data Management Framework - Highlights the new patterns that are used to represent item-product master data. When detailing the new patterns, the document also describes the pattern that is being replaced and how developers should approach updating their code.

Также в последней книге об АX отдельная глава есть :0)

Листаю оглавление книги "Microsoft Dynamics AX 2012", которую доставили недавно, но никакой главы про номенклатуры не нахожу...

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

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

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

[Evgeniy_R]

Цитата:

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

При необходимости добавления полей, характеризующих номенклатуру, непонятно, в какую таблицу их добавлять.

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

Для этих целей в AX2012 была заложена идея, что вообще не нужно добавлять новых полей, характеризующих номенклатуру. Нужно пользоваться атрибутами номенклатур. Однако, как я понял в этой версии использование этой функциональности несколько ограничено, в последующих этот функционал будет расширяться в т.ч. и по удобному использованию этих атрибутов.
Но копать стоит именно сюда J

[sukhanchik]

Цитата:

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

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

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

[Evgeniy_R]

Цитата:

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

Эх... вот так всегда - начинается все с атрибутов под флагом "не надо никаких полей" и заканчивается тем, что в отчете "Мой любимый отчет" нужно убиться, чтобы вывести эти атрибуты.

Боюсь, что в новой системе придется с этим жить. Я тоже не говорю, что почти любая модификация, которая в 2009 делалась x часов, теперь делается x*3 часов, про тестирование вообще молчу.
Поэтому использование того, что сверху на нас снизошло - единственный верный путь, который нам остается. К тому же с той скоростью, с которой выходят обновления, ломающие метаданные, постоянный накат модиф и повторное их тестирование на корню убивает мотивацию о разработке чего-либо нового. Все это мое мнение разумеется, надеюсь, что со временем оно и поменяется...

[sukhanchik]

2Ievgenii:
Во-первых большое спасибо за документы и ссылки.
Во-вторых - я конечно сейчас спрошу глупость - но раз документы писал человек, которому не чужд "великий и могучий" русский язык - то:
1. Не осталось ли каких-либо (пусть даже черновых) документов, которые бы являлись бы прототипом данного документа, но на русском языке? Ну т.е. собственно говоря интересуют не столь сами документы - сколь их содержимое - т.е. я думаю - что вряд ли кто из участников форума будет сильно против такого же документа, но на русском языке, причем полученного не машинным переводом, а можно сказать от первоисточника. Если конечно это не нарушает Ваши обязательства перед Microsoft.

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

2. Нет ли информации - собирается ли Microsoft выполнять работу по переводу такого рода документов на русский язык, но только не машинным переводом, а нормальным, осознанным, человеческим?

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

[Ivanhoe]

Вопрос к автору. А чем не устраивает старая добрая InventTable? И как вы относитесь к старым InventTableModule, InventItemLocation?

[Narayana]

Цитата:

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

Вопрос к автору. А чем не устраивает старая добрая InventTable? И как вы относитесь к старым InventTableModule, InventItemLocation?

Сейчас речь не столько о том, что что-то не устраивает, сколько о том, чтобы разобраться что к чему.
А старая добрая InventTable перестала быть доброй. Хотя бы из-за того, что из нее исчезло поле ItemName.
Это, конечно, очень интуитивные ощущения, но таблица перестала содержать все данные, однозначно идентифицирующие товар.
Никак не могу найти правильной терминологии, но раньше все время было ощущение, что изначально должна быть ОДНА таблица, в которой бы каждая строка однозначно определяла бы факт некоторой эталонной единицы предмета. И при этом по совокупности полей мы могли бы осуществить поиск этой эталонной единицы.
Затем можно делать все, что угодно. Добавлять таблицы с размерами, цветами, местами хранения, но центральное место, где можно было бы указать на присутствие номенклатуры в системе, это InventTable.
При этом логика экспорта-импорта данных по номенклатуре простая и прозрачная. А это очень важный момент в любой торговой компании.
Сейчас вы уже не можете работать со старой доброй InventTable также как раньше просто потому, что в одной этой таблице вы уже не сможете найти товар без поля названия.

[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. Типа релизинг продуктов из общей портянки.

[Maxim Gorbunov]

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

[father_frost]

Не могли бы рассказать подробнее, как пользоваться?

[Maxim Gorbunov]

http://technet.microsoft.com/en-us/l.../gg731850.aspx

[plumbum]

Есть View EcoResProductAttributeValue, с помощью которого можно хитрым путем организовать поиск по аттрибутам. Кроме него на форму как источник данных добавляем EcoResProduct и (ну к сожалению) через Union Query все стандартные типы значений. На выходе можно полуить грид с количеством колонок, соответствующим количеству типов данных (это значение) + продукт + название атрибута.
В свое время работал с решением для аттрибутов, где все значение конвертировались также в строку (ну это уже обсуждалось на форуме EVGL) - вот там поиск был удобный.

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

Цитата:

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

Есть View EcoResProductAttributeValue, с помощью которого можно хитрым путем организовать поиск по аттрибутам. Кроме него на форму как источник данных добавляем EcoResProduct

Там только RecId атрибута, продукта и значения. Т.е. для получения имен атрибутов надо еще джойниться с EcoResAttribute. Для поиска по значениям надо джойниться с EcoResValue. При этом надо иметь ввиду что EcoResValue -- это не одна таблица, а букет из EcoResTextValue, EcoResDateTimeValue, EcoResCurrencyValue..... и т.д.

Алгоритм поиск продукта по значению атрибута:
1. Находим атрибут в таблице EcoResAttribute
2. Определяем его тип атрибута по таблице EcoResAttributeType по полю DataType,
3. В зависимости от типа выбираем правильную таблицу из длинного списка EcoResTextValue, EcoResDateTimeValue, EcoResCurrencyValue..... и т.д.
4. Находим в ней записи по значению атрибута.
5. Для каждой из найденных в п.4. находим запись во View EcoResProductAttributeValue, (по атрибуту и значению) и если эта запись есть то в ней будет RecId искомого продукта(ов).