- Local time
- Today, 16:47
- Joined
- Sep 12, 2006
- Messages
- 15,958
@HASAN-1993
You asked previous questions about this recursive accounting tree.
Take it from me, it's an awful idea. A NL/GL accounting structure needs to be carefully planned in a hierarchical manner. You ned to structure the codes to ensure that a child's account number IS the same as the parent but with an extension. Define the account codes as strings.
Then you have a base account of 1
1
if you need to analyse account 1 in more details then have account 11 and 12. But not account 21. 21 is a child of account 2, and not of account 1. If you need to analyse accounts 11 and 12 in more detail then as follows.
11 - if you need a more detailed analysis of account 11 then have
111
112
113
114
115
12 - if you need a more detailed analysis of account 12 then have
121
122
123
124
So don't think of these as numbers. Think of logical breaks in the structure, to give a more detailed analysis, so it works more like this, where the account numbers are strings, so that everything is left justified.
1
1-1 - if you need a more detailed analysis of account 11 then have
1-1-01
1-1-02
1-1-13
1-1-14
1-1-25
1-2 - if you need a more detailed analysis of account 12 then have
1-2-01
1-2-02
1-2-13
1-2-14
1-2-25
so all of these accounts are children of account 1. (You will also have a systematic set of accounts which are children of account 2. )
accounts 1-1-01 to 1-1-25 are children of account 1-1
accounts 1-2-01 to 1-2-25 are children of account 1-2
there is no recursion needed, and it's very easy to manage,
Note that this way, the accounts with 13 as the code at level 3 (coloured blue above all represent a similar "heading", and you can easily get an overall total for your organisation by summing all the transactions with 13 as the code in section 3.
so you end up having a formal hierarchy, where changes of the code at each level of the structure indicate a specific entity within your organisation. No recursion, just a simple filter/sort process.
You asked previous questions about this recursive accounting tree.
Take it from me, it's an awful idea. A NL/GL accounting structure needs to be carefully planned in a hierarchical manner. You ned to structure the codes to ensure that a child's account number IS the same as the parent but with an extension. Define the account codes as strings.
Then you have a base account of 1
1
if you need to analyse account 1 in more details then have account 11 and 12. But not account 21. 21 is a child of account 2, and not of account 1. If you need to analyse accounts 11 and 12 in more detail then as follows.
11 - if you need a more detailed analysis of account 11 then have
111
112
113
114
115
12 - if you need a more detailed analysis of account 12 then have
121
122
123
124
So don't think of these as numbers. Think of logical breaks in the structure, to give a more detailed analysis, so it works more like this, where the account numbers are strings, so that everything is left justified.
1
1-1 - if you need a more detailed analysis of account 11 then have
1-1-01
1-1-02
1-1-13
1-1-14
1-1-25
1-2 - if you need a more detailed analysis of account 12 then have
1-2-01
1-2-02
1-2-13
1-2-14
1-2-25
so all of these accounts are children of account 1. (You will also have a systematic set of accounts which are children of account 2. )
accounts 1-1-01 to 1-1-25 are children of account 1-1
accounts 1-2-01 to 1-2-25 are children of account 1-2
there is no recursion needed, and it's very easy to manage,
Note that this way, the accounts with 13 as the code at level 3 (coloured blue above all represent a similar "heading", and you can easily get an overall total for your organisation by summing all the transactions with 13 as the code in section 3.
so you end up having a formal hierarchy, where changes of the code at each level of the structure indicate a specific entity within your organisation. No recursion, just a simple filter/sort process.