RFC: Invoice sequences

[Cédric Krier]

Hi,

Following the previous discussions about the invoice sequence and the
fiscal year, I have started a feature request to improve the situation
and manage more cases.

https://bugs.tryton.org/issue5205

Please comment if the proposal could be in conflict with your local
usage.

Thanks,
--
Cédric Krier - B2CK SPRL
Email/Jabber: cedric...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/

[Jordi Esteve (Zikzakmedia)]

El 24/12/15 a les 15:06, Cédric Krier ha escrit:

> Hi,
>
> Following the previous discussions about the invoice sequence and the
> fiscal year, I have started a feature request to improve the situation
> and manage more cases.
>
> https://bugs.tryton.org/issue5205
>
> Please comment if the proposal could be in conflict with your local
> usage.

The new proposal (a check when setting the number on an invoice to
ensure that the invoice date not before any invoice dates numbered with
the same sequence) fits well the Spanish law and practice.

In fact, the Spanish team maintains a module [1] that implements this
idea with some restrictions because the sequence is not yet stored in
invoices.

https://bitbucket.org/trytonspain/trytond-account_invoice_consecutive

--
Jordi Esteve
Consultor Zikzakmedia SL
jes...@zikzakmedia.com
Mòbil 679 170 693

Zikzakmedia SL
St. Jaume, 9, baixos, 2a
08720 Vilafranca del Penedès
Tel 93 890 2108

[Cédric Krier]

On 2015-12-25 22:26, Jordi Esteve (Zikzakmedia) wrote:
> El 24/12/15 a les 15:06, Cédric Krier ha escrit:
> >Hi,
> >
> >Following the previous discussions about the invoice sequence and the
> >fiscal year, I have started a feature request to improve the situation
> >and manage more cases.
> >
> >https://bugs.tryton.org/issue5205
> >
> >Please comment if the proposal could be in conflict with your local
> >usage.
>
> The new proposal (a check when setting the number on an invoice to ensure
> that the invoice date not before any invoice dates numbered with the same
> sequence) fits well the Spanish law and practice.
>
> In fact, the Spanish team maintains a module [1] that implements this idea
> with some restrictions because the sequence is not yet stored in invoices.
>
> https://bitbucket.org/trytonspain/trytond-account_invoice_consecutive

I see you also have a check for invoice_date == accounting_date for out
invoices. I'm wondering if we should also include this constraint in the
base.

[Jordi Esteve (Zikzakmedia)]

El 26/12/15 a les 15:10, Cédric Krier ha escrit:

> On 2015-12-25 22:26, Jordi Esteve (Zikzakmedia) wrote:
>> El 24/12/15 a les 15:06, Cédric Krier ha escrit:
>>> Hi,
>>>
>>> Following the previous discussions about the invoice sequence and the
>>> fiscal year, I have started a feature request to improve the situation
>>> and manage more cases.
>>>
>>> https://bugs.tryton.org/issue5205
>>>
>>> Please comment if the proposal could be in conflict with your local
>>> usage.
>> The new proposal (a check when setting the number on an invoice to ensure
>> that the invoice date not before any invoice dates numbered with the same
>> sequence) fits well the Spanish law and practice.
>>
>> In fact, the Spanish team maintains a module [1] that implements this idea
>> with some restrictions because the sequence is not yet stored in invoices.
>>
>> https://bitbucket.org/trytonspain/trytond-account_invoice_consecutive
> I see you also have a check for invoice_date == accounting_date for out
> invoices. I'm wondering if we should also include this constraint in the
> base.

I think if the invoice sequence must maintain the same order of invoice
dates, the post (accounting) date of these invoices must maintain also
the same order. I don't know if this is a common practice in other
countries.

[Albert Cervera i Areny]

2015-12-26 15:10 GMT+01:00 Cédric Krier <cedric...@b2ck.com>:
> On 2015-12-25 22:26, Jordi Esteve (Zikzakmedia) wrote:
>> El 24/12/15 a les 15:06, Cédric Krier ha escrit:
>> >Hi,
>> >
>> >Following the previous discussions about the invoice sequence and the
>> >fiscal year, I have started a feature request to improve the situation
>> >and manage more cases.
>> >
>> >https://bugs.tryton.org/issue5205
>> >
>> >Please comment if the proposal could be in conflict with your local
>> >usage.
>>
>> The new proposal (a check when setting the number on an invoice to ensure
>> that the invoice date not before any invoice dates numbered with the same
>> sequence) fits well the Spanish law and practice.
>>
>> In fact, the Spanish team maintains a module [1] that implements this idea
>> with some restrictions because the sequence is not yet stored in invoices.
>>
>> https://bitbucket.org/trytonspain/trytond-account_invoice_consecutive
>
> I see you also have a check for invoice_date == accounting_date for out
> invoices. I'm wondering if we should also include this constraint in the
> base.

