Invoice Authorization Module

In the most countries of Latin America, to work with the accounting laws of the government, systems need to have an authorization to invoices and credit notes. I’m not sure if the laws in North America or Europe need to have it too.

The authorization need to have ranges(from_auth, to_auth), number of resolution, software provider, start date, end date and serie. The ranges can not be overlapped. If a serie is new for the resolution, the from_auth is 1. If the auth has been used, the from auth is the last to_auth from the authorization.

Also the authorization need to have the state of draft, active or finished.

If a system doesn’t count with a valid authorization for invoices or credit notes, the system can not post invoices or numerate it.

Also the invoice authorization should be used be the authorized company.

Integrate the authorization with fiscal years or maybe with account configuration and have methods to validate the invoice authorization in the invoices with type ‘out’.

I’m not sure if the module could be useful for all the tryton user or developers, but could be a great improvement for Latin American trytoners.

What is this range?

What is it?

What is the series?

I do not understand this sentence.

Here is an example of the authorizations

Number Date of Auth. Serie From Auth To Auth Start Date End Date Kind
2013-1-1-123 01/10/2013 A 1 10 28/10/2013 27/10/2015 invoice
2015-1-1-7789 15/10/2015 A 11 15 29/10/2015 27/10/2018 invoice
2017-1-1456 29/12/2018 B 1 5 29/10/2018 31/12/2019 credit note

In order to have an authorized ERP system and print invoices and credit notes with goverment authorization, the give you a document with the corresponding authorization number, and periodically check the generated documents and their validity.

This does not help. I still do not understand most of the fields.

I do not see why the system should be modified. The company just has to make the proper requests.

The authorization document given by the goverment has the follow information:
The number, is must be unique.
Date of Auth
Start Date
End Date.
Kind: can be for invoice or for credit note
Serie: A, B, X and so on.

The below image is an example of the generated invoice, en the footer has the info of the authorization.

The account.invoice model need a field to register the authorization used to generate the number and serie of the invoice.

The number of the invoice is assigned from the authorization sequence, instead of the used in fiscalyear sequence.

Makes sense to me.

Why do we care?

Why is it important?

How are those dates managed?

What is it?


I do not understand what are the “From auth”, “To auth”? I thought it was the possible invoice number (even if it sounds fool to limit the number of invoice for a period). But I see the invoice does not have a number between those value.

I’m sorry to ask tones of questions but to be able to take any decision we must have a clear and complete description of the requirements.
Also I would like to hear from other countries with similar needs.

Because is part of the law in the countries, they ask for the authorization number in every invoice.

Because the invoice authorization need to be renew in determinate period.

They are defined by the agents of the goverments when they give the authorization.

If a company has many shops or stores, they give to each one a serie, A, B, C, defined arbitrary by them arbitrarily.

They assign the number of the invoice or credit note based on these document. The goverment has a record of each authorization and validate it again its database periodically, and after compare the invoices with his own records. I don’t know why they ask for these documents, but is the law and they review the system against his requirements.

The From Auth and To Auth define the numbers of invoices that can be generated. I updated the invoice because the last was wrong.

You have reason about that. Let me know if you have more questions.

The countries with similar needs are Guatemala, México, Uruguay, Colombia, Ecuador, Chile, República Dominicana, and others. BTW, some of the countries has an especial process to validate each invoice. But the invoice authorization is similar.

But why do we care that it is unique?

Could it not be linked to the fiscal period? This will be very strange to be random.

So the company has no choice on how they manage their business?
The state imposes who the numbering is dispatch between shops?

How do they do that? Do you have to ask each time you do an invoice what is the number?

But what happens if you reach the end? You stop your business?

I tried to find references about that. I can not find. Please provide reference about this.

Authorization can not have duplicates in the system by company. It is a policy of the goverment.

Yes, it is random. You could have more than one authorization by year.

The company does not have choice with the authorization serie. The company may decide how many invoices they will need, depending on their needs. If they need more, the do a request for a new authorization.

No. it is based in the authorization control, with a sequence.

The system need to have an alert when consuming the 70%, 80% and 90% of the invoices, or when the authorization is going to end, 30 days before. If the business does not have an authorization valid, the can not post invoices.

Below are some links to find references to it. One of Colombia and one from Guatemala.

The last link below list the countries and their polices to electronic invoices.

This is an useless paper work requirement that countries like Colombia has to do. It does not add any value it all, I use the header of company to manage resolution parameters each time it’s needed.

By the way , Colombia , Perú and puerto rico are implementing electronic invoice using UBL. 2.1, the authorizarion (resolution) data will come using a webservice request.

1 Like

These could work on some countires, only change the header. In others no.

Yes, the most part of the countries listed above will migrate, but will still continue with both system almost in the future 3 years. If the traditional authorization is useless, maybe is better to work with UBL like you mention, of course, it will have much more application in the most part of countries listed.

Yo pudo explicar la situación de Perú,
Las autorizaciones con rangos de números y fechas y números de resoluciones para emitir facturas, se hacen cada vez menos, es en los casos de facturas manuales sobre formatos pre impresos.
Actualmente se está masificado la factura electrónica, usando el estándar UBL 2.1. Es así que venimos usando Tryton en el Perú. El chequeo de números duplicados está en el web services (servidor) de la entidad tributaria llamada SUNAT. El sistema no te acepta 2 facturas con el mismo número y serie. Por tanto al menos para Perú no es necesario ningún módulo con esas características.

1 Like

So it looks like we should focus on having a edocument_ubl with at least the invoice document. And for each country like Peru: account_pe_sunat to communicate the UBL invoice.

1 Like