Re: Using the invoice system - government rules

["Chris Travers" <..hidden..>]

On 10/30/07, Pongracz Istvan <..hidden..> wrote:
> Hi All,
>
> To use officially lsmb in Hungary there are several requirements for
> issuing an invoice.

Looking through your list of requirements, these look like they are
specific to AR.  Am I wrong here?

> These rules determined by the government, so, without them, lsmb more or
> less useless here. This is the bad news.
>
> The good news, my opinion, a flexible framework should manage this. Of
> course, this is only my opinion, not yours :)

I have done even more intrusive changes to SQL-Ledger in the past.
LedgerSMB should be a lit easier to work with in this area, and in 1.4
this hsould become downright easy :-)
>
> Here are the required features to use the invoice module
>
> 1st
> The number of the invoice, issued with the LS must be gap-less
> numbering, automatically.

Is this specific to invoices?  Do packing slips or similar documents
(in Greece, they have "transit vouchers") need independant, tracked
numbering?

Are there any other odd specifics here (special hardware for printing
invoices or the like)?

> For example:
> starting from: INV100001
> next numbers are:  INV100002, INV100003
> Any additional part probably no problem in the print view, such as date,
> short customer name etc., for example:   SHELL-2007/10-SZ100124
>
> Other invoice numbers (from a paper based invoice) should be record
> here, but in this case, this invoice must be restricted to print/email.
> This is only to record our invoice, come from somewhere else. I think,
> this feature already exists.
>
> 2nd
> The auto-assigned invoice numbers must be unchangeable after save the
> invoice. In fact, modifying the actual invoice number also must be not
> possible.

I expect that soon we will require full transaction reversal on all
invoices by default on the database side.   Also after 1.4, it should
be possible to prevent people from updating the invoice information
table where certain criteria are met.


> The best way, probably, when one install a new dataset, it is possible
> to determine the company standard initial number.
>
> 3rd
> The invoice must contains additional fields:
> * payment method: cash, bank transfer, card etc.
> Probably a text field should be enough, where the user can write the
> "cash" or "bank transfer".

I agree that this would be an important eature request which would
also be generally applicable.

> Or somewhere in the Basic settings should be define a "list" with the
> possible values (for example: "cash,bank transfer, card") and on the
> invoice form should be a selectbox with these values.
> * the date when the invoice saved.

I was thinking of a simple database table and a simple interface
similar to what we do for taxes.

>
> 4th
> Printing invoice
> The printed invoice must contains the following, when it printed first
> time:
> * how many copies are made
> * the copy number on each copies
> * Example:
>         1st copy of 3
>         2nd copy of 3
>         3rd copy of 3
> When it printed 2nd time and more, it only must contain a note, instead
> of the copy numbers: "This is a copy of the original invoice, with
> exactly the same content"

Ok, this would be another generally applicable feature request.

>
>
> I would like to know you opinion, how difficult to solve these
> localization problems in that way, all modifications would be part of
> the mainstream LS.

Here are my thoughts:

The only one which is not generally applicable is the gapless invoice
numbering.  Many countries do not require gapless numbering (and the
performance cost might be prohibitive here), and other countries have
strange rules for such numbering.  For example, in Greece, you have to
have separate gapless numbering sequences for invoices which are
delivered with goods (and hence also function as "transit vouchers")
vs invoices which are sent separately. vs invoices which void other
invoices vs product returns.

The best solution here is to keep the local requirements in mind when
we build the new invoice system in 1.4 so that such behavior can be
safely modularized.

The rest should be generally applicable and could be incorporated in
the core distribution.

Best Wishes,
Chris Travers