I think this makes sense. It'd be very strange that the law allowed
those dates to be different.

However, as Jordi said, the reason we added this constraint was not
this one. In Spain you cannot create invoice number 0001 on 03/01/2016
and invoice number 0002 on a date < 03/01/2015, which is exactly your
proposal.

I always thought that was a very strict (special) Spanish requirement
so it would be nice to know if other countries have the same
limitation.

>
> --
> Cédric Krier - B2CK SPRL
> Email/Jabber: cedric...@b2ck.com
> Tel: +32 472 54 46 59
> Website: http://www.b2ck.com/
>

> --
> You received this message because you are subscribed to the Google Groups "tryton" group.
> To view this discussion on the web visit https://groups.google.com/d/msgid/tryton/20151226141015.GY11765%40tetsuo.wifi.b2ck.com.



--
Albert Cervera i Areny
http://www.NaN-tic.com
Tel. 93 553 18 03

[Sebastián Marró]

Same limitation in Argentina

Sebastián Marró

Thymbra

[Mathias Behrle]

* Cédric Krier: " Re: [tryton] RFC: Invoice sequences" (Sat, 26 Dec 2015
15:10:15 +0100):

> On 2015-12-25 22:26, Jordi Esteve (Zikzakmedia) wrote:
> > El 24/12/15 a les 15:06, Cédric Krier ha escrit:
> > >Hi,
> > >
> > >Following the previous discussions about the invoice sequence and the
> > >fiscal year, I have started a feature request to improve the situation
> > >and manage more cases.
> > >
> > >https://bugs.tryton.org/issue5205
> > >
> > >Please comment if the proposal could be in conflict with your local
> > >usage.
> >
> > The new proposal (a check when setting the number on an invoice to ensure
> > that the invoice date not before any invoice dates numbered with the same
> > sequence) fits well the Spanish law and practice.
> >
> > In fact, the Spanish team maintains a module [1] that implements this idea
> > with some restrictions because the sequence is not yet stored in invoices.
> >
> > https://bitbucket.org/trytonspain/trytond-account_invoice_consecutive
>
> I see you also have a check for invoice_date == accounting_date for out
> invoices. I'm wondering if we should also include this constraint in the
> base.

According to our knowledge this constraint is definitely wrong for Germany:

The accounting date has to be
- the date of the delivery for imputed taxation
- the date of the payment for actual taxation (cash basis accounting)

--

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://www.m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6

[Cédric Krier]

On 2016-01-07 12:28, Mathias Behrle wrote:
> * Cédric Krier: " Re: [tryton] RFC: Invoice sequences" (Sat, 26 Dec 2015
> 15:10:15 +0100):
>
> > On 2015-12-25 22:26, Jordi Esteve (Zikzakmedia) wrote:
> > > El 24/12/15 a les 15:06, Cédric Krier ha escrit:
> > > >Hi,
> > > >
> > > >Following the previous discussions about the invoice sequence and the
> > > >fiscal year, I have started a feature request to improve the situation
> > > >and manage more cases.
> > > >
> > > >https://bugs.tryton.org/issue5205
> > > >
> > > >Please comment if the proposal could be in conflict with your local
> > > >usage.
> > >
> > > The new proposal (a check when setting the number on an invoice to ensure
> > > that the invoice date not before any invoice dates numbered with the same
> > > sequence) fits well the Spanish law and practice.
> > >
> > > In fact, the Spanish team maintains a module [1] that implements this idea
> > > with some restrictions because the sequence is not yet stored in invoices.
> > >
> > > https://bitbucket.org/trytonspain/trytond-account_invoice_consecutive
> >
> > I see you also have a check for invoice_date == accounting_date for out
> > invoices. I'm wondering if we should also include this constraint in the
> > base.
>
> According to our knowledge this constraint is definitely wrong for Germany:
>
> The accounting date has to be
> - the date of the delivery for imputed taxation

But I guess there are some constraint. You can not put a date that is on
a closed fiscal year for example. Or I think it will be very strange to
have an invoice with a date in year Y (with numbering of year Y) and the
accounting date in Y-1.

> - the date of the payment for actual taxation (cash basis accounting)

I'm not sure we are talking about the same thing. The accounting date of
the invoice can not depend on the payment as it will happen at a
different time. The cash basis accounting is only about tax report.

[Axel Braun]

I would say, the date of invoice. You dont always have a delivery (service
charges)

> - the date of the payment for actual taxation (cash basis accounting)

OK

Cheers
Ax

[Mathias Behrle]

* Axel Braun: " Re: [tryton] RFC: Invoice sequences" (Thu, 07 Jan 2016 13:29:57
+0100):

