dynamics-coe: One warehouse, 2 cost models

[Blog bot]

Источник: http://blogs.msdn.com/b/dynamics-coe...st-models.aspx
==============

Around 14 years ago I designed a feature called the “Dual warehouse”. The feature is scarcely documented (https://technet.microsoft.com/en-us/.../jj733298.aspx) and barely understood. It was intended to maintain 2 warehouse cost prices in parallel in countries suffering from hyperinflation. In 2002 I was even given a chance to present this feature to Erik Damgaard, at that time known not as a Danish TV celebrity but the Damgaard Data co-founder and the father of Dynamics AX. His verdict was “he understood the benefit but the approach was a bit too radical” to his taste.

Indeed, the feature was not only tracking inventory cost in 2 currencies (the local accounting one and in the reporting i.e. secondary currency) but also calculating it in accordance with 2 different cost calculation models and posting the financial impact into the general ledger in an isolated GL layer to make it visible on IFRS vs. local account statements. Every inventory transaction was given an additional set of fields CostAmountSecCur* to store the value in the secondary currency. The feature was blamed for bugs, but after a while it made it into the Dynamics AX core application. A decade later the bugs are gone and the feature is still there in Dynamics AX 2012 R3 for Russia and other Eastern European countries, it has been kept on a par with the latest developments at the AX logistics core.

What have been the reasons to keep it in the application?

• Initially it provided a stable inventory value in the ‘hard’ currency USD, in a country where retail prices in rubles RUB were updated daily and sometimes grounded in a pseudo-currency tied to the dollar. The COGS in RUB was reflecting the past purchase price whereas the revenues were driven by the inflated sales price, resulting in a disproportionally huge profit in RUB. Only the COGS in USD was comparable with the revenues in USD and provided a more solid basis for a business decisions in an economy ravaged by hyperinflation. With the Russian economy “in tatters” my dual warehouse feature may gain back some popularity :)
  
• Not that long time ago I was asked by a CEO: “We buy in euros, we sell in euros, why on Earth would we track our stock and assets in the Polish zloty?!” Indeed, IAS 21 says “an entity is required to determine a functional currency … based on the primary economic environment in which it operates”, but auditors are generally less tolerant and expect the balance to the produced in the national currency.
  
• Costing models in accounting and in the cost accounting sometimes differ. For example, on the balance sheet the average price may be applied to the product stock, whereas in the cost accounting the product may be recorded at a standard price. Here we may utilize the “dual warehouse” with the reporting currency same as the local one but with 2 different cost valuation models.
  

The emphasis is put here on the last requirement as it seems to be pretty common across the globe.

Example 1

I am using the standard Dynamics AX 2012 R3 demo database, the RUMF company. “RUB” is both the local currency and the reporting currency there. The license configuration key Country regional specific features / Multiple countries regions / Russia / Dual warehousing must be active. Contrary to AX2009, local compliance features in Dynamics AX 2012 cannot be re-used in a “foreign” legal entity by just turning the configuration key: the primary company address must be in Russia. I leave it to the reader to hack AX and to ‘jailbreak’ this feature. Do not expect it to be very easy.

Let me first highlight the business case the feature was initially intended to support. Imagine a product valued at a monthly average price. It is delivered in 2 batches at the same effective price in USD but a different equivalent in RUB:

Date

Business case

Price USD

Rate USD/RUB

Primary cost price RUB (Weighted avg.)

Secondary cost price USD (Weighted avg.)

15.01.2015

Purchase 100 kg

10,00

66,10

66,10

10

17.02.2015

Purchase 100 kg

10,00

62,66

64,38

10

16.05.2015

Sale 50 kg

15,00

50,01

64,38

10

The contribution margin in the ‘hard’ currency USD is 33.33%, while the contribution margin in RUB is just 14.17%. Which is the “right” one depends on the cost structure of the company. Technically, the one cannot be deducted from the other without knowing the full transaction history. In Dynamics AX a separate inventory closing run is required. This is exactly what the “Dual warehouse” feature does: it allows for 2 parallel closing runs, 2 settlement data pools and a secondary GL ledger.

Example 2

Now let us explore my major case with one currency but 2 models:

Date

Business case

Price USD

Inventory cost price USD (Weighted avg.)

Inventory cost price USD (Standard)

Cost variation USD

15.01.2015

Purchase 100 kg

10,00

10

10



17.02.2015

Purchase 100 kg

12,00

11

10

+2

16.05.2015

Sale 50 kg

15,00

11

10



To test it, set up a new item model group. Pay attention the secondary inventory model group and the Post secondary financial parameters. The latter activates the “dual” GL posting layer.



