Anulación de secuencias e-NCF¶

Para las secuencias autorizadas que no va a usar (los huecos de su numeración, o un folio que nunca llegó a la DGII). La norma es precisa sobre cuándo aplica:

"El contribuyente podrá anular secuencias autorizadas de comprobantes fiscales electrónicos, si la factura emitida no ha sido enviada a la DGII ni al receptor o si la secuencia no ha sido utilizada […] Si la factura fue enviada a la DGII y/o al receptor, el contribuyente anulará la secuencia emitiendo una Nota de Crédito Electrónica." — Formato Anulación de e-NCF v1.0, §1

Es decir: esto no revierte un comprobante ya transmitido. Para eso está el tipo 34.

`POST /api/v1/voided-sequences`¶

Como el resto de llamadas que actúan por una empresa, lleva el token y, en el cuerpo, emisor.rnc con el RNC de la empresa cuyas secuencias se anulan: es obligatorio, y su token tiene que estar habilitado para esa empresa (permiso sequences:void; ver tokens-y-permisos.md).

{
  "emisor": { "rnc": "133802074" },
  "rangos": [
    { "tipo": "31", "desde": 50, "hasta": 60 },
    { "tipo": "32", "desde": 1,  "hasta": 500 }
  ]
}

Campo	Tipo	Oblig.	Reglas
`emisor.rnc`	string(9\|11)	●	La empresa cuyas secuencias se anulan.
`rangos[]`	array	●	Hasta 10 tipos de e-CF distintos y 10.000 rangos por tipo (topes del formato).
`rangos[].tipo`	string(2)	●	Uno de los diez tipos de e-CF.
`rangos[].desde`	int	●	Consecutivo inicial. Entre 1 y 9.999.999.999.
`rangos[].hasta`	int	●	Consecutivo final. ≥ `desde`.

Sólo se envían los consecutivos: el e-NCF de 13 posiciones (E + tipo + 10 dígitos) se compone aquí, así que {"tipo":"31","desde":50} viaja como E310000000050.

Respuesta¶

{
  "status": "success",
  "message": "Las secuencias fueron anuladas ante la DGII.",
  "data": {
    "lote": "9f1c…",
    "cantidad_anulada": 511,
    "aceptada_por_dgii": true,
    "mensajes_dgii": [],
    "rangos": [
      { "tipo": "31", "desde": "E310000000050", "hasta": "E310000000060", "cantidad": 11 }
    ]
  }
}

201 si la DGII la aceptó, 422 si no. El servicio de la DGII resuelve en la misma llamada: no hay TrackID ni sondeo posterior (cuándo aparece el track_id, en estados.md).

Los 422 llevan el mismo envelope que el resto de la API (cómo leerlo) y, como la anulación no es un e-CF, no llevan document: la explicación está en data.detalle. Hay tres:

La petición no es válida (un rango invertido, un tipo que no existe…): «Los datos enviados no son válidos.», con data.detalle (el primer error) y data.errores (por campo):

{
  "status": "error",
  "message": "Los datos enviados no son válidos.",
  "data": {
    "detalle": "El inicio del rango no puede ser mayor que el final.",
    "errores": {
      "rangos.0.desde": ["El inicio del rango no puede ser mayor que el final."]
    }
  }
}

No se pudo anular: falla una de las dos comprobaciones propias (un e-NCF del rango ya se emitió, o cae fuera de su autorización) —y entonces no se transmite nada y sus números siguen intactos— o la transmisión a la DGII no llegó a completarse (en ese caso, vea «Si una anulación se queda sin respuesta»). El mensaje es «No se pudo anular las secuencias.» y el motivo va en data.detalle.

La DGII contestó y no la aceptó: «La DGII no aceptó la anulación.», con lo que dijo la DGII en data.detalle (y en data.mensajes_dgii) y el resto de la respuesta de arriba, con aceptada_por_dgii: false:

{
  "status": "error",
  "message": "La DGII no aceptó la anulación.",
  "data": {
    "detalle": "Las secuencias que está intentando anular han sido utilizadas | Rechazado",
    "lote": "9f1c…",
    "cantidad_anulada": 11,
    "aceptada_por_dgii": false,
    "mensajes_dgii": [
      "Las secuencias que está intentando anular han sido utilizadas",
      "Rechazado"
    ],
    "rangos": [
      { "tipo": "31", "desde": "E310000000050", "hasta": "E310000000060", "cantidad": 11 }
    ]
  }
}

Con aceptada_por_dgii: false no se anuló nada, aunque cantidad_anulada repita lo que se pidió: los números siguen disponibles y queda constancia del intento.

Qué se comprueba antes de transmitir¶

Dos reglas se validan contra su propia base de datos, para evitarle un rechazo:

Que ninguna secuencia del rango se haya emitido ya. Si encontramos un e-CF con ese e-NCF, se responde 422 nombrando el comprobante y recordando que la vía es una Nota de Crédito. La DGII lo rechazaría igualmente ("Las secuencias que está intentando anular han sido utilizadas"). Se exceptúa lo que la DGII da por no usado, que sí se puede anular: un comprobante que no llegó a transmitirse (rejected_validation) y uno que la DGII rechazó avisando de que la secuencia sigue libre (rejected_dgii con sequence_reusable: true). Un folio rechazado no se puede reenviar (un folio tiene un solo documento), así que anularlo es la salida para no dejar un hueco.
Si registró su autorización de ese tipo, que el rango caiga dentro de ella. Es opcional: sin autorización registrada se transmite igual y es la DGII quien valida el rango.

Además se rechazan los rangos invertidos y los que se solapan entre sí dentro del mismo tipo.

Efecto sobre sus números¶

Las secuencias anuladas no se pueden volver a usar — la DGII no admite "utilizar posteriormente secuencias que sí hayan podido ser anuladas". Como la numeración la lleva su sistema, el efecto es éste: en cuanto la anulación es aceptada, un e-CF que traiga un e-NCF dentro del rango anulado se rechaza con 422 ("pertenece a un rango anulado y no puede volver a usarse"), sin crear nada.

Si la DGII rechaza la anulación, los números siguen intactos y disponibles: queda constancia del intento y nada más.

`GET /api/v1/voided-sequences`¶

Las últimas 200 anulaciones de la empresa que declara con el parámetro emisor_rnc (GET /api/v1/voided-sequences?emisor_rnc=133802074), de la más reciente a la más antigua, con el resultado que dio la DGII en cada una.

Referencias¶

Campos comunes · Estados · README

Si una anulación se queda sin respuesta¶

Transmitir una anulación y no llegar a saber qué contestó la DGII es un caso incómodo: puede que anulara las secuencias y puede que no. Se deja constancia antes de enviar, así que el rango queda registrado con accepted: null, y mientras siga así esos números no se aceptan como folio (422: «cae en un rango cuya anulación ante la DGII se transmitió sin que llegara a confirmarse»).

Es deliberado y conviene entender por qué: si la anulación llegó y se usara el número, la DGII rechazaría el comprobante y esa secuencia tampoco se podría reutilizar. Perder un número es barato; emitir una factura que nace muerta, no.

Para resolverlo, reintente la anulación del mismo rango: si la DGII la acepta, quedan definitivamente anulados. Si la rechaza, escríbanos: hay que confirmar con la DGII si esos números siguen libres antes de liberarlos, y mientras tanto es más seguro no usarlos.