Respuesta por parte de AEAT al envio de 30 facturas - Como desglosar

[frrr@grupo3rs.c]

He probado a enviar casi 30 facturas y como es natural AEAT responde con un xml donde estan todas juntas.

Hay 28 facturas OK y 2 con errores o incidencias.

Como hacen Vds. para desglosar este xml que es un barbaridad de largo, ya que hay que indicar la situacion de cada una de las 30 facturas, indicando las OK y las ERRONEAS para tomar las medidas necesarias.

Existe alguna wsdl o similar que pueda usar y me agilice este tema

Gracias

[jlmoli_67]

Empezado por frrr@grupo3rs.c

He probado a enviar casi 30 facturas y como es natural AEAT responde con un xml donde estan todas juntas.

Hay 28 facturas OK y 2 con errores o incidencias.

Como hacen Vds. para desglosar este xml que es un barbaridad de largo, ya que hay que indicar la situacion de cada una de las 30 facturas, indicando las OK y las ERRONEAS para tomar las medidas necesarias.

Existe alguna wsdl o similar que pueda usar y me agilice este tema

Gracias

Buenas
Yo lo hago asi:
La respuesta para cada registro enviado se encuentra dentro del nodo <RespuestaLinea> correspondiente. Debes, pues , tratar dicho nodo de forma independiente extrayendo los datos de respuesta para asociarlo a cada registro enviado de forma que si consultas la factura en tu aplicacion te diga la situacion en la que se encuentra. Si sabes trabajar con xml es muy facil. Chapgpt me ayudó mucho con los xml

[espinete]

A mí esto de enviar las facturas en bloques (de hasta 1000) me parece un problema, aunque en algunos casos está claro que no queda otra.

Pongamos que una empresa envía 500 facturas de golpe, pero de esas 500, 30 están "aceptadas con errores", 8 rechazadas, etc. ¿Cómo avisas al usuario de que debe subsanar/rectificar esas 38 facturas?

Estos casos se darán en empresas o comercios grandes, como supermercados, empresas que facturen a final de mes, etc. en las que el empleado que lo hace no tiene por qué saber (o no tener premisos) para rectificar una factura, modificar algo, etc. Y todo esto antes del envío del segundo bloque de otras 500, o las que sean (o después, da igual).

He leído que algunos van a implementar una opción para que antes de apagar el PC se compruebe si hay envíos pendientes aún (bien porque hayan dado error o porque no se hayan enviado aún). ¿Y si falla? ¿Y si apagan el PC de golpe? ¿Y si se va la luz a última hora? ¿Las enviamos todas como "incidencia" a primera hora de la mañana? ¿Y si aún no han corregido los errores que hay que subsanar?

Vale, la mayoría de esos errores subsanables simplemente no deberían ocurrir si está todo pulido, pero ya sabemos cómo es la vida real. En 2 años con TicketBAI han pasado cosas que ni se nos pasaron por la cabeza, y solo son unos pocos clientes. A mí lo que más me preocupa es cómo decirle al usuario, que por lo general ni siquiera lee los avisos de error, que "hay que corregir 20 facturas, son estas, y tienen estos problemas". Ya te digo yo que pueden pasar días sin que corrijan nada.

Y ahora ponte en el peor de los casos imaginables: el bloque máximo son 1000 facturas, pero casualidades de la vida, ya hay 1001 facturas pendientes, con incidencias sin corregir, que deben ser subsanadas y no las han corregido. Mientras siguen creando facturas nuevas: 1002, 1003, 1004, que se quedan en cola hasta que no se envíen las 1000 anteriores.

No sé si me estoy preocupando demasiado, pero la verdad es que lo veo complicado. Con lo fácil que sería hacer los envíos sobre la marcha (como el Ticketbai de Gipuzkoa y Araba por ejemplo). Nosotros tenemos clientes que estuvieron enviando durante MESES facturas al entorno de PRUEBAS de SII sin darse cuenta, pese a que antes de cada envío aparece un mensaje indicando que está activado el entorno de pruebas. Por eso me preocupa cómo decirle al usuario que hay X facturas que requieren su atención y si no lo corriges cuanto antes, se va a liar parda.

