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

[fed]

Цитата:

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

Наконец, говоря о проблеме корректировок складских проводок задним числом, затронутой опять таки logger'ом, надо:
1. Наконец-то написать вместо продвинутого отчета по остаткам (из Rollup7), который конечно все партнеры благополучно проигноирировали, а внятную методичку, которая объясняла бы как и почему считается финансовый остаток по номенклатуре на дату, объясняла бы что рассчитывать остаток тупым суммированием inventTrans - нельзя, а также то, что считать денежный остаток по номенклатуре можно только в разрезе подмножества финансовой складской аналитики. Я просто ни разу не видел чтобы кто-то всерьез использовал стандартные отчеты по складским запасам, все пишут свои (просто потому что нужен красивенький отчет с экспортом и в том виде, в котором его привык видеть клиент). И большая часть партнеров не обладает пониманием того как правильно себестоимость складскую считать.
2. Надо сделать специальную галочку (в складской модели наверное) "Запрет корректировки закрытых проводок" и специальный счет "корректировки прошлых периодов" (в разноске по номенклатуре). Если эта галочка установлена, то надо будет при любой попытке прогнать себестоимость через закрытую проводку, немедленно списывать данную корректировку себестоимости на счет корректировок прошлых периодов. При этом надо ОЧЕНЬ тщательно расписать в методичке, что вообще говоря, корректировка прошлых периодов является признаком проблемы с первичными данными. Либо нарушена хронология приходов и расходов, и начисление накладных расходов на открытый приход, из за нарушения хронологии, протягивается через приходы прошлых периодов, либо бухгалтерша по ошибке повесила текущие накладные расходы на накладную прошлого месяца. Причем надо понимать, что подход этот поможет только в сложных ситуациях (когда у нас циклы в графе себестоимости есть или что-то подобное). Если у меня незакрытый расход прошлого месяца сопоставился с приходом текущего (просто потому что бардак в первичке), то никакие переоценки и счета корректировок прошлых периодов - не помогут, потому что списание это сможет работать только при корректировке ПРИХОДА прошлых периодов - а у нас в этом примере у прихода все впорядке с датой, не в порядке дата у расхода...

После некоторых раздумий:
Хорошо бы еще завести какую-то анализируемую таблицу протокола закрытия (ведение которой включается галочкой в форме закрытия). И писать туда о всех нехороших ситуациях при закрытии. Например если в ходе сопоставления сопоставились с расходом закрытого периода. Или информацию о списанных округлениях. Или ситуации когда не нашлось inventTransPosting и система взяла стандартные счета.
Еще неплохо бы после стадии сопоставления (но до стадии прогонки себестоимости), иметь возможность запускать (в качестве дополнительного, опционального шага) процедуру поиска циклов в графе сопоставлений. Правда мне кажется что этот алгоритм не распараллелить, а на одном хэлпере он может очень и очень долго выполняться. В общем - не уверен, хотя сама по себе идея интересная...

[Stitch_MS]

Ваши пожелания разосланы, и наши ПМы уже нашли их "интересными".
Более того, они переслали это ПМам, работающим над Manufacturing, и, судя по начавшейся переписке, ваши пожелания будут учтены.
Особенно им понравился пост feda .

Кстати, fed, зацени, пожалуйста, перевод твоих замечаний по закрытию склада (там была пара-тройка мест, где фразу можно было понять неоднозначно, так что я мог накосячить):

Regarding inventory closing - actually only one major problem remains there, which is mentioned by Logger. Both instant cost and actual cost (the one calculated when closing inventory) must be linked to a combination of "lot ID + financial inventory dimension", rather than to the "lot ID" alone. In that case, the cost will not be distorted, when tranferring inventory. But once you implemented this, you will also need to limit how batches of items may be merged or split in the inventory transfer journal, so situations when 2 batches are received, while 3 batches are issued, were not possible; another journal type would be needed, that would allow for merging/splitting inventory dimensions, so either 1:n or n:1 would be valid, but not n:m.

As to something minor, but still useful: the useless "check open quantities" function should be replaced with a check of open quantities per item ID within the whole period being closed. If I have an item sold before it was bought (even though the current open quantity is positive or zero), the system should report that some particular item has broken sequence of issues/receipts, so there is no way to calculate its actual cost correctly. It doesn't mean that users must be prevented from doing this. We just need a more advanced tool that woould notify users: "something went wrong with the sequence of events, so the inventory closing result may be wrong". Theoretically, it would be cool, if this tool allowed for reversal of wrong documents and posting them with the right date, but this is something very complex to implement...

