Topic: Let the Classes & Types Accounts ID's be Characters

Hello,

I wish from your side, to expand the possibility of using " Characters " when defining the ID numbers in Classes & Types accounts tables.

This will help efficiently in developing reports by grouping the descendent accounts under any group type or class using simple SQL statements.

In this case , using RepGen 2.2 will be very simple to explore & report any grouping of accounts transactions & data.


I am sure that with such simple modification
Note when using character types in :

chart_class (cid)   
I suggest : cid varchar(3)   

chart_types (id ; class_id)   
I suggest : id varchar(8)   & class_id varchar(3)   

chart_master (account_code ; account_type)         
I suggest : account_code varchar(15) & account_type varchar(8)

So you may build an interrelated hierarchical tree for your chart of account who can be accessed at any level you want from a simple SQL Statement using RepGen2.2.

I am sure it will be a wonderfull solution for reporting.

ex. :

1        Class
11       Type
111     Sub-Type
11111  Account



Regards,


Khaled

Re: Let the Classes & Types Accounts ID's be Characters

But khaled, you will still have to make the joins to the other tables and a normal process is to use an sql statements like the one in function get_gl_accounts_all($balance=-1) placed in /gl/includes/db/gl_db_accounts.inc.
Those accounts will be sorted in class / type / subtype / account order and making the joins by an alfa string instead of the numeric value seems not to be easier. So why do that. The numeric variant is more flexible when creating subtypes.

Also I see no idea in extending the account code to 15 instead of 11. It is redundant with all these digits/chars in an account code. Most countries only use 4-5.

But let us hear opinions from other users out there.

/Joe

Re: Let the Classes & Types Accounts ID's be Characters

If you check "Peachtree Accounting " software, you will find that they use 15 Char for the accounts length. Assuming that, you may use the 1st 9-11 for the account & the last 4 for referring to Company Branches/Departments :

ex : 600123-xx-yy   where --> xx : Branch    ;  yy : Department

For this reason I prefer to use characters for the account nb, although the numeric values are more practical
--------------------------------------------------------
RE : Account Types & being Characters :
Generally, the Accountants prefer that the Initials of an active account nb are the same as their Account Types Parent group. This will help them to easily remember and classify. This is why also I prefer it to be Characters and not numeric.

ex:   1 Assets   ( Class)
         
           10 Current Assets  (Type)
                   1060 Checking Account (Account)
                   1065 Petty Cash  (Account)
           11 Non Fixed Assets  (Type)
           12 Inventory Assets  (Type)
           13 Capital Assets (Type)

--------------------------------------------------------
RE : Account Classes :
Being numeric does not infect any concept.
--------------------------------------------------------

Anyhow I don't know what it affects FA if we do changes like I proposed. But for myself I did the modifications and I didn't find problems.

/Khaled

Re: Let the Classes & Types Accounts ID's be Characters

Hello again,
We are using Dimension 1 and 2 for the same thing for the last digits. I know that this was quite common to do before we got the SQL databases. But having the dimensions outside the account string make them much more flexible. That is the reason for not having more than 11 characters in the accounts.

/Joe

Re: Let the Classes & Types Accounts ID's be Characters

I support the idea to have character IDs. This way, we can distinguish between 0 and 00, which are used in some countries as well (I am from Slovenia, and we have fixed assets in class / type 0 and 00).

Maybe there can still be an option to use IDs as "numeric" (so, strings are converted to their values first...), if this functionality is not needed (and, would help anyhow). Or, to have an extra field (and, use one or another) in the same table, or 2 different tables...