Search found 76 matches

Search found 76 matches

Re: Invoicenumber(s) not correct according to EU law

moggiex wrote:
ekerazha wrote:In Italy you restart every year from 1 because it's annual and in other countries too, UK is not the whole world.
Then its not 'EU Law', but specific to 'Italy' :D

Matt
It could be an addition to the EU Law... or maybe UK is not fully compliant, do you have a link to the exact EU law?

Jump to post
  • Sun Nov 15, 2009 10:27 pm
  • Replies 132
  • Views 39541
Re: Invoicenumber(s) not correct according to EU law

In Italy you restart every year from 1 because it's annual and in other countries too, UK is not the whole world.

Jump to post
  • Sun Nov 15, 2009 9:16 pm
  • Replies 132
  • Views 39541
Re: Invoicenumber(s) not correct according to EU law

... then on a new year it should restart 1, 2, 3, 4, 5, 6 etc. For taxation purposes the year starts on 1 July of one year and ends on 30 June of the following year. If you have to put the year as part of the invoice and start renumbering invoices at 1 for the following year, couldn't you end up wi...

Jump to post
  • Fri Nov 13, 2009 7:01 am
  • Replies 132
  • Views 39541
Re: Invoicenumber(s) not correct according to EU law

SXGuy wrote: And as far as i know, there is no law that states the invoice numbers should revert after a financial year, since invoices include dates, and you always take an accounting year between two dates. invoice numbers are merely for reference purposes only.
Maybe UK is different from Italy and Benalux

Jump to post
  • Fri Nov 13, 2009 3:19 am
  • Replies 132
  • Views 39541
Re: Invoicenumber(s) not correct according to EU 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.

Jump to post
  • Wed Nov 11, 2009 5:18 am
  • Replies 132
  • Views 39541
Re: Invoicenumber(s) not correct according to EU law

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

Jump to post
  • Wed Nov 11, 2009 4:20 am
  • Replies 132
  • Views 39541
Re: Invoicenumber(s) not correct according to EU law

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

Jump to post
  • Wed Nov 11, 2009 2:40 am
  • Replies 132
  • Views 39541
Re: Invoicenumber(s) not correct according to EU law

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

Jump to post
  • Wed Nov 11, 2009 1:27 am
  • Replies 132
  • Views 39541
Re: Invoicenumber(s) not correct according to EU law

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

Jump to post
  • Wed Nov 11, 2009 1:12 am
  • Replies 132
  • Views 39541
Re: Invoicenumber(s) not correct according to EU law

Yeah

1
0001
0001/2010
2010-0001
A0001/2010

they are all good

Jump to post
  • Wed Nov 11, 2009 1:00 am
  • Replies 132
  • Views 39541
Re: Invoicenumber(s) not correct according to EU law

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.

Jump to post
  • Wed Nov 11, 2009 12:46 am
  • Replies 132
  • Views 39541
Re: Not-GPL application to OpenCart bridge

It seems like direcly accessing the OpenCart data is a more secure way Suppose I create a seperate application which can read, or write, to the databases used by those applications. Suppose I find the structure of the databases by using PHPMyAdmin, or PgAdmin, or whatever. Would my application have ...

Jump to post
  • Tue Nov 10, 2009 11:56 pm
  • Replies 6
  • Views 966
Re: Not-GPL application to OpenCart bridge

Ok, it was a generic question. Going deep... I'm developing a CDDL cms and I'm planning to release it and I'd like an OpenCart module in order to bridge users/auth... so maybe I can just update the OpenCart data without using OpenCart code (directly working on the database etc.) or I code a GPL plug...

Jump to post
  • Tue Nov 10, 2009 11:36 pm
  • Replies 6
  • Views 966
Re: Not-GPL application to OpenCart bridge

Well... and if I want to release the bridge plug-in or the modification code?

Jump to post
  • Tue Nov 10, 2009 11:04 pm
  • Replies 6
  • Views 966
Not-GPL application to OpenCart bridge

Hello, if I've a CDDL (open-source) Content Management System and I want "to bridge" OpenCart into this not-GPL application (CDDL is not compatible with GPL), what could I do? I can't direcly use GPL code from CDDL code, so... *) Can I code a GPL plug-in (the bridge) and distribute it separately fro...

Jump to post
  • Tue Nov 10, 2009 10:26 pm
  • Replies 6
  • Views 966

Search found 76 matches