Guía conceptual / Operación
Sin respuesta no significa rechazado.
Una integración necesita distinguir lo que sabe de lo que todavía no puede confirmar. Esa diferencia determina si toca conservar evidencia, consultar, corregir o reintentar.
Autoría: Kenea · Revisión editorial: .
Tres capas que conviene leer por separado
- Transporte. ¿Hay una respuesta completa y utilizable? Un corte o un timeout deja incertidumbre; recibir HTTP 200 tampoco demuestra por sí solo aceptación fiscal.
- Envío.
EstadoEnvioresume el conjunto:Correcto,ParcialmenteCorrectooIncorrecto. - Registro.
EstadoRegistroexpresa el resultado individual. El resumen del envío no sustituye su lectura.
| Valor oficial | Lectura |
|---|---|
Correcto | Registro admitido sin errores. |
AceptadoConErrores | Registro admitido con errores que no provocan rechazo. |
Incorrecto | Registro rechazado; no se registra. |
Fuente: AEAT, descripción de servicios web, §6.5.2. «Pendiente de conciliación» o «desconocido» serían etiquetas internas de una aplicación, no valores de ese catálogo oficial.
Cuatro decisiones, con la evidencia delante
1. Se pierde la respuesta después de enviar
Lo que sabemos: hubo un intento. No sabemos si el destino lo procesó.
Diseño propuesto: conservar referencia, contenido y cronología; marcar incertidumbre y reconciliar mediante los mecanismos del servicio. Si consultar no resuelve el caso, aplicar un procedimiento documentado de recuperación y escalado. No crear automáticamente otra factura para conseguir una respuesta.
2. Hay un rechazo explícito de un registro
Lo que sabemos: existe una respuesta que debe asociarse a la operación correcta.
Diseño propuesto: separar el rechazo de un fallo de red, conservar el detalle y asignar responsable de revisión. Repetir el mismo contenido sin entender la causa puede repetir el problema. La vía de corrección se decide según el caso y la especificación, no con un botón genérico de «reintentar todo».
3. El registro está aceptado con errores
Lo que sabemos: aceptación y ausencia de incidencias son cosas distintas.
Diseño propuesto: abrir una tarea visible con responsable, detalle y evidencia de cierre. No ocultar el aviso porque el envío haya terminado. Determinar con quien corresponda si el problema es de datos, software o criterio fiscal.
4. Se repite un evento o llega información contradictoria
Lo que sabemos: dos mensajes podrían referirse a la misma operación.
Diseño propuesto: comparar identidad y contenido; recuperar el resultado ya conocido si corresponde o detener la discrepancia para revisión. Una referencia interna estable ayuda a deduplicar, pero no garantiza que el destino ofrezca idempotencia ni convierte todas las repeticiones en operaciones equivalentes.
La pregunta antes del siguiente intento
¿Podemos explicar por qué este intento es necesario y a qué operación pertenece? En nuestro diseño conceptual, cada intento conservaría su referencia, instante, entorno, motivo, resultado conocido y responsable de la excepción. Los límites de espera y frecuencia se adaptarían al servicio utilizado; esta guía no fija temporizadores normativos.
La revisión humana se reserva para decisiones y excepciones que la política no pueda resolver de forma segura. No sustituye el funcionamiento automático que corresponda a la modalidad elegida. Nunca incluir claves o certificados en el historial que se comparte para soporte.
Prueba el procedimiento, no solo el envío feliz
Un plan de pruebas debería simular respuesta perdida, repetición concurrente, reinicio y resultados distintos dentro de un conjunto. Para cada escenario, pedir un resultado esperado, una evidencia y un responsable. Hasta ejecutar esas pruebas, cualquier resultado es una expectativa.
La muestra ficticia de informe Demo ERP sitúa estas comprobaciones dentro de una decisión de integración. Para conocer el servicio, consulta KeneaFactu y la guía de VeriFactu.
Fuente y límites de revisión
Se consultó el documento técnico de la AEAT, versión 1.0.3, fechado 28/7/2025, el 8/9/2026. El catálogo anterior corresponde a respuestas de alta y anulación; no enumera todos los campos ni estados de otros servicios. No reproducimos códigos concretos de error ni ofrecemos una implementación del protocolo. Las propuestas operativas de esta página son de Kenea.
Consultar mi escenario de integración Ver la muestra de informe