In case of service you have to indicate the time of supply. Invoices missing
those dates are strictly spoken invalid. Either you point to a delivery date
(e.g. on a delivery note) or you have to explicitely write on the invoice, that
the delivery date is the same as the invoice date.

> > - the date of the payment for actual taxation (cash basis accounting)
>
> OK
>
> Cheers
> Ax
>

[Mathias Behrle]

* Cédric Krier: " Re: [tryton] RFC: Invoice sequences" (Thu, 7 Jan 2016
12:53:30 +0100):

The important date for accounting is the delivery date. The invoice date is a
trigger for payment terms.

> > - the date of the payment for actual taxation (cash basis accounting)
>
> I'm not sure we are talking about the same thing. The accounting date of
> the invoice can not depend on the payment as it will happen at a
> different time. The cash basis accounting is only about tax report.

That's what I have found in German forums.

Note:
I am not an accountant.

[Cédric Krier]

Then it means invoice_date == accounting_date :-)
But indeed I think the correct wording will be: the accounting date
should reflect when the profit/expense was done.

[Axel Braun]

Am Donnerstag, 7. Januar 2016, 13:47:57 schrieb Mathias Behrle:
> > > According to our knowledge this constraint is definitely wrong for
> > > Germany:
> > >
> > > The accounting date has to be
> > > - the date of the delivery for imputed taxation
> >
> > I would say, the date of invoice. You dont always have a delivery (service
> > charges)
>
> In case of service you have to indicate the time of supply. Invoices missing
> those dates are strictly spoken invalid.

True from a taxation point of view. But your invoice has not to be on the last
day of the period (or something like this)

> Either you point to a delivery
> date (e.g. on a delivery note) or you have to explicitely write on the
> invoice, that the delivery date is the same as the invoice date.

As we are just in a go-live in Germany, I have asked our experts....the
delivery date has no relation to the invoice date. They are completely
independent. If you think about collective invoices etc that makes sense.

Invoice date is relevant for accounting, taxation and payment terms.

HTH
Axel

PS: I'm not an accoutant either

[Cédric Krier]

Yes but the invoice number is generated using the sequence linked to the
accounting date but with the invoice date in the context for formating.

So my example will still be strange if you look at the invoice numbers.

[Korbinian Preisler]

Think of this case which is very common if the delivery and the
invoicing is done separately:

1. Delivery on 2015-12-30 -> accounting_date = 2015-12-30
2. Invoicing on 2016-01-04 -> invoice_date = 2015-01-04

In Germany the rules for invoice numbering are not very strict. I did a
quick research but did not find any rule that the invoice number cannot
be from the 2015 sequence in this case. But i would prefer to have it
from the 2016 sequence. So i would say that at least in Germany the
sequence should be selected depending on the invoice date.

--
___________________________________
virtual things
Preisler & Spallek GbR
München - Aachen

Windeckstr. 77
81375 München
Tel: +49 (89) 710 481 55
Fax: +49 (89) 710 481 56

in...@virtual-things.biz
http://www.virtual-things.biz

[Korbinian Preisler]

This is not correct. The accounting_date is relevant for the accounting
and for the taxation. The invoice_date is relevant for the payment term.

[Mathias Behrle]

* 'Korbinian Preisler' via tryton: " Re: [tryton] RFC: Invoice sequences" (Thu,
7 Jan 2016 14:54:49 +0100):

Seconded.

[Mathias Behrle]

* 'Korbinian Preisler' via tryton: " Re: [tryton] RFC: Invoice sequences" (Thu,

7 Jan 2016 14:52:54 +0100):

This should be a minor typo?
=> 2. Invoicing on 2016-01-04 -> invoice_date = 2016-01-04

> In Germany the rules for invoice numbering are not very strict. I did a
> quick research but did not find any rule that the invoice number cannot
> be from the 2015 sequence in this case. But i would prefer to have it
> from the 2016 sequence. So i would say that at least in Germany the
> sequence should be selected depending on the invoice date.
>



--

[Cédric Krier]

But then how do you manage to give to the reviewer the invoices
corresponding to the fiscal year 2015 if you can not use the invoice
sequence. And how can he check that you have give him all the invoices
etc.
For me, it is very strange to allow invoice date and accounting date on
different fiscalyear.

[Korbinian Preisler]

yes. sorry. 2016-01-04 is correct.

[Korbinian Preisler]

This is an argument to use the accounting_date to select the sequence.
And as i said there is no rule that prevents to do so.

But anyway not the invoice is relevant for the reviewer but the account
moves. The invoice is just the document that describes the content of
the move.
So if a reviewer requests me to give him all the invoices for the
fiscalyear i can select the invoices by accounting_date as this is the
only date that really defines to which accounting period an invoice
belongs to.

