Anonymous | Login
Project:
RSS
  
News | My View | View Issues | Roadmap | Summary

View Issue DetailsJump to Notes ] Issue History ] Print ]
ID
0004266
TypeCategorySeverityReproducibilityDate SubmittedLast Update
feature request[Openbravo ERP] 09. Financial managementminorunable to reproduce2008-07-02 17:292009-11-19 05:45
ReporterpjuvaraView Statuspublic 
Assigned Tormorley 
PrioritynoneResolutionopenFixed in Version
StatusacknowledgedFix in branchFixed in SCM revision
ProjectionnoneETAnoneTarget Versionpi
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Review Assigned To
Web browser
ModulesCore
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary

0004266: Eliminating account combination concept

DescriptionThe current concept of account combination is causing more usability issues than it provides benefits and it should be removed.
TagsReleaseCandidate
Attached Files

- Relationships Relation Graph ] Dependency Graph ]
related to feature request 0007252 newrmorley Dimensions of valid combinations 
related to defect 0009339 closededuardo_Argal Can not select organizations in account combination 

-  Notes
(0016853)
xeonn (reporter)
2009-06-02 11:58

ACCOUNT COMBINATION should NOT be removed.

In multi organization scenario, account combination make sense by assigning which organization are allowed to use which account. The complete chart of accounts will not apply to some organization within the group due to the difference in nature of business.

Example:-
Holding Company A. (Nature of biz: Investment)
Subsidiary A1 (Nature of biz: Manufacturing)
Subsidiary A2 (Nature of biz: Trading)

Subsidiary A1 use 'Raw Material Closing Stock' account whereby Subsidiary A2 does not because it just do trading.

If Account Combination is removed, then Subsidiary A2 will have a lot of annoying accounts popping up everywhere.

Removing GL Item make more sense.
(0017033)
pjuvara (reporter)
2009-06-05 16:23

xeonn: thanks for you opinion on the matter.

I think that your point is very relevant in 2.35 and 2.40 but it is already addressed in 2.50 in a different manner.

In 2.35 and 2.40, the accounting schema is defined a client level while in 2.50 it has moved down to organization level (for organizations of type legal entity or business unit).

Your scenario, which is related to account security (i.e. configuring the system so that an organization can only see accounts that are pertinent to its line of business) can be achieved by defining 3 accounting schemas and configuring the system as:
Holding company A of type legal entity - with the complete set of accounts
Subsidiary A1 of type legal entity or business unit (depending on whether it is officially registered as a separate company) - with the relevant sub set of accounts
Subsidiary A2 of type legal entity or business unit with the relevant sub set of accounts.

Does this make sense? Does it address your need?
(0017036)
pjuvara (reporter)
2009-06-05 16:31

The idea of the account combination is to provide a valid set of dimensions. When you create an accounting entry using this combination, if the originating document does not have a value for that dimension, the value coming from the code combination is used instead and stored in the Fact_acct table.

Of the various dimensions, we have observed that:
1) the organization is a mandatory attribute on all table so the organization dimension is always taken from the originating document and not the accounting combination, so having the organization dimension in the account combination does not serve any purpose if you accept my explanation above about security.
2) For the other dimensions (business partner, project, etc.), whenever we prompt for an account combination, they either do not make functional sense or they are already available in the document.

The only dimension that makes sense is the natural account, but it does not make sense to have a "combination" of one element.

Because of this reason, we believe that the account combination does not provide a lot of value to users and in facts creates a lot of confusion. This explains why we are considering removing it.

By contrast I think that GL Item provides some value as it is some sort of "alias" for the natural account and it helps in data entry.

It is interesting to see that you disagree and since removing the account combination concept would be a big change I want to make sure that your argument is fully understood.

Thanks,

Paolo
(0017037)
pjuvara (reporter)
2009-06-05 16:33

Reminder sent to: eduardo_Argal, rmorley

Richard, Eduardo,

your opinion on this interesting thread is welcome.

Paolo
(0017053)
DavidV (reporter)
2009-06-05 21:06
edited on: 2009-06-05 21:08

Practically:

EITHER
if I have lots of accounts, many dimensions and many values, then I have THE more account combinations. It is not possible just to scroll down the account combinations. I have to select from all the popus some value so as I can find the right account combination in the Account selector.

