OCA / l10n-mexico

Mexican Localization.
GNU Affero General Public License v3.0
3 stars 19 forks source link

CFDI 4.0 Catalogs #29

Open azubieta opened 1 year ago

azubieta commented 1 year ago

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:

azubieta commented 1 year ago

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 commented 1 year ago

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

agb80 commented 1 year ago

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 commented 1 year ago

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 _cExportacion 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 commented 1 year ago

@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 commented 1 year ago

@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