выгоды перехода с 2009 на 2012

[wojzeh]

коллеги, кто уже пощупал в мясе или набрался маркетинговой мудрости!

интересуют преимущества перехода с 2009 на 2012 можно чётко обозначить для компании, которая кастомизировала решение для дистрибуции товаров лёгкой промышленности (учёт в разрезе дополнительных характеристик: цвет, размер и т.п.)

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

прошу высказываться!

[ansoft]

Цитата:

выгоды перехода с 2009 на 2012

Пока приходят на ум только следующие маркетинговые и политические мотивы:
1) Освоение огоромного бюджета (переход будет дорогим), возможно откаты
2) Показать работу... ради работы, занять людей (переход будет веселым с длительной подготовкой)
3) Ну может еще... не отстать от европы всей (из патриотических мотивов), хотя европа обычно не спешит тратить деньги, если только не п.1, реже п. 2 (а Россия как всегда всех обгонит и перегонит и потешит свое эго)

[pitersky]

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

[mazzy]

Цитата:

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

1) Освоение огоромного бюджета (переход будет дорогим), возможно откаты
2) Показать работу... ради работы, занять людей (переход будет веселым с длительной подготовкой)
3) Ну может еще... не отстать от европы всей (из патриотических мотивов), хотя европа обычно не спешит тратить деньги, если только не п.1, реже п. 2 (а Россия как всегда всех обгонит и перегонит и потешит свое эго)

ну... если автор сообщения не видит других причин... то это больше говорит об авторе - "у кого чего болит..."

Цитата:

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

коллеги, кто уже пощупал в мясе или набрался маркетинговой мудрости!

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

но вопрос точно стоит разделить на две части:
1. международная аксапта в международной компании
2. локализованная аксапта в российской компании

про локализацию точно говорить рано.
поскольку пока нет информации даже о том, как именно будут поднимать локализацию на ax20012 (а изменилось многое)

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

2.2. если компания без активной подписки на обновление, то нужно к стоимости затрат на программирование/поднимание добавить стоимость возобновления подписки.

если стоимость перехода сопоставима со стоимостью поддержки, то думать о переходе международной компании стоит.
это про суммы.

====================
про вкусности снова вопрос разделяется на два:
3.1. вкусности для пользователей
3.2. вкусности для программистов

3.2.1.
вкусности для пользователей пока для меня лично неочевидны. ну да, новый функционал. ну да, новый интерфейс. но стоит ли переходить международной компании из-за этого - надо решать в конкретном случае.

вкусности для программистов.
3.2.1. несомненным плюсом являются "улучшения отчетов SSRS"
наконец-то они не выглядят инородным телом, как в ax2012.
хотя и там есть масса гадостей и подводных камней, в ax2012 отчеты делать будет проще.

3.2.2. составные поля, естественные ключи.
axdaily: Surrogate keys in AX 2012
категорически изменяет всю концепцию программирования в Аксапте.
в чем-то будет проще, а в чем-то сложнее программировать.
ясно одно - пользователи ЭТО спрашивали постоянно.

если в вашем старом приложении ЭТО было камнем преткновения - переходите и будет вам щастье.

3.2.3. ну, и масса другого "по мелочи"

мне сейчас видится, в основном - отчеты.

[EVGL]

Отчеты ужасно сложно программировать в AX2012. Затраты = как раньше * 3

[mazzy]

Цитата:

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

Отчеты ужасно сложно программировать в AX2012. Затраты = как раньше * 3

хм... прислушаюсь к мнению.
тогда почти ничего и не остается. только суррогатные ключи и "мелочи".

либо я чего-то не понимаю.

[Jabberwocky]

Цитата:

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

Отчеты ужасно сложно программировать в AX2012. Затраты = как раньше * 3

А можно уточнить, в результате чего по Вашему мнению в версии 2012 разработка отчетов стала в 3 раза сложнее?

Если мы сравниваем сложность разработки именно SSRS отчетов - то по моему опыту разработка сложных отчетов, где требуется предварительная подготовка/расчет данных напротив упростилась в 2012 за счет добавления например такой технологии как Report Data Provider, используя которую можно подготовить данные во временной таблице (например используя существующую логику в X++) и затем визуалиpовать их отчете. В 2009 это приходилось делать в Business logic .NET сборке на стороне отчета через BC. Если же сравнивать старый X++ дизайнер отчета с VS дизайнером, то разработка отчетов в старом аксаптовом дизайнере была тем еще квестом.

[EVGL]

Именно из-за Report Data Provider: таблицу временную сделай. Класс напиши. Все это отладь, где дебаггера нет.

[Pustik]

!

[Pustik]

Цитата:

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

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

Наследование таблиц тоже не плохо.

[Jabberwocky]

Цитата:

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

Именно из-за Report Data Provider: таблицу временную сделай. Класс напиши. Все это отладь, где дебаггера нет.

