[Stitch_MS]

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

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

EVGL:

According to IFRS, material and labor consumption should be considered when calculating production costs. However, in Russian and Turkish accounting, it is also accepted to include worker salaries, amortization of machines, electricity etc. to production costs. For now, the only way to do that in AX is by using "allocation + cost adjustment", in "semi-manual mode".

It should be possible to include transportation and other costs to the cost of raw materials, and that feature should be integrated to the kernel. This feature is implemented in the Russian localization higher than AX2009 RU4, and the solution is good enough: "accounting distribution". This is a must in all accounting standards, from London to Vladivostok (Russia's largest port city on the Pacific Ocean). Our consultant specialized in Austrian finance was fascinated by this feature.

Well, this one is not quite related to costs, but posting of picking lists in AX does not follow the Western accounting standards. Both "Debit Balance - Credit Balance" and "Debit Costs - Credit Balance" postings are not good enough, so auditors ask questions. I suppose, your analysts are aware about this problem, but do nothing to resolve the issue.

There is no way to assign single material consumption to multiple production orders based on some sort of "distribution base". Say, we pour a bag of polyethylene to a machine, but we don't know for sure how many kilograms have been consumed for production order #3 in a group of 5 orders of the same type.

And the most fatal flaw is that there is no way to make several byproducts based on one production order (except in the Process module). Costs are not distributed; it is not possible to account for that in master planning. This modification is so complex that there are hardly any partners that would dare to solve this problem. There is a "waxwork" of that in the Russian localization, but it is only a "waxwork".

(A comment left to this post by another user: I have nothing to add to that. All major functional holes would get closed.)

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

Raven Melancholic:

I cannot tell what could be a technical must-have in this module. But from my point of view, what is needed in Russia is:

1. documentation that would explain how CERTAIN enterprise problems could be solved;

2. translated documentation, that would use terminology well-established in Russia;

3. publication of business cases, in Russian of course. All in all, one should not forget that documentation about development in AX may be published in English, but when we are talking about consultants, finance and operation people, the documentation must be translated to the local language, if you want to promote your module in the region. Terminology and examples should consider the well-established preferences in the region.

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

Logger:

Calculation of cost amounts (say, when posting inventory movement journals) is buggy under certain conditions. To be honest, there is no cost calculation per inventory dimension in AX. Costs may become mixed for different dimension values – regardless of settings – when moving inventory, filling return lots or marking.

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

I would also consider improving inventory reconciliation functionality.

The biggest problem for finance analysts is that it is possible to use the current system date when adjusting a posting from a previous period. To my experience, the average finance analyst or accountant have difficulties with understanding this. They just don't get it. As a result, after each inventory closing, questions arise as to why inventory doesn't reconcile to ledger.

It would be nice to have something intuitive enough to most of the users. I can't propose anything concrete so far.

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

fed:

As I see it, you have 2 possible paths of development.

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

The first approach is to keep maintaining compatibility with the old versions and don't implement subsidiary accounts for cost accounts. In that case I agree with EVGL. What we are missing is an extensible mechanism of cost distribution, to which I would be able to add new distribution bases and distribution objects in an easy way. Say, it would be possible to create a new distribution object “a truck with a cargo” and a new base “kilogram per kilometer”, and then create the second level for the distribution object “goods in the truck”, with a new base “cubic meters of the cargo”. Again, I don't expect a new transportation module from you; I just need a mechanism that would allow me to easily integrate my own transportation module to the standard cost distribution logic.

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

Another approach is more systematic, but incompatible with the old versions. You could create a cost hierarchy table, a cost posting table and a new account type in the ledger journal - "Costs". But this approach is rather dangerous because:

1. The cost hierarchy will need to be created dynamically. That is, if there is a "transportation costs" branch, then there should be possibility to assign costs to both the transportation in general and the certain purchase. So far, I can’t imagine the right way to implement that.

2. You will need to implement a predefined hierarchy of costs (in order to link each module to the certain place in the hierarchy). Existence of the predefined hierarchy will make the system less flexible, so it will not fit to all customer requirements. Traditionally, documentation is shitty, as it describes checkboxes rather than the economic model, so I am quite sure that the partners will not be able to understand this model, and they will do all sorts of stupid things at each implementation. In other words, if you want to use predefined models - go on. But those models should better be well documented...

3. Of course, the rewritten functionality will be full of bugs in the very beginning (which is inevitable). Considering the quality of the support and difficulty to register bugs in it - the bugs fixing process (I am talking about stupid bugs in the code and not bugs in the design) may become quite lengthy.

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

Personally, I still believe the #2 is possible, but I would NOT recommend you to consider it without keeping in mind the channel of sell/support/partners/documentation. I hope you remember what road is paved with good intentions...

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

… Axapta has its own way. The Dynamics AX team should try building an application framework that would be easy to extend, rather than try to make a product for direct implementation at the clients. Today, we see the opposite: they either extend the kernel (which is useless for real implementations) or make attempts to slap together some end-user functionality, which lacks both extensibility and common sense. For example, Workflow or purchase requisitions. It is much easier to make something from scratch ourselves than to figure out how that miserable crap works.

They’d better extend the fundamental things and fundamental APPLICATION frameworks. I wish that all of them who break into licking the interface or moving everything to .Net were given to the Bing team (which is in such a deep shit that plus-minus 100-200 morons would not make it worse).

More than that – the attempts to copy functionality from competitors without comprehending it and understanding Axapta ended up in the new GL architecture, which is actually copied, as I understand, from the Oracle E-Business Suite.

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

mazzy:

I wish there were storage overheads, i.e. amounts appeared just because of storing goods.

Today the only way to do that is by doing cost adjustment on open receipts, which is not entirely correct, as there may be un-invoiced and un-settled issues.


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

ppson:

1. Implement “Process in Work” module
2. Make the costing module separate from the General Ledger; integrate cost accounting and distribution with purchasing/orders/inventory module/production/product builder/GL journals, so it would be possible to plan and collect costs in WIP/items per cost group at any operation – when purchasing, producing, handling inventory and selling. Cost transactions should be collected from this module, and not from GL.
==============================================================