Think of companies that do invoicing once by month. The invoice date
will always at least the first of the following month and dating back an
invoice is bad practice. The invoice date is just the date when the
invoice has been created. nothing more. more important is the date of
the delivery or the date of the service that has been provided. and that
is the reason why in Germany this date needs to be written onto the
invoice too.

[Axel Braun]

Hi Korbinian,

> Gesendet: Donnerstag, 07. Januar 2016 um 14:54 Uhr
> Von: "'Korbinian Preisler' via tryton" <try...@googlegroups.com>
> An: try...@googlegroups.com
> Betreff: Re: [tryton] RFC: Invoice sequences

> >
> >> Either you point to a delivery
> >> date (e.g. on a delivery note) or you have to explicitely write on the
> >> invoice, that the delivery date is the same as the invoice date.
> > As we are just in a go-live in Germany, I have asked our experts....the
> > delivery date has no relation to the invoice date. They are completely
> > independent. If you think about collective invoices etc that makes sense.
> >
> > Invoice date is relevant for accounting, taxation and payment terms.
> This is not correct. The accounting_date is relevant for the accounting
> and for the taxation. The invoice_date is relevant for the payment term.

You better ask your tax agent. Baseline for taxation is the invoice date. And you have to take the invoice with that date into accounting. Only imputed accounting of course.

(There are special cases around year end, where you should create deferral invoices - but thats a different story.

/Ax

[Korbinian Preisler]

Ok lets see:

The following clauses can be found here:
http://www.gesetzeiminternet.de/

Unfortunately i cannot link directly.

I focus on VAT here:

Please read §14 Abs. 2 UStG:
For national invoices there is period of 6 month until you have to
create invoice.

Please read §14 Abs. 4 Nr. 3 UStG:
The invoice must contain the issue date (which is the invoice date)

Please read §14 Abs. 4 Nr. 6 UStG:
The invoice must contain the date of delivery or services done (which
can be used as accounting date in most cases, but there are exceptions)

Please read §13 Abs. 1 Nr. 1 UStG:
The tax for the delivery or service done accrues for imputed accounting
at the end of the tax declaration period (this is the end of the month
in most cases)
I concentrate on the common case here. There are exceptions.

So as you can see the accrual of the tax is not dependent on the issue
date of the invoice. Similar rules apply to income taxes.

[Vincent Bastos]

For my part ( Australia ), the sequence is not important. As you can see in the links below, the ATO ( Australian Taxation Office ) does not require an invoice to have a number :)... we are pretty easy going down under.

https://www.ato.gov.au/Business/GST/Issuing-tax-invoices/

http://www.business.vic.gov.au/money-profit-and-accounting/getting-paid-on-time/invoicing

However, if we are going to make invoice_date = accounting_date why the 2 fields? To be honest I don't understand what the purpose of the accounting_date field is for?

P.S. I am not an accoutant.

[Cédric Krier]

On 2016-01-08 04:00, Vincent Bastos wrote:
> For my part ( Australia ), the sequence is not important. As you can see in
> the links below, the ATO ( Australian Taxation Office ) does not require an
> invoice to have a number :)... we are pretty easy going down under.
>
> https://www.ato.gov.au/Business/GST/Issuing-tax-invoices/
>
> http://www.business.vic.gov.au/money-profit-and-accounting/getting-paid-on-time/invoicing
>
> However, if we are going to make invoice_date = accounting_date why the 2
> fields?

Because for supplier invoice, you will mostly change it.

> To be honest I don't understand what the purpose of the
> accounting_date field is for?

accounting date is used to fill the move date.

I think Korbinian correctly summarize it:

invoice_date -> for payment term
accounting_date -> for accounting/taxation

[Vincent Bastos]

On Fri, Jan 8, 2016 at 10:24 PM, Cédric Krier <cedric...@b2ck.com> wrote:

On 2016-01-08 04:00, Vincent Bastos wrote:
> For my part ( Australia ), the sequence is not important. As you can see in
> the links below, the ATO ( Australian Taxation Office ) does not require an
> invoice to have a number :)... we are pretty easy going down under.
>
> https://www.ato.gov.au/Business/GST/Issuing-tax-invoices/
>
> http://www.business.vic.gov.au/money-profit-and-accounting/getting-paid-on-time/invoicing
>
> However, if we are going to make invoice_date = accounting_date why the 2
> fields?

Because for supplier invoice, you will mostly change it.

> To be honest I don't understand what the purpose of the
> accounting_date field is for?

accounting date is used to fill the move date.

I think Korbinian correctly summarize it:

    invoice_date -> for payment term
    accounting_date -> for accounting/taxation

ok, so in Australia it is possible to report your income on a cash basis, but your GST on an accrual basis. Quote below is from [1]:

There are two methods of accounting for GST: a cash basis and a non-cash basis (accruals).

The method you use will affect when you must report GST.

