CFDI 4.0 Catalogs

[azubieta]

The Mexican tax authority (SAT) defines a set of catalogs to be used when issuing a CFDI. Those catalogs need to be accessible to the users in order to properly fill the CFDI documents.

The catalogs are published by the SAT as part of the Anexo 20 using xls format.

Some of the catalogs can be considered as extensions of existent Odoo modules others don't. Here is a list of the existent catalogs and their Odoo counterpart if any:

• c_FormaPago ( account.payment.method ? )
• c_Moneda (res.currency)
• c_TipoDeComprobante
• c_Exportacion
• c_MetodoPago
• c_CodigoPostal
• c_Periodicidad
• c_Meses
• c_TipoRelacion
• c_RegimenFiscal
• c_Pais (res.country)
• c_UsoCFDI
• c_ClaveProdServ (product.template)
• c_ClaveUnidad
• c_ObjetoImp
• c_Impuesto (account.tax)
• c_TipoFactor
• c_TasaOCuota
• c_Aduana
• c_PatenteAduanal
• c_NumPedimentoAduana
• C_Colonia
• c_Estado ( res.country.state )
• C_Localidad
• C_Municipio

[azubieta]

We aim to align the SAT catalogs with the existent Odoo modules. It would be great if you could help us identify where this is possible.

[azubieta]

WIP: https://github.com/AugeTec/l10n-mexico/tree/base_cfdi/base_cfdi

[agb80]

c_TipoDeComprobante

Do we really need it? I'ts a really small catalogue that if we would like to create must be mapped to odoo objects like this:

c_TipoDeComprobante	Descripción	Odoo object	Domain value
I	Ingreso	account.move	[('move_type', '=', 'out_invoice')]
E	Egreso	account.move	[('move_type', '=', 'out_refund')]
T	Traslado	stock.picking	N/A
N	Nómina	hr.payslip	N/A
P	Pago	account.payment	[('partner_type', '=', 'customer'), ('is_internal_transfer', '=', False)]

[agb80]

What is the approach you are considering for CFDI fill? Are you going to display every single field for user to fill it?

In our case we opt for make some computed fields based on other fields to make easy for the user to fill the information, for example in the case of c_Exportacion catalogue that is used for fill field Exportacion on Income CFDI XML we made a computation if we select to use Foreing Trade complement and customer country is different to Mexico then we use 02 otherwise use 01.

Similar approach we have being using for other fields and catalogues, please let me know about the approach you are planing to use to continue commenting about the rest of catalogues.

[azubieta]

@agb80 I'm thinking on having a base model which holds the whole document following the CFDI specification which define a base structure and a set of extensions (complementos). The document will be included as a field at account.move, stock.picking, hr.payroll, and account.payment (which match your suggestion).

I would like to create a whole new model because the CFDI specification doesn't maps 1 to 1 with existent Odoo models and use cases and in some scenarios they may require some additional information.

Regarding to the c_TipoDeComprobante, I agree with you, it could be a select field of the base CFDI document.

[agb80]

@agb80 I'm thinking on having a base model which holds the whole document following the CFDI specification which define a base structure and a set of extensions (complementos). The document will be included as a field at account.move, stock.picking, hr.payroll, and account.payment (which match your suggestion).

I would like to create a whole new model because the CFDI specification doesn't maps 1 to 1 with existent Odoo models and use cases and in some scenarios they may require some additional information.

Agree with you in create a special object to hold CFDI information, this object also could have a specific machinery to create XML, sing and send to PAC. We have being created a similar object here: https://gitlab.openpyme.mx/l10n_mx/facturacion/-/blob/master/l10n_mx_ir_attachment_facturae/models/ir_attachment_facturae.py

Regarding to the c_TipoDeComprobante, I agree with you, it could be a select field of the base CFDI document.

Ok, let use as a select field