Prevent using same sequence on earlier customer invoice: which date to use?

I do not see the point but more over for me it is wrong. So please provide rational about the need.

The rational:
Spanish account requires correlation between numbering and “fecha expedición” (this is invoice_date) for customer invoices.
With the current implementation this is right when accounting_date is empty or equal to invoice_date. This is the most of the cases.

The needs:
Some companies want/need to declare and post taxes of invoices in the period in which goods were sent as the law allows a range of 15 days to do that.
So as an example they legally could post today:

  • Invoice X with invoice_date today and without accounting_date
  • a few minutes later Invoice X+1 with invoice_date today and accounting_date 30th November.

Sorry if it’s not clear but I can’t explain it better …

I have a huge doubt about this statement. For me it is a wrong interpretation because this can not guarantee a continuous numbering for all invoices over a single fiscal year (or tax period).
I can not find your statement in the invoice manual which seems to be just a re-transcription of the EU Directive 2001/115/EC.
For me it is clear that the series must be continuous inside a single fiscal year (or inside a single tax period if the period is clearly identified in the numbering).

As usual the Spanish accounting documentation is quite ambiguous and not very explicit.
But in that document they talk in many places about required invoice data:

  • correlated numbering and sequence.
  • issue date (“fecha de expedición”)
  • transaction date (“fecha de operación”) if differs from issue date. It is the delivery date of goods/services.
  • other data …

AFAIU this issue date is invoice_date in Tryton.
If we check de foundation sii module or thirdparty sii module we can find it as FechaExpedicionFacturaEmisor. The accounting date should be FechaRegContable and the transaction date should be FechaOperacion.

So summarizing:

  • the method get_next_number() should use invoice_date to get the sequence for customer invoices.
  • the method set_number() should use invoice_date for customer invoices to check later invoices.

I do not understand how you came to this conclusion.
I think I clearly showed that such change will make the invoice numbering inconsistent inside a single fiscal year (or period).
So for me you are wrongly interpreting the requirements.

How will you manage the SII declaration in this scenario?

The consistency is against issue date …
Anyway we have just queried to “agencia tributaria” about it.

PeriodoLiquidacion: { Ejercicio: 2021, Periodo: 12}
FechaExpedicionFacturaEmisor: 15/01/2022
FechaRegContable: 30/12/2021
FechaOperacion: 30/12/2021

[quote=“sergyo, post:19, topic:4840”]

As far as the invoice is sent for days before issuing it (19/01/2022) I won’t see any issue by sending the invoice in a past period.

hola:

disculpa una pregunta.

¿te refieres a la fecha de devengo para el iva? La cual se produce cuando se realiza la operación o bien la adquisición de la mercancía que no tiene porque coincidir cuando se factura.

hello:
excuse a question.
Do you mean the accrual date for the VAT? Which occurs when the operation is carried out or the acquisition of the merchandise that does not have to coincide when it is invoiced.

Si, la fecha de registro contable debe ser la fecha del devengo del impuesto y esta no tiene porque coincidir con la fecha de emisión de factura que puede ser igual o posterior

FYI my mistake I thought @roliver sent an email to “agencia tributaria” but seems there isn’t this contact mechanism. So we have to phone.

At the moment we are using a custom module that replace get_next_number () and set_number () methods as cannot be adapt for this purpose.

I did some research on the constraints for invoice sequences for Germany, here are my results. I found basically two legal texts applying to the topic:

  1. Umsatzsteuergesetz (UStG) § 14 Ausstellung von Rechnungen

The interesting part should be

(4) Eine Rechnung muss folgende Angaben enthalten:

<…>

  1. eine fortlaufende Nummer mit einer oder mehreren Zahlenreihen, die zur Identifizierung der Rechnung vom Rechnungsaussteller einmalig vergeben wird (Rechnungsnummer),
  1. Umsatzsteueranwendungserlass (UStAE 2010 14.5. (Zu § 14 UStG (§§ 31 bis 34 UStDV))

This decree is in principle the implementing regulation for the law in 1).

