[Advacs-discuss] Re: Advacs accounting system

[Oliver Elphick]

On Mon, 2004-08-09 at 15:18, Helmut Wollmersdorfer wrote:
> 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/ ?

Yes, I suppose that makes most sense.  I'll need to create an en
directory and move the existing stuff down; then a new xx directory can
be created for each new language.

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

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.

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

Yes.  I treat accruals as mere notes, which are not incorporated into
the ledgers until the period end program is run.  The accounts can be
used continually; there is no need to stop entering data for period
ends, because each period's data is flagged with the period id.  Very
late data, which comes after its proper period is closed, is put in the
next open period, but retains its own proper date.  Reports distinguish
the desired data by its period.

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

Yes to both of those.

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

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.

> 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 centre?

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.

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

That's a great idea!  There will be some problems though in
accommodating languages which are much more verbose than English and
those which scan right-to-left instead of left-to-right.

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

This is one area where everyone can scratch his own itch.

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

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.

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

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.

I think that there will have to be an indirect link to tax modules; I
can conceive, for instance, that some country might choose to impose a
new tax separate from VAT, while continuing to collect VAT.  Therefore
we will allow for three different taxes on any GL account and separately
define which tax module and which tax rate are meant by the tax codes in
the account definition.

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

I do feel it needs its own module; and doing it like that makes the
whole thing more flexible for use in countries which don't have VAT.

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

The English term is "open item".  I forgot to list this as an attribute
of the Sales and Purchase Ledger modules.  Every payment received/made
is matched against outstanding items.  Items which are fully paid are
cleared; if there is not an exact match, either the whole payment is
recorded and no items matched with it, or else those items are matched
and cleared that can be, and the remaining balance of the payment is
left open.

Customer statements generally list all open items; however, some
businesses merely list the opening balance and any new items.

-- 
Oliver Elphick                                          olly@lfix.co.uk
Isle of Wight                              http://www.lfix.co.uk/oliver
GPG: 1024D/A54310EA  92C8 39E7 280E 3631 3F0E  1EC0 5664 7A2F A543 10EA
                 ========================================
     "Be still before the LORD and wait patiently for him;
      do not fret when men succeed in their ways, when they
      carry out their wicked schemes." 
                            Psalms 37:7