By the way, some time ago I wrote in my article why it was difficult to check open quanities for a date when issuing from inventory. First of all, because of performance, then because of reservation (if you have something available for reservation now, it is hard for you to explain why they don't allow you to issue the goods). I mean, I doubt that Microsoft could make such a check for issue events, even if they wanted to...

Finally, regarding the backdating problem (also mentioned by Logger), the following is needed:
1. Instead of the advanced open quantities report (from Rollup 7), which has been simply ignored by the partners, there must be a whitepaper that would:
- clearly describe how and why the open financial quantity for an item is calculated on a certain date;
- explain, why calculating open quantities with a simple summarizing in InventTrans is wrong;
- explain that open amounts per item must be calculated for subsets of financially active inventory dimensions. The most of the partners don't understand how inventory cost should actually be calculated.

2. There must be a new checkbox (most likely in the inventory model setup) named "Block adjustment of closed transactions" and a new account named, say, "Adjustments of previous periods" (for item posting). If this checkmark is on, then whenever a cost is propagated through the closed transaction, this adjustment should be posted to this account. By the way, the whitepaper should thoroughly explain that adjustment of previous periods indicates that there are problems in the initial data: either the sequence of receipts and issues is brocken (so that markup allocated to an open receipt is propagated through receipts of the previous periods), or accountant made a mistake by allocating current markup cost to a previous period invoice. One must realize, that this approach will help only in complicated cases (when there are cycles in the cost graph or something like that). If I have an open issue from the previous month that got settled with a receipt in the current period (because of a mess in the initial data), then neither revaluation or adjustment of the previous periods will help, as this issue will work only when adjusting a previous period RECEIPT - and in our example, the receipt date is fine, the problem is with the issue date...

Finally, they must implement something that is already done in the Russian localization - there must be a new account in the posting profiles, for posting errors and rounding errors during inventory closing (i.e. normal errors, not something related to adjustments of previous periods). Again, the whitepaper should explain how that works. The thing is that - in the Western standard - a "P&L for item" account is used for that, and it is impossible for an average consultant to figure out "why those N cents with some dimension value appeared on the P&L account" by looking at the inventory closing voucher.

Also, one might add a new field to the InventSettlement table (or extend some enum with a settlement type), so it would be easy to find all those corrections with errors and rounding errors in the InventSettlement table.

------------------

It would also be nice to have a table where the process of inventory closing could be logged. This optional feature would be enabled with a checkbox on the IC form, and anything what went wrong during the closing process would be "written down". E.g.:
- if there was a settlement with an issue in a closed period, or
- information about posted roundings, or
- a situation when there were no InventTransPosting and standard accounts were used.

Another nice-to-have is an optional analyzer, that would look for cycles in the graph of settlements. The analyzer would be run between the settlement and the cost propagation steps. However, it seems to me that this algorithm cannot be split to multiple threads, and it might be too long to run it with one helper. I believe the idea is interesting, though.

[fed]

Вроде все нормально с переводом. Спасибо ! Если что - ваши PMы могут спросить, чего я имел в виду. В целом я не против с ними напрямую подискутировать если что

[Stitch_MS]

Цитата:

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

Вроде все нормально с переводом. Спасибо ! Если что - ваши PMы могут спросить, чего я имел в виду. В целом я не против с ними напрямую подискутировать если что

Тебе спасибо.
PMам так и передам .

[fed]

Все таки я немножко тормоз: под " Instead of the advanced open quantities report (from Rollup 7)" имелся в виду отчет Inventory Value Report, про который пишут вот здесь: http://blogs.msdn.com/b/axinthefield...namics-ax.aspx

[Ivanhoe]

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

[Stitch_MS]

Цитата:

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

под " Instead of the advanced open quantities report (from Rollup 7)" имелся в виду отчет Inventory Value Report, про который пишут вот здесь: http://blogs.msdn.com/b/axinthefield...namics-ax.aspx

ОК, учтём.

[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 уже доказал свою эффективность, почему этим не воспользоваться? Причём вне зависимости от наличия Аксапты

[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 консультантов ни у кого нет мгновенного интуитивного понимания, то что-то не так в самой программе.

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

[EVGL]

Цитата:

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

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

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

[fed]

Цитата:

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

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

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

[fed]

Цитата:

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

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

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

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

[Maxim Gorbunov]

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