[Advacs-discuss] Latest CVS updates

Helmut Wollmersdorfer helmut@wollmersdorfer.at
Mon, 06 Sep 2004 01:21:51 +0200


Oliver Elphick wrote:

> Then take a look at the schema and consider what might be missing.

Two things at first view:

1) /sql/CB/bank.sql

| compounded    CHAR(1)    CONSTRAINT CT_VALID_COMPOUNDED_CODE
|                              CHECK (compounded IN ('D','M','Y')),

As I understand, this means Daily, Monthly, Yearly.
In Austria it usual by banks to compound Monthly, Quarterly, 
Half-yearly, or Yearly.

Besides, for calculation of interests by banks the _each_ month has 30 
days. Silly, but tradition.

And from reporting I know the following logical periods:
- day
- week
- month
- quarter (3 months)
- trimester (4 months), fits better the saisonal flow in some branches
- half year
- year

2) payment terms

This seems to be different in different nations or cultures.

Here the so called "Skonto" is usual. This is a cash discount, e.g.
typical terms read
      14 days 3% Skonto
      30 days full payment
      delayed payment 12% interest, and EUR 5,- for reminders costs

 From the above the following transactions can result on e.g. an invoice 
of 100,- + 20% VAT, balance/open_item on customer account is 120,-:

1) Skonto applies:
bank/customer   116.40 (= 120,- x (100% - 3%))
skonto/customer   3.00
VAT/customer      0.60

2) No Skonto:
bank/customer   120.00

3) delayed payment:
- generate an invoice about interest, reminder costs, and VAT.

Usually Skonto is calculated at the moment of payment, and the 
accountant is asked by the system "balance off Skonto (Y/n)", or the 
system is configured to do it without asking.

Similar is done for small differences, where you can configure a 
threshold for "neglectable payment differences = EUR 0.10".

Payment terms are usually configurable in a "table of payment terms" 
with the attributes

payment_term_code
description_text
skonto_days
skonto_percentage
regular_days
delay_interest_rate
reminder_costs

And the payment terms can be specified at company level (standard 
terms), customer/supplier level, or contract level.

Thus I think we should provide an extra module for handling payment 
terms, similar to the tax module.

Next thing we should consider, is automatic debit transfer system (don't 
know, if this is the correct translation of "Bankeinzug". It works as 
follows: customer gives the supplier the number of the customers bank 
account, and allows the supplier to get money by a request to customers 
bank.) Usually this is an additional modul, which creates data media 
with all details for the bank, and payment transactions for the ledger.

Helmut Wollmersdorfer