[jlmoli_67]

Empezado por espinete

A mí esto de enviar las facturas en bloques (de hasta 1000) me parece un problema, aunque en algunos casos está claro que no queda otra.

Pongamos que una empresa envía 500 facturas de golpe, pero de esas 500, 30 están "aceptadas con errores", 8 rechazadas, etc. ¿Cómo avisas al usuario de que debe subsanar/rectificar esas 38 facturas?

Estos casos se darán en empresas o comercios grandes, como supermercados, empresas que facturen a final de mes, etc. en las que el empleado que lo hace no tiene por qué saber (o no tener premisos) para rectificar una factura, modificar algo, etc. Y todo esto antes del envío del segundo bloque de otras 500, o las que sean (o después, da igual).

He leído que algunos van a implementar una opción para que antes de apagar el PC se compruebe si hay envíos pendientes aún (bien porque hayan dado error o porque no se hayan enviado aún). ¿Y si falla? ¿Y si apagan el PC de golpe? ¿Y si se va la luz a última hora? ¿Las enviamos todas como "incidencia" a primera hora de la mañana? ¿Y si aún no han corregido los errores que hay que subsanar?

Vale, la mayoría de esos errores subsanables simplemente no deberían ocurrir si está todo pulido, pero ya sabemos cómo es la vida real. En 2 años con TicketBAI han pasado cosas que ni se nos pasaron por la cabeza, y solo son unos pocos clientes. A mí lo que más me preocupa es cómo decirle al usuario, que por lo general ni siquiera lee los avisos de error, que "hay que corregir 20 facturas, son estas, y tienen estos problemas". Ya te digo yo que pueden pasar días sin que corrijan nada.

Y ahora ponte en el peor de los casos imaginables: el bloque máximo son 1000 facturas, pero casualidades de la vida, ya hay 1001 facturas pendientes, con incidencias sin corregir, que deben ser subsanadas y no las han corregido. Mientras siguen creando facturas nuevas: 1002, 1003, 1004, que se quedan en cola hasta que no se envíen las 1000 anteriores.

No sé si me estoy preocupando demasiado, pero la verdad es que lo veo complicado. Con lo fácil que sería hacer los envíos sobre la marcha (como el Ticketbai de Gipuzkoa y Araba por ejemplo). Nosotros tenemos clientes que estuvieron enviando durante MESES facturas al entorno de PRUEBAS de SII sin darse cuenta, pese a que antes de cada envío aparece un mensaje indicando que está activado el entorno de pruebas. Por eso me preocupa cómo decirle al usuario que hay X facturas que requieren su atención y si no lo corriges cuanto antes, se va a liar parda.

Buenas,
hombre, yo creo que te preocupas demasiado por lo siguiente. .... No somos ni magos ni tenemos varita que resuelva problemas por nadie. En ese sentido podemos dejar las cosas hechas de la mejor forma que sabemos para que el cliente actue segun un procedimiento. Hasta ahi nuestra responsabilidad. Si a un niño le dices mil veces que no cruce y al final cruza y lo atropellan pues eso, no se puede hacer nada mas. Con ello te indico que llevas toda la razon del mundo, el cliente "deberia"....... pero si no lo hace pues ni fú ni fa . Ya le requeriran y tendra que hacer lo que no hizo. Es como el caso del SII que expones.Que mas puedes tu hacer si ya avisas de que lo que se esta haciendo esta mal hecho y el cliente pasa de todo?


Lo que si debemos es de avisar y creo que debemos centrarnos en que en todo momento nuestro cliente este informado sobre el estado de su registro de facturacion con mensajes que impliquen la necesidad de intervencion por parte del usuario para que este pueda seguir trabajando (por ejemplo al iniciar sesion, al cerrar la aplicacion, al crear una factura, etc) asi como de crear procedimientos que sean lo mas sencillos posibles (pocos pasos) para que estos puedan subsanar los errores. Yo al lado de cada incidencia pongo una especie de recomendacion de como puede subsanar el error que va desde opciones totalmente automaticas a otras totalmente manual ( segun el caso a eleccion del usuario). Creo que hasta ahi llega mi responsabilidad para con mis clientes el resto dependera de ellos.




