4 года Dynamics AX 2012

[DAX.Company]

Цитата:

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

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

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

[ZornFire]

Чем будет новая версия по своей сущности понять бы еще.

[DAX.Company]

Да вот же ж. Первое, что выдает яндекс в поиске от Нети :
- Облачное развертывание
- Доступ с мобильных устройств
- Сервисы обеспечения жизненного цикла
- Web клиент
- Использование HTML5
- Постепенные улучшения
- Лицензии и подписки

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

Все что остальное выдает Яндекс не лучше. Никакой информации.

[fed]

Единственное реальное улучшение в 7ке, о котором я знаю - появились достаточно серьезные отчеты для выверки склада (вроде бы даже основанные на power BI). При этом те структуры данных, на которых эти отчеты построены, планируется использовать в будущей версии себестоимости (в которой потоки стоимости будут отделены от количественных потоков).
Замечу, что в европе семерка тоже очень плохо продается и большая часть клиентов ни о каких облаках вообще и Микрософтовском в особенности, применительно к ERP, слышать не хочет. Реально сейчас европейские партнеры живут апгрейдами на DAX2012R3. Проекты на 7ке - единичны.

[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 уже кодить на проекте не должен практически. Консультантская работа тоже должна претерпеть изменения.

[ZornFire]

А что с русским языком и особенностями для РФ, в новой версии, которых в ней сейчас нет?
Ждем 2020 года, когда снимут санкции и дополнят версию для РФ?

[Ivanhoe]

Текущая позиция - выход локализации во второй половине 2017.

[fed]

Цитата:

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

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

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

[pitersky]

Цитата:

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

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

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

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

[ax_mct]

Технически решение есть - дублирование системных объектов, и форм и классов.
Иногда так делаю, но делать так не всегда по фэньшую, и не факт что легально если для продаваемого решения.

P.S. Если подумать то причина в облачном хостинге чтобы накатывать фиксы всем и сразу. Со спросом или без спроса не понятно, но коль модель "мы берём все IT заботы на себя" то для части клиентов может быть и достоинством. Я правда таких не могу представить на enterprise уровне, SMB - может быть.
Но в on-premise такое точно лишнее.

[Ivanhoe]

Пока же Dynamics 365 ниразу не "общая" и "последняя версия для всех клиентов". Каждый инстанс - изолированный.
Вот чтобы проще было ставить "Apps" и собирать солянку из решений партнеров - думаю, ближе к истине. Видел не один план проекта крупных западных игроков, включая MS. Типовой случай - стандарт + десяток мелких "решений".

[ax_mct]

Цитата:

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

Пока же Dynamics 365 ниразу не "общая" и "последняя версия для всех клиентов". Каждый инстанс - изолированный.
Вот чтобы проще было ставить "Apps" и собирать солянку из решений партнеров - думаю, ближе к истине. Видел не один план проекта крупных западных игроков, включая MS. Типовой случай - стандарт + десяток мелких "решений".

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

Слабо понимаю как в этом всем могут делиться роли вендора и партнера, так как конфликт интересов налицо.

[mazzy]

History of AX
Fredrik Sætre

https://community.dynamics.com/ax/b/.../history-of-ax

[Ace of Database]

Я за последние три года поработал в Андроиде, Jave, C++, C#, 1C. И могу сказать, что для разработки приложений среда разработки X++ самая эффективная, быстрая и легкая. В AX2012 ее еще не убили. Поэтому AX2012 - тоже удачная версия Аксапты.
В маркетинге Аксапты надо сместить акценты на этот феномен среды разработки X++.
Среда MorphX позволяет быстро рисовать формы, которые хорошо смотрятся при любом разрешении экрана. Логирование изменений данных и стек вызовов позволяют разобраться в логике работы без наличия документации.

[George Nordic]

Цитата:

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

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

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

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

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

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

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

[Morpheus]

Цитата:

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

...что среди нововведений DAX2012 только одно мне кажется безнадежным - Subledger/Distributions/Source document architecture.

У меня сложилось впечатление, что функционльность Subledger/Distributions/Source document перенесли из другого приложения, написанного на хранимых процедурах. В ней нет и намека на ООП. Одни временные таблицы и куча запросов группирует затем перегруппировывает записи читая их из одних таблиц и записывая в другие. Читать такой код сложно, исправлять/расширять еще сложнее.

[macklakov]

Цитата:

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

У меня сложилось впечатление, что функционльность Subledger/Distributions/Source document перенесли из другого приложения, написанного на хранимых процедурах. В ней нет и намека на ООП.

Я бы скзал что основная часть нового системного кода в 2012 написана вчерашними web-программистами. Заслуженными ветеранами asp кодинга. Поэтому ощущается большое недоверие структурам данных, к x++ запросам, к временным таблицам. Из-за этого так часто попадаются таблицы которые используются как временные, являсь обычными, а это, в свою очередь, приводит к конфликтам и накоплению мусорных записей. Еще ощущается полное непонимание, зачем нужен сервер приложений. Поэтому механизм кэширования не развивается, застрял на уровне конца 90-х и больше тормозит систему, чем ускоряет работу.
В сущности, morphX и x++ у них явно путаются под ногами, раздражают, и они хотели бы все это переписать под "нормальную" архитектуру. Но избавиться пока не могут, т.к. открытость кода и простота модификации является тем конкурентным приемуществом, благодаря которому система все еще представлена на рынке, несмотря на всю недоделанность. Для сравнения, разработка через add-on's в "правильном" CRM на порядки сложнее и "общедоступные" C# программисты в CRM, на поверку, оказываются очень редки и дороги.

[fed]

Цитата:

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

У меня сложилось впечатление, что функционльность Subledger/Distributions/Source document перенесли из другого приложения, написанного на хранимых процедурах. В ней нет и намека на ООП. Одни временные таблицы и куча запросов группирует затем перегруппировывает записи читая их из одних таблиц и записывая в другие. Читать такой код сложно, исправлять/расширять еще сложнее.

Согласно утечке от одного из локализаторов (теперь уже бывшего), спецификация на эту фичу была написана каким-то нанятым с улицы программ-манагером, без знания аксапты и вообще серьезного опыта в финансовых системах. Этот чувак на полпути к выпуску Ax2012 свалил постановщиком в скайп, и к моменту релиза, модулем занимался уже третий программ-манагер. По пути они поимели очень много проблем с производительностью и вынуждены были код несколько раз очень всерьез переделывать. Правда у меня ощущение от стиля кодинга - диаметрально протовоположные. Там на каждый чих иерархия классов и две-три интерфейса созданы. Правда потом, по моему, после столкновения с реальностью и проблемами производительности, туда в индусском стиле с помощью кувалды и медитации вколотили временные таблицы и вообще всякие SQL-фичи, которые с изначально overengineered ООП не особо совместимы, но хоть как-то по производительности тянут.

[Ivanhoe]

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