Incidencia=s

[ermendalenda]

Acabo de lanzar una pregunta a Veri*Factu , no sé si los demás ya sabeis la respuesta por obviedad, pero yo he preferido preguntarla

Si tengo una incidencia puntual y un paquete Soap no he podido mandarlo por que, por ejemplo, no habia conexion, cuando vuelva a intentar, lo mas lógico es que tenga que rehacer el paquete, marcarlo como incidencia e incluir los registros nuevos aunque estos ultimos no sean incidencias. Lo digo por si alguno va a dejar ese paquete de varios registros encolado y marcar solo lo que contenga como incidencia creo que no es lo ideal, por que te van a retornar de nuevo el tiempo de espera y puede que lo nuevo se te salga del tiempo y tienes que volver a macarlo como Incidencia y asi hasta que baje laa hora punta de facturacion.

[unomasmas]

Empezado por ermendalenda

Acabo de lanzar una pregunta a Veri*Factu , no sé si los demás ya sabeis la respuesta por obviedad, pero yo he preferido preguntarla

Si tengo una incidencia puntual y un paquete Soap no he podido mandarlo por que, por ejemplo, no habia conexion, cuando vuelva a intentar, lo mas lógico es que tenga que rehacer el paquete, marcarlo como incidencia e incluir los registros nuevos aunque estos ultimos no sean incidencias. Lo digo por si alguno va a dejar ese paquete de varios registros encolado y marcar solo lo que contenga como incidencia creo que no es lo ideal, por que te van a retornar de nuevo el tiempo de espera y puede que lo nuevo se te salga del tiempo y tienes que volver a macarlo como Incidencia y asi hasta que baje laa hora punta de facturacion.

La verdad es que me cuesta seguir la lógica. Es un lío de tres pares de narices tener que valorar si se ha rechazado, si hay que subsanar, si se trata de un caso de rectificativa, si se trata de una incidencia... No sé si me pierdo algo, pero en el "Alta por rechazo", que según la descripción, se trata del "alta por rechazo del registro de facturación de alta inicial (y que, por tanto, no existe aún en la AEAT)" ¿No es posible, ya que no existe el registro en la AEAT, enviar nuevamente el alta, sin más, con la rectificación hecha?

Vale, vale, creo que no; me respondo a mi mismo; corregidme si me equivoco. Creo que enviar un nuevo registro (de alta por rechazo) evitará el error 2004 = El valor del campo FechaHoraHusoGenRegistro debe ser la fecha actual del sistema de la AEAT...

[ermendalenda]

Ya me han respondido,
como hay que mandar todo lo que estaba en incidencia y hay que ir acumulando hasta que se levante la incidencia, se manda todo lo que se lleva hasta el momento con lo cual el proximoo envio estará en hora.

Total, pienso yo que para no calentarnos mas las neuronas con este tema, lo mejor es no tener en cuenta nada de que si hay internet que si ya ha vuelto etc, todo lo que esté fuera de hora o pueda estarlo, (si le sumas los 60seg), se manda como incidencia lo antes posible y santas pascuas.

[ermendalenda]

Ya lo tengo, que sencillo era y estaba liandome, va a ser culpa de la Dana.

Como guardo, como la mayoria de vosotros, en una tabla ordenada cronologicamente,
si ell primer registro pendiente de enviar se ha pasado de hora, toooodo el envio va como incidencia.
Es que estoy ahora empezando a desarrollar el algoritmo del flujo de envios, yo sé que era evidente para los demás, jeje.

[ermendalenda]

Compañeros, os aconsejo que guardéis a buen rexaudo los eventos/logs de intentos fallidos de envío (o incidencias) y que sean lo más descriptivo posible, o sea que tipo de problema se ha encontrado en la incidencia de la remisión, ta que os la podrán solicitar, extraído de la OM:

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.

Yo voy a crear 4 tipos de errores:
-No hay conexión a Internet
-Error de acceso a verifactu(guardando la cabecera de respuesta)
-Certificado caducado, revocado..
-Error al crear un registro se solucionará cuando sea <subsanado>

No sé si se os ocurre alguno distinto

Pero lo que me asusta más es DEBIDAMENTE, eso significa que también tenemos que hacer registro de eventos los que mandan, pero es contradictorio, por que entonces hay que firmarlo también.

[[newtron]]

Yo he optado por guardarlo TODO, los .xml que se envían y los .xml de respuesta. Los guardo tal cual en una carpeta así como: \Respuestas\AÑO\MES\respuestaXXX.xml


De esta manera si algún dato se me escapa por controlar siempre puedo ir a buscar el fichero original de respuesta y sacarlo de ahí.


Saludos.

[ermendalenda]

Empezado por newtron

Yo he optado por guardarlo TODO, los .xml que se envían y los .xml de respuesta. Los guardo tal cual en una carpeta así como: \Respuestas\AÑO\MES\respuestaXXX.xml


De esta manera si algún dato se me escapa por controlar siempre puedo ir a buscar el fichero original de respuesta y sacarlo de ahí.


Saludos.

