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

[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.