> ## Documentation Index > Fetch the complete documentation index at: https://www.emissa.com.ar/docs/llms.txt > Use this file to discover all available pages before exploring further. # Cómo se numera una serie > La numeración es correlativa por punto de venta y tipo, y no perdona huecos. Qué hace Emissa por vos. La numeración de comprobantes es **correlativa y sin huecos**, por punto de venta y por tipo. No es una convención administrativa: ARCA rechaza el comprobante `N+1` si el `N` nunca existió, y una serie trabada no se destraba reintentando. > [!NOTE] > > **La versión corta:** Emissa se encarga de todo esto. Lo único que tenés que > hacer bien es mandar una `Idempotency-Key` que identifique **qué** estás > facturando, no cada intento. Eso está al final. ## Una serie por punto de venta y por tipo Cada combinación de punto de venta y tipo de comprobante lleva su propio contador independiente. Está desarrollado en [qué es un punto de venta](https://www.emissa.com.ar/docs/guias/punto-de-venta.md). ## Por qué un hueco no es un detalle Una serie fiscal es una sucesión, y ARCA la valida como tal. Si tu sistema pide el número 7 cuando ARCA registró hasta el 5, el organismo rechaza — y **el rechazo no arregla nada**: al siguiente intento el desfasaje sigue igual, o peor. > [!WARNING] > > Ese modo de falla se midió en este proyecto. Contando los comprobantes > rechazados como si ocuparan número, cada intento empeoraba el desfasaje en uno > y **la serie de homologación se fue de 4 a 521 sin volver a emitir**. Es la > razón por la que las reglas de abajo existen y no son celo de más. ## Quién decide el número **ARCA, no Emissa.** Antes de cada emisión se le pregunta cuál es el último número que tiene autorizado en esa serie, y se sigue desde ahí. Es deliberado y tiene una consecuencia útil: si alguien emitió desde **otro sistema** con el mismo punto de venta, ARCA está adelante, y seguir por la cuenta local produciría un rechazo. Preguntándole al organismo, la serie converge sola. Adentro se toma el mayor entre el número de ARCA y el último local, así que ninguna de las dos fuentes puede hacerte retroceder. ## Dos pedidos al mismo tiempo Ésta es la parte que un integrador necesita saber para no escribir un lock propio: **no hace falta**. Emissa serializa la asignación del número. > [accordion] La medición: tres emisiones en paralelo > > Tres emisiones lanzadas a la vez contra el mismo contribuyente y la misma > serie, con tres claves de idempotencia distintas: > > ``` > concurrente-1 [HTTP 201] [0,22 s] 0001-00000133 cae 86300697123075 > concurrente-2 [HTTP 201] [2,21 s] 0001-00000134 cae 86300697123135 > concurrente-3 [HTTP 201] [2,49 s] 0001-00000135 cae 86300697123148 > ``` > > Tres números **consecutivos**, tres CAE distintos, ninguna colisión. Y contando > en la base después: > > ``` > number | status | cae > 132 | AUTHORIZED | 86300697121691 > 133 | AUTHORIZED | 86300697123075 > 134 | AUTHORIZED | 86300697123135 > 135 | AUTHORIZED | 86300697123148 > > números repetidos: 0 filas > CAE repetidos: 0 filas > ``` > > Los tiempos cuentan la historia: el primero entró y salió en 0,22 s, los otros > dos esperaron su turno. **Eso es el lock funcionando.** ### Lo que se serializa es más chico de lo que parece Sólo **resolver el número y escribir la fila** ocurre dentro del lock. Lo que tarda —hablar con ARCA— queda afuera: ![Preguntarle el último número a ARCA ocurre afuera del lock. Adentro sólo se resuelve el número y se escribe la fila. Pedir el CAE y guardarlo también ocurre afuera.](https://mintcdn.com/emissa/4QpgM24I6Fz3ej59/images/diagramas/lock-de-numeracion.light.svg?fit=max\&auto=format\&n=4QpgM24I6Fz3ej59\&q=85\&s=e2e21cd6356dbcf4b51a338fd922a3f0) ![](https://mintcdn.com/emissa/4QpgM24I6Fz3ej59/images/diagramas/lock-de-numeracion.dark.svg?fit=max\&auto=format\&n=4QpgM24I6Fz3ej59\&q=85\&s=21f7d202dd1cd0e231b8c03b5d144aae) Sólo el tramo del medio es exclusivo Por qué importa para vos: si el pedido de CAE —que puede tardar segundos— estuviera adentro, **dos clientes del mismo contribuyente emitiendo a la vez se esperarían uno al otro todo ese tiempo**. ## El estado decide si el número se libera Acá hay una asimetría que conviene entender, porque explica qué pasa después de un fallo: | Estado del comprobante | ¿Ocupa número? | Por qué | | - | - | - | | **Autorizado** | Sí | ARCA lo registró. Es definitivo | | **Rechazado** | **No** | ARCA nunca lo registró: del otro lado ese número sigue libre | | **Enviado, sin respuesta aún** | Sí | No se sabe si ARCA lo registró | | **Sin resolver** | Sí | No se sabe si ARCA lo registró | **Un rechazado no cuenta y su fila se borra** para liberar el número. Si contara, sería exactamente el caso del 4 al 521 de más arriba. > [!WARNING] > > **Los dos últimos sí cuentan, y es la regla más importante de esta guía.** De > esos no se sabe si el organismo los registró, así que reutilizar su número > podría **duplicar un comprobante fiscal**. Se resuelven preguntándole a ARCA; > si la respuesta es que no existe, pasan a rechazado y recién entonces su > número vuelve a estar disponible. > [accordion] Cómo listar los que quedaron sin resolver > > ```bash theme={null} > curl "https://api.emissa.com.ar/v1/invoices/unresolved?taxpayerId=TU_TAXPAYER_ID" \ > -H "X-API-Key: $EMISSA_API_KEY" > ``` > > ```json theme={null} > [] > ``` > > Vacío es lo que querés ver. Qué hacer cuando no lo está está en > [qué hacer cuando el CAE viene rechazado](https://www.emissa.com.ar/docs/guias/cae-rechazado.md). ## La clave de idempotencia es obligatoria Es el único requisito que la numeración te impone. Sin ella, el pedido no entra. > [!WARNING] > > **No es burocracia: un comprobante fiscal duplicado no se deshace.** No hay > `DELETE`. Lo único que se puede hacer es emitir una nota de crédito que lo > anule, y las dos cosas —la factura de más y su nota— quedan en tu historia y > en la de ARCA para siempre. Con la clave, repetir el mismo pedido devuelve el mismo comprobante: mismo id, mismo CAE, mismo número, y **no se emite un segundo**. ### Cómo elegir la clave La clave tiene que identificar **la intención de facturar**, no el intento. Derivala de algo que ya sea único en tu dominio y que no cambie al reintentar. | | Ejemplo | Qué pasa | | - | - | - | | ✅ **Bien** | El id de la suscripción más el período: `sub_8123-2026-07` | Si tu proceso corre dos veces, la clave es la misma y el segundo pedido no emite nada | | ❌ **Mal** | Un UUID nuevo por intento | Es lo mismo que no mandar nada: cada reintento se ve como una factura distinta | | ❌ **Mal** | El timestamp | Mismo problema | > [!NOTE] > > Un reintento con una clave distinta **es una emisión nueva**, y es correcto > que lo sea: la API no puede saber que quisiste decir lo mismo. > [accordion] Qué contesta la API sin la clave, y qué contesta al repetir > > Sin el header: > > ```json theme={null} > { > "statusCode": 400, > "errorCode": "IDEMPOTENCY_KEY_REQUIRED", > "message": "Falta el header Idempotency-Key. Es obligatorio en las operaciones que emiten un comprobante." > } > ``` > > Repitiendo el mismo pedido con la misma clave: > > ``` > HTTP 201 · Idempotent-Replay: true · 0,02 segundos > id devuelto: cms6l4gnq0007ur04xl1dcqf0 | cae: 86300696468093 | number: 131 > ``` > > Verificado contando en la base: siguió habiendo un solo comprobante con ese > CAE. ## Qué sigue > [card] [Cuando el CAE viene rechazado](https://www.emissa.com.ar/docs/guias/cae-rechazado.md) > > Los comprobantes sin resolver, y qué se reintenta. > [card] [Cómo se arma una integración](https://www.emissa.com.ar/docs/guias/integracion.md) > > El recorrido completo, en orden. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.