[Advacs-discuss] Re: Advacs accounting system

[Oliver Elphick]

On Mon, 2004-08-09 at 17:53, Helmut Wollmersdorfer wrote:
> 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/.

I think it's best to keep the structure consistent

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

If there are differences in basic practice, I will just have to stick
with the way I was taught.  
...

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

We have some prescribed forms nowadays (a rather un-English way of doing
things) so we will have to provide the prescribed formats for different
countries.  SQL-Ledger does something similar.

> >>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
> 
> 
> _______________________________________________
> Advacs-discuss mailing list
> Advacs-discuss@lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/advacs-discuss
-- 
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