Create a new product with the tracking groups None-None. Assign a default site and a warehouse. Use the button Manage costs / Item price on the released product ribbon to assign a standard price to the item. Do not enter the price of 10.00 on the first tab page of the “Pending price” grid but on the second, in the field Secondary cost! Leave the primary standard cost to be zero. Activate the price. In the item group of the product, set an account for the “Rounding variance”.

Open a purchase order to the “Vortex corporation” and post 2 PO invoices with different prices as outlined above. Open a sales order and post an AR invoice with 50 kg.

Now check the inventory transactions and look at the awaited, but still stunning result, or as we say at Microsoft – awesome. Just awesome:



Note the column Cost amount (cur.) meticulously tracking our standard cost as opposed to the average cost in the ordinary Cost amount column. Now open the GL voucher for the second PO invoice:



Examine how the system recorded the cost variance in a separate posting layer.

You may also perform the Inventory management / Periodic / Closing and adjustment vs. Closing and adjustment in currency. Here nether of the procedures is going to make any cost adjustments, since within the primary cost model the momentary cost price happens to be the same as the total average, while the secondary model should not produce any settlements at all for our product valuated at a standard cost.

Conclusion

The examples above have been deliberately kept simple; in reality different currencies and models lead to collisions where an inventory transaction may be settled in one model but remain ‘open’ in the other; where manual adjustments and write-offs are only applied to one of the models; where the ‘physical’ price affects the calculation. I still hope this short introduction has given you an idea what this feature can do if applied creatively.






Источник: http://blogs.msdn.com/b/dynamics-coe...st-models.aspx

[gl00mie]

Цитата:

Сообщение от Blog bot

Around 14 years ago I designed a feature called the «Dual warehouse». A decade later the bugs are gone

Bullshit!!! Это глюкалово до сих пор по-нормальному не работает, потому что все эти 14 лет никто его толком, видать, не тестировал: закрытие склада/пересчеты валятся с ошибкой деления на ноль, отмена закрытия склада/пересчетов не работает в пакете (вместо валюты отчетности пытается отменять в валюте учета), какая-нить там малоценка и спецодежда вообще чихать хотели на слой разноски "валютный склад" и, скажем, при отмене ввода в эксплуатацию разносят в ГК фарш из проводок на первый попавшийся слой разноски. Ааа!!! И идите лесом со своей регистрацией багов...

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

[gl00mie]

А, да, еще пересчет себестоимости в валюте не запускается в пакете в принципе, потому что CLR не умеет приводить тип InventCostClosingRecalcSecCur_RU к InventCostClosingRecalc: первый не является прямым или косвенным наследником второго, и такое раздолбайство с приведением типов прокатывает только в интерпретаторе Х++.

Т.е. с момента выхода AX 2012 никому из Microsoft, включая автора исходной публикации, даже в голову не пришло запустить пересчет себестоимости в валюте в пакетном режиме.

[fed]

Цитата:

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

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

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

[Logger]

Цитата:

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

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

Там еще криво проводки InventTrans расщеплялись при совместном использовании закрытия по первичной и вторичной валюте.

[EVGL]

Цитата:

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

И идите лесом со своей регистрацией багов...

Интересный подход. MCS - такой же партнер MBS, как и все остальные. И ничего, регистрируем найденные ошибки, работаем с поддержкой, а не встаем в позу как дива.

[gl00mie]

Цитата:

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

Ты там поспрашивай аксакалов - может его и вправду где-то внедряли.

Мне самому довелось участвовать во внедрении этого чудо-функционала и узнать "интимные подробности" его работы

Цитата:

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

Интересный подход. MCS - такой же партнер MBS, как и все остальные.

Я очень рад за вас Среди партнеров MBS, наверно, принято прогонять сквозной пример, прежде чем рекомендовать какой-то функционал? Интересно, как в вашем сквозном примере отработал пакет пересчета себестоимости в валюте?

[EVGL]

Цитата:

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

Среди партнеров MBS, наверно, принято прогонять сквозной пример, прежде чем рекомендовать какой-то функционал? Интересно, как в вашем сквозном примере отработал пакет пересчета себестоимости в валюте?

В пылу эмоций логика молчит. Что мне еще для вас прогнать в свободное от моих клиентов время? Ох уж этот русский человек со своей пассивностью и фатализмом, всегда можно указать на кого-то другого, который должен был бы сделать за вас работу.

[gl00mie]

Цитата:

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

Интересный подход. MCS - такой же партнер MBS, как и все остальные. И ничего, регистрируем найденные ошибки, работаем с поддержкой, а не встаем в позу как дива.

