[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