Allow different invoice sequences on the same period


The Spanish Invoicing Normative allows to define diferent invoice sequences for the same period in some special cases. This is included in the Article 6, section 1a. This paragraph says:

Se podrán expedir facturas mediante series separadas cuando existan razones que lo justifiquen y, entre otros supuestos, cuando el obligado a su expedición cuente con varios establecimientos desde los que efectúe sus operaciones y cuando el obligado a su expedición realice operaciones de distinta naturaleza

Which translates to:

Invoices with diferent series can be used when exist a reason that justifies it. Among other assumptiens they can be used when there are several establishments where the operations are done or when the issuer realizes operations of diferent naturity.

Note that in spanish we use the term “Serie” to refer to a “Invoice Numberin”. We normally use a prefix or a sufix to diferentiate each serie.


I propose to use the Journal (account.journal model) to allow tryton users to diferentiate the naturity of the operation or the establishment where the operation is done. Then just adding the Journal on the Invoice Sequence criteria will easly allow to use diferent number sequences for each operation.


For me, this should not be in standard, we should just allow to easily make such setup.
As the description said it is a practical option to ease some management. But this is mainly when there is no central numbering tools like Tryton.
So we should not advertise for the wrong practice by default, nor complex the UI.

Sorry but I do not understand what do you mean with dthis sentence. Coudl you please clarify?

Which practise is wrong with the described behaviour?

I’m not sure if adding an optional field to a form means having a complex UI

I mean that the existence of using different numbering for invoices based on journal come from manual booking when it was not physically possible to synchronize the numbering between different services.
But this constraints are gone with the information technology.

Having different numbering because it is no more needed.

Yes it does like any option. The more options there are, the more complicate the interface is for the user. We must reduce the choices as much as possible by default.
That’s why I said we should give the ability to make such customization but we should not added just because we can. We must add it only if it is a real added value for the usage and in this case I really do not think it adds anything.

Totally agree so… What is, in example, the natural way in Tryton to show the sales by office?

I mean not from the accounting point of view but only of sales (knowledge about quotes, sales)… by distinct offices (for example in a distinct geographic location) of the same company (only one chart of accounts).


As there is no such definition of “office”, there is no way.

For sure.

Just to ensure myself.

Do you understand me when I’ve tried to explain the, of course a little abstract, concept of office?

There are several reasons why a company may want to have different numbering. The “several establishments” one is just one of them.

Another case we’ve frequently seen is that a company emits invoices at fixed days for several of their customers (for example on the 15th, or the last day of the month, etc). Those invoices are usually created one or two (or more) days later (on the 16th/17th, etc), but while those invoices are not yet created the company must create an invoice on the 16th, because some goods must be delivered (usually for export).

In that case, given that the invoice numbers must be correlated with dates, they have one invoice sequence for export invoices, and another one for the national invoices.

We have other similar cases, not related to export but basically the situation is the same: for some reason you cannot create an invoice of some type of customers on the date you’ll put the invoice date to, and need to create other invoices with later dates.

Not sure I explained correctly…

Also, the law forces the use of a distinctive invoice number in case of «Procedimientos administrativos y judiciales de ejecución forzosa» which would translate to «Administrative and judicial procedures of forced execution». Although I have to say I’ve never seen such requirement.

Well that’s just cheating your customer with payment terms.

I totally agree with @albert.
Let me show another real use cases:
In some industries (I’ll talk about agricultural industry on EU) is usually that customer invoices are posted 2 weeks later than product shipment. But some specific customers demand posted invoicing at shipment moment.
Cheat customer with payment terms is not an option due to the invoice conditions are “imposed” by customer, even prices and product quantities, according to quality criteria, market situation, etc.

So managing this situations with an unique numbering and correlated date restriction is not possible.

Another use case, the more rare one we found, is a customer that sends grapes from Spain to South Africa. A commission agent needs the posted invoice a week before product shipment in order to submit the container paperwork on time.

in France, we have a mecanism called “auto-facturation” or “mandat de facturation”. it looks like what @sergyo describe for agricultural industry. a customer or an external party could generate the invoice.

BOI-TVA-DECLA-30-20-20-10-20131018 §120

Lorsque les factures afférentes aux opérations réalisées par un assujetti sont matériellement établies par un mandataire (client ou tiers), la séquence de numérotation utilisée par ce mandataire, qui doit être chronologique et continue, doit être propre à l’assujetti concerné. Elles ne doivent donc pas s’insérer dans les séquences de factures que le mandataire émet pour son propre compte ou pour celui d’autres mandants.

also, French Fiscal Administration recognize the following use-cases for multi-sequences :

  • the existence of several invoicing sites for the same company;

  • the existence of several categories of customers for whom the invoicing rules are not identical (example: taxable persons or individuals);

  • the use by the same taxable person of several methods of issuing invoices making it difficult to use a single series: self-billing, invoicing on behalf of third parties, electronic invoicing, paper invoicing, etc.

This is false. This is just because people think that the invoice date they receive should match the period when the book it. But this is completely wrong, the booking period should be the period the service or goods were delivered.

This is again wrong. You can probably give a pro forma or an advance payment invoice. And even just the delivery note if it has the prices is often enough.

Then the company does not have to generate an invoice. Or it is a new kind which should not have any number at all. I think this is another case and it should not be solved by using another sequence.

Those are all optional and not required by default.

My two cents. In our country all monthly payments (rent, electricity, phone, security, cleaning, fuel etc) are invoiced (dated) the last day of month. In reality the monthly invoice can’t be writen on this day because the client can use the service till last second of the last day (to call, to fill fuel etc) and service supplier can get all results only the next day. But usually the invoice depends on the others monthly invoices or require to make some operations. For example, the office rent service must get invoices from cleaners, security, phone companies, must check gas and electricity counters etc. In reality all monthly invoices are writing till end of the first week but dated the last day of previous month. If there isn’t an alternative sequence, the supplier can’t write any invoice on this week.

Please remember what I already said:

So I do not think we need more example of special use case which may require such feature. We already have the design to customize and solve such cases.
The discussion is about having it in base module or not.

Now I think someone may make a dedicated module. But I think it will need probably more features than adding a field. I guess it will require tools to ease the management of all those sequences.

I doubt this as, at least in the cases we come across, the payment terms are typically something based upon something like the end of the month (e.g. end of month + xx days or xx days + end of month) or similar.
Most professionals seek solutions that are reasonable.

The classification of all the accounting facts in journals is an ERP feature and should not be influenced by local regulations.
So, as I read above, I put in a journal something that, for my business has a certain “nature”, is “similar”.
Then come the local tax rules, you have sometimes some “tax journal”(that you usually establish consistently to your journals) and the sequences, in Italy for example you are even more free with your sequences within your “tax” journals.
I would keep the journals as key erp accounting functionality, and, possibly, increase the options for the sequences.