Qué se bloquea y qué se avisa
El SAT clasifica cada RFC de la lista con una situación. Timbrix actúa así:
Los RFC genéricos
XAXX010101000 (público en general) y XEXX010101000 (residente en el extranjero) nunca se consultan.
Se consulta en estos momentos:
- Timbrar una factura (
POST /invoices) y un complemento de pago (POST /invoices/payments): se revisa el RFC del receptor y, en producción, también el tuyo como emisor. - Crear un cliente (
POST /customers) y cambiar el RFC de un cliente (PUT /customers/{customerId}): se revisa el RFC nuevo. Si solo cambias otros datos, no se consulta.
CFDI que corrigen o complementan uno ya timbrado
Bloquear a un receptor definitivo es una política de Timbrix para que no emitas nuevos CFDI a ese RFC. Pero a veces necesitas corregir o completar uno que ya timbraste antes de que el SAT lo publicara. Por eso, si el receptor es definitivo y el CFDI está ligado a uno ya timbrado a ese mismo RFC, Timbrix lo timbra y responde con el avisoRFC_69B_DEFINITIVO:
- Nota de crédito (Egreso con
relatedInvoiceUuid) sobre una factura emitida a ese mismo RFC, en el mismo ambiente (sandbox o producción). - Sustitución (
relatedCfdiscon tipo04) de un CFDI emitido a ese mismo RFC, solo si ese CFDI no tiene ya otro sustituto vigente ni uno en proceso de timbrado. La excepción se usa una vez por CFDI original: un segundo sustituto del mismo original responde422. - Complemento de pago cuando todas las facturas que pagas se emitieron a ese mismo RFC.
422 RFC_IN_69B_LIST: la sustitución de un CFDI que ya tiene un sustituto vigente o en proceso de timbrado, la sustitución de un CFDI que a su vez sustituye a otro que sigue vigente (cancela primero el original de la cadena), y la nota de crédito sobre una factura de otro ambiente. Si el definitivo es tu propio RFC como emisor (en producción), se bloquea siempre.
Sandbox y producción
En sandbox no se revisa el RFC del emisor, porque ahí se usan RFC de prueba. El del receptor sí se revisa. En producción se revisan ambos.Ejemplo de bloqueo
Cuando el receptor es definitivo y el CFDI no corrige ni complementa uno ya timbrado a ese receptor, la API responde422 y no se timbra nada:
Ejemplo de aviso
Cuando el receptor es presunto, o es definitivo pero el CFDI corrige o complementa uno ya timbrado a ese receptor, la operación se completa y la respuesta incluyewarnings. El campo solo aparece si hay avisos:
Si reintentas una solicitud con la misma
idempotencyKey, recibes la respuesta original: no se vuelve a consultar la lista ni se agregan avisos nuevos.
La web muestra los mismos avisos y bloqueos. En la CLI, timbrix invoices create, timbrix invoices pay y timbrix customers create imprimen cada aviso en amarillo al terminar. En el SDK, la respuesta trae warnings y el bloqueo es un TimbrixApiError con code === "RFC_IN_69B_LIST".