|
09.04.2018, 11:48 | #1 |
Участник
|
Кстати, да. Почему-бы не продавать как платформу разработки бизнес-приложений по вкусной цене.
__________________
Ivanhoe as is.. |
|
09.04.2018, 17:23 | #2 |
Banned
|
Цитата:
Были бы поумнее пустили бы AX в open-source. На одних серверных лицензиях (Windows Server, SQL Server etc) получали бы достаточно. Последний раз редактировалось ax_mct; 09.04.2018 в 17:26. |
|
09.04.2018, 23:18 | #3 |
Участник
|
А нет задачи зарабатывать на лицензиях - есть задача зарабатывать на подписке, и вендор маниакально тащит всех за уши в Azure. Уже и Windows с D365O называет не продуктами, а сервисами, мол, оттого и обновления постоянные, оттого и подписка. Хочешь получать сервис - плати постоянно; платить перестал - доступ к сервису потерял.
|
|
|
За это сообщение автора поблагодарили: ax_mct (5). |
10.04.2018, 08:42 | #4 |
Участник
|
|
|
|
За это сообщение автора поблагодарили: ax_mct (5). |
10.04.2018, 17:42 | #5 |
Banned
|
Цитата:
Но в ситуации роста популярности разбираться в системе будет программист MS CRM. Аналогия с SSRS-программистами не случайна. Ни на одном из десятков проектов я не видел SSRS программиста который бы взял за труд изучить и использовать X++. Им удобнее неудобно. Они остаются чистыми SSRS программистами. С учетом смешения продуктов, если массово AX программисты не будут переходить в Microsoft CRM, то программировать в AX будет чистый Microsoft CRM программист. А чистые ребята они не золотари как мы. Разбираться в X++ они не будут. В принципе здесь открывается возможность аутсорса, но если можно будет достичь результата как в SSRS, не пачкаясь с X++, то будут делать как эффективней, а не как предполагается. Можно будет через T-SQL, значит будет T-SQL. Цитата:
Сообщение от belugin
Получается что основная проблема, что они что-то не подозревают, и хотят то, что было раньше.
Мне кажется, первая часть проблемы решается ссылкой на документацию, а вторая справедлива для ОЧЕНЬ ограниченных сценариев (типа публичная часть или какая-нибудь мобильная) иначе придется переписывать интерфейс аксапты чтобы им угодить. Переобучить и немного допилить проще. когда его жена вчера на web-конструкторе типа wix.com сделала себе сайт, а сын проходит курсы HTML и показывает современные плюшки на одном .CSS типа такого где это просто один стиль CSS http://www.cssplay.co.uk/menu/csspla...-css-only.html "Ну вы же понимаете, у нас серьезная бизнес-система... Мы вот можем наследовать через аттрибуты..." То есть мой пойнт в том что ожидания клиента уже сформированы современным web. Про SAP все знают - "даже не думай", а вот про D365FO - вряд ли. Особенно при схожести интерфейса с MS CRM. И мне сдается что расширяемость front-end в для популярности значит не меньше чем back-end. С учетом стоимости этих расширений и нахождения специалистов. Не исключаю того что front-end D365FO это уникальная ниша. Но возможно было бы правильней для AX программистов идти в MS CRM для более реальной ниши на стыке двух продуктов. Последний раз редактировалось ax_mct; 10.04.2018 в 17:55. |
|
11.04.2018, 03:48 | #6 |
Участник
|
Цитата:
т.е. те кто хотят по старинке сложным языком кодят в X++ а новый подход успешных людей - это мышкой создавать Power apps, из AX брать только данные https://dynamics.microsoft.com/en-us...#release-notes Последний раз редактировалось trud; 11.04.2018 в 04:25. |
|
|
За это сообщение автора поблагодарили: ax_mct (5). |
Теги |
ax8, dyn365fo, extensions, mfp |
|
|