Показать сообщение отдельно
Старый 20.03.2019, 11:29   #52  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
В общем - решил возродить старую ветку чтобы описать опыт взаимодействия с поддержкой. (Пользуясь случаем, хочу передать привет сторонникам секты "зарегистрируйте вашу проблему в поддержке").
Хронология событий примерно такая:
С конца ноября клиент нудно интересуется, почему стандартная себестоимость показывает для некоторых производственных заказов полную фигню: Почти вся себестоимость уходит в 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).