mfp: Enabling extensibility on Pricing

[gl00mie]

Телепатия! Только вчера обсуждали с коллегой, как теперь в D365O кастомизировать PriceDisc, - и вот, пожалуйста. Жаль только, что лишь в следующем релизе...

[kashperuk]

Цитата:

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

Телепатия! Только вчера обсуждали с коллегой, как теперь в D365O кастомизировать PriceDisc, - и вот, пожалуйста. Жаль только, что лишь в следующем релизе...

Было бы интересно от Вас получить подтверждения, что все Ваши кастомизации решаются вышеупомянутым рефакторингом.
Если нет, дайте знать.

[mazzy]

Цитата:

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

Было бы интересно от Вас получить подтверждения, что все Ваши кастомизации решаются вышеупомянутым рефакторингом.

Скорее всего, нет.
Но это не так важно - будут следующие версии, рано или поздно исправят.

Ваня, скажи лучше: на основании твоего опыта работы над экстеншеном к одному семейству классов, можешь ли ты утверждать, что подобная работа над остальными классами будет легкой? что такую работу можно поставить на поток?

или по каждому семейству классов нужно будет принимать отдельное решение, находить отдельный подход?

=======================
Если работа поточная, то, на твой взгляд, можно ли сделать какой-то интеллектуальный тул для преобразования всего функционала в расширяемый? Насколько сложным должен быть такой тул?

=======================
Если работа индивидуальная, то каковы, на твой взгляд, оценки трудозатрат на то, чтобы весь функционал аксапты сделать расширяемым? Не проще ли создать новую систему, чем отмывать старую?

[Alex_KD]

Цитата:

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

Было бы интересно от Вас получить подтверждения, что все Ваши кастомизации решаются вышеупомянутым рефакторингом.
Если нет, дайте знать.

Я правильно понимаю, что данная история не включает retail price engine и как его расширять?

Так же были проблемы заставить вышеупомянутый engine ежедневно считать прайс лист для 10\100\500 магазинов для ~50000 продуктов. Каждый магазин со своим ценообразованием.

[mazzy]

Цитата:

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

не включает retail price engine и как его расширять?

не включала, не включает и, похоже, не будет включать.

расширения в ритейле - отдельная пестня.
пока могу сказать - расширения в ритейле делают. отдельная команда.

может, Иван что-нибудь добавит. например, про вазимодействие команд.

[kashperuk]

Цитата:

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

не включала, не включает и, похоже, не будет включать.

расширения в ритейле - отдельная пестня.
пока могу сказать - расширения в ритейле делают. отдельная команда.

может, Иван что-нибудь добавит. например, про вазимодействие команд.

Retail pricing engine менять будет Retail команда, все верно.
Они знают об этой необходимости, но я повторно только-что сослался на эту тему напомнил им.

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

[mazzy]

Цитата:

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

Они знают об этой необходимости, но я повторно только-что сослался на эту тему напомнил им.

Цитата:

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

Было бы интересно от Вас получить подтверждения, что все Ваши кастомизации решаются вышеупомянутым рефакторингом.

Alex_KD дал отличный пример для самоконтроля - решаются ли задачи ценообразования в аксаптовском ритейле (который сам по себе является экстеншенем к аксапте)

понятно, что внутри оно будет решаться силовым способом через колено.
но представь, что некий партнер делает решение для ритейла на экстеншенах.

в рамках этого решения:

• реализована работа отдельных от аксапты программулек для работы в распределенной сети магазинов
• каждый магазин содержит свою реплику справочных данных (настройки, номенклатура, цены, скидки...). в качестве СУБД в магазинах зачастую используется MS SQL Expression Edition.
• каждый магазин может продавать свой ассортимент номенклатуры. ассортименты могут частично пересекаться.
• понятно, что решение будет предлагать свои добавки для видов цен, скидок и наценок. похоже что это вы продумали и закрыли.
• насколько легко будет реализовать логику PriceDisc с экстеншенами во внешних приложениях?
• это решение должно еще сформировать минимальный набор данных для отправки в магазин. с учетом ассортимента данного магазина. как при добавлении цен, так и при удалении/выключении цен. при этом нужно минимизировать набор цен в самом магазине (не забываем про SQL Express). насколько легко это сделать с экстеншенами?
• это решение должно контролировать в аксапте действительно ли в магазине работали те цены, которые были установлены централизовано.
• это решение должно каким-то образом централизовано включать-выключать цены в магазине в зависимости от внешних обстоятельств (например, цены на ценниках и в кассе должны совпадать. поэтому цену можно применять только после того, как ценники напечатаны и развешены в зале). Насколько легко добавить внешнее условие включения цен с экстеншенами?
• и так далее. поиск по TFS, ключевые слова "Retail, Price, Dicount" )

[Volodymyr]

Привет, делаю расширение на прайс калькулейшин в D365 7.3 без оверлееринга.

Был выбран такой подход:
1) Создаю наследника PriceDisc в котором пишу свой findPrice метод. Вызываю супер если нужно.
2) Создаю экстеншин на PriceDisc, в котором использую chain of command для newFromPriceDiscParameters метода. В этом методе после next() инициализирую свой класс наследник PriceDisc. Возвращаю свой класс.