Pero solo guardar las respuestas no se si es suficiente, por que... y si no hay respuesta. Puedes verificar al menos 3 problemas: conexión a Internet, certificado inválido, no hay respuesta de la aeat aunque haya Internet.
Después si no hay Internet ya hasta ahí podemos llegar, puede ser un router bloqueado, cable de Red roto, la WiFi, fesconexion física del cable de Red, y en estas cosas no tenemos un registro y es imposible saber cual es la causa exacta a través del software.

[[newtron]]

Empezado por ermendalenda

Pero solo guardar las respuestas no se si es suficiente, por que... y si no hay respuesta. Puedes verificar al menos 3 problemas: conexión a Internet, certificado inválido, no hay respuesta de la aeat aunque haya Internet.
Después si no hay Internet ya hasta ahí podemos llegar, puede ser un router bloqueado, cable de Red roto, la WiFi, fesconexion física del cable de Red, y en estas cosas no tenemos un registro y es imposible saber cual es la causa exacta a través del software.

Ok, ahora lo pillo. Es en el más que posible caso de que quieras enviar y no se pueda. Pues no sé porque según parece no detallan mucho sobre qué hacer. Si creas un registro de incidencias pero "a tu bola" igual no sirve para nada porque te lo puedes inventar o no gustarles de la manera que lo plantees. Imagino que detallarán ese supuesto.

[ermendalenda]

Empezado por newtron

Ok, ahora lo pillo. Es en el más que posible caso de que quieras enviar y no se pueda. Pues no sé porque según parece no detallan mucho sobre qué hacer. Si creas un registro de incidencias pero "a tu bola" igual no sirve para nada porque te lo puedes inventar o no gustarles de la manera que lo plantees. Imagino que detallarán ese supuesto.

Exacto.
Creo que tienen un fallo ahí
Mande ayer la consulta y me han respondido que lo pasan a los responsables y si responden algo me lo dirán.
Me reservo mi opinión de ese párrafo.
Pero la respuesta que me espero es que la peticiones me la harán para casos extremos de que tengan muchas incidencias continuadas, y tampoco soluciona nada

[Jesusggc]

Empezado por newtron

Yo he optado por guardarlo TODO, los .xml que se envían y los .xml de respuesta. Los guardo tal cual en una carpeta así como: \Respuestas\AÑO\MES\respuestaXXX.xml


De esta manera si algún dato se me escapa por controlar siempre puedo ir a buscar el fichero original de respuesta y sacarlo de ahí.


Saludos.

Has pensado en guardar los xml en la BD ?(en binario). Creo que sería las limpio y seguro.

Podriamor tener una tabla de envios con fichero enviado y respuesta en cada registro.

[ermendalenda]

Empezado por Jesusggc

Has pensado en guardar los xml en la BD ?(en binario). Creo que sería las limpio y seguro.

Podriamor tener una tabla de envios con fichero enviado y respuesta en cada registro.

El tema es que no sabemos como hay que guárdala, esta enviada la consulta, a ver si responden, por que dicen que hay que demostrar DEBIDAMENTE las incidencias si te hacen un requerimiento, y no explican lo que es debidamente, por que debidamente es un xml firmado y se contradice con otros artículos de los que no son No veri*factu.
Por que por ejemplo demostrar una caída de Internet del proveedor, puede que sea posible, pero demuestra un bloqueo del router, una desconexion de un cable de Red y muchs situaciones indemostrables. Y lo que no pueden decirnos es que mantengamos los sistemas informáticos libres de averías de incidencias no demostrables.
Y si hay que firmar eventos en verifactu no se so al final es mejor el no verifactu y que pidan los registros cuando quieran ya que así tengo más tiempo de reparar/subsanar o lo que sea sin que estemos continuamente observados

[jlmoli_67]

Empezado por ermendalenda

Ya lo tengo, que sencillo era y estaba liandome, va a ser culpa de la Dana.

Como guardo, como la mayoria de vosotros, en una tabla ordenada cronologicamente,
si ell primer registro pendiente de enviar se ha pasado de hora, toooodo el envio va como incidencia.
Es que estoy ahora empezando a desarrollar el algoritmo del flujo de envios, yo sé que era evidente para los demás, jeje.

Buenas,


se puede enviar registros marcados como "incidencias" junto con otros que no estan marcados como incidencia en el mismo lote de envio...¿o si se puede?

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

Empezado por jlmoli_67

se puede enviar registros marcados como "incidencias" junto con otros que no estan marcados como incidencia en el mismo lote de envio...¿o si se puede?

Creo recordar que la "INCIDENCIA" no va a nivel de registro, sino del paquete que se envía.
Nosotros SI enviamos dentro de un mismo paquete marcado con INCIDENCIA, registros de facturación que provienen de la situacxión que generó la incidencia, junto con los nuevos (sin incidencia) que se han generado desde ese momento.

[Faneka]

Efectivamente va a nivel de cabecera, nosotros tambien tenemos el caso de que vaya marcado como incidencia y pueda haber RF que se generaron en ese momento sin ella.