Re: Using the invoice system - government rules

[Pongracz Istvan <..hidden..>]

Hi,


2007. 10. 30, kedd keltezéssel 10.16-kor Chris Travers ezt írta:

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

Account receivable, I think yes, at this moment it is related only to
AR.

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

This is very good news :)

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

Yes, this is specific to invoices.
My guess, if one can manage this for invoice, optionally it should be
useful for all (nearly all) similar documents.
For example, when one install a new dataset, the initial settings should
provide some controls to manage these local-specific requirements.

For example in the invoices case a form:

Invoice starting value: [_________________________]
Gap-less, tracked invoice numbers  ( )
Free-style invoice numbers         (*)


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

If one uses a laser printer, one must print 3 copies. If somebody uses a
matrix printer with 3-copies-leporello, he only needs one to print.
Hmmm, I forgot this option. You are right, it is a possibility to one
use any kind of printer, even hammer and rock or braille ....


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

I agree. Especially, if something saved and issued (invoice), the
content must be never updated.



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

If possible, with some additional preferences with them.
Look at the "Saving date" which means, when the invoice saved to the
database (save and print in the form):

New field -> invoice date
		Options:
		type [date/datetime/sequence/text/list]
		required [ ]
		auto-value (default) [current_date() / current_datetime() / SEQ1120 /
"changeme" / "cash,promise,pray,bank"]


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

See above, yes. With a framework, this kind of feature allows users to
extend documents with any kind of locale-specific data.
Easy to manage (relatively) these predefined sequences, lists etc.
Easy to insert them into the form (I do not know, how :)

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

One half in the application side, the other in the invoice (whatever)
template.
See later.

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

Based on your idea, you wrote above, I think it could be possible. The
invoice number could be a predefined field.
But this example from Greece seems tricky.....
But in this special case, the user should choose between two or more
predefined sequences.....


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

This is the one of the best news in this year :)

Generally, that kind of sql-ledger on my homepage (downloadable) already
contains these local specific modifications.
Some of them use additional database tables, modified templates etc.
The author of that localized sql-ledger tried to put his work into the
mainstream, but he failed. He told me this.

I think, all my country would be happy to get LS work here :)

Regarding the 1.3 and 1.4.

As I understand, you (core team) will finish the work with 1.3 soon (~2
months) and after you (core team) will start working on 1.4 and bugfixes
for 1.3.
Am I wrong?

Regards,
István


> 
> Best Wishes,
> Chris Travers
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Ledger-smb-devel mailing list
> ..hidden..
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
-- 
eGroupWare, gLiveCD, gentoo és barátai
http://www.osbusiness.hu
„A humor a méltóság támasza, fölényünket hirdeti 
mindazzal szemben, amit a sors ránk mér.” 
(Romain Gary)