04.10.2018, 19:53 | #21 |
Banned
|
Цитата:
Функционал catch weight как был, так и остался. Он как не поддерживался в мобильном сканере, так и не поддерживается. Причина: изначально и тот (WHS) и другой (CW) функционал пришел от партнеров, только от разных (Blue horseshoe ISV vs. Some other ISV). Последние 4 года Microsoft старается "поженить" их друг с другом, и с остальной системой. При этом в последнем году сканер поменял frontend и от IIS-приблуды стал Android app. |
|
04.10.2018, 21:11 | #22 |
Участник
|
|
|
04.10.2018, 21:19 | #23 |
Banned
|
Цитата:
Сообщение от EVGL
Ваше впечатление неверно. Извините, но видно, что вы совершенно не в теме, но на все имеете свое безапелляционное мнение.
Функционал catch weight как был, так и остался. Он как не поддерживался в мобильном сканере, так и не поддерживается. Причина: изначально и тот (WHS) и другой (CW) функционал пришел от партнеров, только от разных (Blue horseshoe ISV vs. Some other ISV). Последние 4 года Microsoft старается "поженить" их друг с другом, и с остальной системой. При этом в последнем году сканер поменял frontend и от IIS-приблуды стал Android app. Summary of what's new in Finance and Operations Цитата:
This topic lists the features that are planned for release in Microsoft Dynamics 365 for Finance and Operations between October 2018 and March 2019.
Цитата:
Catch weight product processing with warehouse management - Undetermined (may release after March 2019)
говорит о CW в целом, и ничего о терминалах. Название функционала в списке, указание сроков и материал по ссылке и создают то впечатление которое выглядит безапелляционным. Как это можно трактовать иначе на основе прочитанного? https://docs.microsoft.com/en-us/bus...ain-management Последний раз редактировалось ax_mct; 04.10.2018 в 21:38. |
|
04.10.2018, 21:36 | #24 |
Banned
|
Спасибо. Удивительно как быстро я отстал от жизни.
Добавление параметра по умолчанию - breaking change. Cкорее всего из-за Chain of command. То есть ради того чтобы у других были связаны руки, они связали себе ноги. Цитата:
Adding or removing a default method parameter on a protected or public method – Consumers might have wrapped or subscribed to the method.
|
|
04.10.2018, 21:43 | #25 |
Banned
|
Цитата:
Сообщение от fed
В общем - официальной информации от MS по этому поводу нету (насколько я знаю), но вроде бы они рассматривали такой подход, при котором в полугодовых релизах могут менятся сигнатуры методов (и вообще делатся более существенные изменения). Вот в месячных релизах, они это точно обещали не делать. А насчет полугодовых - не знаю, не уверен...
Действительно требуются годы тогда. Был неправ. |
|
04.10.2018, 22:18 | #26 |
Banned
|
Цитата:
Трактовать надо так: warehouse management <> Inventory management, а далее углубиться в детали трех абзацев. Доказательство: Если вы не осведомлены даже о функциональных возможностях AX2012 R3, то как вы вообще собираетесь сравнивать AX2012 R3 с D365FO 8.0? |
|
|
За это сообщение автора поблагодарили: ax_mct (10), Link (1). |
05.10.2018, 00:13 | #27 |
Banned
|
Цитата:
Сообщение от EVGL
По одним пресс-релизам систему не освоить. Трогать надо, внедрять, программировать, а не наблюдать тени на стене пещеры и рассуждать о них, как о данности.
[B]Трактовать надо так: warehouse management <> Inventory management, а далее углубиться в детали трех абзацев. Если вы не осведомлены даже о функциональных возможностях AX2012 R3, то как вы вообще собираетесь сравнивать AX2012 R3 с D365FO 8.0? Неправ я был. Но кто-то же должен быть задницей форума И ведь всего лишь управление складом с управлением запасами перепутал. What's a shame! |
|
05.10.2018, 10:05 | #28 |
Moderator
|
|
|
05.10.2018, 10:12 | #29 |
Banned
|
Наверняка по запросу клиента. Мы вот тоже до десятка запросов послали сделать тот или иной расширяемым. Кому дать приоритет? Непонятно. С точки зрения бизнеса - тем, кто просят расширить, поскольку увеличивает клиентсткую базу.
|
|
05.10.2018, 11:49 | #30 |
Участник
|
Вы немного перекручиваете. Еще с первой версии документации про енумы было написано: "не используйте > или <, а то сделают его расширяемым и все развалится" Ребята, которые возмущались, ее не читали и у них таки развалилось, но они решили винить МС. Хотя МС пока заявляет о совместимости на уровне компиляции, а не на уровне логики, потому как предсказать извращенность некоторых расширений дано только высшему разуму.
Последний раз редактировалось skuull; 05.10.2018 в 13:28. |
|
|
За это сообщение автора поблагодарили: EVGL (1), ax_mct (1). |
05.10.2018, 12:42 | #31 |
Moderator
|
Цитата:
Сообщение от skuull
Вы немного перекручиваете. Еще с первой версии документации про енумы было написано: "не используйте > или <, а то сделают его расширяемым и все развалиться" Ребята, которые возмущались, ее не читали и у них таки развалилось, но они решили винить МС. Хотя МС пока заявляет о совместимости на уровне компиляции, а не на уровне логики, потому как предсказать извращенность некоторых расширений дано только высшему разуму.
Вообще - на мой взгляд, то что сейчас с этой continuous update происходит - это классический пример сочетания технооптимизма (верой в то что магическая новая технология обновлений может решить нерешаемую проблему) и явно выраженной проблеммы коммуникаций внутри корпорации (рядовые ПМ вполне себе понимают что все это - полная херня, но чтобы не создавать себе проблем - тупо ждут негативного фидбека от клиентов или первого громного скандала с гигантскими клиенсткими убытками по итогам обновления...) |
|
05.10.2018, 13:08 | #32 |
Moderator
|
Цитата:
Сообщение от skuull
Вы немного перекручиваете. Еще с первой версии документации про енумы было написано: "не используйте > или <, а то сделают его расширяемым и все развалиться" Ребята, которые возмущались, ее не читали и у них таки развалилось, но они решили винить МС. Хотя МС пока заявляет о совместимости на уровне компиляции, а не на уровне логики, потому как предсказать извращенность некоторых расширений дано только высшему разуму.
|
|
05.10.2018, 13:12 | #33 |
Banned
|
Цитата:
Цитата:
Сообщение от fed
Я не перекручиваю. Я просто вижу конфликт между задекларированным (правда в не очень ясной форме) отсутствием breaking changes и явной необходимостью заполнения дыр в функционале (которые теперь партнеры не могут сами затыкать). У меня в целом ощущение, что Микрософт чуть позже пойдет на попятную и по поводу отсутствия breaking changes в новых версиях и по поводу обязательности обновлений каждый месяц.
Вообще - на мой взгляд, то что сейчас с этой continuous update происходит - это классический пример сочетания технооптимизма (верой в то что магическая новая технология обновлений может решить нерешаемую проблему) и явно выраженной проблеммы коммуникаций внутри корпорации (рядовые ПМ вполне себе понимают что все это - полная херня, но чтобы не создавать себе проблем - тупо ждут негативного фидбека от клиентов или первого громного скандала с гигантскими клиенсткими убытками по итогам обновления...) Остаюсь технопессимистом. Перефразируя http://ifreestore.net/4790/2/ Техноопессимизм -мировоззренческая позиция, система взглядов, в соответствии с которыми погоня за технологиями рассматривается в качестве главной причины нарушения баланса в отношениях бизнеса и вендора, появления и резкого обострения проблем развития системы. |
|
05.10.2018, 13:35 | #34 |
Участник
|
Цитата:
Сообщение от fed
Кстати - с формальной точки зрения, там в этой дискуссии кто-то привел ссылку на микрософтовский документ, которая описывает переделку из enum в extensuble enum как breaking change. Что микрософт, вроде бы, обещал не делать после выхода версии 8.0 Вот мне и интересно - у них концепция изменилась или они просто ошиблись ? Ну то есть - я вполне могу согласиться с тем, что партнер не очень корректно закодил. Вопрос в том, что микрософт нарушил (или не нарушил ???) ими же самими задекларированные условия.
Вы еще вспомните internalUseAttribute он в PU20 всем все поломал, раньше был ворнинг но всем было всеравно, а щас вот ошибка компиляции, breaking это по вашему? |
|
05.10.2018, 13:38 | #35 |
Moderator
|
ну я скорее говорю о пробелах в функциональности, которые были в DAX2012 и благополучно остались в D365FO. Например - более или менее сложная и расширяемая себестоимость сопродуктов, более или менее жизнеспособная незавершенка (и не только в Российской локализации) и тд и тп. И если до закрытия overlayering партнеры могли как-то это допиливать на проектах, то в extensions model все более или менее существенные изменения могут быть сделаны только MS.
|
|
|
За это сообщение автора поблагодарили: ax_mct (3). |
05.10.2018, 13:45 | #36 |
Moderator
|
Цитата:
Сообщение от skuull
С формальной точки зрения высказывания на ямере эквивалентны высказыванимя тут, с docs таже беда, сегодня там одно написано, завтра - другое. Я думаю нет ниодного документа в котором было бы что-то написано, а то засудят еще
Вы еще вспомните internalUseAttribute он в PU20 всем все поломал, раньше был ворнинг но всем было всеравно, а щас вот ошибка компиляции, breaking это по вашему? Плюс рано или поздно, у какого-то клиента не хватит ресурсов на то чтобы очередной ежемесячный багфикс потестить и у него весь бизнес встанет недельки на три-четыре. Я конечно понимаю что лицензионные соглашения MS позволяют ему выйти сухим из воды. Но вот выхлоп на рынок (Типа - фирма XYZ Productions с внедрением на 1000 рабочих мест простояла месяц с убытками в 800 лямов) может быть достаточно неприятным. А прессрелизы о том что "Да они сами виноваты - толком не тестировали", могут навести потенциальных клиентов на неприятную мысль что им теперь раз в месяц придется ключевых сотрудников отрывать от бизнеса и все тестировать. А это очень хороший sales point для конкурентов, и очень плохой для партнеров MS. |
|
05.10.2018, 15:13 | #37 |
Banned
|
Цитата:
При этом выбирают ту систему в которой все уже подходит изначально. Что интересно некий опрос говорит о том что 70% бизнеса не важно облако или нет, им важнее функциональность. То есть заполненность дыр на первом месте. https://softwareconnect.com/mrp/buye...s-2018-report/ Цитата:
Manufacturers claim to be very flexible in how they are willing to deploy MRP software, with nearly three-quarters (71 percent) indicating they would be open to reviewing either hosted or on-site installation options.
Кстати по поводу D365FO и крупного бизнеса. Размер базы данных. Как то выглядит все непросто в облаке. https://docs.microsoft.com/en-us/azu...ngle-databases P.S. Ну и немного жизнерадостности Есть такие фотки у команды MS? Хочется посмотреть им в лицо Последний раз редактировалось ax_mct; 05.10.2018 в 15:16. |
|
|
За это сообщение автора поблагодарили: belugin (0). |
05.10.2018, 19:15 | #38 |
Участник
|
Цитата:
т.е. допустим тебе надо добавить параметр в метод, добавить просто так нельзя, это breaking changes, но можно сделать следующее: добавляешь к этому методу атрибут SysObsolete, делаешь новый метод-копию с нужными тебе параметрами, правишь везде вызовы на твой новый метод. Профит сейчас при обновлении на 8.1 вылезно несколько таких штук Несовместимые обновления кстати никто не обещал выпускать, обещали без breaking changes Последний раз редактировалось trud; 05.10.2018 в 19:18. |
|
|
За это сообщение автора поблагодарили: EVGL (1). |
05.10.2018, 21:41 | #39 |
Участник
|
|
|
06.10.2018, 04:39 | #40 |
Участник
|
Сложно сказать. Т.е. тут можно поставить вопрос более глобально - если в решении используются методы помеченные SysObsolete - будет ли решение работать правильно?
В части то функций наверное да, возможно будет не учитывать какие-то новые поля в алгоритмах |
|
Теги |
ax7, dyn365fo, dynamics 365 for operations |
|
|