# Contingencia

> Qué hacer cuando DGI no responde: los tipos 2xx

<Info>
**No hay endpoints separados de contingencia.** La contingencia se emite por el
mismo `POST /v1/companies/{rut}/sendCfes/{branchOffice}`, usando el tipo de CFE
de contingencia correspondiente.
</Info>

## Mapeo tipo normal → tipo contingencia

| Comprobante | Normal | Contingencia |
|---|---|---|
| eTicket / NC / ND | 101 / 102 / 103 | 201 / 202 / 203 |
| eFactura / NC / ND | 111 / 112 / 113 | 211 / 212 / 213 |
| eFactura Expo / NC / ND / eRemito Expo | 121 / 122 / 123 / 124 | 221 / 222 / 223 / 224 |
| eTicket Cuenta Ajena / NC / ND | 131 / 132 / 133 | 231 / 232 / 233 |
| eFactura Cuenta Ajena / NC / ND | 141 / 142 / 143 | 241 / 242 / 243 |
| eBoleta / NC / ND | 151 / 152 / 153 | 251 / 252 / 253 |
| eRemito / eResguardo | 181 / 182 | 281 / 282 |

Los tipos de contingencia usan **CAEs propios** (numeración separada): la
empresa debe tener cargada numeración de contingencia para poder emitirlos -
ver `GET /v1/companies/{rut}/cfesActiveNumbers`.

## La diferencia práctica: la numeración la ponés vos

Es el cambio que rompe una integración si no se conoce. En los tipos normales el
gateway asigna serie y número desde el CAE, y mandarlos no hace nada. **En los
tipos de contingencia tenés que mandarlos vos**, en `IdDoc.Serie` e `IdDoc.Nro`:

```json
{
  "201": [
    {
      "clientEmissionId": "cont-2026-000012",
      "IdDoc": { "Serie": "A", "Nro": 2221321, "MntBruto": "1", "FmaPago": "1" },
      "…": "el resto igual que una emisión normal"
    }
  ]
}
```

La lista es exacta y no tiene excepciones: los veintiún tipos `2xx` llevan serie
y número propios, y los veintiún tipos `1xx` los reciben del CAE. Si la serie o
el número no son válidos, el comprobante queda en `BAD_CUSTOM_SERIE_NUMBER`.

## Qué le pasa a un comprobante de contingencia después

Dos cosas que sólo les pasan a estos:

- **Se pueden reliquidar.** DGI puede devolver un CFC reliquidado, y el estado
  queda en `PROCESSED_RELIQUIDATED`. Los comprobantes normales nunca pasan por
  ahí.
- **`PROCESSED_REJECTED` es ambiguo para ellos.** La API usa el mismo valor
  para un CFE rechazado y para un CFC observado, así que el estado por sí solo no
  distingue los dos casos (ver [Emisión](/emision)).

## Cuándo corresponde usar contingencia

<Warning>
**El criterio es de DGI, no de esta API.** Cuántos fallos o cuánto tiempo sin
respuesta habilitan emitir en contingencia, y por cuánto, es una regla del
régimen, y la API no la aplica: no hay un umbral ni un modo que se active solo,
y tampoco un aviso de que DGI no responde. Lo que se ve es el estado de los
comprobantes: la emisión sigue respondiendo `SUCCESS`, y los CFE que no se
pudieron enviar quedan en `SCHEDULED_CONNECTION_ERR` y se reintentan solos (ver
[Emisión](/emision)).

Es exactamente el tipo de decisión de la sección [Cuándo parar y
preguntar](/): consultalo con el contador de la empresa antes de emitir en
contingencia, no lo deduzcas del comportamiento de la API.
</Warning>

<Note>
Cómo se informan a DGI los comprobantes de contingencia una vez normalizado el
servicio (reporte diario o reenvío) no está documentado acá. Consultalo con pymo
antes de armar un proceso propio.
</Note>