Цитата:

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

В пылу эмоций логика молчит.

Всю "логику" регистрации найденных ошибок уже давно и подробно расписал fed, если забылось, я напомню:

Цитата:

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

в 99% случаев любой баг правится самостоятельно, а потом, возможно, регистрируется в MBS. Однако, регистрация уже исправленного тобой бага в MBS, это гарантированно работа с негативным экономическим эффектом, поскольку:
1. Ты тратишь свое время (гарантированные затраты), с очень негаратированным результатом (неизвестно признают ли твой инцидент ошибкой; если признают, то неизвестно будут ли исправлять; если будут исправлять - то неизвестно в каком rollup).
2. В случае если ошибка будет таки исправлена, то с большой вероятностью, это приведет к дополнительным затратам. Скажем, если ты незарепортил баг, то скорее всего твое исправление будет поднято на новый rollup (если ты на него будешь апргрейдиться) полуавтоматически, Если же ты его зарепортил, то тебе придется заниматься исследованием того как микрософтовский подход к исправлению бага отличается от твоего собственного, курочить и свой и микрософтовской код, писать конвертеры данных для апгрейда.
Соответственно, регистрация ошибок выгодна ТОЛЬКО для партнеров (которые вели и ведут много проектов) и ТОЛЬКО если речь идет о какой-то часто встречающейся ошибке, в часто внедряемом модуле. Только в этом случае, есть слабые шансы что затраты на регистрацию ошибки, когда-то отобьются. (И то не факт).

Цитата:

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

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

Во-первых, спасибо за понимание, Евгений, и надеюсь, что вы не [слишком] стыдитесь своего происхождения после общения с подобными мне соотечественниками.

Цитата:

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

Что мне еще для вас прогнать в свободное от моих клиентов время?

Во-вторых, для меня прогонять ничего не надо, "я себе уже всё доказал". Но коль скоро

1. вы в корпоративном блоге для ваших, надо полагать, нынешних и потенциальных клиентов расписываете какой-то функционал, при этом
2. ссылаетесь на то, что MCS, т.е. ваш работодатель, насколько я понимаю, - такой же партнер MBS, и
3. чуть ранее совершенно искренне заявляете, что в вашей группе - только опытные спецы, отбор очень строгий

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

[EVGL]

Мысль понял. Вы критикуете меня за недостаточную проработку блога, написанного на общественных началах вечером в свободное от работы время, и ожидаете большего качества. Это ваше право, разумеется. Более того, вы даже можете оставить там соответствующий комментарий: "bullshit!" Целью однако было не детальное тестирование функциональности, а проверка (proof of concept) определенного не предусмотренного сценария и популяризация данной функции. Потому как вещь, которая никому не нужна, совершенно точно не будет ни развиваться, ни исправляться.

К регистрации ошибок вы подходите с экономической точки зрения: "выгодно-не выгодно". Разница в европейской ментальности, если угодно, это альтруизм, улучшение мира, а не только жалобы на него. К примеру, соседка подбирает мусор не только тот, что валится на ее участке, но и на улице перед домом. В этом ключе я постараюсь проверить проблему с пакетной обработкой, а также зарегистрировать баг. Еще у меня в запасниках лежит баг с отсутствием округления в русском реестре просроченной задолженности, есть еще кое-что. Делать это придется в свободное от работы время, так что не ожидайте быстрых результатов.

[Logger]

Цитата:

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

К регистрации ошибок вы подходите с экономической точки зрения: "выгодно-не выгодно". Разница в европейской ментальности, если угодно, это альтруизм, улучшение мира, а не только жалобы на него. К примеру, соседка подбирает мусор не только тот, что валится на ее участке, но и на улице перед домом.

Вообще-то в США и Британии по закону домовладелец несет ответственность за порядок перед своим домом. Или если сосулька с вашего дома упадет и прибьет прохожего - есть шансы присесть в тюрьму. Так что еще вопрос, где тут альтруизм а где суровая необходимость. Хорошие законы там придуманы

Возможно, в Австрии должно быть нечто подобное.

P.S.
Но с темы вы красиво съехали.
Завидую.

[fed]

Цитата:

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

К регистрации ошибок вы подходите с экономической точки зрения: "выгодно-не выгодно". Разница в европейской ментальности, если угодно, это альтруизм, улучшение мира, а не только жалобы на него. К примеру, соседка подбирает мусор не только тот, что валится на ее участке, но и на улице перед домом.

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

[Digger]

Коллеги,

а каким образом можно настроить разноску проводок по валютному складу на отдельных забалансовых счетах?