especially interesting in original language (I can provide translations by Google if it is not possible to use the discuss feature for parts of messages):

(10) 1Durch die fortlaufende Nummer (Rechnungsnummer) soll sichergestellt werden, dass die vom Unternehmer erstellte Rechnung einmalig ist. 2Bei der Erstellung der Rechnungsnummer ist es zulässig, eine oder mehrere Zahlen- oder Buchstabenreihen zu verwenden. 3Auch eine Kombination von Ziffern mit Buchstaben ist möglich. 4Eine lückenlose Abfolge der ausgestellten Rechnungsnummern ist nicht zwingend. 5Es ist auch zulässig, im Rahmen eines weltweiten Abrechnungssystems verschiedener, in unterschiedlichen Ländern angesiedelter Konzerngesellschaften nur einen fortlaufenden Nummernkreis zu verwenden.

(11) 1Bei der Erstellung der Rechnungsnummer bleibt es dem Rechnungsaussteller überlassen, wie viele und welche separaten Nummernkreise geschaffen werden, in denen eine Rechnungsnummer jeweils einmalig vergeben wird. 2Dabei sind Nummernkreise für zeitlich, geographisch oder organisatorisch abgegrenzte Bereiche zulässig, z. B. für Zeiträume (Monate, Wochen, Tage), verschiedene Filialen, Betriebsstätten einschließlich Organgesellschaften oder Bestandsobjekte. 3Die einzelnen Nummernkreise müssen dabei nicht zwingend lückenlos sein. 4Es muss jedoch gewährleistet sein (z. B. durch Vergabe einer bestimmten Klassifizierung für einen Nummernkreis), dass die jeweilige Rechnung leicht und eindeutig dem jeweiligen Nummernkreis zugeordnet werden kann und die Rechnungsnummer einmalig ist.

In summary this says that the purpose of the invoice sequence is to provide uniqueness. It even says that the sequence has not obligatory to be consecutively numbered. And most notably there is no constraint to follow invoice or accounting dates.

We (MBSolutions) try nevertheless to have consecutively numbered invoices. If an invoice sequence was not used (e.g. given back by a rollback) we document that gap to provide complete track to be on the safe side.

The actual constraint to forbid the usage of the same invoice sequence for earlier invoice dates thus doesn’t meet IMO the requirements for Germany. Of course I would like to hear from other german colleagues their view on the topic and how they handle it.

As Tryton aims to be a generic solution I propose to remove the constraint in the base module (account_invoice) and put it in localization modules where it applies. AFAIS this would at least serve the Spanish and German case.

I do not agree. This constraint applies to almost all countries and even for rare countries with relaxed constraints (which I really do not think Germany fall in) this is not a problem but a good practice to follow.

Apart from the problem at hand, what is considered best practice in Tryton to solve the following use case (happened really last year):

A company sent out invoices in December 2021 that after an audit of the tax adviser are considered illegal. The company says we will send out corrected invoices, but we will no more manage that during this year.
Note: The invoices have to be replaced with the same invoice date as the original invoices to be valid for the customers.

What is considered best practice in Tryton to solve the problem? Creating a separate period and sequence for each of those cases?

This can not be a requirement as the tax period can be closed etc.
The only valid requirement for the customer is that the due date is at least the same or later.

Do I understand you right that the current bookkeeping legislation in Germany can not be fulfilled with Tryton?

As a reference, in SAP you can book into the previous period (customizing setting)

I doubt that in SAP you can book in a previous closed period.

Knowing is better than believing (ddg helps in that case).
Even if it is in the same month, an invoice with an earlier date than current (or last posted invoice) is not possible in Tryton (this is what the thread is about).
So you cant fulfil german (and spanish) accounting requirements as it is now.

Thanks @yangoon for your time.

Indeed the constraint is not the problem but the consistency criteria (which date to use).
As there is no agreement probably by enabling a way to customize it would be enough …

I still do not believe it.

This is perfectly supported by Tryton. As anyone actually using Tryton knows about.

But we still do not have clear statement for Spanish accounting about your claimed requirement, nor counter argument about the consistency issue with your proposed workflow.