En cuanto al numero de incidencias en cola si ya tienes 1000 dara igual que tengas dos , tres mil o treinta mil. El caso es que tienes incidencias y que estas se deben enviar cuando te digan y hasta un tope de 1000 registros lo antes posible. Imagina que a un cliente le cortan el telefono e internet por falta de pago y no puede enviar y omite los avisos del programa informando de la necesidad de dicho envio. Aunque queramos que todo vaya bien hay cuestiones que se nos escapan porque no todo depende de nosotros. Asi que por todo ello creo que no te deberias de preocupar tanto por el motivo que nos has expuesto porque no todo se puede controlar.


Un saludo

[ISCOPYME]

Empezado por espinete

.........

Y ahora ponte en el peor de los casos imaginables: el bloque máximo son 1000 facturas, pero casualidades de la vida, ya hay 1001 facturas pendientes, con incidencias sin corregir, que deben ser subsanadas y no las han corregido. Mientras siguen creando facturas nuevas: 1002, 1003, 1004, que se quedan en cola hasta que no se envíen las 1000 anteriores.

No sé si me estoy preocupando demasiado, pero la verdad es que lo veo complicado. Con lo fácil que sería hacer los envíos sobre la marcha (como el Ticketbai de Gipuzkoa y Araba por ejemplo). Nosotros tenemos clientes que estuvieron enviando durante MESES facturas al entorno de PRUEBAS de SII sin darse cuenta, pese a que antes de cada envío aparece un mensaje indicando que está activado el entorno de pruebas. Por eso me preocupa cómo decirle al usuario que hay X facturas que requieren su atención y si no lo corriges cuanto antes, se va a liar parda.

A ver, yo no sé cómo has desarrollado tu estructura de bases de datos, pero yo te cuento la mía ya que lo que estás diciendo no debería de darse. Yo tengo una Master-Detail con envíos y sus registros de facturación enviados. En estas tablas se guardan los datos de envío y las respuestas de la aeat. Cuando se crea una factura, se crea su registro de facturación (detail) y se relaciona con los envíos (master), de forma que cuando la cabecera de envíos llega a 1000 registros de facturación se crea una nueva cabecera y así sucesivamente. Por otro lado hay un servicio que "cuando toca"(bien porque ya hay 1000 registros o porque ha pasado el tiempo entre envíos) empieza a hacer envíos a la aeat. Si de esos 1000 me devuelven 500 porque están mal, no pasa nada. Se avisa a la aplicación que hay errores en los envíos. En el momento que tú subsanes 1 error, se crea un nuevo registro de facturación que se relaciona con la cabecera, etcc.... y vuelta a empezar... Si se van haciendo facturas por el otro lado, pues se van generando nuevos registros de facturación que se van relacionando con las cabeceras de envíos y así sucesivamente... Como ejemplo, hice una facturación masiva de 1218 facturas y se enviaron en dos bloques, uno de mil y otro de 218 facturas...

[ermendalenda]

Empezado por ISCOPYME

A ver, yo no sé cómo has desarrollado tu estructura de bases de datos, pero yo te cuento la mía ya que lo que estás diciendo no debería de darse. Yo tengo una Master-Detail con envíos y sus registros de facturación enviados. En estas tablas se guardan los datos de envío y las respuestas de la aeat. Cuando se crea una factura, se crea su registro de facturación (detail) y se relaciona con los envíos (master), de forma que cuando la cabecera de envíos llega a 1000 registros de facturación se crea una nueva cabecera y así sucesivamente. Por otro lado hay un servicio que "cuando toca"(bien porque ya hay 1000 registros o porque ha pasado el tiempo entre envíos) empieza a hacer envíos a la aeat. Si de esos 1000 me devuelven 500 porque están mal, no pasa nada. Se avisa a la aplicación que hay errores en los envíos. En el momento que tú subsanes 1 error, se crea un nuevo registro de facturación que se relaciona con la cabecera, etcc.... y vuelta a empezar... Si se van haciendo facturas por el otro lado, pues se van generando nuevos registros de facturación que se van relacionando con las cabeceras de envíos y así sucesivamente... Como ejemplo, hice una facturación masiva de 1218 facturas y se enviaron en dos bloques, uno de mil y otro de 218 facturas...

