Certificación de cada contribuyente

Cada cliente de tu plataforma se certifica como emisor electrónico ante la DGII con su propio RNC. Tu ERP guía al usuario; ZarelaFact firma, envía las pruebas a CerteCF y registra la evidencia.

Quién hace qué

#	Paso	Lo hace	Cómo
1	Cargar el certificado	Usuario, desde tu UI	Sesión de carga
2	Postularse en DGII	Usuario, en el portal DGII	Datos de `GET .../dgii-registration`
3	Firmar la postulación	Tu backend	`POST .../certification-xml-signatures`
4	Subir el set de pruebas	Tu backend	El Excel que la DGII le entregó al contribuyente: `POST .../certification-test-sets`
5	Crear el caso y registrar la postulación	Tu backend	`POST .../certification-cases` y `POST .../attestations`
6	Ejecutar el set	Tu backend	`POST .../runs`
7	Completar los pasos finales en DGII	Usuario	Atestaciones
8	Verificar la aprobación DGII	ZarelaFact	Con evidencia; el caso pasa a `approved`

Después sigue Activación y emisión.

Incrustar los pasos en tu ERP

Si no quieres construir esta guía con la API, muestra en tu ERP la misma pantalla de pasos del dashboard, para una Cuenta fiscal: los pasos a la izquierda con su estado, el paso actual con sus tareas («Automático», «Tú, aquí», «Tú, en la DGII») y el avance como lo cuenta la DGII, por ejemplo e-CF aceptados 15/21 y Resúmenes aceptados 0/4. Tu usuario carga ahí el certificado, sube los Excel de la DGII, envía las pruebas, baja los PDF y las facturas de consumo y marca los pasos en la DGII. Usa la misma API por detrás, así que tu ERP recibe los mismos webhooks.

Tu backend pide un enlace con su credencial (permiso certification:execute):

curl -sS -X POST "$BASE_URL/fiscal-accounts/$FISCAL_ACCOUNT_ID/certification-sessions" \
  -H "X-PARTNER-KEY: $PARTNER_KEY" \
  -H 'Content-Type: application/json' \
  --data '{"browserOrigin":"https://erp.example.com","expiresInMinutes":120}'

