[Advacs-discuss] Latest CVS updates

Oliver Elphick olly@lfix.co.uk
Mon, 06 Sep 2004 16:21:05 +0100


On Mon, 2004-09-06 at 00:21, Helmut Wollmersdorfer wrote:
> 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.

OK.  It's easy to add those

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

So a year has 360 days?  The mention of days suggests a daily
calculation done monthly.  I don't anticipate that we would be
generating anything but predictive data from this: presumably the
definitive charges will be calculated the bank - we just need to know
approximate amounts for budgeting.

> 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

Curious, since the word actually means a period of three months!

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

There's a snag to start with!  In Britain, VAT is not chargeable on the
amount that might be allowed in settlement discount; it looks as if in
your case the customer gets a VAT rebate on early settlement.

We will somehow have to link to the tax module for this.

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

OK

> 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

I need to add those last two fields

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

So a default system-wide definition; one in the customer record and one
on each invoice.

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

It might need to be a national module, but I'd like to see if we can't
avoid that.  The idea of the type field is that it should control the
manner of calculating settlement discount or surcharge for late payment;
if we extend the number of types that would, I hope, be sufficient.  In
a national SL module, you could drop and recreate the constraint so as
to restrict the choice to those used in that country.

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

We call them Direct Debits, if the payee initiates each transaction, or
Standing Orders, if the same amount is paid automatically every month,
or Bank Giro Transfers when the payer initiates a one-off transfer to
one or more payee accounts.

>  Usually this is an additional modul, which creates data media 
> with all details for the bank, and payment transactions for the ledger.

I don't see a need to create a separate module for it; I would just
build it into the cashbook.  It's not as if we were trying to get extra
sales.

-- 
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
                 ========================================
     "Behold, I stand at the door, and knock; if any man 
      hear my voice, and open the door, I will come in to 
      him, and will sup with him, and he with me."       
                                   Revelation 3:20