4 года Dynamics AX 2012

[ice]

Цитата:

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

А семерка - лучше !

чем лучше? лучше продается? или меньше багов? или восхищает функциональность?
ПС никаких тайных смыслов в вопросах. реально интересно

[Vadik]

Цитата:

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

чем лучше?

Легче дорабатывать не трогая стандарт за счет расширений и улучшенного eventing-а. Легче разворачивать и деплоить за счет того что все среды - стандартные из шаблонов. Легче поддерживать и обновлять (LCS). Вот я например сейчас на форуме, а билд в клиентской UAT среде разворачивается. Сам. Один

Цитата:

лучше продается?

Продается. Лучше или хуже - сказать не могу

Цитата:

или меньше багов?

Багов наверное столько же. В новых модулях - естественно больше чем в среднем по больнице. Но overlayering-а гораздо меньше (см. выше) и установка хотфикса предельно упрощена. Я вообще хотфиксы не ищу когда что-то ломается, а ставлю превентивно все что выходит где-то раз-два в неделю потому что теперь так проще. Собрать на LCS пакет из доступных еще не установленных фиксов дело 5-10 минут. Столько же чтобы импортировать его в DEV. Еще 5 минут на проверку конфликтов и полчаса на то чтобы собрать билд

Цитата:

или восхищает функциональность?

Она не то чтобы радикально богаче чем в 2012. Но развивается достаточно активно

Цитата:

Прям ломанутся сейчас заказчики. Особенно за "Сервисы обеспечения жизненного цикла"

Это про LCS, если что. Крутая штука.Не расскажете что именно Вас так развеселило ?

Цитата:

Вот как продажи пойдут. Тогда присоединюсь к восторгу

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

[ax_mct]

Цитата:

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

Продается. Лучше или хуже - сказать не могу

https://www.microsoft.com/en-us/dynamics365/operations
Не сомневаюсь что у версии все будет для нее самой хорошо.
Но какие бы не были продажи возникает вопрос в чей карман деньги.

Есть ли программирование как часть внедрения?
Потому как по идее программирование на самом внедрении должно стремиться к нулю, и программирование должно концентрироваться вокруг создания продуктов через Marketplace. То есть программист AX уже кодить на проекте не должен практически. Консультантская работа тоже должна претерпеть изменения.

[George Nordic]

Цитата:

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

Есть ли программирование как часть внедрения?
Потому как по идее программирование на самом внедрении должно стремиться к нулю, и программирование должно концентрироваться вокруг создания продуктов через Marketplace. То есть программист AX уже кодить на проекте не должен практически. Консультантская работа тоже должна претерпеть изменения.

Вот категорически несогласен. Основное преимущество DAX, о котором я упомянул здесь: Чем Qlik похож на Axapta как раз и состояла в том, что я быстрее бы новый модуль написал, чем разбирался бы в галочках уже готового модуля в другой системе. К тому же, "уже готовый модуль" писался под других клиентов, и там или все вшито в код, так что не исправишь, или куче ненужных мне настроек, которые нужны для "решения различных типов задач широкого круга клиентов", но мне они ну вот совсем не нужны и сильно снижают скорость настройки, понимание системы и, зачастую, скорость его работы.

Т.е. самая сильная стороны DAX были - это:
1. Отличный интерфейс и методы разработки интерфейса (метки, авторазмещение элементов, многооконный интерфейс, Morphix)
2. Грамотная техническая реализация моделей данных (Расширяемые типы данных, Таблицы/Проводки, связь таблиц по relations, AOS и т.д.)
3. [почти]Однотипная реализация основных механизмов работы учетной системы, шаблоны и паттерны (FormLetter, RunBase и т.д.). Зная один модуль, можно было легко разобраться как работает другой.
4. Отличная среда разработки. Самая быстрая, что я видел, для построения учетных систем. Самодокументируемая (рефакторинг), хорошо читаемая.
5. Да еще и с отличным дебаггером, начиная с 3ки.
обеспечение
6. Отличный механизм совмещения разработок - слои.
7. Да много еще плюсов

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

И при этом клиент получал решение именно его задач, адаптированное под него.

С Уважением,
Георгий

[fed]

Цитата:

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

Легче дорабатывать не трогая стандарт за счет расширений и улучшенного eventing-а.

Замечу, что только за счет расширений и улучшенного eventing можно делать только совсем простые доработки, которые и раньше на раз-два переносились с помощью upgrade wizard.
При этом очень пугают попытки Микрософт как-то отрубить возможность перекрывать стандартный код и продавить партнеров все делать с помощью расширений. Да - была и есть проблема безумных партнеров, которые прогибаются под любые хотелки клиентов и используют Аксапту как средство разработки. Тем не менее, даже на хорошо управляемых внедрениях, с вменяемым клиентом и консультантами, часто приходится модифицировать стандартную функциональность. Просто проблема в том, что очень часто, клиенту проще взять на себя риски и косты затрудненного обновления, чем риск просто остановить нафих весь бизнес при попытке одномоментной смены бизнес-процессов. В конце концов - апгрейд не самоцель. Если система работает и потребности бизнеса покрывает, может оказаться дешевле аккуратненько бэкпортить микрософтовские фиксы по мере надобности.
Ну и конечно Микрософт пытается решить эту проблему по принципу "нет глазок - нет мультиков". Это конечно проще чем реально контроллировать деятельность партнеров, собирать статистику доработок по проектам, обеспечивать нормальную систему фидбека в Microsoft Connect или развивать нормальный консалтинг (который вообще-то нужен в первую очередь для фидбека по продукту, а не как sales engine). Но только проблема в том, что все это создает коллосальное недоверие к MS со стороны клиентов и партнеров. И именно поэтому, спрос на D365 в Azure так мал. Никто не хочет идти в крепостные к барам из MS. Потому что хрен его знает, что еще эти инноваторы нам выколят или отрежут для удобства апгрейда на следующую версию....

[pitersky]

Цитата:

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

Замечу, что только за счет расширений и улучшенного eventing можно делать только совсем простые доработки, которые и раньше на раз-два переносились с помощью upgrade wizard.
При этом очень пугают попытки Микрософт как-то отрубить возможность перекрывать стандартный код и продавить партнеров все делать с помощью расширений. Да - была и есть проблема безумных партнеров, которые прогибаются под любые хотелки клиентов и используют Аксапту как средство разработки. Тем не менее, даже на хорошо управляемых внедрениях, с вменяемым клиентом и консультантами, часто приходится модифицировать стандартную функциональность.

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

P.S. А вообще мне кажется странной сама логика такой трансформации. Ведь был же прекрасный механизм слоёв, стандартный код был полностью защищён от изменений.