Clientes
No hay /v1/customers. Un cliente se crea en la factura misma, mandando el objeto
customer en vez de un customer_id: una integración que
nunca abre el panel tiene que poder traer su propio receptor sin darlo de alta primero.
customer.id es el del registro que quedó guardado.
De ahí en adelante puedes mandar customer_id y ahorrarte los cuatro campos.
El objeto customer
- tax_id
- requerido
- El RFC. Lo normalizamos y verificamos su dígito antes de mandarlo al SAT.
- legal_name
- requerido
- La razón social tal como el SAT la tiene, sin el régimen de capital: "ACME" y no "ACME, S.A. de C.V.".
- tax_regime
- requerido
- Su régimen, del catálogo c_RegimenFiscal. Tiene que ser el que el SAT le tiene registrado.
- postal_code
- requerido
- El código postal de su domicilio fiscal, que el SAT compara contra su padrón.
- default_cfdi_use
- opcional
- El uso que suele darle. Se puede cambiar factura por factura.
- opcional
- A dónde mandarle el comprobante.
- tax_residency / foreign_tax_id
- opcional
- Para un receptor extranjero.
Un RFC que ya conocemos no se reescribe
Si mandas un customer cuyo RFC ya existe en tu cuenta, reusamos ese registro y
no lo actualizamos. Un nombre que llega en una llamada de facturación no es una instrucción para
corregir la razón social del cliente, y hacerlo cambiaría todos sus comprobantes futuros por un dedazo.
Para corregir de verdad los datos de un cliente, el panel: Clientes → el cliente → Editar.
El régimen decide el uso del CFDI
No todos los usos valen para todos los receptores: un régimen 605 no admite G03, y mandar esa combinación es
cfdi_use_not_allowed, el rechazo más común que hay. Lo validamos antes de llamar al PAC
contra la matriz del catálogo c_UsoCFDI, así que ese error llega sin costar timbre.