Community mailing list archives
Re: Chart of Account structure & amp; Financial year closing in Odoo 9by
Nhomar,In accounting jargon usually I hear them called the terms Header and Detail Account usually.
On Wed, Jan 27, 2016 at 3:42 PM, Graeme Gellatly <email@example.com> wrote:
Without a chart of accounts capability, there is no point continuing with Odoo. It really is nothing to do with a reporting engine. It is a fundamental accounting concept. Glad I caught this thread before starting migration work.They are entirely different things. A chart of accounts has no concept of debits or credits, or any temporal nature really at all other than its own evolution over time, but does have groups of Assets, Liabilities etc and logical groups of accounts within them, even if just essentially abstract constructs. It is the user (or users government/accounting institution) that assigns meaning to them. (As per Nhomars link)Chart of Accounts - usually hierarchical even if just into Assets, Liabilities etc.Hi,Trial Balance - always flat.
Saying trial balance and chart of accounts are the same thing is a rather scary statement. Saying your accountants don't understand the difference even scarier. I think the problem here may be English understanding. There is definitely confusion that a chart of accounts and trial balance are the same thing.Trial Balance does not equal Chart of Accounts.A trial balance is an accounting report, a very simple one, it only includes postable ledger accounts with dr or cr balances at a given date.
A chart of accounts is not an accounting report, it is the (or a) map of the accounts structure. Some reports may/must use this structure, e.g. Balance Sheet, Profit and Loss, others may not, e.g. Cashflow Report, but certainly accountants do unless you have only a few accounts, say 100. When deciding how an entry will be classified, and without a map to guide them it would be chaos, clerks would just pick the easiest/nearest thing. Most accounts people I know print a copy of the chart and keep it close by to assist classifying entries as not everything is obvious. The chart guides them. I have never seen a trial balance stuck to a wall as what good is a long list of accounts.
A trial balance needs no concept of Assets, Liabilities etc (in theory, although often accounts displayed in order), but must be temporal and have debits and credits (As per Fabiens link).On Wed, Jan 27, 2016 at 2:22 PM, Nhomar Hernández <firstname.lastname@example.org> wrote: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 <email@example.com>: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_balanceOk, 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-cuentasI 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 accountingNo 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......Problems:- 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/editionsI 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"
http://accounting-simplified.com/financial/types-of-accounting.htmlYour 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 :-) jejejejejeReally 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.--FabienGood Luck (For you and for us ;-)) and Let's wait and see to know what the new days brings with it :-)