Культура работы с номенклатурами в 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)

[sukhanchik]

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

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

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

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

[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 часов, про тестирование вообще молчу.
Поэтому использование того, что сверху на нас снизошло - единственный верный путь, который нам остается. К тому же с той скоростью, с которой выходят обновления, ломающие метаданные, постоянный накат модиф и повторное их тестирование на корню убивает мотивацию о разработке чего-либо нового. Все это мое мнение разумеется, надеюсь, что со временем оно и поменяется...

[Narayana]

Цитата:

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

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

...из советского анекдота

- Милок. а коммунизм ученые или коммунисты придумали?
- Коммунисты...
- Вот и я думаю, коммунисты. Ученые сначала б на собаках попробовали...

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

[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. И уже работать с параметром в разрезе конкретного юр. лица.

[Narayana]

Цитата:

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

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

Для консолидации, это понятно.
Я использую EcoRes, поотому что без него просто нельзя обойтись в системе.
Либо вы делаете сначала шаблон, а потом его реализуете в конкретной компании, либо вы создаете Item сразу для конкретной компании, но при этом шаблон все-равно автоматом создается. Говорить о присутствии полей в конкретной компании и отсутствии их в шаблоне, - это как-то непонятно.
Ну, должно у меня быть поле производителя, значит оно должно быть и в шаблонах, и в конкретных номенклатурах. Просто потому, что без него невозможно правильно идентифицировать товар.

Цитата:

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

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

Я пытаюсь совокупить Ax2012 и неоригинальный интернет магазин, так как оригинальный пока не работает и когда будет нормально работать, пока непонятно. В связи с этим у меня остро стоит вопрос синхронизации данных каталогов товаров в интернет-магазине и в Аксапте. При этом производитель должен быть там и там. Соответственно, если я делаю производителя только в InventTable, я, действительно, не смогу создать еще одну компанию и шаблонный каталог товаров будет нечитаемым. Причем, чтобы это исправить после добавления поля в шаблоны товаров, нужна будет утилита добавления значений в это поле.
Значит, лучше делать поле сразу везде и заботиться о том, чтобы при реализации товара его значение переносилось в ItemTable, а при прямом создании реализованных номенклатур обратно в шаблоны.

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

Цитата:

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

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

Попробовал. Да, действительно, работает. Но, при этом атрибут нужно смотреть, открывая отдельную форму. Неудобно. И как искать по этому атрибуту? И нельзя выбрать значение атрибута из выпадающего списка. Или можно?