Businesses with an aggregated turnover (your businesses' turnover and the turnover of closely associated entities) of less than $2 million, or who use cash accounting for income tax, can use either method. Most larger businesses must use the non-cash method.

It is allowed and possible to create an invoice in one period, but only have it paid in another period. How would one create both the income and GST ( VAT ) report accurately? Or rather which fields to use?

[1] https://www.ato.gov.au/Business/GST/Accounting-for-GST-in-your-business/Choosing-an-accounting-method/

--

Vincent Bastos

Lava Lab Software

[pgm.l...@gmail.com]

Hi Tryton fans,

After many years accountancy and even more years ict, I'm exploring Tryton as a new challenge. Like it very much. The only disappointment for me until now was the duty to make new invoice sequences, every year ...
I saw your discussion and would like to add the following.

invoice-date=account-date  world wide standard
delivery-date=account-date   world wide standard
tax-date=invoice-date=account-date        many countries standard, in some countries deviations possible: decision local accountant
invoice number free    many countries accepted, different rules for invoice numbers in different countries 

So my request to Tryton is to delete the duty to yearly replace the invoice number sequence.

If we in 2016 want to make an invoice with a new invoice number but 27 December 2015  as invoice date, then that must be possible.

Hope ...

Thanks,

Pieter.

On Thursday, December 24, 2015 at 3:10:07 PM UTC+1, Cédric Krier wrote:

Hi,

Following the previous discussions about the invoice sequence and the
fiscal year, I have started a feature request to improve the situation
and manage more cases.

https://bugs.tryton.org/issue5205

Please comment if the proposal could be in conflict with your local
usage.

Thanks,

[Cédric Krier]

On 2016-05-02 14:07, pgm.l...@gmail.com wrote:
> Hi Tryton fans,
>
> After many years accountancy and even more years ict, I'm exploring Tryton
> as a new challenge. Like it very much. The only disappointment for me until
> now was the duty to make new invoice sequences, every year ...
> I saw your discussion and would like to add the following.
>
> invoice-date=account-date world wide standard
> delivery-date=account-date world wide standard
> tax-date=invoice-date=account-date many countries standard, in some
> countries deviations possible: decision local accountant
> invoice number free many countries accepted, different rules for invoice
> numbers in different countries

I'm not sure to understand this list.

> So my request to Tryton is to delete the duty to yearly replace the invoice
> number sequence.
>
> If we in 2016 want to make an invoice with a new invoice number but 27
> December 2015 as invoice date, then that must be possible.

This is exactly what the issue5205 is about.


PS: Please don't top-post on this mailing list, see
http://groups.tryton.org/netiquette

[pgm.l...@gmail.com]

Cédric, made the list because there was a discussion about this.

I'm afraid that Issue5205 still does not accept the freedom that many countries have with invoice dates and numbers. In your mail of 24-12-2015 you write:

"...to ensure that the invoice date not before any invoice dates numbered with the same sequence ..."

But maybe I misunderstand your text ... I hope ... ...

Pieter   

[Cédric Krier]

On 2016-05-03 02:25, pgm.l...@gmail.com wrote:
> Cédric, made the list because there was a discussion about this.

I mean I can not understand/read what it means. The formatting is
strange. Please elaborate it.

> I'm afraid that Issue5205 still does not accept the freedom that many
> countries have with invoice dates and numbers. In your mail of 24-12-2015
> you write:
>
> "...to ensure that the invoice date not before any invoice dates numbered with the same sequence ..."
>
> But maybe I misunderstand your text ... I hope ... ...

This means that invoice number must follow a increasing sequence number
when ordered by invoice date.

Could you name at least one country where numbering invoice should not
follow at least this rule?


PS: Please don't top-post on this mailing list if you want your future
posts not be moderated, see http://groups.tryton.org/netiquette

[pgm.l...@gmail.com]

On Tuesday, May 3, 2016 at 12:00:04 PM UTC+2, Cédric Krier wrote:

On 2016-05-03 02:25, pgm.l...@gmail.com wrote:
> Cédric, made the list because there was a discussion about this.

I mean I can not understand/read what it means. The formatting is
strange. Please elaborate it.

Cédric, just don't like discussions about the accounting date. For
> delivery its the delivery date, for the invoice its the invoice date.

 

> I'm afraid that Issue5205 still does not accept the freedom that many
> countries have with invoice dates and numbers. In your mail of 24-12-2015
> you write:
>
> "...to ensure that the invoice date not before any invoice dates numbered with the same sequence ..."
>
> But maybe I misunderstand your text ... I hope ... ...

This means that invoice number must follow a increasing sequence number
when ordered by invoice date.

For the sequence, its right that a new invoice gets the increasing sequence
> number. Of course.
> But .... this has no relation with any date ...
> The number of a new invoice is always the last invoice number +1, but
> sometime the date of the new invoice is before the last invoice date.

 

Could you name at least one country where numbering invoice should not
follow at least this rule?

Unfortunately I still don't know your "when ordered by invoice date". Sorry.

[Cédric Krier]

On 2016-05-03 05:49, pgm.l...@gmail.com wrote:
>
>
> On Tuesday, May 3, 2016 at 12:00:04 PM UTC+2, Cédric Krier wrote:
> >
> > On 2016-05-03 02:25, pgm.l...@gmail.com <javascript:> wrote:
> > > Cédric, made the list because there was a discussion about this.
> >
> > I mean I can not understand/read what it means. The formatting is
> > strange. Please elaborate it.
> > Cédric, just don't like discussions about the accounting date. For
> > > delivery its the delivery date, for the invoice its the invoice date.

I still don't understand this answer.

> > > I'm afraid that Issue5205 still does not accept the freedom that many
> > > countries have with invoice dates and numbers. In your mail of
> > 24-12-2015
> > > you write:
> > >
> > > "...to ensure that the invoice date not before any invoice dates
> > numbered with the same sequence ..."
> > >
> > > But maybe I misunderstand your text ... I hope ... ...
> >
> > This means that invoice number must follow a increasing sequence number
> > when ordered by invoice date.
> > For the sequence, its right that a new invoice gets the increasing sequence
> > > number. Of course.
> > > But .... this has no relation with any date ...
> > > The number of a new invoice is always the last invoice number +1, but
> > > sometime the date of the new invoice is before the last invoice date.

I don't think this is allowed in any country. If you know one country
where this behaviour is allowed please share.

> > Could you name at least one country where numbering invoice should not
> > follow at least this rule?
> > Unfortunately I still don't know your "when ordered by invoice date".
> > Sorry.

Usually the rules of invoice numbering in countries is like this:

2015-12-20: INV-0018
2015-12-21: INV-0019
2015-12-22: INV-0020

2016-01-02: INV-0001
2016-01-03: INV-0002

even if INV-0002 was created before INV-0020
This means that if you look at the generated invoice over one fiscal
year ordered by invoice date, you must see only increasing and
continuous numbering.

issue5205 is about not resetting the sequence so we will have:

2015-12-20: INV-0018
2015-12-21: INV-0019
2015-12-22: INV-0020

2016-01-02: INV-0021
2016-01-03: INV-0022

But we can not allow to do this:

2015-12-20: INV-0018
2015-12-21: INV-0019
2015-12-22: INV-0022

2016-01-02: INV-0020
2016-01-03: INV-0021

Because if there is a fiscal control for the year 2015, the controller
can not know if the hole between INV-0019 and INV-0022 is because there
are invoices on another fiscal year or if it is a tax fraud by hiding
invoices.

Note that I'm talking about the accounting date which is most of the
time the same as the invoice date, except usually during the period of
fiscal year change.

[Korbinian Preisler]

Are you really talking about the accounting date here? In issue5205 you
are talking about the invoice date.

If you are talking about the accounting date the planned constraint is
not a good idea as you would not be able to create an invoice for the
year 2015 if you share the invoice sequence with 2016 and you already
created an invoice for 2016.

If you do a monthly invoicing of services the invoice date will differ
from the accounting date every month as the invoice date will be a day
of the following month and the accounting date will be the last day of
the month when the services have been done.

[Cédric Krier]

On 2016-05-03 16:54, 'Korbinian Preisler' via tryton wrote:
> On 03.05.2016 16:00, Cédric Krier wrote:
> > Note that I'm talking about the accounting date which is most of the
> > time the same as the invoice date, except usually during the period of
> > fiscal year change.
> >
> Are you really talking about the accounting date here? In issue5205 you
> are talking about the invoice date.

Yes, it is a shortcut because the accounting date is set to invoice date
if not manually set. In the code, it is the accounting date that is used
to select which sequence to use.

> If you are talking about the accounting date the planned constraint is
> not a good idea as you would not be able to create an invoice for the
> year 2015 if you share the invoice sequence with 2016 and you already
> created an invoice for 2016.

This is exactly the purpose of the change. User can reuse the same
sequence over two fiscal year only if they invoice in the right order.

[pgm.l...@gmail.com]

Very clean explanation Cédri. Thanks!!!

In these countries I have the possibility to create 2015-12-22: INV-0020
in 2016, after INV-0002.

 

 

issue5205 is about not resetting the sequence so we will have:

    2015-12-20: INV-0018
    2015-12-21: INV-0019
    2015-12-22: INV-0020

    2016-01-02: INV-0021
    2016-01-03: INV-0022

But we can not allow to do this:

    2015-12-20: INV-0018
    2015-12-21: INV-0019
    2015-12-22: INV-0022

    2016-01-02: INV-0020
    2016-01-03: INV-0021

In the Netherlands I created 2015-12-22: INV-0022 in 2016, after creating 2016-01-03: INV-0021. Did it in Exact, the largest financial application in this country.
Within the discussion Vincent Bastos wrote: ... or my part ( Australia ), the sequence is not important. As you can see in the links below, the ATO ( Australian Taxation Office ) does not require an invoice to have a number :)... we are pretty easy going down under. ...
At least the Netherlands and Australia don't have rules for numbering the invoices.

 

