How a ticket moves from upload until it’s invoiced or rejected, and how the status (ticketStatusId) and the code (ticketCodeId) differ.
For: administrators and technical teams at client companies who want to read their tickets’ progress in the business web app, the API or webhooks. Terms are defined in Concepts.
The full list of ticket statuses and codes (id, name and type: initial, intermediate or final) is in Catalogs.
Status and code: the difference
Every ticket has two values that describe where it stands. They complement each other, but answer different questions:
| Ticket status | Ticket code | |
|---|---|---|
| Question it answers | What stage of the process is it in? | What was the result, or why couldn’t it be invoiced? |
| API field | ticketStatusId / ticketStatus | ticketCodeId (GetTicketCodes catalog) |
| How many there are | 8 | 19 |
| When it changes | Every time the ticket moves to a new stage. Each change is recorded in the ticket history. | Only when there’s a result: when it’s invoiced or rejected. |
| History | Yes: every change is saved (it’s what you see in Seguimiento) and every change triggers webhooks. | No: only the current code is saved. |
| In the Enterprise app | Each ticket’s status (Facturado, Auto factura, Revisión manual…). | The rejection reason shown in the detail and in Reportes › Atención. |
| While the ticket is in progress | Changes with the stage. | Usually 1 (Created): there’s no result yet. |
Rule of thumb: use the status to know whether the ticket is finished and the code to know how it finished.
| Status | Code | Means |
|---|---|---|
11 SIGNED | 2 Invoiced | Fotofacturas generated the invoice. |
11 SIGNED | 3 Previously invoiced | The ticket was already invoiced on the merchant’s portal with the same RFC; that invoice was recovered. |
10 UNSIGNABLE | 8 Illegible ticket | Not invoiced because the image can’t be read. |
10 UNSIGNABLE | 16 Previously invoiced to another RFC | Not invoiced because the merchant had already invoiced it to another RFC. |
6 MANUAL REVIEW | 1 Created | Still in progress; no result yet. |
Final statuses can be reopened. A Fotofacturas agent can send an invoiced or rejected ticket back to a processing stage (for example, if the customer reports an error or the merchant replies later). So in an integration, always treat the most recent status as the current one, and don’t consider a ticket closed just because it was at 10 UNSIGNABLE or 11 SIGNED at some point.
Special cases
Discarded ticket
If a ticket is archived while it’s still at 1 CREATED (before processing starts), it becomes discarded: it’s no longer processed, it can’t be unarchived, it doesn’t appear in reports or lists and it doesn’t count toward plan usage.
Archived tickets
Tickets archived in any other status stop being processed automatically while archived, but they still count toward usage and appear in some filtered lists.
History and webhooks
Every status change is recorded in the ticket history and triggers the corresponding webhooks: ticket.status_changed on every change, ticket.invoiced on reaching 11 SIGNED and ticket.failed on reaching 10 UNSIGNABLE. See Webhooks.
How to read it in reports
| Report group | Status |
|---|---|
| Invoiced | 11 |
| In progress | 1, 3, 5, 6, 7, 8 |
| Rejected | 10 |
In GetPeriodStats they correspond to processedTicketCount, waitingTicketCount and cancelledTicketCount, respectively.