21.09.2017, 16:11 | #1 |
Участник
|
mfp: Enabling extensibility on Pricing
Источник: https://blogs.msdn.microsoft.com/mfp...ty-on-pricing/
============== Disclaimer: This is only a proposed solution and is subject to change without further notice Here is an overview of the changes being done to make the pricing area extensible. Pricing is a heavily customized area and modifying the price search is currently impossible without overlayering. This article outlines a proposed solution for some... ============== Источник: https://blogs.msdn.microsoft.com/mfp...ty-on-pricing/
__________________
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору. |
|
22.09.2017, 08:23 | #2 |
Участник
|
Телепатия! Только вчера обсуждали с коллегой, как теперь в D365O кастомизировать PriceDisc, - и вот, пожалуйста. Жаль только, что лишь в следующем релизе...
|
|
22.09.2017, 10:07 | #3 |
Участник
|
Цитата:
Если нет, дайте знать. |
|
|
За это сообщение автора поблагодарили: mazzy (8), Alex_KD (3). |
25.09.2017, 17:08 | #4 |
Участник
|
Чего еще недостает - это создания экземпляра PriceDisc в стандарте через статический construct() вместо экземплярного new(): очень надеюсь, что это изменение также будет реализовано в рамках рефакторинга движка подбора цен.
PS. И чтобы new() при этом стал максимум protected, а то гхм... некоторые разработчики стандарта любят делать его private, как, с кажем, в SysLookupMultiSelectCtrl. PPS. А сам класс чтоб не оказался final |
|
|
За это сообщение автора поблагодарили: Logger (3). |
25.09.2017, 17:38 | #5 |
Участник
|
Цитата:
Но это не так важно - будут следующие версии, рано или поздно исправят. Ваня, скажи лучше: на основании твоего опыта работы над экстеншеном к одному семейству классов, можешь ли ты утверждать, что подобная работа над остальными классами будет легкой? что такую работу можно поставить на поток? или по каждому семейству классов нужно будет принимать отдельное решение, находить отдельный подход? ======================= Если работа поточная, то, на твой взгляд, можно ли сделать какой-то интеллектуальный тул для преобразования всего функционала в расширяемый? Насколько сложным должен быть такой тул? ======================= Если работа индивидуальная, то каковы, на твой взгляд, оценки трудозатрат на то, чтобы весь функционал аксапты сделать расширяемым? Не проще ли создать новую систему, чем отмывать старую? |
|
25.09.2017, 22:36 | #6 |
Участник
|
Есть много изменений, которые можно было бы автоматизировать.
Но более сложный "логический" рефакторинг конечно в индивидуальном порядке. Трудозатраты довольно большие. Может и проще было бы создать что-то поменьше, но уже сразу extensible. Но этого в планах нет. |
|
25.09.2017, 22:40 | #7 |
Участник
|
вот я и думаю - а что из этой ляпоты доберется до конечного потребителя?
в данном случае потребителем является разработчик на клиенте/партнере. да, конечно некоторые вещи будут сделаны. некоторые будут даже образцово показательно вылизаны до идеального блеска. но в массе то своей народ будет затруднятся совсем не с идеально реализованными семействами. |
|
25.09.2017, 23:36 | #8 |
Участник
|
Цитата:
Сообщение от mazzy
вот я и думаю - а что из этой ляпоты доберется до конечного потребителя?
в данном случае потребителем является разработчик на клиенте/партнере. да, конечно некоторые вещи будут сделаны. некоторые будут даже образцово показательно вылизаны до идеального блеска. но в массе то своей народ будет затруднятся совсем не с идеально реализованными семействами. Это длительный процесс, он не закончится в 2018 когда мы закроем доступ на overlayering Это не просто длительный процесс, это непрерывный процесс с этого времени.. История покажет, насколько хорошо мы сделали свою работу. |
|
26.09.2017, 03:12 | #9 |
Участник
|
А какие кстати KPI данной работы?
вот если сравнивать одного и того-же решения на АХ7.1 (это реально заняло пару часов) и на АХ7.2(это заняло пару дней, из за как раз подобной переработки базовых классов, около 10 новых методов решения просто перестало компилится) на АХ7.3 подозреваю будет еще больше, так как грозятся поменять InventDim Цитата:
т.е. какой критерий успеха данной работы - "сделать AX более расширяемой"? можно к примеру заново изобрести слои(типа Chain of Command 2), тогда вообще 100% расширяемость получится т.е. на первый взгляд более логичным видится все же направить усилия на разработку именно новой функциональности(необходимой клиентам), а не на усложнение того что уже есть PS: конечно как программист я понимаю, что именно фан в текущей работе перевода на extension большой, т.е. начертить диаграмму классов, подумать где тут точки расширения, придумать какие-нибудь атрибуты и т.п. , это все на порядок веселее чем разбираться в каком-нибудь запутанном ценообразовании реального клиента Последний раз редактировалось trud; 26.09.2017 в 03:27. |
|
26.09.2017, 14:46 | #10 |
Участник
|
Цитата:
Так же были проблемы заставить вышеупомянутый engine ежедневно считать прайс лист для 10\100\500 магазинов для ~50000 продуктов. Каждый магазин со своим ценообразованием.
__________________
AxAssist 2012 - Productivity Tool for Dynamics AX 2012/2009/4.0/3.0 |
|
26.09.2017, 14:53 | #11 |
Участник
|
не включала, не включает и, похоже, не будет включать.
расширения в ритейле - отдельная пестня. пока могу сказать - расширения в ритейле делают. отдельная команда. может, Иван что-нибудь добавит. например, про вазимодействие команд. Последний раз редактировалось mazzy; 26.09.2017 в 15:02. |
|
26.09.2017, 16:00 | #12 |
Участник
|
Цитата:
Они знают об этой необходимости, но я повторно только-что сослался на эту тему напомнил им. У них немного другой график - более жесткие временные рамки для закрытия оверлейеринга, но и более частые релизы, поэтому для тех, кто использует месячные апдейты - следите за обновлениями. |
|
26.09.2017, 17:13 | #13 |
Участник
|
Цитата:
Цитата:
понятно, что внутри оно будет решаться силовым способом через колено. но представь, что некий партнер делает решение для ритейла на экстеншенах. в рамках этого решения:
Последний раз редактировалось mazzy; 26.09.2017 в 17:21. |
|
|
За это сообщение автора поблагодарили: gl00mie (2). |
31.05.2018, 20:46 | #14 |
Участник
|
Расширяю так
Привет, делаю расширение на прайс калькулейшин в D365 7.3 без оверлееринга.
Был выбран такой подход: 1) Создаю наследника PriceDisc в котором пишу свой findPrice метод. Вызываю супер если нужно. 2) Создаю экстеншин на PriceDisc, в котором использую chain of command для newFromPriceDiscParameters метода. В этом методе после next() инициализирую свой класс наследник PriceDisc. Возвращаю свой класс. |
|