Community mailing list archives
Re: Accounting Roadmap V9by
2014-10-09 23:46 GMT-04:30 Fabien Pinckaers <firstname.lastname@example.org>:
As explained in the document, my proposition is not the remove hierarchies but:
- to manage hierarchies at the reporting level instead of the account configuration level.
- have reports to become the default browsing methods instead of tree views
Exactly as you didi with partners (with which al of us are suffering yet because extra duplication of unnecesary data, and extra useless developments as partner_merge wizard, and impossible to replicate by default base_contact missing feature without make sort of magic to manage our partners) can you enlight us quickly what will be the technical approach on have an consistent CoA without parent and chill
I think in accounting (pure accouting) a partent account IS a parent account that's it.
In some countries you have even a close relation between the code and the parent child relation, you actual datamodel achieve such need __perfect__.
Why do you need remove it from the account itself and move to reports?
If you are so sure of this is the correct path... without develop it yet, can you explain how will be the new approach?
As I understand from SQL pov you will change:
Just making the most "basic example".
As you know integer is more efficient than char on SQL.
Can you enlight me (us) what will be your approach "conceptually" in terms of data model?
Please dont try to convince us that the "usability " needs change the data model, with actual data model you can achieve perfect views and improve a lot the usabilitiy.
Today: 1 method compute all the balance in the CoA.