Hola
Me he perdido con el control de flujos que usas.
Me ha parecido que vas acumulando registros y si llegas 1000registros o al tiempo envío creas una nueva cabecera de envios(entiendo que es un nuevo soap), pero que pasa si falla el envío por que no hay conexión?, lo lógico es que se recalcule esas "cabeceras"
Saludos

[Jarogo08]

Buenas Espinete

Empezado por espinete

Pongamos que una empresa envía 500 facturas de golpe, pero de esas 500, 30 están "aceptadas con errores", 8 rechazadas, etc. ¿Cómo avisas al usuario de que debe subsanar/rectificar esas 38 facturas?

Supongo que tendrás un mantenimiento de facturas, donde se verá una lista de todas las facturas del ejercicio/empresa/etc. Ahí puedes tener un campo de "Correcta/Aceptada con errores/Incorrecta". Así, cada vez que vaya al mantenimiento de facturas va a ver ese campo, y todo lo que no sea "Correcto" tendrá que hacerle algo.

Empezado por espinete

He leído que algunos van a implementar una opción para que antes de apagar el PC se compruebe si hay envíos pendientes aún (bien porque hayan dado error o porque no se hayan enviado aún). ¿Y si falla?
¿Y si apagan el PC de golpe? ¿Y si se va la luz a última hora? ¿Las enviamos todas como "incidencia" a primera hora de la mañana? ¿Y si aún no han corregido los errores que hay que subsanar?

Si tienes algo que está enviando cada 60 segundos (en nuestro caso será un servicio de windows) ya se encarga él de enviar lo pendiente, no tienes nada que comprobar antes de apagar el pc. En caso de que no se envíe algo que debería (falló el servicio, falló internet) pues la próxima vez que se pueda tendrá que ir marcado como "Incidencia", como bien dices.
Y los errores que no se han corregido no sé si te estás haciendo un lío... Te explico como lo hacemos nosotros, por si te puede ayudar: si yo creo 10 facturas creo también 10 registros para enviar a Verifactu (en otra tabla, la de envíos). El servicio de windows revisa esa tabla y envía si hay algo pendiente. Una vez que envía actualiza las facturas con la respuesta (y así la persona que entra en el mantenimiento de facturas verá en el campo que te decía en el primer punto si subió correcta o no). Si de las 10 hubo 2 que dieron error las verá en la lista. Tendrá que ir a ellas y corregir lo que sea, y en el momento en que lo haga se creará otro registro en la tabla de envíos. Me da igual si lo hace a los 10 minutos del envío o a los 10 días. En la tabla aparecerán y se enviarán las facturas que cree nuevas más las facturas que subsane (sean de cuando sean)

Empezado por espinete

Y ahora ponte en el peor de los casos imaginables: el bloque máximo son 1000 facturas, pero casualidades de la vida, ya hay 1001 facturas pendientes, con incidencias sin corregir, que deben ser subsanadas
y no las han corregido. Mientras siguen creando facturas nuevas: 1002, 1003, 1004, que se quedan en cola hasta que no se envíen las 1000 anteriores.

Pues hago un envío de 1000 facturas ahora y dentro de 60 segundos otro envío de 1 (y si aparecieron 10 facturas más pues será de 11). Y si en ese tiempo subsané una de la semana pasada, pues el segundo envío llevará 12 registros: la 1001 que no me entró en el primer envío, las 10 nuevas que creó y la subsanación de la factura que subió la semana pasada

Empezado por espinete

No sé si me estoy preocupando demasiado

Creo que sí


Espero haberte ayudado

[ermendalenda]

Es cierto
Una apagón es una incidencia
Pero si le Dan a "Apagar /reiniciar Windows " hay una forma de verificar si hay algo pendiente y esperar todo el proceso, tiempo de envios etc para que se envíe.
O sea puedes poner una llamada a una aplicación, tanto en Windows como en Linux que.se ejecute antes de apagar.

[ISCOPYME]

Empezado por ermendalenda

