|
05.08.2011, 10:06 | #1 |
Участник
|
К тому же ежегодные деньги, которые необходимо уплачивать за Enhancement Plan совершенно диссонируют с объемом выгод от него получаемых. Мало того, что деньги нужно регулярно отправлять в MS, так еще и ошибки за свой счет исправлять. Одно только неработающее закрытие склада в RU5 чего стоит!
|
|
05.08.2011, 10:59 | #2 |
Участник
|
|
|
15.03.2013, 20:15 | #3 |
Moderator
|
Продолжая сложившуюся традицию оффтопика в данной ветке:
Тарик написал еще одну статью про анализ краш-дампов - теперь для версии 2012: Finding the X++ stack and AX user with public symbols in AX2012 Вероятно стоит это мое сообщение убить, а ссылочку перенести в соответствующее сообщение на первой странице темы - для коллекции. Кстати еще интереснее -почему форум на этот блог не подписан - там довольно много любопытного, как выяснилось. |
|
|
За это сообщение автора поблагодарили: mazzy (2). |
17.11.2020, 16:04 | #4 |
Участник
|
Цитата:
Сообщение от fed
Продолжая сложившуюся традицию оффтопика в данной ветке:
Тарик написал еще одну статью про анализ краш-дампов - теперь для версии 2012: Finding the X++ stack and AX user with public symbols in AX2012 https://web.archive.org/web/20150703...-easy-way.aspx для 2012-й версии ? |
|
16.03.2013, 14:17 | #5 |
Участник
|
спасибо. ссылку добавил. на блог подписал.
|
|
20.03.2019, 11:29 | #6 |
Moderator
|
В общем - решил возродить старую ветку чтобы описать опыт взаимодействия с поддержкой. (Пользуясь случаем, хочу передать привет сторонникам секты "зарегистрируйте вашу проблему в поддержке").
Хронология событий примерно такая: С конца ноября клиент нудно интересуется, почему стандартная себестоимость показывает для некоторых производственных заказов полную фигню: Почти вся себестоимость уходит в substitution variance. Где-то накануне западного рождества удалось выяснить что в D365 есть бага с фантомами. Перенумерация операций маршрута в производственном заказе и в рассчете спецификации использует разные подходы, в результате чего номера операций там и там не совпадают. Поскольку номер операции учитывается при расчете отклонений, то все маршрутные затраты падают в substitution variance (поскольку системе не удалось сопоставить результаты плановой и фактической калькуляции). Где-то числа 4ого января начались попытки зарегистрировать багу в системе. Для начала потребовалось воспроизвести проблему в Contoso. Саппортеры не имеют доступа к нашим окружениям и не могут их скопировать. (Ведь не зря же их теперь называют cloud support). Где-то к числу к 20ому января удалось добиться воспроизведения, но частного случая. После этого в битву вступил Escalation Engineer, который явно не понимал (и не понимает) смысла стандартной себестоимости и доказывал нам что раз отклонения списываются, значит стандартная работает. После пары итераций удалось натыкать его носом в хелп и доказать что это все таки баг. Дальше история развивалась следуюшим образом: 1. Сначала они нам писали что это "by design". 2. Потом "by design", это давно известное ограничение реализации. На вопрос - где оно описано, они выложили свежую статью в issue search в LCS. 3. Потом они все-таки признали что это ошибка. Мы им написали что нас, скорее всего, просто устроила бы новая галочка, которая позволяет исключить номер операции из сравнения при поиске соответствия плановых и фактических расходов. Они сказали что в целом против галочки не протестуют. Мы получили подтверждение клиента что они тоже считают использование номера операции для расчета отклонений экономическим абсурдом и будут всячески поддерживать новую галочку. Мы еще раз подтвердили Микрософту что нас новая галочка устроит. 4. Через неделю внезапно пришло новое письмо из MS, где нам написали что они рассматривают два способа решения проблемы, быстрый и правильный. При быстром они просто подкурочат отчет по отклонениями, но в главную книгу будет все равно фигня разносится. При правильном - они по честному все починят, но это займет больше времени. И спросили какой бы способ мы предпочли? Мы конечно ответили, и организовали конф-колл с клиентом, на тему что нам все равно, нас бы галочка устроила, о который мы пару недель назад вроде бы договорились. 5. Прошла еще неделя, мы получили очередное письмо из поддержки с благой вестью: По результатам конф-колла они приняли решение чинить проблему быстрым способом (то есть - в ГК все равно будет фигня, а про обещанную галочку они и не вспомнили). Сейчас просто замечу, что в DAX2012 я бы либо просто убрал бы номер операции из сравнения за 5 минут (после 2 часов отладки), либо убил бы часика 4 на то чтобы сделать правильный параметр и разные варианты сравнения. С подходом "регистрация ошибки в MS" мы уже убили порядка 4-5 человеко-дней на всякие конф-коллы и воспроизведения в Contoso, фикс будет, как я понимаю, где-то в июне-июле, бага все равно по сути дела не исправлена, а попытаться решить проблему с помощью extensions бесполезно, просто потому что понятно, что в результате регистрации баги, микрософт будет курочить те классы, которые надо расширять. Последний раз редактировалось fed; 20.03.2019 в 12:47. |
|
|
За это сообщение автора поблагодарили: EVGL (10), Vadik (1), trud (3), Logger (3), Stitch_MS (3), mnt_dx (4). |
20.03.2019, 13:19 | #7 |
Модератор
|
Цитата:
P.S. Вариант запросить новый extensibility point - не рассматривали?
__________________
-ТСЯ или -ТЬСЯ ? Последний раз редактировалось Vadik; 20.03.2019 в 13:24. |
|
20.03.2019, 13:27 | #8 |
Moderator
|
Цитата:
Сообщение от Vadik
Понимаю и сочувствую, но вынужден спросить - а дальше что? Цель твоего поста какая, что-то предложить (полагаю, ничего не регистрировать), или просто выговориться?
Но если серьезно - я не верю в One Version и continuous update. Микрософт просто не может себе позволить быстро фиксить баги. Разработка хороших покрывающих тестов - слишком затратна, а если быстро фиксить баги без автоматического тестирования то вероятность остановить систему у очень крупного и скандального клиента - почти 100%. Так что либо они вернуться к старой схеме - с overlayering и релизами раз в 2-3 года, либо через полтора - два года у них случиться резкая утрата рыночной репутации как раз из за того что проекты либо останавливаются после запуска, либо не могут запуститься из за багов. Ах да - над extensibility point мы конечно думаем, только его во первых ждать надо, во вторых - надо бюджет от клиента какой-то, а клиент свято верит что Микрософт свои баги сам править будет. Они же пока верят в One Version. |
|
20.03.2019, 13:30 | #9 |
Модератор
|
Понятно (а с виду - взрослый, серьезный дядька). Ну-ну
__________________
-ТСЯ или -ТЬСЯ ? |
|
|
За это сообщение автора поблагодарили: fed (1). |
20.03.2019, 20:07 | #10 |
Banned
|
Цитата:
Вот забавная примета времени Цитата:
Looking to contact someone who had deployed more than 20,000 seats of AX or D365 F&O in their system? Want to connect a customer looking to do this with another customer who has already done this. Please contact me. Thanks
------------------------------ Barbara Thomas - v-bathom@microsoft.com Global Customer Advocacy Team Lead – WWM&O Marketing Services Microsoft N. Potomac MD https://www.axug.com/communities/com...7-c27a1ed719ac |
|
20.03.2019, 22:38 | #11 |
Banned
|
Цитата:
Сообщение от fed
Где-то накануне западного рождества удалось выяснить что в D365 есть бага с фантомами. Перенумерация операций маршрута в производственном заказе и в рассчете спецификации использует разные подходы, в результате чего номера операций там и там не совпадают. Поскольку номер операции учитывается при расчете отклонений, то все маршрутные затраты падают в substitution variance (поскольку системе не удалось сопоставить результаты плановой и фактической калькуляции).
|
|
21.03.2019, 10:41 | #12 |
Moderator
|
Цитата:
Открытый номер статьи в KB: 289847 Но на самом деле грабля случается только в том случае, если в спецификации есть фантомная строка с пустым маршрутом. То есть - Route Version привязан, но реально Route пустой. Если у тебя производство не очень сложное, то в целом - можно такие маршруты искать батчиком и выкашивать руками. Но если производство сложное, то это может быть чревато, просто потому что маршрут периодически меняется и его нельзя удалять просто потому что на какое-то время производственники решили эти операции отключить. |
|
|
За это сообщение автора поблагодарили: EVGL (3). |
21.03.2019, 11:37 | #13 |
Moderator
|
Цитата:
Сообщение от fed
Но на самом деле грабля случается только в том случае, если в спецификации есть фантомная строка с пустым маршрутом. То есть - Route Version привязан, но реально Route пустой. Если у тебя производство не очень сложное, то в целом - можно такие маршруты искать батчиком и выкашивать руками. Но если производство сложное, то это может быть чревато, просто потому что маршрут периодически меняется и его нельзя удалять просто потому что на какое-то время производственники решили эти операции отключить.
В общем - у прогрессистов-обновляторов похоже что совсем нету автоматических тестов по функциональности фантомов и пользоваться ими нельзя, потому что они в любом апдейте могут тихо умереть. |
|
14.01.2020, 17:00 | #14 |
Moderator
|
Цитата:
Сообщение от fed
3. Потом они все-таки признали что это ошибка. Мы им написали что нас, скорее всего, просто устроила бы новая галочка, которая позволяет исключить номер операции из сравнения при поиске соответствия плановых и фактических расходов. Они сказали что в целом против галочки не протестуют. Мы получили подтверждение клиента что они тоже считают использование номера операции для расчета отклонений экономическим абсурдом и будут всячески поддерживать новую галочку. Мы еще раз подтвердили Микрософту что нас новая галочка устроит.
4. Через неделю внезапно пришло новое письмо из MS, где нам написали что они рассматривают два способа решения проблемы, быстрый и правильный. При быстром они просто подкурочат отчет по отклонениями, но в главную книгу будет все равно фигня разносится. При правильном - они по честному все починят, но это займет больше времени. И спросили какой бы способ мы предпочли? Мы конечно ответили, и организовали конф-колл с клиентом, на тему что нам все равно, нас бы галочка устроила, о который мы пару недель назад вроде бы договорились. 5. Прошла еще неделя, мы получили очередное письмо из поддержки с благой вестью: По результатам конф-колла они приняли решение чинить проблему быстрым способом (то есть - в ГК все равно будет фигня, а про обещанную галочку они и не вспомнили). Сейчас просто замечу, что в DAX2012 я бы либо просто убрал бы номер операции из сравнения за 5 минут (после 2 часов отладки), либо убил бы часика 4 на то чтобы сделать правильный параметр и разные варианты сравнения. С подходом "регистрация ошибки в MS" мы уже убили порядка 4-5 человеко-дней на всякие конф-коллы и воспроизведения в Contoso, фикс будет, как я понимаю, где-то в июне-июле, бага все равно по сути дела не исправлена, а попытаться решить проблему с помощью extensions бесполезно, просто потому что понятно, что в результате регистрации баги, микрософт будет курочить те классы, которые надо расширять. "Microsoft has evaluated this issue and determined that this functionality is working as designed. Currently we support calculation of variances at following levels Summarized : A total variance is posted as price variance Per cost group: The variance is calculated by Price, Quantity, Lot size, Substitution. Per cost group means that we compare the individual BOM lines per Operation ID in the variance calculation. A new feature is required that allow users to select at which level the variance calculation should take place." Не очень понятно, зачем мы прошли через пункты 3-5, если в итоге нас просто послали. Можно было это сразу сделать, сэкономив всем несколько человеко-дней времени. |
|
20.03.2019, 12:20 | #15 |
Участник
|
И это еще повезло, что было куда ткнуть и в целом все-таки действительно баг в логике и учете. В менее очевидных случаях все еще печальнее
__________________
Ivanhoe as is.. |
|
20.03.2019, 12:41 | #16 |
Moderator
|
Цитата:
P.S. да - забыл сказать что escalation engineer несколько раз пытался нас грузить что "раз сумма отклонений правильная, то разблюдовка по видам отклонений не важна, слушайте лучше Валенки". Это в общем довольно забавно было. Последний раз редактировалось fed; 20.03.2019 в 12:54. |
|
20.03.2019, 12:53 | #17 |
Axapta
|
Нам на один из запросов с явной ошибкой в расчете налогов в DAX2012 ответили "All the focus of the product teams is towards the release of application version 10 and if we try to go for a design change request to the product team, in the best scenario, it will get Long-term planned status."
__________________
С уважением, Олег. |
|
14.01.2020, 22:36 | #18 |
северный Будда
|
wolokita as is
__________________
С уважением, Вячеслав |
|
15.01.2020, 22:20 | #19 |
Участник
|
Единственный способ что-то не исправить - зарегистрировать запрос
|
|
|
За это сообщение автора поблагодарили: vmoskalenko (1). |
Теги |
aos, crash, dump analisys, support, tariq bell, uniconta, аос, поддержка, полезное |
|
|