Openbravo Issue Tracking System - Openbravo ERP |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0004266 | Openbravo ERP | 09. Financial management | public | 2008-07-02 17:29 | 2009-11-19 05:45 |
|
| Reporter | pjuvara | |
| Assigned To | rmorley | |
| Priority | none | Severity | minor | Reproducibility | unable to reproduce |
| Status | acknowledged | Resolution | open | |
| Platform | | OS | 5 | OS Version | |
| Product Version | | |
| Target Version | pi | Fixed in Version | | |
| Merge Request Status | |
| Review Assigned To | |
| OBNetwork customer | |
| Web browser | |
| Modules | Core |
| Support ticket | |
| Regression level | |
| Regression date | |
| Regression introduced in release | |
| Regression introduced by commit | |
| Triggers an Emergency Pack | No |
|
| Summary | 0004266: Eliminating account combination concept |
| Description | The current concept of account combination is causing more usability issues than it provides benefits and it should be removed. |
| Steps To Reproduce | |
| Proposed Solution | |
| Additional Information | |
| Tags | ReleaseCandidate |
| Relationships | | related to | feature request | 0007252 | | new | rmorley | Dimensions of valid combinations | | related to | defect | 0009339 | | closed | eduardo_Argal | Can not select organizations in account combination |
|
| Attached Files | |
|
| 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 | |
|
Notes |
|
|
(0016853)
|
|
xeonn
|
|
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. |
|
|
|
|
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? |
|
|
|
|
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 |
|
|
|
|
|
Reminder sent to: eduardo_Argal, rmorley
Richard, Eduardo,
your opinion on this interesting thread is welcome.
Paolo |
|
|
|
(0017053)
|
|
DavidV
|
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
|
|
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. |
|
|
|
|
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.... |
|