[Advacs-discuss] Re: Advacs accounting system

[Helmut Wollmersdorfer]

Oliver Elphick schrieb:

> I've put up some stuff into Docs showing my ideas about where this is
> going to go. 

Some comments on it:

docs/

How do you want to include translated versions?
Like this: docs/de/ ?

docs/description.txt

| At year-end, GL accounts should be balanced off and
| transferred to Profit and Loss or have their balances carried down.

Don't know, if this method is the same as usual here in DE and AT.
 From theory (technical solutions can vary) all accounts are zero at the 
beginning of a fiscal period, and the accounts start with an "opening 
balance transaction" (translated word by word DE->EN) against an 
"opening balance account".
E.g. the balance sheet per 2003-12-31 says "Bank account .... EUR 
200.11", then you do on 2004-01-01

debt: Bank cred: opening balance account amount: EUR 200.11

After all "opening balance transactions" the "opening balance account" 
must be zero.

Similar method is used at the end of the fiscal period. First every 
earnings/expenditures balanced off against an "Profit & Loss account", 
and then every remaining non-zero (GL-)accounts against "closing balance 
account".

In practice accruals, depreciation, inventory etc. need some time (can 
be months) to have correct values in the closing balance. Daily 
accounting can not wait for this. Thus the balances of the accounts are 
forwarded to the new period on the date of period switch. All this 
transactions take place on a logical date, not the real date.

| Account codes should be purely arbitrary.  The organisation of
| accounts should depend on separate attributes of the account
| definitions, not on their codes

ACK on this, if you mean the same:
I assume, that "account code" means the unique identifier of an account,
e.g.
   code: 2000
   short-name: Bank
   full-name: Royal Bank Acc.No. 123 456 789

Alphanumeric must be allowed for account code.

Separate attributes:
- balance sheet code
   This specifies under which position of the balance sheet the
   account is accumulated or displayed.
- report code(s)
   Similar functionality as balance sheet code.
- aggregate to account
   To collect some accounts into one summary account, e.g. all vendors.

What's about "sub accounts"? In the building & construction branch 
invoicing and payment can be very complex, which needs separation of 
projects within one personal account.

| The system should be fully integrated.  Cashbook, sales and purchase
| invoicing, asset depreciation, employee expenses, tax deductions and
| direct journal entries should all interact; the journal should be able
| to address any ledger.

ACK. But interfaces should exist, e.g. if someone wants to use an other 
billing system with special features.

| The system must handle international use, first in terms of its
| interface, which must be internationalised,

Best is, switching online between different languages (or locales). 
Imagine the controller of an japanese multinational sitting with an 
hungarian accountant on front of a screen.

| The system should accommodate different user interfaces.

- something curses like will be sufficient for full time accountants
- web-frontend for greatest flexibility
- batch interface for testing and mass import
- maybe (less priority) GUIs

| Cashbook

A typical example where EN provides better words than DE;-)
In DE we need two terms for this: "bank book" and "cash book", which 
provide nearly the same logic. Or is EN: Cashbook a cash book in the 
narrow sense?

| The system will provide tax modules for different countries.

Don't know, if modules are necessary.

The usual logic is, that a tax-table (tax-code, tax-percentage, 
short-name, full-name, related tax-account) can be edited.

Earning and expenses accounts have a field with the tax-code in it.
An invoice transaction inherits this tax-code from the related account, 
applies the percentage, calculates the tax-amount, and creates a tax 
(sub-)transaction. Before confirmation of the transaction the user can 
overwrite the tax-code (or percentage) for re-calculation. This is 
sufficient enough for the usual VAT-rules and other taxes, which are 
related to turnover transactions.

But VAT calculation is getting more complex nowadays, especially in some 
branches like building & construction.

/docs/glossary.txt

I'am missing the EN equivalent of a German term:
"Offener Posten", word by word translated to "open item".
"open payments" would better express the meaning.
Usually this is implemented like this, e.g.
on an A/R invoice transaction the "payment conditions" are deduced from 
a system wide "payment conditions table", customer specific or order 
specific. E.g. this can be "payment within 14 days get 3% cash discount, 
regular payment within 30 days, payment in arrears apply to 12% interest 
for delay".
At invoice transaction an "open item" record is created. These records 
are used for automatic reminders and later on for more inpolite letters.

At payment transaction the GL-transaction is associated to the "open 
item", and the "open item" is balanced to zero, or a balance is 
remaining, or differences are out-balanced to appropiate accounts.

Helmut Wollmersdorfer