Invoicenumber(s) not correct according to EU law

According to what I know on Dutch and EU laws the way that OC generates it's invoicenumbers is not correct.

As i see it now it generates the invoicenumber the same as the ordernumber and according to many Laws the invoicenumber should be independend and in line (follow up).
To make OC complying with these Laws the way the invoicenumbers are generated should change.

So is OpenCart not good for EU countries?

ekerazha wrote:So is OpenCart not good for EU countries?

Yes, but you cannot use the invoices generated bij OpenCart.

I hope that Daniel will change the way on how the invoicenumber is generated in the next release otherwise you need an additional program to generate invoices.

I've checked the Italian law (and Italy is in the EU), it must be progressive and annual.

Examples:

Year 2009 invoices

0001
0002
0003

...

Year 2010 invoices

0001/2010
0002/2010

etc.

ekerazha wrote:I've checked the Italian law (and Italy is in the EU), it must be progressive and annual.

Same here in the Netherlands.

You can add the year in front so I currently have 20090001 etc.

Yeah

1
0001
0001/2010
2010-0001
A0001/2010

they are all good

i2Paq wrote:

ekerazha wrote:I've checked the Italian law (and Italy is in the EU), it must be progressive and annual.

Same here in the Netherlands.

Progressive is not the same as sequential. Example:

• 0001
  0004
  0009
  0043

are progressive, just not sequential.

If the law says they have to be "progressive", what is the problem?

fido-x wrote:

i2Paq wrote:

ekerazha wrote:I've checked the Italian law (and Italy is in the EU), it must be progressive and annual.

Same here in the Netherlands.

Progressive is not the same as sequential. Example:

• 0001
  0004
  0009
  0043

are progressive, just not sequential.

If the law says they have to be "progressive", what is the problem?

No, that's not progressive, progressive numbers also means difference between near numbers is constant... so

1, 4, 43 is not progressive

2, 4, 6, 8, 10 could be progressive, but law doesn't talk math language

So if I use 2, 4, 6, 8 the "tax-man" will knock knock on my door and he'll say "where are invoices 1, 3, 5, 7 etc?" ehmmm uhmmm

Also there are no reasons to use 2,4,6 over 1,2,3,4,5,6, moreover it must be annual.

Invoice numbers could be generated this way

COUNT(*) products invoiced that YEAR

the new invoice is "COUNT(*)+1/YEAR"

example

575/2010 is the 575th invoice of year 2010

maybe there's a more efficient way, like keeping an index instead of COUNT(*)ing every time (however, COUNT(*) is quite fast on MyISAM)

fido-x wrote: If the law says they have to be "progressive", what is the problem?

I see what you where tinking but like ekerazha it is not math

In the Netherlands the tax man don't care about what year the number is made as long as there is an invoice-date on the invoice.
For myself i do use the year in front of my invoice-number, just to make life easyer.

I can, however, live with 00012010.

i2Paq wrote: In the Netherlands the tax man don't care about what year the number is made as long as there is an invoice-date on the invoice.
For myself i do use the year in front of my invoice-number, just to make life easyer.

I can, however, live with 00012010.

In Italy it is usually separated because it restarts from 1 every year, so we have 2010-1 or 1/2010 etc. I never saw the number merged as 20101 or 12010, maybe it is acceptable maybe not I don't know... because it's not clear if it is the invoice number 12010 or the number 12010

ekerazha wrote:

i2Paq wrote: In the Netherlands the tax man don't care about what year the number is made as long as there is an invoice-date on the invoice.
For myself i do use the year in front of my invoice-number, just to make life easyer.

I can, however, live with 00012010.

In Italy it is usually separated because it restarts from 1 every year, so we have 2010-1 or 1/2010 etc. I never saw the number merged as 20101 or 12010, maybe it is acceptable maybe not I don't know... because it's not clear if it is the invoice number 12010 or the number 12010

OK, that makes sence.

So it should be: 0001-2010.

should be year first for sorting reasons

I understand your problems and will look into fix this.

I will say though that the goverments around the world should not be telling people how to setup a shopping cart. they are incompetent and do not have the educated skill to set up a shopping cart system.

one of the EU laws ecommerce laws is to show order totals on the cart page before a customer signs up. how are you supposed to show taxes and shipping totals if you don;t know what country the customer is in?

Daniel wrote:I understand your problems and will look into fix this.

I will say though that the goverments around the world should not be telling people how to setup a shopping cart. they are incompetent and do not have the educated skill to set up a shopping cart system.

Hello Daniel, thanks for your reply and THANKS! for this great piece of work and your quick way of addressing "issues".
Comming from osCommerce (my shop still runs on it) and also PrestaShop I must say that in the 2 days that I have been using your Cart I'm still suprised every minut about the easy of use and functionality already build in.

Your right but keep in mind that Tax-laws where before there ever was a piece of software that was called "cart".

one of the EU laws ecommerce laws is to show order totals on the cart page before a customer signs up. how are you supposed to show taxes and shipping totals if you don;t know what country the customer is in?

So true, but Law makers have sometimes no clue on how software works.

It would be great if you could fix this and I think that it is not that hard to do.
But hey, I'm no coder (sorry for that).

I highlight it should be progressive, so if I delete an order (before generating its invoice) and then I generate the invoice for another order, there shouldn't be a "hole" because of the deleted order, invoices must always be progressive.

Every invoice-number should be N+1 where N is the number of the previously generated invoice (not the previous order).

In the end I must always have 1, 2, 3, 4, 5, 6, 7, 8, 9 etc. without "holes" for every generated invoice... then on a new year it should restart 1, 2, 3, 4, 5, 6 etc.

See i was right.. stupid laws

i'm sure i can do that!

I will have to create another field in the db called invoice_no. once the order is confirmed the number can appear. problem maybe if callbacks don't get through.

ekerazha wrote:... then on a new year it should restart 1, 2, 3, 4, 5, 6 etc.

Why? You must not restart every new year. Set a start value like 1 and then value+1. Important is: Never delete a invoice. When a customer don't pay, cancel the transaction but don't delete. The tax collector will only see a clear transaction, that is the reason for this law.

Because I've always seen it does restart every year, italian wikipedia also states this: http://it.wikipedia.org/wiki/Fattura_%28documento%29

la numerazione progressiva annuale (che ad ogni inizio anno fiscale deve ripartire da 1);

Otherwise it wouldn't be "annual", just progressive.