[Advacs-discuss] Re: Advacs accounting system

[Helmut Wollmersdorfer]

Oliver Elphick schrieb:
> On Mon, 2004-08-09 at 15:18, Helmut Wollmersdorfer wrote:

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

> Yes, I suppose that makes most sense.  I'll need to create an en
> directory and move the existing stuff down; 

As EN is the primary language this is not necessary. At an other GPLed 
package - DRBD - we have /documentation with all the original stuff in 
it, and subdirectories /documentation/ja and ./pt_BR. But maybe 
installation is easier with an explicit ./EN/.

>>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".
> 
> 
> What I am doing (and have done before in a different system) amounts to
> the same thing, but is more directly related to the way manual books are
> done.  

Here in DE & AT the way with use of balance accounts is educated even 
for the manual method. Standard account shemes list the balance accounts.

> Rather than transferring out to a closing balance account, an
> automatic transaction is run which for each account incorporates any
> accruals at the period end and writes ledger entries for them,
> calculates the account balance, and finally either transfers the balance
> to P&L a/c or carries it down on the same account (debit year 1, credit
> year 2 or vice versa).  

This is how most computerized ledgers work. It's mostly called DE:"Saldo 
Übertrag", with IT,DE:Saldo equivalent to EN:balance, and 
DE:Übertrag=EN:transfer.

> This transaction is different from all others in
> that it can be wiped out and redone, if there are any late journals or
> extra accruals to take account of.

I know your variant, and another one, where incremental balance 
transfers are possible, and they are recorded as extra journal entries.

> Doing it that way has two benefits: there does not need to be a pair of
> extra accounts which do not represent anything real and the books are
> fully in accordance with the practices of manual bookkeeping (which is
> one of my design goals).  One drawback is that a special program is
> needed to do the yearend transfers, whereas the version you describe
> could be done by a standard journal program.

Hmm ... you can implement your method by a module, which generates 
standard journal transactions - I think.

> Yes, I define two extra tables: subhead and subhead_line which describe 
> possible sections and lines in the balance sheet and P&L a/c.  Each GL
> account belongs to 1 or 2 subhead_line entries (1 for debit balances and
> 1 for credit balances).  subhead_line entries define a subtotal level.

Hmm ... local AT-laws define very detailled, how a balance sheet must be 
structured at minimum. This needs more than two levels. It looks 
something like this:
1. foo
1.1 foo-1
1.2 foo-2
1.2.a foo-2-a
1.2.a.1 ....

>>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.

> project?
= cost object (usally)

> cost centre?

That's one possible way to solve it.

> Such fields can easily be added at the planning stage.  AT the moment
> I'm designing the GL SQL database structure, which I'll put up in a few
> days (or maybe bits of it sooner).   Everything is very easy to change
> until we start writing code.

ACK.

>>| 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.

> Yes.  Those interfaces will need defining.

The most important one is the batch transaction.

> That's a great idea!  There will be some problems though in
> accommodating languages which are much more verbose than English

Is there any language not more verbose than EN? ;-)

> and
> those which scan right-to-left instead of left-to-right.

I think, first version should be UTF-8, but not all features of UNICODE 
should be supported. Thus left-to-right -> later, non-latin -> later.

> Generally cashbook means the record of a bank account.  Actual cash
> money is supposed to be paid straight into the bank without deductions. 
> Then cash is withdrawn to top up the Petty Cash Account, from which
> small payments are made (like buying coffee and sugar for refreshments).
> The phrase "cash book" could mean either cashbook as described or a
> small notebook in which petty cash transactions are rcorded.  It would
> depend on the context.

Hmm ... different culture, different laws. DE:Kassabuch (~EN:cashbook) 
means real money (coins, banknotes, checks ...) which need an extra 
account and precise documentation by law. It must be daily up to date in 
a separate book/ledger or in the GL. But from the viewpoint of GL it 
casn be treated the same way as a "bankbook", just name the account 
Kassa-1, Petty, or as you like, and give it the attribute "this is a 
cash account", which special support of payment transactions.

> There's an awful lot of complexity in VAT law; most of it can be left to
> the people who attach tax codes to accounts, but we also need to track
> total inputs and outputs, restrict VAT input claims where there are
> exempt outputs and produce reports suitable for completing VAT returns.
> Inter-EU sales to registered traders must be separately recorded, and so
> on.  I'm sure there are national variations, even inside the EU.

All this is true. In AT we have VAT percentages of 0%, 10%, 12%, 16% and 
20%, and we need a lot of tax codes to document the reasons (= the 
paragraph of the rule in the VAT-law), and for each tax code different 
accounts should exist (for practical reasons).


Helmut Wollmersdorfer