Notice that the popups in Account selector contain the full lists of values (full chart of accounts, all partners, all products...). Then I finally find the right combination and I select it. (one useless step comparing selection from all the dimensions directly).

If I do not find the right accounting combination, I muse create it (second overabundant step) and then select it.

OR
When I do not have so big business, I just need to quickly do accounts, and not to setup an abstraction layer (endlessly for my various transactions)... but I must create annoying account combinations insted of selecting immediately the values...

Your
voice of populi

:)

(0017054)
xeonn (reporter)
2009-06-06 06:36

David's argument indeed have its merit. Its the downside of account combination. But a selecting accounts combination in product accounting tab or anywhere else are 1 time job of setting up.

For small setup consisting a single user, yes, account combination is pain. Don't forget, this is an ERP system. Suitable for big corporation with holding's and subsidiary.

I am looking from the view of accounting (not really focusing on security), where Consolidated account is of importance. The consolidation process is made easy by having 1 Account tree at client level and forcing organization to use combinations.

The accounts consolidation is the biggest selling point to accountants and company owner. This is one issue where small system do not handle due to different Chart of Accounts used by subsidiaries. Forcing accountants to consolidate manually using excel.

For GL Item, accounts *Is* GL. Some system call accounts as GL, some call it GL and never use the terms account. Having alias is unnecessary. But I've made peace with the 2.40 flow.
(0021999)
vanphuc (reporter)
2009-11-19 05:45

I thinks that account combination is nice feature of Openbravo. But, it still make me confuse so much. How to select product, project,... if i is not done set up account combination. Consequently, we cannot select these dimension in this step one time because we didn't set up accounting category for product, business partner... som, it cannot appear here at this time. Hopefully, i am right? Furthermore, when you run your trial balance report, system just concentrate on your account elements? so, what is the real meaning of account combination values?
Another thing, system create account combination description automatically. It is used to break down my account into more detail according to specific subsidize company or for specific activities... normally, it cannot keep the same description for all kinds of account combination which have the same account element....

- Issue History
Date Modified Username Field Change
2008-07-02 17:29 pjuvara New Issue
2008-07-02 17:29 pjuvara Assigned To => eduardo_Argal
2008-07-02 17:29 pjuvara sf_bug_id 0 => 2008909
2008-07-02 17:29 pjuvara Tag Attached: ReleaseCandidate
2008-07-02 17:29 pjuvara Status new => scheduled
2008-07-02 17:29 pjuvara fix_in_branch => trunk
2008-11-03 13:43 pjuvara Target Version 2.50 => 2.60
2008-11-21 16:45 pjuvara Status scheduled => acknowledged
2008-11-21 17:05 pjuvara Target Version 2.60 => trunk
2008-12-17 11:09 pjuvara Assigned To eduardo_Argal => rmorley
2009-02-02 06:43 pjuvara Relationship added related to 0007252
2009-06-02 11:58 xeonn Note Added: 0016853
2009-06-05 00:12 DavidV Issue Monitored: DavidV
2009-06-05 15:52 pjuvara Relationship added related to 0009339
2009-06-05 16:23 pjuvara Note Added: 0017033
2009-06-05 16:31 pjuvara Note Added: 0017036
2009-06-05 16:33 pjuvara Issue Monitored: eduardo_Argal
2009-06-05 16:33 pjuvara Note Added: 0017037
2009-06-05 21:06 DavidV Note Added: 0017053
2009-06-05 21:08 DavidV Note Edited: 0017053
2009-06-06 06:36 xeonn Note Added: 0017054
2009-06-30 19:54 pjuvara Reproducibility have not tried => N/A
2009-06-30 19:54 pjuvara fix_in_branch pi =>
2009-06-30 19:54 pjuvara Reproducibility N/A => always
2009-06-30 19:55 pjuvara Reproducibility always => sometimes
2009-06-30 19:56 pjuvara Reproducibility sometimes => random
2009-06-30 19:56 pjuvara Reproducibility random => have not tried
2009-06-30 19:57 pjuvara Reproducibility have not tried => unable to reproduce
2009-11-19 05:45 vanphuc Note Added: 0021999


Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker