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.
Reason: Made sticky
Norman in 't Veldt
Moderator OpenCart Forums
_________________ READ and Search BEFORE POSTING _________________
Our FREE search: Find your answer FAST!.
[How to] BTW + Verzend + betaal setup.
Yes, but you cannot use the invoices generated bij OpenCart.ekerazha wrote:So is OpenCart not good for EU countries?
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.
Norman in 't Veldt
Moderator OpenCart Forums
_________________ READ and Search BEFORE POSTING _________________
Our FREE search: Find your answer FAST!.
[How to] BTW + Verzend + betaal setup.
Same here in the Netherlands.ekerazha wrote:I've checked the Italian law (and Italy is in the EU), it must be progressive and annual.
You can add the year in front so I currently have 20090001 etc.
Norman in 't Veldt
Moderator OpenCart Forums
_________________ READ and Search BEFORE POSTING _________________
Our FREE search: Find your answer FAST!.
[How to] BTW + Verzend + betaal setup.
Progressive is not the same as sequential. Example:i2Paq wrote:Same here in the Netherlands.ekerazha wrote:I've checked the Italian law (and Italy is in the EU), it must be progressive and annual.
- 0001
0004
0009
0043
If the law says they have to be "progressive", what is the problem?
Modules for OpenCart 2.3.0.2
Homepage Module [Free - since OpenCart 0.7.7]
Multistore Extensions
Store Manager Multi-Vendor/Multi-Store management tool
If you're not living on the edge ... you're taking up too much space!
No, that's not progressive, progressive numbers also means difference between near numbers is constant... sofido-x wrote:Progressive is not the same as sequential. Example:i2Paq wrote:Same here in the Netherlands.ekerazha wrote:I've checked the Italian law (and Italy is in the EU), it must be progressive and annual.are progressive, just not sequential.
- 0001
0004
0009
0043
If the law says they have to be "progressive", what is the problem?
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.
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)
I see what you where tinking but like ekerazha it is not mathfido-x wrote: If the law says they have to be "progressive", what is the problem?
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.
Norman in 't Veldt
Moderator OpenCart Forums
_________________ READ and Search BEFORE POSTING _________________
Our FREE search: Find your answer FAST!.
[How to] BTW + Verzend + betaal setup.
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 12010i2Paq 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.
OK, that makes sence.ekerazha wrote: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 12010i2Paq 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.
So it should be: 0001-2010.
Norman in 't Veldt
Moderator OpenCart Forums
_________________ READ and Search BEFORE POSTING _________________
Our FREE search: Find your answer FAST!.
[How to] BTW + Verzend + betaal setup.
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?
OpenCart®
Project Owner & Developer.
Hello Daniel, thanks for your reply and THANKS! for this great piece of work and your quick way of addressing "issues".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.
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".
So true, but Law makers have sometimes no clue on how software works.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?
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).
Norman in 't Veldt
Moderator OpenCart Forums
_________________ READ and Search BEFORE POSTING _________________
Our FREE search: Find your answer FAST!.
[How to] BTW + Verzend + betaal setup.
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.
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.ekerazha wrote:... then on a new year it should restart 1, 2, 3, 4, 5, 6 etc.
Otherwise it wouldn't be "annual", just progressive.la numerazione progressiva annuale (che ad ogni inizio anno fiscale deve ripartire da 1);
Users browsing this forum: Majestic-12 [Bot] and 156 guests