Invoicenumber(s) not correct according to EU law

any possible timeframe on when this is coming out?

So is doing it this way ok with every one?

0001/2010
0002/2010

Before this issue will be solved, please consider this:

1. fiscal year MUST not be the same as calendar year
2. depending on your invoice system (and to go confirm with it), let the user input something like a 'prefix' or 'suffix' (depending on his accounting system)
3. maybe somewhere in the future there will be a conenctor to an invoicing/accounting system (therefore see #2 - OC must hand over correct numbers)
4. if a shop starts during the fiscal year, the accounting department may have invoiced already some invoices -> therefore the shop owner must be able to fill in a starting point (where the old invoice numbering ended) to continue with
5. ACL - only the shop owner is allowed to do this changes!

joomx wrote:Before this issue will be solved, please consider this:

1. fiscal year MUST not be the same as calendar year

Maybe in the country where you live, here it is.

2. depending on your invoice system (and to go confirm with it), let the user input something like a 'prefix' or 'suffix' (depending on his accounting system)

That sounds fair. But how will you restart from 001 at the begining of the new year?

3. maybe somewhere in the future there will be a conenctor to an invoicing/accounting system (therefore see #2 - OC must hand over correct numbers)

4. if a shop starts during the fiscal year, the accounting department may have invoiced already some invoices -> therefore the shop owner must be able to fill in a starting point (where the old invoice numbering ended) to continue with

So it should be that you will have to have a prefix (year as in 2010) and the actualy invoicenumber (wich should be entered manualy to restart from that number on.

5. ACL - only the shop owner is allowed to do this changes!

Not only that but there should be a security so that entering by accident is not possible. Maybe 2x ask "are you sure?".

Maybe in the country where you live, here it is

In the EU (exactly AT).
Generally it is your choice how you want to have the fiscal year - and that should be the same in the whole EU.
For example Microsoft (US company) has it from the 1.9. to 31.8.

So if I have defined my fiscal from (e.g.) starting from the 1.9. (every year), the counter starts at 1 (how many pre digits should be also defineable!), eg. 001 or 00001 or 00000001 or only 1.
In the case the company change the fiscal year (yes this can also happen), the store owner should be able to change it oalso in OC - and the counter MUST start again!

But how will you restart from 001 at the begining of the new year?

As you have defined it (or automatically) which should be selectable by the store owner.

Not only that but there should be a security so that entering by accident is not possible. Maybe 2x ask "are you sure?

This should be done at several places in the backend (saw a thread about this here).
I have deleted accidentically some products i created just before because of 'nobody asked if I want to delete them' (yeah I know my fault ... )

joomx wrote: 1. fiscal year MUST not be the same as calendar year

Here in Italy it's the same from 30-40 years.

Daniel wrote:So is doing it this way ok with every one?

0001/2010
0002/2010

Yeah that's good

This is an example of an Italian invoice http://www.gestionalev5.it/images/modello_fattura.jpg (just an example, layout may change)

a hardcoded invoice number format is useless.

what we must do is gather as many possible
number formats as possible and create
a template from it.

it will have to be either a format string
a la "%Y-%i" (%Y=year, %i = invoice no, etc)
or a prefix, suffix and a template similar to when
we choose date formats from a dropdown
in applications, e.g. mm/dd/yy, dd/mm/yyyy, etc.
one doesn't have every single possibility of formating
a date, but the most often used ones.

Is there a confirmed fix (hack) for this in 1.3.2?

I'm not bothered about pre-fixes and the year issue as I'm in the UK. Just want it to not increment the invoice number if a sale isn't completed.

If there is a fix can some one point me at it as my search foo skills have let me down.

Cheers

gavin m wrote:Is there a confirmed fix (hack) for this in 1.3.2?

I'm not bothered about pre-fixes and the year issue as I'm in the UK. Just want it to not increment the invoice number if a sale isn't completed.

If there is a fix can some one point me at it as my search foo skills have let me down.

Cheers

There is none atm.

i2Paq wrote:

gavin m wrote:Is there a confirmed fix (hack) for this in 1.3.2?

I'm not bothered about pre-fixes and the year issue as I'm in the UK. Just want it to not increment the invoice number if a sale isn't completed.

If there is a fix can some one point me at it as my search foo skills have let me down.

Cheers

There is none atm.

Maybe my search foo skills didn't let me down after all.

Just wondering, is anyone working on a fix for this in 1.3.2?

If not, I would be interested in having it fixed as far as the invoice number increments one when an order is actually placed and payment received. Not bothered about any of the other EU stuff like having the year in it or it resetting each year.

Any one?

I really would like a fix for 1.3.2 that results in the invoice incrementing 1 when it should do.

If someone can help, please do. I'm even willing to pay for it (as long as it's not silly money)

Cheers

I AM ALL ABOUT SILLY MONEY!
I am not sure what you are asking but I think this is what you want:
http://forum.opencart.com/viewtopic.php ... 92&p=43453

Qphoria wrote:I AM ALL ABOUT SILLY MONEY!
I am not sure what you are asking but I think this is what you want:
http://forum.opencart.com/viewtopic.php ... 92&p=43453

Close, but not quite (if I understand that mod)

I need it so the invoice number itself increases when the sale is confirmed.If I understand that mod, it only reuses the same order number in that session, so if the last invoice was 100, the a customer generates order number 101, but doesn't buy, then the following customer does buy, their invoice number would be 102 instead of 101

Is that correct? If so, then it doesn't fix what I want.

In the above example, I want the the buying customers invoice to be correct (101)

You see, I am thinking of going VAT registered and want this to work right so I don't have to argue with the VAT man about missing invoices when he wants to see my accounts. The VAT man is one man you don't argue with.

Basically, there should be no breaks in the invoice numbers.

This is for 1.3.2 by the way.

Correct. The fix only fixes half of the problem. The invoice issue is another problem and needs to be separate from the order id. I think that might be added in 1.4.1

Is it quite a bit of work to fix it then? Was hoping to avoid having to upgrade again for some time.

gavin m wrote:Is it quite a bit of work to fix it then? Was hoping to avoid having to upgrade again for some time.

If you have read all posts in this thread, you may understand why this cannot be a 'quick and dirty' hack.

Rename the OC "invoice" to "Initial Receipt" and do a formal invoice in Quickbooks, or some similar program, you are going to have to enter everything into some sort of accounts anyhow. Then just email the invoice from the accounting program.

You will have everything in order and a set of balanced books, inventory status if you want it, profit and loss statement, etc.