ИМХО, отделение логики расчета отчета от его дизайна - абсолютно правильная вещь, как и отделение бизнес-логики от дизайна форм. Я лично всегда испытывал смешанные чувства при виде X++ отчетов, содержащих логику, "размазанную" по многочисленным executeSection()... А временную таблицу новую можно не делать - можно вернуть и курсор постоянной таблицы или превратить во временную через setTmp() - была бы фантазия.
А то, что технологии не стоят на месте и требуется их изучение с каждой новой версией - да, это "суровый, офигенный факт"

[mazzy]

Цитата:

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

Наследование таблиц тоже не плохо.

не знаю...
мне кажется, что это очень спорное решение.
к тому же требующее тотального рефакторинга.

готов еще раз послушать в чем преимущества.
особенно в части перехода с предыдущих версий.

[plumbum]

Цитата:

Отчеты ужасно сложно программировать в AX2012. Затраты = как раньше * 3

+1, хотя вопрос тоже немного неоднозначный.

Преимущества
1. можно любому свойству контрола присваивать вычисляемые значения: поля таблиц, вызовы методов и т.д.
2. Работа с DataContract - простота и гибкость в управлении диалогами
3. Вроде еще можно потом отчет преобразовать в диаграму или сводную таблицу "не отходя от кассы"

Недостатки:
1. Тяжело программировать логику отчетов (необходимо навешать кучу классов в VS)
2. Неудобно группировать данные по секциям (хотя дело привычки): в SSRS источник данных - плоская таблица, чтобы вывести строки заказа под конкретным заказом, надо настраивать специально группировку в контроле
3. Чтоб настроить взаимодействие SSRS и AX надо будет голову поломать не один день.

Это мои впечатления об отчетах.

Теперь еще один важный вопрос, касающийся подъема решения:
Переработанная RunBase Framework. Собственно теперь можно вообще без RunBase, еще и при этом ускорить работу, перекомпилировав код в MISL.

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

С точки зрения фунционала, на ум приходит переработанная концепция справочника номенклатуры, а ля глобальная адресная книга в 2009. Выгодно для концернов, где под несколько юр. лиц заведены отдельные компании, работающие с одинаковым товаром.

[Pustik]

Цитата:

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

готов еще раз послушать в чем преимущества.
особенно в части перехода с предыдущих версий.

Преимущества вижу только для программистов :
1) При создании новой таблицы, которая будет хранить какую-нибудь дополнительную информацию любого модуля, не надо будет создавать основные поля, которые хранятся в базовой таблице. Достаточно будет просто эту дополнительную таблицу унаследовать от базовой.
2) Очень напрягает в новых таблицах писать такие методы как Find(), дисплей-методы ItemName(), initValue()... и т.д. Тут их уже писать будет не надо. Они будут унаследованы от базовой.
С точки зрения хранения информации тоже, наверное, какая-то правда есть.
Для пользователей по-моему по барабану.
Если говорить о переходе, с точки зрения потраченных на это сил, времени и средств, то преимуществ не вижу ни каких.

[plumbum]

Цитата:

Они будут унаследованы от базовой.

Хм. А разве статические методы наследуются? При этом, как определить тип нужной таблицы из базовой, плюс к этому ключи могут не совпадать. Зато всякие validateWrite, validateField, modifiedField и initValue это бы заметно укоротило!

[Pustik]

Цитата:

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

Хм. А разве статические методы наследуются? При этом, как определить тип нужной таблицы из базовой, плюс к этому ключи могут не совпадать. Зато всякие validateWrite, validateField, modifiedField и initValue это бы заметно укоротило!

Точно, а было бы не плохо их тоже как-нибудь передавать. Мечта

Цитата:

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

Зато всякие validateWrite, validateField, modifiedField и initValue это бы заметно укоротило!

Согласен!

[ansoft]

Цитата:

ну... если автор сообщения не видит других причин... то это больше говорит об авторе - "у кого чего болит..."

Я осветил часть вопроса:

Цитата:

бизнес-сторона вопроса тоже интересна

Техническую часть оставив профессионалам.

Здоровый сарказм еще никому не вредил... и слава богу у меня ничего не "болит".

Цитата:

не знаю...
мне кажется, что это очень спорное решение.
к тому же требующее тотального рефакторинга.

Surrogate keys тоже сомнительная прелесть. Причем как я понял рекомендованная для новых таблиц. Я так понимаю в старых все будет по старому.

[EVGL]

Цитата:

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

Surrogate keys тоже сомнительная прелесть. Причем как я понял рекомендованная для новых таблиц. Я так понимаю в старых все будет по старому.

Щас. Попробуйте номенклатуру заимпортировать в AX2012. Квест на неделю, наверное.

[ansoft]

Вообще всё сомнительная прелесть...
Рад что не одинок:
axdaily: Surrogate keys in AX 2012

[EVGL]

Приверженцам simplicity рекомендую попробовать поменять цену продажи одного товара в AX2012. Посчитайте количество "кликов".