Hola
Me he perdido con el control de flujos que usas.
Me ha parecido que vas acumulando registros y si llegas 1000registros o al tiempo envío creas una nueva cabecera de envios(entiendo que es un nuevo soap), pero que pasa si falla el envío por que no hay conexión?, lo lógico es que se recalcule esas "cabeceras"
Saludos

Buenos días. Es más o menos como dice Jarogo08 en su mensaje.

Básicamente se trata de tener la estructura del xml que envía en tablas, es decir, cuando creo una factura, se crea un registro de facturación. Cuando se crea el registro de facturación se va a ver si hay alguna "cabecera" pendiente de enviar, o que no ha llegado a 1000 registros, o que no esté bloqueada, enviada, etc... si no la hay, la crea y al mismo tiempo crea el detalle de la cabecera con él mismo. Por tanto tengo una estructura master-detail de cabeceras y registros de facturación asociados. Esto no cambia nunca, ya está creado, lo envíes o no. Luego el servicio se encarga de buscar la primera cabecera libre, la bloquea, crea el SOAP y la envía. Si hay error simplemente se deshace el bloqueo de la cabecera y vuelta a empezar cuando toque. Si no hay error se actualizan la cabecera y los registros enviados con la contestación de aeat. La aplicación principal consulta periódicamente si hay registros de facturación marcados como rechazados o aceptados con errores y muestra una notificación o señal de alarma en la pantalla principal. Así el usuario ya sabe que tiene registros de facturación por solucionar. Cuando solucionas uno, se crea de nuevo un registro de facturación que sigue el mismo procedimiento.... La resolución de los registros marcados como errores, se puede hacer en un momento, una semana después o cuando uno pueda y se tenga solución para ello. Por cierto, el servicio marca como incidencia todo registro que desde que se creó hasta que se envía hayan pasado más de 120 segundos.

Espero haber aclarado tus dudas.

Un saludo.

[ermendalenda]

Empezado por ISCOPYME

Buenos días. Es más o menos como dice Jarogo08 en su mensaje.

Básicamente se trata de tener la estructura del xml que envía en tablas, es decir, cuando creo una factura, se crea un registro de facturación. Cuando se crea el registro de facturación se va a ver si hay alguna "cabecera" pendiente de enviar, o que no ha llegado a 1000 registros, o que no esté bloqueada, enviada, etc... si no la hay, la crea y al mismo tiempo crea el detalle de la cabecera con él mismo. Por tanto tengo una estructura master-detail de cabeceras y registros de facturación asociados. Esto no cambia nunca, ya está creado, lo envíes o no. Luego el servicio se encarga de buscar la primera cabecera libre, la bloquea, crea el SOAP y la envía. Si hay error simplemente se deshace el bloqueo de la cabecera y vuelta a empezar cuando toque. Si no hay error se actualizan la cabecera y los registros enviados con la contestación de aeat. La aplicación principal consulta periódicamente si hay registros de facturación marcados como rechazados o aceptados con errores y muestra una notificación o señal de alarma en la pantalla principal. Así el usuario ya sabe que tiene registros de facturación por solucionar. Cuando solucionas uno, se crea de nuevo un registro de facturación que sigue el mismo procedimiento.... La resolución de los registros marcados como errores, se puede hacer en un momento, una semana después o cuando uno pueda y se tenga solución para ello. Por cierto, el servicio marca como incidencia todo registro que desde que se creó hasta que se envía hayan pasado más de 120 segundos.

Espero haber aclarado tus dudas.

Un saludo.

Si, veo que lo tienes controlado

Aunque aún veo dudas, lo de marcar todos los registros no es muy necesario, ya que si marcas 1, ya el resto tienen que enviarse como incidencia en el mismo bloque si no ha llegado a 1000, ya se hayan pasado del tiempo o no, ya que es el encabezado eel.envio el que indica la incidencia
Saludos

[ISCOPYME]

Empezado por ermendalenda

Si, veo que lo tienes controlado

Aunque aún veo dudas, lo de marcar todos los registros no es muy necesario, ya que si marcas 1, ya el resto tienen que enviarse como incidencia en el mismo bloque si no ha llegado a 1000, ya se hayan pasado del tiempo o no, ya que es el encabezado eel.envio el que indica la incidencia
Saludos

