Community mailing list archives
Re: Chart of Account structure & amp; Financial year closing in Odoo 9by
Hi Fabien.Thanks for clarify the way I think I must do things (partially what you said is what I will do) but conceptually you are wrong and it does not matter how many times you want to compare to softwares We already thought was wrong one of the best things Odoo had was the hierarchy. Let me answer in line in order to point to the especific concepts.
2016-01-26 17:17 GMT-06:00 Fabien Pinckaers <firstname.lastname@example.org>:
1.- It was OK on community since Version 4.x2.- You argument and remove it unilaterally for V9.0 making the highest quantity of extrange arguments about a basic accounting feature.3.- Now you "Release" as an Enterprise feature, without a correct supported data model (which you damaged actually) removing the parent left parent right.4.- Now IF no pay no Feature....Ok, I will explain once again :)We removed the account hierarchy in version 9 because, from an accounting point of view, a trial balance should be flat and have only one debit or credit per account. (and not both) Have a look at some references from wikipedia or other accounting software in Google Images if you are not convinced:- Trial Balance Examples: http://bit.ly/1K9eUhI- Wikipedia: https://en.wikipedia.org/wiki/Trial_balance
Ok, this is partially wrong my dear friend.
IFRS (<sarcasm>I think they know a little more about accounting than wikipedia or Xero</sarcasm>) propose a Hierarchly structure (Software Term) or a Tree Structure (Accountant Term) where the View Account (Odoo Term) is known in Spanish (I do not know forsure the term on English) is "Cuenta de Mayor" and the last level (account.child_ids == False in odoo term, and Account without childrens in Accountant terms). is called "Detail account".
As you see it is the same but just a matter of "Terms".
The codification of accounts MUST comply a parent-child structure which work PERFECT and SECURE on v8.0.
The source of my statement: http://www.gaap-ifrs.eu/en/chart-of-accounts-ifrs-3-digit/
The Colombian CoA (just as a real example): http://puc.com.co/normatividad/decreto-2650-1993/catalogo-de-cuentas
I can share more but it is not the point, you rewrite completely a feature which only need a change of label to use a better accounting term, and almost all the world is moving to IFRS :-s.
Let me continue bellow to finish my PoV.
It's important for Odoo to produce reports the way an accountant expect. And a trial balance / chart of account is NOT a hierarchy.In addition to that, the parent hierarchy implied a lot of problems / difficulties for accountants:- complexity to import a chart of account- error prone at account configuration, leading to wrong legal statements- bad usability with strange tricks, like a 'View' account that is a concept which does not exist in accounting
No dude, this structure represented "consistency" for accountants and complexity to programers to make correclty some stuffs, but the benefits:
- Parent child consistency (you only need to match the codes, and the balance will be always right).
- Automatic (almost) consistency on your CoA balance.
- Always your tree will be the "Father" of all the rest of reports (exactly as the real world works)-.
- In only a quick view of the tree you see what you need to re.map in terms of codes and terms.
- For sure, more difficul to mantain technically because you can not make errors mixing things that bring inconsistencies. But this problems brings the benefit of better consistency in terms of data.
- Better SQL Knowledge is necesary to manage efficiency (but again your data is consistent from the root).
All softwares that took the actual approach on my understanding and in our experience simply pass for the next map.
- Less difficult to start, HUGE amount of time and effort in mantain, because the code/data consistency that the Data Structure give will be re-programed al report level, and not at data level, inserting A LOT of use cases where will represent problems.
So, we were happy to remove it to avoid these issues and delegate the hierarchy computation to the report engine.
I will follow you as usual, but you will remember me in 2 years or less, when you have 2 years data with an inconsistency in reports which is inexplicable, and then you will need to develop features like the "Partner Meerge (because of the mess)" and/or replicate the parent-child consistency at label level.....
It always happen with change of this size, just supported by 2 programmers in a room, If you inform such change and ask for help I am sure we should propose better things for such "problems" (remember I oposite to this change since the plan itself).
But again dude, it is a matter of PoV, and not always teh True is only 1, from My PoV it was a bad move (and I will decline my PoV in a future if I am wrong), but then, you make us expend the extra effort if I am right.
I personally prefer "Problems at the begining because data-structure solid constraints", than "problems at the end because user mess up everything"..... You think for SaaS -quick start we solve later- I think for long term relations with my customers -no solve stupid problems in 2 years-.... see? PoV problem, that's it.
In terms of reporting (the only usefulness of hierarchies), reports can still be in a tree structure, as we moved the hierarchy structure at the report engine level. This is more powerful as, instead of having one hierarchy only, we can have as much as we want: P&L, Balance Sheet, Trial Balance, Cashflow Statement, ... all have their own hierarchy. All of that out-of-the-box, without configuration requirements for the accountant.I pay all my enterprises (you know) I am not saying you closed a feature... but now , What will we do with aaaaallll the AGPL code that is based on such hierarchy?The report engine changed in v9. For nearly all countries, it will hugely simplify localizations (probably divide code by 4). The drawback is that these l10n_* modules should be redeveloped on the new accounting structure, instead of trying to forward port old v8 reports.
About l10n_* I saw them and technically you are right we will need to start from scratch in order to have a lot of features already working, and YES you are right it will be less expensive in terms of effort than in the old versions.
But rememeber, before we didn't think in terms of accounting consistency, now i will review and give my feedback especifically I just hope it is taken into account.
But the CoA is not one of them :-s
should not you simply put free the feature in an extra module?.....We rewrote the report engine in version 9 from scratch. It's a huge effort and we made all accounting reports in Odoo Enterprise. You may like it or not, but we need to put some features in Odoo Enterprise to create value for it. I think we do a good trade-off: some features go to Odoo Community, others to Odoo Enterprise. The list is here and will probably not change that much, and accounting reports are part of Odoo Enterprise: https://www.odoo.com/editions
I am ok with that, but honestly, NO report of odoo base has even 1 cent of value for our customer, Until today, just the work of community and our own job has given to us the correct value for such feature... Odoo do not considere DATA INCONSISTENCY at accounting report level as an issue, it is always User's Fault..... We think the contrary but again "PoV", I am sure if this time that feature is an enterprise feature may be it will be better (I pray to God it will be in that manner) because if not I see a black future for us....BTW, I think at the end we will need to mke some extensions (and that is fine for us) with OCA and/or by ourself as usual.
An technically speaking, and conceptually speaking, what you did with a new data model, we had it since 2 versions ago on odoo-ifrs with actual data model .....
Which Concept? group accounts no matter its concept at report level. Check it out.
(yes may be not technically clean and not "fancy" bot conceptually correct without change the actual data-model.
I do not understand, Thanks for rectify (I mean it seriously), but, NO thanks for making it too late and in the incorrect version, and with the incorrect approach.Actually, I think the trial balance hierarchy is NOT useful for accountants, and certainly not a requirement of an accounting software. Accountants used to read P&L and BS as a hierarchy, but not trial balances / chart of accounts. However, we did it to help you do the transition: even if the v8 behavior was not good, our users are already used to it.
That's not true at all.....
Managers see P&L and BS, "accountants" audit, and the father of all accountability is the General Ledger, but again, I respect your point, but from my PoV it is not true at all.
Read about the "Type of accountings"
Your Statement is PERFECT and ABSOLUTLY TRUE from a "Management Accounting PoV" BUT the daily operation, the one that generate the real data is the "Financial Accounting", and there, is where you MUST be solid like a rock, any error there will make IMPOSSIBLE the rest of accounting types.
But again, cool that Xero give you good ideas.... on this topic I prefer Odoo 8.0 :-) jejejejeje
Really better I think.
Again I will trust and I will try, but I see a lot of unecesary work if we have a correct data model.
As a project manager point of view, I think it's better to manage the change with your customer and train them on the new way of working with accounting reports (the CoA is not the main report anymore, now they have dynamic P&L, BS...) However, if you really want to stick to the v8 way of working, you can do it with the provided patch.
Absolutly understood, no other option here.
Good Luck (For you and for us ;-)) and Let's wait and see to know what the new days brings with it :-)