Cómo avanza un ticket desde que se sube hasta que se factura o se rechaza, y en qué se diferencian el estatus (ticketStatusId) y el código (ticketCodeId).
Dirigido a: administradores y equipos técnicos de las empresas cliente que quieren interpretar el avance de sus tickets en la web app business, la API o los webhooks. Los términos se definen en Conceptos.
La lista completa de estatus y códigos del ticket (id, nombre y tipo: inicial, intermedio o final) está en Catálogos.
Estatus y código: la diferencia
Cada ticket tiene dos datos que describen su situación. Se complementan, pero responden preguntas distintas:
| Estatus del ticket | Código del ticket | |
|---|---|---|
| Pregunta que responde | ¿En qué etapa del proceso está? | ¿Cuál fue el resultado, o por qué no se pudo facturar? |
| Campo en la API | ticketStatusId / ticketStatus | ticketCodeId (catálogo GetTicketCodes) |
| Cuántos hay | 8 | 19 |
| Cuándo cambia | Cada vez que el ticket avanza de etapa. Cada cambio queda en el historial del ticket. | Solo cuando hay un resultado: al facturarse o al rechazarse. |
| Historial | Sí: se guarda cada cambio (es lo que ves en Seguimiento) y cada cambio genera webhooks. | No: solo se guarda el código vigente. |
| En la app Enterprise | El estatus de cada ticket (Facturado, Auto factura, Revisión manual…). | El motivo de rechazo que aparece en el detalle y en Reportes › Atención. |
| Mientras el ticket está en proceso | Cambia según la etapa. | Normalmente vale 1 (Creado): todavía no hay resultado. |
Regla práctica: usa el estatus para saber si el ticket ya terminó y el código para saber cómo terminó.
| Estatus | Código | Significa |
|---|---|---|
11 SIGNED | 2 Facturado | Fotofacturas generó la factura. |
11 SIGNED | 3 Facturado previamente | El ticket ya estaba facturado en el portal del comercio con el mismo RFC; se recuperó esa factura. |
10 UNSIGNABLE | 8 Ticket ilegible | No se facturó porque la imagen no se puede leer. |
10 UNSIGNABLE | 16 Facturado previamente con otro RFC | No se facturó porque el comercio ya lo había facturado a otro RFC. |
6 MANUAL REVIEW | 1 Creado | Sigue en proceso; aún no hay resultado. |
Los estatus finales se pueden reabrir. Un agente de Fotofacturas puede regresar un ticket facturado o rechazado a una etapa de proceso (por ejemplo, si el cliente reporta un error o el comercio responde después). Por eso, en una integración, toma siempre el estatus más reciente como el vigente y no des por cerrado un ticket solo porque alguna vez estuvo en 10 UNSIGNABLE o 11 SIGNED.
Casos especiales
Ticket descartado
Si un ticket se archiva mientras sigue en 1 CREATED (antes de empezar a procesarse), queda descartado: ya no se procesa, no se puede desarchivar, no aparece en reportes ni en listas y no cuenta en el consumo del plan.
Tickets archivados
Los tickets archivados en cualquier otro estatus dejan de procesarse automáticamente mientras estén archivados, pero siguen contando para el consumo y aparecen en algunas listas filtradas.
Historial y webhooks
Cada cambio de estatus queda en el historial del ticket y genera los webhooks correspondientes: ticket.status_changed en cada cambio, ticket.invoiced al llegar a 11 SIGNED y ticket.failed al llegar a 10 UNSIGNABLE. Ver Webhooks.
Cómo leerlo en reportes
| Grupo en reportes | Estatus |
|---|---|
| Facturados | 11 |
| En proceso | 1, 3, 5, 6, 7, 8 |
| Rechazados | 10 |
En GetPeriodStats corresponden a processedTicketCount, waitingTicketCount y cancelledTicketCount, respectivamente.