Because if there is a fiscal control for the year 2015, the controller
can not know if the hole between INV-0019 and INV-0022 is because there
are invoices on another fiscal year or if it is a tax fraud by hiding
invoices.

In the view of invoices with invoice number as order, the controller can see, that there are no missing numbers. No fraud.

Note that I'm talking about the accounting date which is most of the
time the same as the invoice date, except usually during the period of
fiscal year change.

I don't understand that the invoice date can be different from the accounting date when the year changes ...

[pgm.l...@gmail.com]

Very clean explanation Cédri. Thanks!!!

In these countries I have the possibility to create 2015-12-22: INV-0020
in 2016, after INV-0002.

 

 

issue5205 is about not resetting the sequence so we will have:

    2015-12-20: INV-0018
    2015-12-21: INV-0019
    2015-12-22: INV-0020

    2016-01-02: INV-0021
    2016-01-03: INV-0022

But we can not allow to do this:

    2015-12-20: INV-0018
    2015-12-21: INV-0019
    2015-12-22: INV-0022

    2016-01-02: INV-0020
    2016-01-03: INV-0021

In the Netherlands I created 2015-12-22: INV-0022 in 2016, after creating 2016-01-03: INV-0021. Did it in Exact, the largest financial application in this country.
Within the discussion Vincent Bastos wrote: ... or my part ( Australia ), the sequence is not important. As you can see in the links below, the ATO ( Australian Taxation Office ) does not require an invoice to have a number :)... we are pretty easy going down under. ...
At least the Netherlands and Australia don't have rules for numbering the invoices.

 

