"Управление затратами" в следующей версии Dynamics AX - ваши пожелания

[Ivanhoe]

Хорошие, быстрые отчеты, только мне казалось что они не с RU7 появились, а гораздо раньше?

[fed]

Цитата:

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

Хорошие, быстрые отчеты, только мне казалось что они не с RU7 появились, а гораздо раньше?

Мне казалось что до RU7 они были в отдельной приблуде, которая устанавливалась как xpo-файл. (Хотя возможно я не прав)...

[Stitch_MS]

Наши PMы просили передать:
================================================================
По поводу комментария EVGL:

"...В стандарте нет возможности отнести потребление материалов сразу на несколько производственных заказов по некоей базе распределения. Пример: засыпыем в машину мешок полиэтилена, но не знаем в точности, сколько килограммов пошло за заказ номер 3 из группы 5 однотипных заказов..."

(Этот ответ PMa не перевожу, так как не уверен, что точно переведу термины

There is a new capability that costing for lean manufacturing introduces. As the cost accumulator is the production flow and not a single instance of a kanban, material is accounted against multiple end-products. So far, this is restricted to standard costing.
By the way, there is a whitepaper: "Lean Manufacturing – Production flows and activities"
http://www.microsoft.com/downloads/e...4-e6427b488a29
that describes a couple of possible scenarios, but honestly runs a bit short on the costing part.
Still I would be interested in the feedback of these guys if the costing for lean approach could solve some of their issues, especially the one mentioned above.
And yes, unfortunately the Russian customers need to wait to AX 6.2 (= AX2012 R3) for that, but there may be a customer or partner taking on interest that wants to join the TAP for AX 6.2.

================================================================

По поводу комментария fed:

"...Наконец-то написать вместо продвинутого отчета по остаткам (из Rollup7), который конечно все партнеры благополучно проигноирировали..."

PMы спрашивают: почему так получилось, что Inventory Value и Potential Conflict отчёты были проигнорированы партнёрами? Потому что о них не знали? Потому что не поняли, как они работают ? Что об этом отчёте думает сам fed и как восприняли новый отчёт его клиенты?

================================================================

[fed]

Цитата:

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

Наши PMы просили передать:


PMы спрашивают: почему так получилось, что Inventory Value и Potential Conflict отчёты были проигнорированы партнёрами? Потому что о них не знали? Потому что не поняли, как они работают ? Что об этом отчёте думает сам fed и как восприняли новый отчёт его клиенты?

================================================================

Мои клиенты этот отчет никак не восприняли Просто я сейчас работаю чисто техническим консультантом и разработчиком и поперек консультантов в проект влезть не могу. (По причине языковых барьеров). Я ни разу не видел чтобы отчет кто-то применял. Отчет я смотрел поверхностно (поскольку нету повода с ним разбираться). Учитывая качество партнерской сети, количество стажеров на проектах и отсутствие контроля качества внедрений со стороны MS, документацию редко кто читает и за whitepapers мало кто смотрит. Кроме того, обычно клиент готов заплатить за отчет в его любимом формате. А поскольку задача рассчета складского сальдо среднему партнеру кажется очень простой, они охотно берутся за ее разработку (по принципу - просуммировали inventTrans и если не подбилось - сказали клиенту что себестоимость в Аксапте вообще кривая и лучше мы свою напишем). Ну и чарждат клиента сначала за кривой отчет, а потом еще и за кривую собственную себестоимость. Вот я тут наблюдаю второй раз, как самый золотой-презолотой и рекомендованный микрософтом партнер в Турции, повторяет этот номер второй раз; Первый раз, из за того что их замечательное самописное закрытие склада не срабатывало за трое суток, клиент, в последствии, тупо переписал всю логику (изначально кривую) на T-SQL... На втором проекте объемы поменьше и у их самописки есть шансы уложиться в сутки (и наверное клиента это устроит).

Короче говоря - чуваки, возможно вы делаете неплохой софт (я про MDCC), но до тех пор пока микрософт не начнет СИЛЬНО карать партнеров за насилие над ним, тупость проектных решений и плохую подготовку консультантов, многие из ваших усилий будут пропадать впустую.

P.S. Постараюсь на выходных покопать отчет по смыслу и, возможно, покритиковать.
P.P.S. Кстати я на втором проекте, мягко намекнул CIO,что, возможно, стандартное закрытие склада вполне справится с рассчетом себестоимости по средней для торговой фирмы. Но когда он сказал это партнеру, партнер сказал что через две недели надо сдавать налог на прибыль и у него нету времени разбираться со стандартным закрытием, проще использовать самописное. А потом уж можно будет и со стандартом разбираться если будет время и желание. Правда, боюсь что после того как склад разочек закрыли самописным закрытием, стандартное на нем ни в жизнь не заработает...

[Stitch_MS]

Цитата:

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

возможно вы делаете неплохой софт (я про MDCC), но до тех пор пока микрософт не начнет СИЛЬНО карать партнеров за насилие над ним

"Над ним" - это в смысле над "нашим софтом" или "над микрософтом"?
Хочу передать слово в слово .

Классные отзывы, Денис. Спасибо. Наставьте кто-нибудь ему плюсов, а-то мне ещё сутки ждать, пока я снова смогу ему свои жалкие 3 балла оставить.

[fed]

Цитата:

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

"Над ним" - это в смысле над "нашим софтом" или "над микрософтом"?
Хочу передать слово в слово .

Классные отзывы, Денис. Спасибо. Наставьте кто-нибудь ему плюсов, а-то мне ещё сутки ждать, пока я снова смогу ему свои жалкие 3 балла оставить.

Над софтом конечно.

[EVGL]

Цитата:

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

There is a new capability that costing for lean manufacturing introduces. As the cost accumulator is the production flow and not a single instance of a kanban, material is accounted against multiple end-products. So far, this is restricted to standard costing.
By the way, there is a whitepaper: "Lean Manufacturing – Production flows and activities"
http://www.microsoft.com/downloads/e...4-e6427b488a29
that describes a couple of possible scenarios, but honestly runs a bit short on the costing part.
Still I would be interested in the feedback of these guys if the costing for lean approach could solve some of their issues, especially the one mentioned above.
And yes, unfortunately the Russian customers need to wait to AX 6.2 (= AX2012 R3) for that, but there may be a customer or partner taking on interest that wants to join the TAP for AX 6.2.

Даже не смешно. Неужели они всерьез думают, что клиенты бросятся перевнедрять производство под Lean? А сколько производственных предприятий - новых клиентов работает по схеме Kanban и принципиально готовы к внедрению?

[pitersky]

Цитата:

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

Даже не смешно. Неужели они всерьез думают, что клиенты бросятся перевнедрять производство под Lean? А сколько производственных предприятий - новых клиентов работает по схеме Kanban и принципиально готовы к внедрению?

Я так думаю, что если предприятие не стремится к переходу на Lean (в дискретном производстве), то это немного странно. Lean уже доказал свою эффективность, почему этим не воспользоваться? Причём вне зависимости от наличия Аксапты

[EVGL]

Цитата:

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

Я так думаю, что если предприятие не стремится к переходу на Lean (в дискретном производстве), то это немного странно. Lean уже доказал свою эффективность, почему этим не воспользоваться? Причём вне зависимости от наличия Аксапты

Я не работаю с серийным дискретным производством, поэтому для моих клиентов "lean" - это пустой звук.

[fed]

Я пожалуй готов конструктивно покритиковать отчет по выверке ГК и склада (Inventory value report):

Во первых, за десять лет с Аксаптой, я второй раз разбираюсь с отчетом. Ну то есть, все знают, что если пользователю показать Аксаптовский отчет и предложить с ним разбираться и работать, то пользователь начнет жаловаться, стучать ножкой и требовать себе нормальную форму с гридом, поиском и возможностью эскпорта в Excel. Собственно - именно по этому, партнеры крайне редко разбираются с ЛЮБЫМ отчетом. Зачем - если он понадобится, его все равно передется на на форму и грид переписывать... Собственно, это ключевая причина по которой отчетом не пользуются. Если бы меня на слабо не взяли, я бы и сейчас не полез разбираться. (Кстати в прошлый раз я на этот отчет наткнулся тогда, когда искал примеры использования хелперов, а не потому что мне этот отчет был нужен).

Вторая стратегическая ошибка - это то, что этот отчет выверяет одни непонятные циферки с помощью других непонятных циферок.
Хотите чтобы пользователи отчетом пользовались, попробуйте сделать так примерно:
1. На экране находится грид, в котором в первых двух колонках находится код номенклатуры и ее название. К гриду приделана стандартная складская аналитика, с возможностью ее показывать в гриде и на отдельном табе.
2. Для каждой цифры по номенклатуре должен срабатывать drill-down на следующий уровень данных. Например - щелкнул я на колонке WIP Qty, открылась формочка со складскими проводками списания данной номенклатуры в производство, щелкнул на на колонке с непрямыми затратами, открылась формочка с prodIndirectTrans, щелкнул на колонке с Deferred COGS- складские проводки в статусе Deducted по продажам.

В таком случае, пользователь будет доверять цифрам, поскольку он может сравнить исходные данные с рассчетами. Нет, я конечно верю что у вас в коде нету ошибок и он дает правильные результаты. Но ведь если у меня встала задача выверки склада, значит что-то у меня в данных не так. Может партнерские модификации с ошибками, может нечаянно джобиком какие-то данные удалили. Соответственно - ни одной стандартной цифре верить нельзя, до тех пор пока она не выверена первичными проводками. А в нынешнем варианте идет попытка выверить одни цифры, которым нельзя доверять с помощью других цифр, которым тоже нельзя доверять.

Говоря о более мелких замечаниях:
Долго не мог добится печати собственно кода номенклатуры. Оказывается включать его надо галочкой с интересным названием "Resource Id". Пока не полез в код разбираться - не догадался. До этого система печатала загадочные отчеты с количествами но без номенклатуры.

Не очень понимаю любви к названиям полей типа "Deferred COGS account" или "COGS". Нет, я конечно понимаю, какой финансовый смысл стоит за этими словами. Но чтобы догадаться что имеются в виду счета разноски Sales - packing slip и Sales -revenue - это надо либо долго экспериментировать, либо опять таки лезть копаться в исходном коде. Поэтому просьба, если вы в настройках складской разноски или складских моделей используете какой-то термин, то используйте его же и в отчетах. Если вы вспомните о том, как метки переводятся на другие языки (чуть-ли не машинной трансляцией), то вы поймете почему я об этом так прошу. Возможно после машинной трансляции перевод будет не ахти какой, но он хотя бы одинаковым в разных местах модуля будет.

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

Также не понял смысла вводить в параметры отчета счета ГК. По логике вещей, надо брать счета ГК для данной номенаклатуры либо из настроек разноски, либо сохраненные счета из inventTransPosting. В существующем виде мне надо будет как-то сделать настройки отдельного отчета для каждой номенклатурной группы (с разными разносками), при том что номенклатурную группу-то я как раз и не могу задать в параметрах отчета. Так что если я в отчет вбил счета от одной группы, а пользователь у меня при запуске отчета выбрал другую группу, то меня ждет большой облом.

Не очень понял наличия галочки "Average Unit Cost". Вроде бы для всех моделей кроме средней, в этой галочке нету особого смысла.

"Inventory transactions: Include not posted to ledger". Не понятно - это вообще не разнесенные транзакции включать, или все-таки транзакции с физической разноской (которые в общем-то могут быть разнесены на счета ГК, пусть и accruals). Если речь идет о физически разнесенных складских проводках (в статусах Deducted и Received), то может и стоило написать "Include physically posted inventory transactions"?

[EVGL]

Цитата:

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

Не очень понимаю любви к названиям полей типа "Deferred COGS account" или "COGS". Нет, я конечно понимаю, какой финансовый смысл стоит за этими словами. Но чтобы догадаться что имеются в виду счета разноски Sales - packing slip и Sales -revenue - это надо либо долго экспериментировать, либо опять таки лезть копаться в исходном коде.

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

Что касается "Include not posted to ledger" и "Ressource Id" - полный пролет, конечно. Я как раз на прошлой неделе был на тренинге по AX2012, где в том числе смотрели эти отчеты. Если у группы из 15 консультантов ни у кого нет мгновенного интуитивного понимания, то что-то не так в самой программе.

По выборке по счету ГК у меня нет определенного мнения. Практически любая выверка начинается с того, что сравниваем сальдо на счете с суммой по складу. Если не сходится, то посыпаем голову пеплом, берем неделю и начинаем копаться в проводках. В этом плане счет ГК - достаточно естественная настройка, несмотря на все негативные стороны.

[fed]

Цитата:

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

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

COGS - термин распространенный - согласен. Deferred COGS - уже что-то менее стандартное. К слову сказать, я когда исходное сообщение писал, в запарке назвал не те счета из разносок (Revenue вместо Consumption). И ты не заметил Что как раз говорит о том что не хорошо разную терминологию использовать...

[fed]

Цитата:

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

По выборке по счету ГК у меня нет определенного мнения. Практически любая выверка начинается с того, что сравниваем сальдо на счете с суммой по складу. Если не сходится, то посыпаем голову пеплом, берем неделю и начинаем копаться в проводках. В этом плане счет ГК - достаточно естественная настройка, несмотря на все негативные стороны.

Наверное могу согласиться. Но в таком случае, надо в параметрах отчета дать возможность жестко указывать группы (или группы) номенклатуры. Тогда можно будет задать в параметрах отчета счета и те группы номенклатуры которые должны на эти счета разноситься.

А если смотреть на проблему более комплексно, то хорошо бы реализовать возможность поддерживать однозначную связь между проводкой модуля и проводкой (проводками) ГК. А в конце периода, специальной кнопкой схлопывать (после выверки периода) деальные проводки ГК в суммированную проводку по ваучеру. Вот тогда можно будет реально выверять модуль с ГК. Однако, такой подход потребует капитального изменения архитектуры интеграции всех модулей с ГК.

[Maxim Gorbunov]

Кстати, если уж зашла речь про выверку, то не помешал бы отчёт, который позволил бы сверять рассчитанную себестоимость после закрытия по weighted average, с начальным остатком и приходами за период. То есть, по сути, оборотная ведомость по складу, заточенная под выверку себестоимости. Я в курсе, что в русской локализации оборотная ведомость есть (про её качество сказать ничего не могу), но, как выясняется, сверять себестоимость любят не только в России Ещё бы неплохо было, чтобы отчёт как-то основные источники "ошибок" выделял: маркировку, переносы, возвраты. Практика показывает, что такой отчёт в проекте просят одним из первых. Практически у всех партнёров, конечно, уже есть наработки, но их качество очень сильно разнится (о чём уже было сказано выше).

[Stitch_MS]

Еще раз всем спасибо за участие.

В данный момент мы тут мастерим онлайн-опросник (на английском), посвященный управлению затратами, в связи с чем один из ПМов разослал нашей команде следующую просьбу:

----------------------
Please check your records of contacts at Partners, Customers and even non Customers. If you have contacts that have a focus on Cost management or Inventory valuation and you think they might be interested or willing to participate in this research program for Cost management, please send me Name and e-Mail address + a short statement why you think this would be of interest.
----------------------

Если у кого-нибудь появится желание поучаствовать, или вы знаете кого-то из клиентов/партнеров/консультантов, кто был бы не против потратить 15 минут своего времени чтобы мы тут лучше поняли, в каком направлении идти: пришлите, пожалуйста, мне в личку имя, email, и пару слов на тему why you think this would be of interest.

Неразглашение данных гарантирую.

Спасибо.

[Zabr]

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

[fed]

Наверное поезд уже ушел, но допишу для порядка: Сегодня второй раз сталкнулся с интересной схемой рассчета средней себестоимости и учета возвратов. На первом этапе считается средняя себестоимость для всего, КРОМЕ ВОЗВРАТОВ. В идеале еще и пишется средняя себестоимость в какую-то табличку - в разрезе номенклатуры и аналитик финансового склада. На втором этапе, все возвраты переоцениваются до получившейся средней себестоимости. Схема применяется тогда, когда идет торговля быстро уцениваемым товаром. Типа газет Соответственно - необходим механизм регулярного рассчета справедливой себестоимости товара для возвратов.
В существующую схему расчета себестоимости это дело, вроде бы, пристойно укладывается. Просто в момент создания фиктивного переноса сначала рассчитываем количество и сумму для всего кроме возвратов, потом немедленно переоцениваем возвраты по пропорции количество_возврата*общая_сумма/общая количество. Потом докидываем сумму и количество возвратов к сумме и количеству расходной и приходной проводок фиктивного переноса и дальше работаем как обычно. Можно еще сделать какую-то отчетную форму, которая просто показывает проводки фиктивного переноса в каждом периоде и выводит по ним среднюю себестоимость (просто display-метод. Хотя вроде бы в 2012ой появилась поддержка вычислимых полей во view...)

[Stitch_MS]

Цитата:

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

Наверное поезд уже ушел

Пока нет . Переведу, разошлю. Спасибо!

[Ivanhoe]

Пришли ссылки на опросы. Вопросы пока общие, а зачастую не однозначные. Также не совсем адаптированы для партнеров с опытом разных проектов. Посмотрим, что будет дальше

[Stitch_MS]

Цитата:

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

Пришли ссылки на опросы. Вопросы пока общие, а зачастую не однозначные. Также не совсем адаптированы для партнеров с опытом разных проектов. Посмотрим, что будет дальше

А можно в личку примеры неоднозначностей, не-совсем-адаптированности и т.п.? Я бы это создателям опросов передал - они только спасибо скажут.