Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/TI-Sin-Problemas/erpnext_mexico_compliance/llms.txt

Use this file to discover all available pages before exploring further.

The SAT (Servicio de Administración Tributaria) publishes official catalogs — catálogos — that must be referenced in every CFDI document. ERPNext Mexico Compliance maps each of these catalogs to a Frappe DocType so they integrate naturally with ERPNext’s link fields, dropdown filters, and validation rules. Rather than hardcoding SAT codes in your configuration, you work with named records that carry both the official code and its Spanish description.

Available catalog DocTypes

DocTypeSAT Catalog (Spanish)Used In
SAT Tax RegimeRégimen fiscal SATCompany, Customer
SAT CFDI UseUso de CFDI SATCustomer, Sales Invoice
SAT Payment MethodForma de pago SATMode of Payment
SAT Payment OptionMétodo de pago SATSales Invoice, Subscription
SAT Product or Service KeyClave de producto/servicio SATItem, Sales Invoice Item, Sales Order Item
SAT UOM KeyClave de unidad de medida SATUOM
SAT Relationship TypeTipo de relación SATRelated Sales Invoices table
Cancellation ReasonMotivo de cancelación SATSales Invoice, Payment Entry

DocType structure

Most catalog DocTypes share a common set of core fields:
  • key — the official SAT code (e.g., 601 for a tax regime, G01 for a CFDI use, 01 for a payment method). This field is used as the document name and is enforced as unique.
  • description — the human-readable name in Spanish, exactly as published by the SAT (e.g., General de Ley Personas Morales).
  • enabled checkbox — all records default to enabled. Uncheck this flag to hide entries that are not applicable to your business without deleting them. Disabled entries are excluded from link field dropdowns.
  • key_name — a read-only computed field that combines the key and description for display in list views and link fields.
Some DocTypes carry additional fields specific to their catalog:
  • SAT UOM Key adds a uom_name field (the short unit name, e.g., KGM) alongside the longer description.
  • SAT CFDI Use adds a tax_regimes child table (DocType: SAT CFDI Use Tax Regime) listing which SAT Tax Regime codes are permitted to use that CFDI use code — this drives the CFDI Use filtering described below.
SAT Relationship Type differs from the other catalog DocTypes in one important way: its primary identifier field is named code (not key), and it does not include the key_name computed field. It shares the description and enabled fields with the rest of the catalogs, and adds a valid_from date field tracking when the SAT activated that relationship type code.

SAT CFDI Use and Tax Regime filtering

Not all CFDI use codes are valid for every tax regime. The SAT’s own catalog defines which combinations are permitted. ERPNext Mexico Compliance enforces this through the cfdi_use_query function, which is wired to the SAT CFDI Use link field on the Sales Invoice and Customer forms. When a customer is set on a Sales Invoice (or when editing a Customer record directly), cfdi_use_query reads the customer’s SAT Tax Regime and filters the SAT CFDI Use list to only show records whose tax_regimes child table includes that regime code. This prevents selecting a CFDI use combination that the SAT would reject at stamping time. If no customer is provided, all enabled CFDI use records are shown without regime filtering.

How catalogs are populated

Catalog DocTypes are not populated manually — they are maintained automatically by the app:
  • On installation / migration: running bench migrate triggers the after_migrate hook, which enqueues background jobs that download the latest SAT catalog data and upsert every record into the corresponding DocType. No manual data entry is required after a fresh installation.
  • Data source: all catalog data originates from the phpcfdi/resources-sat-catalogs project, which repackages the official SAT Excel files into a versioned SQLite database (catalogs.db.bz2). The app downloads the latest release automatically.
  • Manual refresh: catalog updates can also be triggered at any time from the Frappe console or via the CatalogManager Python class without waiting for a migration. See Updating Catalogs for the full procedure.

Build docs developers (and LLMs) love