Because if there is a fiscal control for the year 2015, the controller

can not know if the hole between INV-0019 and INV-0022 is because there
are invoices on another fiscal year or if it is a tax fraud by hiding
invoices.

In the view of invoices with invoice number as order, the controller can see, that there are no missing numbers. No fraud.

Note that I'm talking about the accounting date which is most of the
time the same as the invoice date, except usually during the period of
fiscal year change.

I don't understand that the invoice date can be different from the accounting date when the year changes ...

[Cédric Krier]

In which countries???

> > issue5205 is about not resetting the sequence so we will have:
> >
> > 2015-12-20: INV-0018
> > 2015-12-21: INV-0019
> > 2015-12-22: INV-0020
> >
> > 2016-01-02: INV-0021
> > 2016-01-03: INV-0022
> >
> > But we can not allow to do this:
> >
> > 2015-12-20: INV-0018
> > 2015-12-21: INV-0019
> > 2015-12-22: INV-0022
> >
> > 2016-01-02: INV-0020
> > 2016-01-03: INV-0021
> >
> > In the Netherlands I created 2015-12-22: INV-0022 in 2016, after creating
> 2016-01-03: INV-0021. Did it in Exact, the largest financial application in
> this country.
> Within the discussion Vincent Bastos wrote: ... or my part ( Australia ),
> the sequence is not important. As you can see in the links below, the ATO (
> Australian Taxation Office ) does not require an invoice to have a number
> :)... we are pretty easy going down under. ...
> At least the Netherlands and Australia don't have rules for numbering the
> invoices.

I can understand that Australia doesn't care about invoice numbering
because they doesn't have VAT. But in Netherlands, I have some doubt, it
is not because a software allow to do it that it is the truth. By the
way, are you sure that the accounting date is really in the past?

> > Because if there is a fiscal control for the year 2015, the controller
> > can not know if the hole between INV-0019 and INV-0022 is because there
> > are invoices on another fiscal year or if it is a tax fraud by hiding
> > invoices.
> >
> > In the view of invoices with invoice number as order, the controller can
> see, that there are no missing numbers. No fraud.

How can he see the invoice for the next fiscal year when he is verifying
the current fiscal year?

> Note that I'm talking about the accounting date which is most of the
> > time the same as the invoice date, except usually during the period of
> > fiscal year change.
> >
>
> I don't understand that the invoice date can be different from the
> accounting date when the year changes ...

Korbinian answered

[Vincent Bastos]

Hey Cedric,

I can understand that Australia doesn't care about invoice numbering
because they doesn't have VAT. But in Netherlands, I have some doubt, it
is not because a software allow to do it that it is the truth. By the
way, are you sure that the accounting date is really in the past?

