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:
The interesting part should be
(4) Eine Rechnung muss folgende Angaben enthalten:
<…>
- eine fortlaufende Nummer mit einer oder mehreren Zahlenreihen, die zur Identifizierung der Rechnung vom Rechnungsaussteller einmalig vergeben wird (Rechnungsnummer),
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.
OK, quick test in the demo DB, post an invoice with invoice and accounting date for today, then try to post an invoice for the first of Jan:
Consequence: Your statement is plain wrong. With this setup, Tryton cant cope with real world requirements, as ‘anyone actually using Tryton knows about’
In Spanish case the accounting date would be 1 January and invoice date 31 January (or later until 16 February).
I’m wondering what would be an helpful error message for you?
Wrong Tryton works correctly.
Nobody has shown any proof that people can number invoices without following a sequence.
And this works correctly with Tryton.
You can also post an invoice with the invoice date on 31 December as it will be a different sequence.
No it doesn’t as we have posted invoices with accounting date greater than 1 January.
Retrieving the origin of this thread … the accounting date of invoice taxes must be the moment the goods are delivered (this is called “momento del devengo” o “devengo del impuesto”). But invoice can be issued until 15th of next month.
This is described in section " Cómo se devenga el IVA según el artículo 75 de LIVA" of this article.
So if we limit the invoice sequence by accounting date, users cannot post an invoice with invoice_date 10Feb (assume this is today) and accounting_date 20Jan because they have post another invoices with accounting date greater than 20Jan.
I understand the usual thing in B2C is invoice_date=accounting_date but in certain B2B sectors this is not the case.
OK so I think we could relax the constraint by searching for prior invoice sequence usage based only on the invoice date and using the invoice date of the numbered invoice. But we must still use the accounting date to get and generate the number.
Such change could not be back-ported but for me business having such constraint should use a sequence per period and use the last day of the period as accounting date. The exact date is not really important for tax report as long as it is on the right period.
Why? Sales invoice is first of all related to the sales process. Then this is posted into accounting is a different story
As already explained earlier in this thread the proposed solution is not enough for Germany. While there are very detailed requirements for the dates on invoices (invoice date, date of supply and service) there is no combined constraint on date and numbers for the invoice number.
Just some more additional links
https://rechnungen-muster.de/rechnungsnummern
Instead of guessing and believing I would prefer a solution in Tryton based on evidence.