Sí. Es totalmente correcto lo que dices. Se marca la cabecera como incidencia y no los registros de facturación.

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

Aquí están todos los esquemas necesarios:
https://www.agenciatributaria.es/AEA...icios_web.html

[espinete]

Buenas...

¿Cómo hacéis para enviar un bloque de X facturas en las que algunas de ellas, por el motivo que sea, van con Incidencia?
Porque la Incidencia va en la cabecera del envío, no en cada registro, así que hay que saberlo "antes".

Durante las pruebas, se me ha dado el caso de que pasaron más de 10 minutos desde que se emitió la factura hasta que se envió.
Obtengo el error 2004: El valor del campo FechaHoraHusoGenRegistro debe ser la fecha actual blablabla

Hacienda acepta la factura "con avisos", pero la acepta y según ellos no hay que hacer nada en este caso (ni volverla a enviar, ni subsanar, ni nada).

Pero ¿y si quiero evitar el error antes de enviar el bloque? ¿Puedo enviar el bloque como Incidencia = S aunque solo una de las facturas vaya con retraso y las otras no?
O si el motivo de la incidencia es otro, se podría hacer eso?

[delphiGar]

consulta la FechaHoraHusoGenRegistro de los registros que vayas a enviar y si alguno tiene mas de 120 segundos de diferencia con respecto a la hora actual marca el paquete como Incidencia=S.

[ermendalenda]

Empezado por delphiGar

consulta la FechaHoraHusoGenRegistro de los registros que vayas a enviar y si alguno tiene mas de 120 segundos de diferencia con respecto a la hora actual marca el paquete como Incidencia=S.

60+t
120 puede ser incorrecto en algunos casos

[FelixDL]

Empezado por ermendalenda

60+t
120 puede ser incorrecto en algunos casos

¿ Podías ser mas claro a que te refieres con "puede ser incorrecto en algunos casos"?

Yo últimamente recibo el error si es mas de 240 segundos. Pero por ahora mando "Incidencia=S" si veo que el registro mas antiguo tiene mas de 120 segundos. Quizás sería mejor crear variable para obtener los segundos a tener en cuenta. 120 o 240

[espinete]

Mi duda era en realidad si puedo enviar un bloque como Incidencia = S aunque solo algunas facturas de ese bloque vayan fuera de tiempo pero otras no.

Porque el campo Incidencia va en la cabecera del bloque, no en cada registro/factura.

[gcqZW]

Mi duda era en realidad si puedo enviar un bloque como Incidencia = S

No es mala cuestión para plantear a la AEAT, la verdad es que no recuerdo haber visto nada que diga algo al respecto, pero por lo pronto parece más lógico mandarla en el paquete que toque aunque solo una tenga incidencia, no vaya a ser que al mandar esa incidencia provoques otras más por desajuste de tiempos.

¿ Podías ser mas claro a que te refieres con "puede ser incorrecto en algunos casos"?

La AEAT te devuelve un tiempo de espera 't' que es el que tendrás que esperar entre envíos, pudiendo no ser exactamente 120

[FelixDL]

Empezado por gcqZW

No es mala cuestión para plantear a la AEAT, la verdad es que no recuerdo haber visto nada que diga algo al respecto, pero por lo pronto parece más lógico mandarla en el paquete que toque aunque solo una tenga incidencia, no vaya a ser que al mandar esa incidencia provoques otras más por desajuste de tiempos.


La AEAT te devuelve un tiempo de espera 't' que es el que tendrás que esperar entre envíos, pudiendo no ser exactamente 120

Buenas,

Creo que el tiempo t que se recibe en cada envío en <TiempoEsperaEnvio>60</TiempoEsperaEnvio>, no es el que estamos hablando, el que se recibe en cada envío es el tiempo que debe de pasar para poder realizar otro envío ( Siempre que no tengas mas de 1000 registros pendientes de envío que si puedes realizarlo)

El tiempo que creo estamos hablando es el máximo que puede pasar entre un envío y otro, que originalmente yo recibía 120 segundos y ahora estoy recibiendo 240 segundos.

Saludos

[gcqZW]

ah joder, culpa mia pues, obviad ese comentario.