Just thought I would point out that Australia does have VAT - it is just called GST. But maybe you were pointing out the fact that some businesses are allowed to operate without collecting GST.

[Cédric Krier]

Indeed, my bad. But in Europe the invoice number is rule quiet strictly:
https://en.wikipedia.org/wiki/Invoice#Invoice
Also it seems that Australian has a very specific definition as it has a
specific paragraph.
Anyway, I think it is better to conform to the majority as far as it is
not against the rule of any other countries.

[pgm.l...@gmail.com]

Hi Vincent,

This reply is also for Cedric but I don't know how to reply his answer from 5/5. This is because I am more an accountant than a ict developer and that's also the reason why I was a bit disappointed to the invoice sequences in Tryton.

In my opinion their cannot be much discussion.
Accountancy principles are in the big lines worldwide the same. Not much discussions.
The invoice date is the date that is written on the invoice, the invoice-date. It is a dependency of all rights and obligations of the invoice.
The account-date is a mechanism for ict developers to put all bookings in the right statements period, mostly month and year.

When a new year is started, many companies make invoices for deliveries in the previous year. Some of these invoices have the invoice date in the new year, some in the previous year.
In the financial applications that I know, every year has a starting invoice number, as first invoice number for that year, thats much larger than the previous year. E.g 2014 10000, 2015 20000, 2016 30000 etc. The user can change these first numbers per year, some times must make them.
Making an invoice at 28 February 2016 with 31 December 2015 as invoice date will get the next free number of 2015 e.g. 20446.
Making an invoice at 28 February 2016 with 28 February 2016 as invoice date will get the next free number of 2016 e.g. 30098.
So I never heard any problem with invoice numbers and invoice dates.

Apparently there can be a problem when we want to make an invoice in/for a period that is already locked and our controller or accountant accepts no unlock because that period has already definitive statements. In that case he himself has to say how to solve this problem. Maybe the account date must be changed to a date in this year.

Pieter

[Cédric Krier]

On 2016-05-07 08:28, pgm.l...@gmail.com wrote:
> When a new year is started, many companies make invoices for deliveries in
> the previous year. Some of these invoices have the invoice date in the new
> year, some in the previous year.

This is where we don't agree. It is the accounting date that can be in
the previous year because the payment term are base on the invoice date,
you can not request from your customer to pay you starting from a date
before you actually send him the invoice.

So the following is exactly what Tryton does if you just replace invoice
date by accounting date.

> In the financial applications that I know, every year has a starting
> invoice number, as first invoice number for that year, thats much larger
> than the previous year. E.g 2014 10000, 2015 20000, 2016 30000 etc. The
> user can change these first numbers per year, some times must make them.
> Making an invoice at 28 February 2016 with 31 December 2015 as invoice date
> will get the next free number of 2015 e.g. 20446.
> Making an invoice at 28 February 2016 with 28 February 2016 as invoice date
> will get the next free number of 2016 e.g. 30098.
> So I never heard any problem with invoice numbers and invoice dates.

[pgm.l...@gmail.com]

On Saturday, May 7, 2016 at 6:35:04 PM UTC+2, Cédric Krier wrote:

On 2016-05-07 08:28, pgm.l...@gmail.com wrote:
> When a new year is started, many companies make invoices for deliveries in
> the previous year. Some of these invoices have the invoice date in the new
> year, some in the previous year.

This is where we don't agree. It is the accounting date that can be in
the previous year

Yes, the accounting date can be in the previous year. Because many dependent things of it, always accounting-date=invoice-date

 
because the payment term are base on the invoice date,

you can not request from your customer to pay you starting from a date
before you actually send him the invoice.

The requested-payment-date is only one of the dependencies, the invoice-date has.
Making invoices with an invoice date before "today", easily can be managed in the system with e.g.:
- initiate a warning on the screen to the user who is doing this
- generate a requested-payment-date of "today"+ e.g. 30 days if the invoice-date < "today"
- always give the possibility to the user to change the requested-payment-date (e.g. generated as invoice-date + 30 days) to another date.

 

So the following is exactly what Tryton does if you just replace invoice
date by accounting date.

> In the financial applications that I know, every year has a starting
> invoice number, as first invoice number for that year, thats much larger
> than the previous year. E.g 2014 10000, 2015 20000, 2016 30000 etc. The
> user can change these first numbers per year, some times must make them.
> Making an invoice at 28 February 2016 with 31 December 2015 as invoice date
> will get the next free number of 2015 e.g. 20446.
> Making an invoice at 28 February 2016 with 28 February 2016 as invoice date
> will get the next free number of 2016 e.g. 30098.
> So I never heard any problem with invoice numbers and invoice dates.

Very nice if Tryton does it. But without any replacement of the invoice-date that the company uses.

Pieter