Si estás en la certificación de DTE y el SII te devolvió el set de pruebas rechazado —o consultas el estado y aparece "El Documento No Está en el SII"—, el envío quedó frenado antes de darse por aprobado. Es una de las trabas más frecuentes para un desarrollador que recién se enfrenta al ambiente de certificación, y casi siempre tiene una causa concreta y reproducible. Acá repasamos qué es el set, por qué falla y cómo destrabarlo.
Qué es la certificación y el set de pruebas
La certificación es el proceso por el cual un postulante queda autorizado a emitir DTE. No es un solo trámite: tiene seis pasos. 1) el SII te asigna un set de prueba, 2) Simulación, 3) Intercambio de Información, 4) Envío de Muestras de Impresión, 5) Declaración de Cumplimiento de Requisitos y 6) Autorización del Contribuyente.
El set de pruebas es el primer paso técnico y el que más cuesta destrabar. Consiste en que el SII reciba, sin rechazos ni reparos, un envío de documentos que tú construyes a partir de un archivo con datos de prueba que el propio Servicio te entrega. Para armar esos documentos hay que seguir las "Instrucciones para la Construcción del Set de Prueba" del SII: cada caso del archivo define qué documentos generar y con qué datos.
El paso se considera aprobado solo cuando todo el conjunto pasa limpio. Un único documento con reparo basta para que el set no quede aprobado.
Cómo valida el SII tu envío
Entender el orden de validación es clave para depurar con eficiencia, porque el SII se detiene en la primera etapa que falla. El Servicio valida en este orden:
- Validar Schema. El XML debe cumplir el esquema definido por el SII.
- Validar Firma Digital. La firma del documento y del envío debe ser correcta.
- Validar Timbre Electrónico (TED). El timbre debe ser válido y coherente con el folio.
Si el schema falla, el SII no llega a mirar la firma; si la firma falla, no llega al TED. Por eso conviene depurar de schema hacia TED, en ese orden, en lugar de saltar al timbre cuando el problema real está antes.
Errores más comunes y sus causas
Un envío del set puede quedar en distintos estados, y conviene distinguirlos antes de buscar la causa.
Envío rechazado (todo el envío cae)
Cuando el envío completo queda rechazado, ningún documento se acepta. Las causas verificadas más habituales son:
- Errores de schema. El XML no cumple el esquema del SII (un campo fuera de lugar, un tipo de dato inválido, un elemento obligatorio ausente).
- Error en la firma del envío. La firma del envío no valida.
- Usuario no autorizado. Quien envía no está habilitado para hacerlo en el ambiente de certificación.
Estos tres casos detienen todo el envío de una sola vez, así que afectan a todos los documentos del set por igual.
Documentos rechazados o con reparo dentro de un envío aceptado
Un envío puede ser aceptado y, aun así, contener documentos individuales Aceptados y otros Rechazados o con Reparo. Acá el problema es por documento: un caso del set mal construido, un dato que no corresponde al archivo de prueba, un cálculo que no cuadra. Como el set exige el conjunto sin reparos, hay que corregir el documento puntual y reenviar.
"El Documento No Está en el SII"
Este caso confunde porque el envío parecía haber salido bien. El mensaje "El Documento No Está en el SII" aparece, según casos reales del foro de desarrolladores, cuando consultas un Identificador de Envío que ya no está vigente o cuyos archivos el SII ya no conserva. No es que tu documento esté mal construido: estás preguntando por un envío que el Servicio ya no tiene.
Envío fuera de plazo
Hay un límite temporal que pasa desapercibido. Los envíos con documentos del set de prueba deben llegar al SII dentro de un plazo de 2 meses contados desde que obtuviste el set. Los que exceden ese plazo son rechazados, y no hay corrección posible sobre ese set: hay que generar un set de pruebas nuevo y volver a empezar.
Cómo solucionarlo
- Identifica el estado real. ¿Es un envío rechazado completo, un documento con reparo dentro de un envío aceptado, un "No Está en el SII" o un envío fuera de plazo? Cada estado apunta a una causa distinta.
- Depura de schema hacia TED. Valida primero el schema, después la firma y al final el TED. No persigas el timbre si el schema todavía falla.
- Revisa el XML antes de enviarlo al set. Pasa cada documento por el validador de XML DTE de Emitir, que revisa schema, firma y TED directamente en tu navegador, sin subir el archivo a ningún servidor. Así detectas el problema en tu máquina y no en el rechazo del SII.
- Para "El Documento No Está en el SII", reintenta con un Identificador de Envío fresco. Genera un envío nuevo y consulta el estado con el Identificador de Envío que devuelve esa última carga, no uno anterior que pueda haber caducado.
- Vigila el plazo de 2 meses. Si tu set ya venció, no insistas con él: genera un set nuevo desde el SII.
- Reintenta el set. El postulante puede iterar: corriges la causa, reenvías el conjunto y repites hasta que todo pase sin rechazos ni reparos dentro del plazo.
Recomendaciones
- Construye estrictamente según el archivo del set. Cada caso define datos y documentos concretos; improvisar montos o folios produce reparos.
- Valida antes de enviar, no después. El ambiente de certificación premia las iteraciones cortas: cuanto antes detectes un error de schema o firma, menos vueltas das.
- Trata cada estado como un diagnóstico distinto. Un rechazo de envío completo y un reparo de documento individual no se arreglan igual.
Si quieres el panorama general de por qué el Servicio detiene un documento —folios, schema, firma y timbre—, revisa por qué el SII rechaza un DTE. Y como el TED es la tercera etapa de validación y una fuente habitual de reparos, conviene tener claro qué es el timbre electrónico del DTE antes de armar el set.
Emitir ya está certificada ante el SII
Emitir es la API que emite DTE del SII y que ya pasó la certificación ante el Servicio, incluido el set de pruebas. La idea es que el desarrollador no tenga que pasar el set por su cuenta: emite contra una integración ya autorizada en lugar de construir y depurar el conjunto de certificación desde cero.
Todavía estamos en lista de espera, sin producto en producción aún: súmate a la lista de espera para probarla cuando abramos el acceso.
Preguntas frecuentes
¿Qué es el set de pruebas del SII?+
Es uno de los pasos de la certificación para emitir DTE. El SII te asigna un set de prueba con datos, y a partir de ese archivo construyes y envías un conjunto de documentos al ambiente de certificación. El paso se aprueba cuando el SII recibe ese envío sin rechazos ni reparos.
¿Qué significa que el set de pruebas esté rechazado?+
Significa que el SII no aceptó el envío completo: ningún documento quedó procesado. Suele deberse a errores de schema, un problema en la firma del envío o un usuario no autorizado. Mientras haya un rechazo o reparo en el conjunto, el set no se da por aprobado.
¿Por qué aparece 'El Documento No Está en el SII' en el set de pruebas?+
Ese mensaje aparece al consultar un Identificador de Envío que ya no está vigente o cuyos archivos el SII ya no conserva. Reintenta generando un envío nuevo y consulta el estado con el Identificador de Envío que devuelve esa última carga, no uno anterior.
¿Cuánto tiempo tengo para enviar los documentos del set de pruebas?+
Los envíos con documentos del set de prueba deben llegar al SII dentro de un plazo de 2 meses contados desde que obtuviste el set. Los envíos que excedan ese plazo son rechazados y debes generar un nuevo set de pruebas.
¿Puedo reintentar el set de pruebas si fue rechazado?+
Sí. El postulante puede iterar el set de pruebas: corriges la causa del rechazo y vuelves a enviar el conjunto. No tienes un único intento, pero todo el set debe quedar sin rechazos ni reparos dentro del plazo de 2 meses.
¿En qué orden valida el SII un envío de certificación?+
El SII valida en tres etapas y en este orden: primero el schema del XML, luego la firma digital y finalmente el timbre electrónico (TED). Si falla la primera etapa, no llega a revisar las siguientes, así que conviene depurar de schema hacia TED.