¿Qué se considera como "incidencia"?

[wilecoyote]

Buenas:


Me he estado leyendo el hilo donde se discutía este tema de las incidencias (el de "Reenvío de facturas el Entorno de Pruebas SIN especificar Subsanación") y las respuestas que ha estado dando la AEAT, pero me queda una duda: si no se me va la luz ni Internet, pero me surgen algunos de los errores que están en la lista de la AEAT, ¿se pueden considerar como "incidencia" también?


Me explico: todos tenemos claro que un apagón o una caída del servidor de la AEAT (error 4134) es una incidencia. Pero, ¿qué pasa si tengo por ejemplo un error 4119 ("Error al informar caracteres cuya codificación no es UTF-8")? ¿ O un error 1262 ("La longitud de huella no cumple con las especificaciones")? Tal como yo lo veo, esos errores no deberían suceder nunca en un sistema en producción bien hecho y bien testeado. Si suceden, tiene que ser por un bug de programación por nuestra parte...


...lo cual entraría, según la orden ministerial, en la definición también de "incidencia". La orden dice textualmente "por ej. ausencia de corriente eléctrica, problemas de
conexión a Internet, fallo del sistema informático de facturación…"


A lo que voy es: si envío un registro de facturación y me lo rechazan con algunos de los errores que he citado antes como ejemplo (u otros similares, que solo puedan ocurrir por bug nuestro), al reenviarlo, ¿tendría que marcarlo como "Incidencia"?

[gcqZW]

Yo entiendo que no, que incidencia es cuando se da un fallo (cualquiera) y no puedes cumplir con los tiempos de envío, si te ocurre cualquier fallo y lo consigues solucionar antes de que pase los 240 segundos yo entiendo que no ha habido incidencia.

[Neftali [Germán.Estévez]]

Empezado por wilecoyote

A lo que voy es: si envío un registro de facturación y me lo rechazan con algunos de los errores que he citado antes como ejemplo (u otros similares, que solo puedan ocurrir por bug nuestro), al reenviarlo, ¿tendría que marcarlo como "Incidencia"?

Yo creo que no.
Entiendo que incidencias son en el envío o comunicación.

En los casos que tú describes la comunicación o el circuito con la AEAT se ha cumplido y ha sido correcto (petición + respuesta), sólo que el resultado es "Rechazada", pero en ese proceso no ha habido incidencias.
No se si me explico...

[wilecoyote]

Pues me han respondido de la AEAT sobre esta pregunta (les escribí ayer por la mañana, pero ya estaba desesperado de que me contestaran... y lo típico: escribo aquí y al momento me responden )... y parece que no está tan claro. Me dicen que van a trasladar esa pregunta a los responsables para que lo valoren.

También les pregunté un par más de cosas relacionadas: por ejemplo, les pregunté por esto que dice la orden ministerial:

"Las incidencias en la remisión voluntaria de registros de facturación agrupados deberán ser debidamente justificadas por el remitente si así se lo requiere la Agencia Estatal de Administración Tributaria”

Y les pregunté cómo justificar una incidencia: quiero decir, si se me va la luz o la conexión o el servidor de la AEAT se cae, ¿cómo lo justifico luego? Y me han dicho que también van a trasladar esa pregunta a los responsables.

También hay otra pregunta que les hice y cuya respuesta pongo aquí por si es de interés. Les pregunté qué pasa cuando hay un registro de facturación rechazado y se genera otro posterior: ¿tengo que esperar a que acepte el registro rechazado antes de poder mandar el siguiente? En otras palabras, un registro que no ha podido ser enviado (por rechazo o por incidencia), ¿actúa como "tapón"? Yo creía que sí, pero me dicen que no:

2. No es correcto su planteamiento. Aunque un registro devuelva error, pueden seguir emitiendo las siguientes facturas con normalidad. El encadenamiento se realiza por orden cronológico de generación de registros en el SIF, independientemente de que un registro haya sido rechazado por la AEAT. Aunque existan saltos en la cadena de registros de facturación, algo que desde la AEAT asumimos y prevemos que ocurra, tenemos la forma de detectar esta circunstancias excepcionales ya que quedarán marcadas convenientemente con los indicadores de la operativas comentadas (rechazo previo o subsanación) y serán fáciles de trazar con nuestras herramientas de explotación. El sentido de tener encadenados cronológicamente a través hash de la forma que se solicita en el reglamento es porque en la mayoría de las casuísticas esta cadena estará bien formada y sólo existirán casos excepcionales que estarán bajo control. No debería ser una preocupación como empresa desarrolladora, la responsabilidad de detectar el mal uso o incumplimiento reiterado está en nuestro tejado.

En otras palabras, que comprueban el encadenamiento de huellas no según el orden en el que les llegan las facturas, sino en el orden indicado por "FechaHoraHusoGenRegistro", si no lo he entendido mal.