La respuesta 201 trae url (por ejemplo, https://zarelafact.com/embed/certificacion/…), browserOrigin y expiresAt.

Tu UI la muestra en un iframe:

<iframe
  src="URL_DE_LA_RESPUESTA"
  title="Certificación DGII"
  style="width:100%;height:900px;border:0"
  sandbox="allow-scripts allow-same-origin allow-forms allow-downloads allow-popups"
  allow="clipboard-write"></iframe>

O ábrela en una pestaña nueva: funciona igual.

Origen. browserOrigin es el origen HTTPS exacto de tu UI (sin ruta). La pantalla solo se puede mostrar en un iframe desde ese origen. Si ZarelaFact tiene configurados los orígenes de integración de tu Partner, tiene que ser uno de ellos (422 BROWSER_ORIGIN_NOT_ALLOWED).
Vencimiento. expiresInMinutes va de 5 a 480 (120 si no lo envías). El enlace no se renueva: al vencer, la pantalla dice que lo pidas de nuevo. Pide uno cada vez que el usuario abra la certificación.
Alcance. El enlace sirve solo para esa Cuenta fiscal y solo para la certificación, no para emitir ni ver documentos de producción. Quien lo tiene puede actuar en esa certificación mientras no venza: no lo guardes en registros ni lo compartas.
Estado del Partner. Con tu Partner suspendido la pantalla solo consulta; deshabilitado, el enlace deja de funcionar.
Certificado. El usuario lo carga en el primer paso, con su contraseña y confirmando que es el contribuyente o tiene su autorización. Se valida igual que la carga desde el dashboard.

Cada acción queda en la auditoría de la Cuenta fiscal como hecha desde el enlace (embed:…).

Desde el dashboard

Cada paso de esta página también se hace sin código desde el dashboard de ZarelaFact, con la misma API por detrás. Sirve para tus primeros clientes o para ayudar a uno que se atascó.

Elige el cliente en el selector Cliente y abre Certificación.
Certificado digital: si falta, pídeselo desde tu pantalla con la carga embebida o cárgalo en Certificados con su autorización (ver Carga del certificado).
Postulación en la DGII: copia los datos con Copiar y firma ahí el XML de la postulación o de la declaración jurada; se descarga firmado para subirlo a la DGII.
Set de pruebas y caso: el cliente descarga su Excel en CerteCF (DESCARGAR COMPROBANTES); súbelo tal cual y el caso se crea con ese set. Registra que ya envió la postulación.
Pruebas en CerteCF: pulsa Enviar las pruebas; después de las aprobaciones comerciales, Enviar la simulación. El estado se actualiza solo: ves cada e-NCF con su estado y, si la DGII rechaza alguno, su mensaje. Al terminar, descargas la evidencia.
Pasos finales en la DGII: marca cada paso cuando el cliente lo complete. Al marcar el último, el caso queda aprobado y la producción se activa sola.

Cualquier miembro de tu Partner ve el avance; los cambios los hacen el owner y los developers con el correo verificado, y cada uno queda en la auditoría con su usuario. Tu ERP recibe los mismos webhooks (certification.state_changed, production.state_changed) que si los pasos se hicieran por API.

Postulación ante la DGII

El contribuyente crea su postulación en el portal de certificación DGII declarando a ZarelaFact como software externo. Tu ERP obtiene los valores exactos con:

curl -sS "$BASE_URL/fiscal-accounts/$FISCAL_ACCOUNT_ID/dgii-registration" \
  -H "X-PARTNER-KEY: $PARTNER_KEY"

Campo DGII	Valor
Tipo de software	`EXTERNO`
Nombre del software	`ZarelaFact` (versión en `software.version`)
RNC del proveedor	`133816164` (133-81616-4)
Razón social del proveedor	`ZARELA GROUP SRL`
Nombre comercial del proveedor	`ZARELA GROUP`
URL de recepción y de aprobación comercial	`environments.certecf.*` (por ejemplo `https://api.zarelafact.com/CerteCF`)
URL de autenticación	En blanco

Las URLs son la base del ambiente: la DGII y los demás emisores les agregan /fe/recepcion/api/ecf o /fe/aprobacioncomercial/api/ecf. Muestra los valores de la respuesta en vez de construirlos.

Firmar la postulación y la declaración jurada

DGII exige firmar con el certificado del contribuyente el XML de postulación y, al final, el de la declaración jurada. Con el certificado ya instalado, tu backend envía el XML sin firmar:

curl -sS -X POST \
  "$BASE_URL/fiscal-accounts/$FISCAL_ACCOUNT_ID/certification-xml-signatures" \
  -H "X-PARTNER-KEY: $PARTNER_KEY" \
  -H 'Content-Type: application/json' \
  --data "{\"documentType\":\"postulation\",\"xmlBase64\":\"$(base64 < postulacion.xml | tr -d '\n')\"}"

La respuesta trae signedXmlBase64 y un fileName sugerido para que el usuario lo suba a DGII. Usa documentType: "sworn_declaration" para la declaración jurada.

Respuesta	Qué significa
`200`	XML firmado.
`409 CERTIFICATE_NOT_INSTALLED`	Falta cargar el certificado del contribuyente.
`422 CERTIFICATION_XML_TYPE_NOT_ALLOWED`	No es un XML de postulación ni de declaración jurada.
`422 CERTIFICATION_XML_RNC_MISMATCH`	El XML no contiene el RNC de esta Cuenta fiscal.
`422 INVALID_CERTIFICATION_XML` / `CERTIFICATION_XML_SIGNING_FAILED`	El archivo no es válido o no se pudo firmar.

Firmar no es atestar

ZarelaFact nunca firma e-CF, acuses ni semillas de autenticación por esta ruta. Firmar tampoco registra nada en el caso: cuando el usuario suba el archivo a DGII, registra la atestación correspondiente.

Set de pruebas y caso CerteCF

La DGII le entrega a cada contribuyente su propio set de pruebas de datos y compara campo por campo cada comprobante que recibe con ese set. Por eso las pruebas de datos salen siempre del Excel del contribuyente: lo descarga en CerteCF, en Pruebas de Datos e-CF (DESCARGAR COMPROBANTES), y tu ERP lo sube tal cual:

curl -sS -X POST "$BASE_URL/fiscal-accounts/$FISCAL_ACCOUNT_ID/certification-test-sets" \
  -H "X-PARTNER-KEY: $PARTNER_KEY" -H 'Content-Type: application/json' \
  --data "{\"fileName\":\"set-dgii.xlsx\",\"contentBase64\":\"$(base64 < set-dgii.xlsx | tr -d '\n')\"}"

Acepta el Excel o el JSON en contentBase64 (hasta 700 KB), o el JSON como objeto en set.
El Excel va tal como lo descarga el contribuyente: la hoja ECF trae un comprobante por fila (CasoPrueba es su RNC seguido del e-NCF) y la hoja RFCE, el resumen de cada Factura de Consumo menor a RD$250,000. ZarelaFact arma cada comprobante con esos datos, sin cambiarlos.
ZarelaFact lo procesa al subirlo: comprueba que el emisor sea el RNC de la Cuenta fiscal (422 CERTIFICATION_SET_ISSUER_MISMATCH), que sus eNCF no se hayan emitido en CerteCF (409 CERTIFICATION_SET_ALREADY_USED) y que cada comprobante pase la prevalidación (422 CERTIFICATION_PREVALIDATION_FAILED).
Si una columna con datos no existe en el formato de la DGII para ese tipo de comprobante, o la hoja RFCE no coincide con su factura, responde 422 CERTIFICATION_SET_INVALID con el detalle en details: no se ignora ningún dato del set.
201 trae el testSetRef; subir el mismo archivo otra vez devuelve 200 con el mismo testSetRef.

Crea el caso con ese testSetRef en officialSetRef:

curl -sS -X POST "$BASE_URL/fiscal-accounts/$FISCAL_ACCOUNT_ID/certification-cases" \
  -H "X-PARTNER-KEY: $PARTNER_KEY" -H 'Content-Type: application/json' \
  --data "{\"officialSetRef\":\"$TEST_SET_REF\"}"

201 crea el caso; 200 devuelve el caso activo (o el aprobado, si repites la misma referencia después de la aprobación).
409 CERTIFICATION_CASE_SET_CONFLICT: ya hay un caso activo con otro set.
422 CERTIFICATION_OWN_SET_REQUIRED: pediste el set modelo de ZarelaFact (dgii-model). No sirve para las pruebas de datos; ZarelaFact lo usa solo en la simulación, después de las aprobaciones comerciales.
Una Cuenta fiscal tiene como máximo un caso activo.
El orden con el certificado no importa: si lo cargas después, ZarelaFact registra certificate_validated en el caso abierto sin que tengas que repetir el POST.

Si la DGII rechaza el run con el código 135 («no existe en nuestra colección de datos»), los e-NCF enviados no están en el set que la DGII le entregó a ese cliente y la DGII reinicia sus pruebas de datos: compara la primera columna de su Excel (CasoPrueba) con los e-NCF del run. Si la DGII le entregó un set nuevo, súbelo y cambia el caso a ese set.

Casos creados con el set modelo

Un caso creado antes con dgii-model trae nextAction: "upload_certification_test_set" y sus runs de pruebas de datos responden 409 CERTIFICATION_OWN_SET_REQUIRED. Sube el Excel del contribuyente y cambia el caso a ese set como se explica abajo. Si ya pasó las aprobaciones comerciales, sigue con la simulación sin cambiar nada.

Si la DGII le entrega un set nuevo

Si el caso ya existe (por ejemplo, la DGII le entregó al contribuyente un set nuevo después de reiniciar todo desde cero en su portal), sube ese Excel y cambia el caso a ese set sin cerrarlo:

curl -sS -X POST \
  "$BASE_URL/fiscal-accounts/$FISCAL_ACCOUNT_ID/certification-cases/$CASE_ID/official-set" \
  -H "X-PARTNER-KEY: $PARTNER_KEY" -H 'Content-Type: application/json' \
  --data "{\"officialSetRef\":\"$TEST_SET_REF\"}"

Las pruebas de datos se reinician con el set nuevo: los comprobantes del set anterior quedan reemplazados y el caso conserva su certificado y sus atestaciones. Un set nuevo de la DGII puede repetir e-NCF del anterior; la subida solo los rechaza si los usa un comprobante que no salió de un set de pruebas. En el dashboard, cada set subido trae Usar este set.

Al crear el caso con un set subido, además de las respuestas de arriba:

404 CERTIFICATION_SET_NOT_FOUND: ese testSetRef no se subió para esta Cuenta fiscal.
422 CERTIFICATION_SET_ISSUER_MISMATCH: el set es de otro RNC; no se crea el caso.

Ejecutar el set

curl -sS -X POST \
  "$BASE_URL/fiscal-accounts/$FISCAL_ACCOUNT_ID/certification-cases/$CASE_ID/runs" \
  -H "X-PARTNER-KEY: $PARTNER_KEY" \
  -H "Idempotency-Key: $RUN_IDEMPOTENCY_KEY" \
  -H 'Content-Type: application/json' --data '{}'

ZarelaFact firma cada documento del set con el certificado del contribuyente, lo envía a CerteCF y consulta su estado. La respuesta 202 trae runId. En las pruebas de datos también simula la aprobación comercial, salvo que envíes "b2bSimulation": false; la simulación solo envía los e-CF y sus resúmenes.

Los envía en el orden que pide la DGII: las facturas (incluidas las de consumo de RD$250,000 o más), después las notas de débito y crédito y al final los resúmenes RFCE. Una nota siempre sale después de la factura que modifica: si modifica una factura que va por resumen, las notas esperan a los resúmenes. Las pruebas de datos (el set de la DGII del contribuyente) salen de una en una y el run se detiene en el primer rechazo: un rechazo reinicia esas pruebas en la DGII, y un comprobante que la DGII procesa en ese momento queda "ya utilizado" para el intento siguiente. La simulación sale por lotes. GET .../runs/{runId} trae en cases cada comprobante con su encf, status y dgiiMessages.

Idempotency-Key es obligatoria en los runs. Genérala y guárdala en tu backend antes del request, reutilízala mientras el resultado sea incierto y crea otra solo para un intento nuevo. La misma clave con los mismos parámetros devuelve el mismo runId; con parámetros distintos, 409 IDEMPOTENCY_CONFLICT. El usuario final nunca la ve.

Consulta	Ruta
Estado de un run	`GET .../runs/{runId}`
Runs recientes (si perdiste la respuesta)	`GET .../runs`
ZIP de evidencia en base64, cuando esté listo	`GET .../runs/{runId}/evidence`
XML íntegro (e-CF) de cada Factura de Consumo menor a RD$250,000 aceptada, lo que la DGII pide en Facturas de consumo < 250Mil (ZIP en base64, cada uno como RNC + e-NCF; con `?encf=` un XML suelto)	`GET .../runs/{runId}/consumer-invoices`
Copia de los resúmenes RFCE que ZarelaFact envió por esas facturas, uno por factura (no se suben en el portal; ZIP, o con `?encf=` un XML suelto)	`GET .../runs/{runId}/consumer-summaries`
PDF de la representación impresa de cada comprobante, el paso siguiente en la DGII (ZIP en base64; `exceedsDgiiLimit` si pasa de 10 MB)	`GET .../runs/{runId}/printed-pdfs`

Si un run devuelve 409 CERTIFICATION_SET_ALREADY_USED, los eNCF de ese set ya se emitieron en CerteCF: no reintentes con el mismo set. Para enviar otra vez las pruebas de datos, reinicia las pruebas de datos. 409 CERTIFICATION_OWN_SET_REQUIRED significa que el caso usa dgii-model y le tocan las pruebas de datos: sube el Excel del contribuyente y cambia el caso a ese set.

Con las aprobaciones comerciales aceptadas (checklist.commercialApprovalsSent), el siguiente run es la simulación (paso 4 de la DGII), en el mismo caso, aunque las pruebas de datos se hayan reiniciado en ZarelaFact después: la DGII ya las dio por pasadas. El caso vuelve a running y conserva sus atestaciones. nextAction lo pide como run_simulation_tests y latestRun.mode dice si el último run fue data o simulation. Antes de las aprobaciones, un run desde customer_action_required (pruebas de datos aceptadas) también envía la simulación.

En la simulación la DGII no compara con el set del contribuyente: ZarelaFact envía su set modelo (dgii-model), 25 e-CF de todos los tipos y 4 resúmenes de facturas de consumo, con el RNC del cliente como emisor y datos de prueba en nombres, direcciones y montos. Sus e-NCF van dentro de las secuencias 1 a 10,000,000 que la DGII da a cada tipo, en un bloque nuevo por intento (por ejemplo, E310009001004): nunca chocan con los del set ni se repiten entre intentos.

Mostrar los pasos siguientes en tu ERP

El detalle del caso trae parts con el avance de las pruebas de datos y de la simulación. Cada parte cuenta como la DGII en CerteCF: ecf (accepted de total, sin los resúmenes) y summaries (los resúmenes de facturas de consumo). Muéstralo como «e-CF 15/21 · Resúmenes 0/4».

Cuando la DGII acepta el run, el caso trae downloads con las rutas que tu ERP ofrece al contribuyente, en el orden en que la DGII las pide:

downloads.consumerInvoiceFiles: una entrada por Factura de Consumo menor a RD$250,000, con su encf y la url de su XML íntegro (e-CF). Muestra un botón por factura: el contribuyente sube cada XML en Facturas de consumo < 250Mil del portal de la DGII una vez aceptados sus resúmenes. downloads.consumerInvoices baja todos en un ZIP. La lista viene en el detalle de la Cuenta fiscal y del caso, no en los listados. ZarelaFact ya envió esos resúmenes (RFCE) al servicio de resúmenes de la DGII; downloads.consumerSummaries es solo una copia y no se sube. Ofrece cada XML suelto (?encf=) y del último run: el portal valida cada archivo contra el XSD «e-CF 32» y rechaza un ZIP, un RFCE o el XML de otro envío, y ese rechazo reinicia sus pruebas de datos. Null si el set no tiene Facturas de Consumo menores a RD$250,000.
downloads.printedPdfs: los PDF impresos de los comprobantes de la simulación, lo que la DGII pide en el paso 5 (Representaciones impresas). Es null mientras el último run sea de pruebas de datos. Con ?selection=dgii trae un solo PDF por casilla del portal de la DGII, numerado y con el nombre de la casilla (01 - Tipo 31 - E310009002001.pdf), y slots dice cuál va en cada una: muéstralo como la descarga principal.
downloads.evidence: la evidencia completa.

nextAction dice cuál de los pasos en la DGII sigue (antes de las pruebas de datos, run_certification_tests, o upload_certification_test_set si el caso no tiene el Excel de la DGII): send_commercial_approvals (paso 3), run_simulation_tests (paso 4), upload_printed_representations, submit_production_urls, submit_sworn_declaration y configure_ofv_roles, en ese orden, y partnerActions trae los que faltan. Las aprobaciones comerciales (abajo) y la simulación (POST .../runs) las envía ZarelaFact; los demás se cierran con su atestación. El dashboard Partner muestra esos pasos así, uno por tarjeta, como el asistente de los clientes directos.

Aprobaciones comerciales (paso 3 de la DGII)

Después de las pruebas de datos y de subir las facturas de consumo, CerteCF muestra Pruebas de Datos Aprobación Comercial: el contribuyente debe aprobar, como comprador, cada e-CF de tipo 31, 33, 34, 44 y 45 de su set de datos (en los sets actuales son 11). Cada contribuyente tiene los suyos. En ese paso descarga en CerteCF un Excel con DESCARGAR APROBACIONES COMERCIALES (hoja ACEECF_Generadas). La DGII compara cada aprobación con ese Excel, incluida la fecha y hora de la aprobación, que es la de la descarga.

Tu ERP pide ese Excel al contribuyente y lo envía a ZarelaFact, que manda cada fila tal cual al servicio de aprobación comercial de CerteCF, de una en una y firmada con su certificado:

Acción	Ruta
Enviar las aprobaciones: `{"workbookBase64": "<el Excel en base64>"}` con `Idempotency-Key`	`POST .../certification-cases/{caseId}/commercial-approvals` → `202`
Consultar el avance	`GET .../certification-cases/{caseId}/commercial-approvals`

Ofrécelo cuando nextAction sea send_commercial_approvals: el contribuyente sube el Excel en tu ERP y pulsa «Continuar». Si lo descarga otra vez en CerteCF, debe subir el nuevo.
commercialApprovals trae status (running, completed, failed), summary (aceptadas, rechazadas, sin respuesta y pendientes) y cada aprobación con su encf, status y los messages de la DGII. También viene en el detalle de la Cuenta fiscal y del caso; checklist.commercialApprovalsSent pasa a true cuando todas quedan aceptadas.
El envío se detiene en la primera que la DGII rechace. Un nuevo POST las envía todas otra vez. Si una queda uncertain (sin respuesta), pide al contribuyente revisar el contador en CerteCF antes de enviar de nuevo.
400: falta workbookBase64 (o COMMERCIAL_APPROVAL_SET_REQUIRED). 422: COMMERCIAL_APPROVAL_SET_INVALID (no es el Excel de la DGII o una fila no cumple su formato; details dice cuál, p. ej. un MontoTotal escrito como texto ambiguo, como 83,320) o COMMERCIAL_APPROVAL_SET_OTHER_TAXPAYER (el comprador del Excel no es la Cuenta fiscal).
409: CERTIFICATION_DATA_TESTS_PENDING (las pruebas de datos no están aceptadas), CERTIFICATE_NOT_ACTIVE, COMMERCIAL_APPROVALS_IN_PROGRESS o IDEMPOTENCY_CONFLICT.

Pruebas de comunicación (pasos 7 a 11 de la DGII)

Después de las representaciones impresas, la DGII envía comprobantes y aprobaciones comerciales de prueba a las URLs de CerteCF de la Cuenta fiscal (environments.certecf), como lo haría otro contribuyente. ZarelaFact los recibe y responde solo: el acuse de recibo (ARECF) firmado con el certificado del cliente por cada e-CF, y 200 o 400 por cada aprobación. Tu ERP no envía nada.

Paso 7. El contribuyente confirma en CerteCF las URLs de prueba. La de autenticación va en blanco.
Paso 8. Indica que está listo para recibir. Descargar el certificado raíz es opcional.
Paso 9. La DGII envía los e-CF.
Paso 10. Pulsa Enviar prueba de Aprobaciones Comerciales.
Paso 11. La DGII envía las aprobaciones comerciales.

El detalle del caso trae communicationTests con lo que de verdad llegó al receptor de CerteCF: ecf y approvals, cada uno con received, rejected, lastAt y, de lo que no se recibió, rejections con su encf y code. Muéstralo mientras la DGII prueba. El resultado lo da la DGII en su portal; cuando le habilita las URLs de producción, el siguiente paso es submit_production_urls.

Atestaciones

Las acciones que el usuario completa fuera de ZarelaFact se registran con POST .../certification-cases/{caseId}/attestations. actorRef es obligatorio e identifica a la persona de tu ERP que confirmó (máximo 200 caracteres) y evidenceRefs puede apuntar a comprobantes. Repetir el mismo type devuelve 200 sin duplicar.

Acción del usuario	`type`	Campo del `checklist`
Enviar la postulación en DGII	`dgii_postulation_submitted` (pasa el caso a `application_pending`)	`dgiiPostulationSubmitted`
Subir las representaciones impresas	`printed_representations_uploaded`	`printedRepresentationsUploaded`
Registrar las URLs de producción (`environments.ecf`)	`production_urls_submitted`	`productionUrlsSubmitted`
Presentar la declaración jurada	`sworn_declaration_submitted`	`swornDeclarationSubmitted`
Configurar los roles en la OFV	`ofv_roles_configured`	`ofvRolesConfigured`

Para ofv_roles_configured, el contribuyente delega en la OFV de su empresa los roles Firmante, Solicitante y Aprobador Comercial al titular del certificado, la persona cuya cédula aparece en él. Sin el rol Firmante, la DGII no recibe sus e-CF. Ver el paso 11 y los problemas frecuentes con la DGII.
Solo esos cinco type son válidos; otro devuelve 400 INVALID_ATTESTATION_TYPE.
Los pasos del sistema (certificate_validated, test_set_prevalidated, runner_passed, evidence_ready, dgii_approval_verified, production_active) los registra ZarelaFact; intentarlos devuelve 403 SYSTEM_ATTESTATION_FORBIDDEN.
Con la evidencia del run lista y las cinco atestaciones registradas, ZarelaFact registra la Aprobación DGII verificada: el caso pasa a approved y la producción del cliente se activa sola (ver Activación y emisión). La respuesta de la última atestación ya trae state: "approved".

Estados del caso

Consulta GET .../certification-cases/{caseId}: state, checklist, blockingReasons, partnerActions y nextAction indican qué mostrar en tu UI.

`state`	Qué significa	Qué hace tu ERP
`profile_ready`	Caso creado; falta el certificado.	Pedir la carga del certificado.
`certificate_ready`	Certificado validado.	Registrar la postulación.
`application_pending`	Postulación registrada. `nextAction` dice `wait_for_dgii_application`.	Con el certificado validado, ya puedes ejecutar el run.
`ready_for_tests` / `running`	Set prevalidado o en ejecución.	Consultar el run.
`customer_action_required`	Evidencia lista; faltan pasos en DGII.	Completar las atestaciones pendientes del `checklist`.
`approved`	Aprobación DGII verificada; producción se activa sola.	Esperar `production.state_changed` con `active` y emitir.
`failed`	Un run falló.	Reiniciar la parte que falló.
`rejected`	La DGII rechazó el caso.	Cerrarlo y crear otro.
`blocked`	Caso detenido por ZarelaFact.	Escribir a ZarelaFact con el `caseId`.

Reenviar o reiniciar una parte

Cuando un envío falla por la DGII (corta la conexión, no responde o da un resumen por duplicado), no hace falta cerrar el caso. Mientras el run sigue en curso, reenvía el comprobante trabado; si el run ya falló, reinicia la parte.

Reenviar un comprobante. En GET .../runs/{runId}, un comprobante trabado trae resendable: true:

curl -sS -X POST \
  "$BASE_URL/fiscal-accounts/$FISCAL_ACCOUNT_ID/certification-cases/$CASE_ID/documents/$DOCUMENT_ID/resend" \
  -H "X-PARTNER-KEY: $PARTNER_KEY" -H 'Content-Type: application/json' --data '{}'

202 lo deja listo para enviarse de inmediato (jobType: "ecf.send") o, si la DGII ya le dio TrackID, para consultar su estado (ecf.status.poll). Si la DGII da un resumen RFCE por duplicado, ZarelaFact consulta su estado en la DGII (ConsultaRFCE): si lo tiene aceptado o rechazado, ese es el resultado; si no, reenvía el mismo resumen. La factura nunca se vuelve a firmar.
409 dice por qué no: DOCUMENT_ALREADY_ACCEPTED, DOCUMENT_REJECTED (reinicia esa parte), DOCUMENT_NOT_RESENDABLE (todavía espera su lote), DOCUMENT_SEND_IN_PROGRESS o DOCUMENT_SUPERSEDED.

Reiniciar una parte. Para enviar otra vez desde cero las pruebas de datos (data) o la simulación (simulation):

curl -sS -X POST \
  "$BASE_URL/fiscal-accounts/$FISCAL_ACCOUNT_ID/certification-cases/$CASE_ID/restart" \
  -H "X-PARTNER-KEY: $PARTNER_KEY" -H 'Content-Type: application/json' \
  --data '{"part":"data"}'

Detiene el run en curso y deja los comprobantes de esa parte como reemplazados (no se borran). El caso vuelve a ready_for_tests y el siguiente run envía las pruebas de datos con los mismos e-NCF del set, o la simulación con e-NCF nuevos.
El caso conserva su certificado y sus atestaciones, incluidas la postulación y la declaración jurada: nada que el contribuyente firmó se repite.
La respuesta trae el caso con restart.supersededDocumentCount y parts, el avance de cada parte (también en GET .../certification-cases/{caseId}).
409 CERTIFICATION_CASE_NOT_RESTARTABLE: el caso ya fue aprobado, está bloqueado o espera a la DGII.
Antes de reiniciar las pruebas de datos, confirma que la DGII también las reinició (un rechazo las reinicia sola): si todavía tiene aceptados esos e-NCF, puede rechazarlos por repetidos.

En el dashboard, cada comprobante trabado trae Reenviar y el paso de pruebas trae Reiniciar pruebas de datos y Reiniciar simulación.

Cerrar el caso

Cierra el caso solo si la DGII lo rechazó: para cambiar de set no hace falta cerrarlo (ver Si la DGII le entrega un set nuevo). Se puede cerrar en cualquier estado salvo prevalidating o running (hay un envío en curso), submitted_to_dgii o awaiting_dgii (espera a la DGII), approved y blocked (ese lo cierra ZarelaFact).

curl -sS -X POST \
  "$BASE_URL/fiscal-accounts/$FISCAL_ACCOUNT_ID/certification-cases/$CASE_ID/close" \
  -H "X-PARTNER-KEY: $PARTNER_KEY" -H 'Content-Type: application/json' \
  --data '{"reason":"Reiniciar las pruebas"}'

La respuesta trae el caso con closed: true. Repetirla devuelve replayed: true.
409 CERTIFICATION_CASE_NOT_CLOSABLE: el caso tiene un envío en curso, espera a la DGII, ya fue aprobado o está bloqueado.
Después crea el caso otra vez con el testSetRef del set que vas a usar.
En el dashboard, un caso que la DGII rechazó trae Abrir un caso nuevo, que hace los dos pasos con el mismo set.

Quién hace qué​

Incrustar los pasos en tu ERP​

Desde el dashboard​

Postulación ante la DGII​

Firmar la postulación y la declaración jurada​

Set de pruebas y caso CerteCF​

Si la DGII le entrega un set nuevo​

Ejecutar el set​

Mostrar los pasos siguientes en tu ERP​

Aprobaciones comerciales (paso 3 de la DGII)​

Pruebas de comunicación (pasos 7 a 11 de la DGII)​

Atestaciones​

Estados del caso​

Reenviar o reiniciar una parte​

Cerrar el caso​