|
|
|
|
#1 |
|
Microsoft Dynamics
|
Цитата:
Или это все-таки было бизнес-требование от ЛПР. Если это было бизнес-требование, то насколько проще, дешевле и безглюкавее это было бы сделать без встроенного workflow в AX? Возвращаясь к дискуссии про SSRS. Ничего, кроме отвращения не могу вспомнить о собственном dev experience создания более-менее сложных отчетов в MorphX. Этот движок хорош только для создания автоотчетов Если считать за аксиому, что среда разработки ERP-системы должна позволять создавать сложные отчеты, включая графику, то тут есть два пути развития: 1. Изобрести велосипед, т.е. разработать новый движок внутри MorphX 2. Сделать хорошую интеграцию с уже имеющимся движком того же вендора, реализовав возможность создавать автоотчеты и обращаться к метаданным AX В AX6 сейчас активно ведутся работы по направлению 2. Что в этом плохого - непонятно. Да, старым аксаптоведам (вроде меня) придется немного подучиться. И все. |
|
|
|
|
#2 |
|
Участник
|
Цитата:
Для рисования таких "красивых" объектов MorphX подходит плохо. Вот если бы у постановщиков задач в Майкрософте зватило духу поставить задачу не так "сделать как в 1С", а так "сделать как стандартные в Аксапте", то и ваше мнение было бы другим, и мнение клиентов, и мнение многих программистов, которые работают с этими угребищными отчетами с рамочками. А нужно то было всего лишь, отказаться от рамочек в отчетах... Впрочем, про рамочки и способах создания отчетов без них писалось на форуме неоднократно. Именно!!!! Причем пользователи могут сами выворачивать запросы и получать итоги по любым группировкам. Только для этого программисту не нужно вмешиваться своими лапками в запросы, не нужно фиксировать порядок таблиц, сортировок и полей, не нужно скрывать условия от пользователей. Нужны итоги по строкам заказа? нет проблем - делайте автоотчет. Нужны итоги по строкам журнала? нет проблем - делайте автоотчет. Нужны итоги по складским движениям? нет проблем... Цитата:
Мне кажется, что аксиомы должны быть другими: 1. ERP-система должна позволять пользователю быстро и лего получить нужные ему данные из одной или двух-трех таблиц. 2. ERP-система должна позволять программисту быстро и легко сделать сложные связи и получить данные из нескольких таблиц 3. ВАЖНО! полученные данные ERP-система должна уметь выгружать в Excel. Все! Большего от ERP-системы и не нужно по большому счету. Если пользователям нужна графика, то переносим в Excel и применяем диаграммы/графики Беда morphX отчетов в том, что там нет инструмента для выгрузки данных в Excel. Цитата:
Я против интеграции-только-для-того-чтобы-интеграция-была. |
|
|
|
| За это сообщение автора поблагодарили: glibs (1). | |
|
|
#3 |
|
Microsoft Dynamics
|
Цитата:
Сообщение от mazzy
Вы наверное рисовали эти безумные формы с рамочками как в Счете, счете-фактуре и т.п.?
Для рисования таких "красивых" объектов MorphX подходит плохо. Вот если бы у постановщиков задач в Майкрософте зватило духу поставить задачу не так "сделать как в 1С", а так "сделать как стандартные в Аксапте", то и ваше мнение было бы другим, и мнение клиентов, и мнение многих программистов, которые работают с этими угребищными отчетами с рамочками. А нужно то было всего лишь, отказаться от рамочек в отчетах... Впрочем, про рамочки и способах создания отчетов без них писалось на форуме неоднократно. Именно!!!! Причем пользователи могут сами выворачивать запросы и получать итоги по любым группировкам. Только для этого программисту не нужно вмешиваться своими лапками в запросы, не нужно фиксировать порядок таблиц, сортировок и полей, не нужно скрывать условия от пользователей. Нужны итоги по строкам заказа? нет проблем - делайте автоотчет. Нужны итоги по строкам журнала? нет проблем - делайте автоотчет. Нужны итоги по складским движениям? нет проблем... Э-э-э... А зачем принимать такую аксиому? Мне кажется, что аксиомы должны быть другими: 1. ERP-система должна позволять пользователю быстро и лего получить нужные ему данные из одной или двух-трех таблиц. 2. ERP-система должна позволять программисту быстро и легко сделать сложные связи и получить данные из нескольких таблиц 3. ВАЖНО! полученные данные ERP-система должна уметь выгружать в Excel. Все! Большего от ERP-системы и не нужно по большому счету. Если пользователям нужна графика, то переносим в Excel и применяем диаграммы/графики Беда morphX отчетов в том, что там нет инструмента для выгрузки данных в Excel. Я - за хорошую интеграцию. Я против интеграции-только-для-того-чтобы-интеграция-была. |
|
|
|
|
#4 |
|
Участник
|
Проект у меня на ax2009.
Давай или в личку, или в ту тему. Цитата:
- Не так. Программеры на "C# & X++" стоят дороже чем программеры на C# или на X++ ![]() Нет, неправильно. |
|
|
|
|
#5 |
|
Участник
|
Я про то, что аргумент "сейчас маззи нанимает SSRS программера" скорее в пользу SSRS
Где я не прав: 1. Для проекта на Ax2009 тебе нужен SSRS девелопер 2. В Ax2009 пользоваться SSRS необязательно => у SSRS настолько больше возможностей чем у MorphX, что это для каких-то случаев для тебя оправдывает траты на программиста. Цитата:
- Пришлось все переделывать нафиг.
Цитата:
- Не так. Программеры на "C# & X++" стоят дороже чем программеры на C# или на X++
Кстати, никто не может напомнить ссылку, где написали про SSRS отчеты в Ax6 - я бы попросил автора поподробнее про это написать? |
|
|
|
|
#6 |
|
Участник
|
Цитата:
Как к примеру в SSRS вы будете делать отчет типа списка поставщиков(фиксированный набор полей). При условии что пользователь может накладывать фильтры на любые поля поставщиков(в том числе и сложные фильтры) и связанных таблиц(тех которые есть сейчас и появятся в будущем) и с возможностью сортировки по любым полям этой таблицы? Это то, что можно сделать в MorphX за несколько минут, сколько времени у вас это займет в SSRS |
|
|
|
|
#7 |
|
Участник
|
В Ax2009 можно использовать перспективы и Report Builder - конечно степень интеграции недостаточная, я с этим согласен. Но это скорее движок выборки данных, чем печатного представления.
|
|
|
|
|
#8 |
|
Moderator
|
Цитата:
Сообщение от mifi
Так это программисты сделали, без запроса от руководства проекта внедрить цепочку утверждений? Они, видимо, по ночам работали и потом тайком перенесли на рабочую версию?
Или это все-таки было бизнес-требование от ЛПР. Если это было бизнес-требование, то насколько проще, дешевле и безглюкавее это было бы сделать без встроенного workflow в AX? Но это понимание пришло только после того как клиент сначала показал workflow пользователям, потом (после того как выяснилось что встроенный workflow мало что может) потратил кучу средств на изучение способов доработки workflow в .net, а потом при старте системы выяснилось что при реальном количестве пользователей, групп и прав, функция securityKeySet.loadUserRights() может отработать за 0.2 секунды, а может и за 45. Соответственно - стандартное ядро WorkFlow и системы обработки Eventов постоянно ждало завершения этой функции и события в очереди стояли по 5-6 часов. Цитата:
Возвращаясь к дискуссии про SSRS. Ничего, кроме отвращения не могу вспомнить о собственном dev experience создания более-менее сложных отчетов в MorphX.
Этот движок хорош только для создания автоотчетов Если считать за аксиому, что среда разработки ERP-системы должна позволять создавать сложные отчеты, включая графику, то тут есть два пути развития: 1. Изобрести велосипед, т.е. разработать новый движок внутри MorphX 2. Сделать хорошую интеграцию с уже имеющимся движком того же вендора, реализовав возможность создавать автоотчеты и обращаться к метаданным AX В AX6 сейчас активно ведутся работы по направлению 2. Что в этом плохого - непонятно. Да, старым аксаптоведам (вроде меня) придется немного подучиться. И все. Именно это-то и пугает. Вот сделают счас компиляцию в .net на лету. Дык страшно подумать что будет, если первые пару версий это будет работать так же стабильно как SSRS или WF в версиях 4.0 и 2009. И если проблемы с отчетами или WF еще можно как-то обойти, то проблемы с ядром системы исполнения - явно нет... |
|
|
|
| За это сообщение автора поблагодарили: gl00mie (2). | |
|
|
#9 |
|
Microsoft Dynamics
|
Цитата:
Сообщение от fed
Workflow сделали естественно по просьбам ЛПР. Счас клиент понимает что сделать без встроенного workflow было бы проще дешевле и безглюкавее.
Но это понимание пришло только после того как клиент сначала показал workflow пользователям, потом (после того как выяснилось что встроенный workflow мало что может) потратил кучу средств на изучение способов доработки workflow в .net, а потом при старте системы выяснилось что при реальном количестве пользователей, групп и прав, функция securityKeySet.loadUserRights() может отработать за 0.2 секунды, а может и за 45. Соответственно - стандартное ядро WorkFlow и системы обработки Eventов постоянно ждало завершения этой функции и события в очереди стояли по 5-6 часов. Просто отчеты на SSRS выпустили еще в версии 4.0. Похоже что до более или менее работоспособного состояния их доведут в версии 6.0 Именно это-то и пугает. Вот сделают счас компиляцию в .net на лету. Дык страшно подумать что будет, если первые пару версий это будет работать так же стабильно как SSRS или WF в версиях 4.0 и 2009. И если проблемы с отчетами или WF еще можно как-то обойти, то проблемы с ядром системы исполнения - явно нет... |
|
|
|
| За это сообщение автора поблагодарили: mazzy (2). | |
|
|
#10 |
|
Гость
|
Цитата:
Сообщение от fed
....
Но это понимание пришло только после того как клиент сначала показал workflow пользователям, потом (после того как выяснилось что встроенный workflow мало что может) потратил кучу средств на изучение способов доработки workflow в .net, а потом при старте системы выяснилось что при реальном количестве пользователей, групп и прав, функция securityKeySet.loadUserRights() может отработать за 0.2 секунды, а может и за 45. Соответственно - стандартное ядро WorkFlow и системы обработки Eventов постоянно ждало завершения этой функции и события в очереди стояли по 5-6 часов.
|
|
|
|
|
#11 |
|
Moderator
|
|
|
|
| Теги |
| .net, ssrs, visual studio, workflow, как правильно, права доступа, производительность, ax2012 |
|
|
|