[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 might be 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 state of sales channel/support channel/partners management channel/documentation development practice. 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 life 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's approach ended up in the ill-fated new GL architecture, which is actually copied, as I understand, from the Oracle E-Business Suite.