Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[ermendalenda]

Empezado por bmfranky

Hola, ahi esta , que has vuelto a enviar como primer registro, eso es trampa, si encadenas mal, hasta que encadenes bien *falla. Mejor dicho da aceptado con errores, si das como primer registro, te pone a cero el encadenamiento, por lo menos de momento.

Que va.
Lo he hecho 2 o 3 veces rompiendo encadenamiento y sd lo come todo. Que raro que a unos sí y a otros no.

[ermendalenda]

Ahora toca a analizar todas ests movidas y las posibles combinaciones:
Incidencia, subsanacion, rechazo previo, tiempo de espera próximo envío.

Hay que sentarse con la librería y ver qué se puede automatizar, que puede decidir un usuario y "que cosa"
tienen que llamar a un informático.
De momento veo un gran enredo de tres pares de narices y 2 paquetes de ibuprofeno de 600.
No por saber que hay que enviar en cada situación, si no en evitar confusiones y que además no se quede en el olvido.

[ermendalenda]

No creo que esto llegue a buen puerto, van a tener que simplificar más. La mayoría de los que estamos aquí le estamos dedicando decenas de horas, pero cuando esto les toque a los miles de desarrolladores de programas hechos con mucho esfuerzo para empresas con programas muy específicos y que ha costado muchísimo tiempo y el desarrollador diga que en esto no se mete, va a haber un gran problema, se van a cargar el particular ecosistema de desarrollos y obligarán a las empresas a comprar softwares a multinacionales que no atenderán las demandas de estas empresas como estaban acostumbrados, en cuando a rapidez y de tú a tú y ya sabemos como trabajan los desarrollos de programas distribuidos a media y gran escala.
Me temo que va a haber repercusiones políticas. Al final no sé si merece la pena adelantarse tanto. Peor claro el miedo a que nos pille el toro nos puede a todos.
Es que no es normal de que nos caiga la mochila de todo:
Que si los servidores están cargados tengamos el programa preparado para la ralentizar los envíos al ritmo que vayan imponiendo.
Que la forma de actuar ante una incidencia este tan complicada para los desarrolladores y suaurios para que ellos tengan los datos súper limpitos para analizar lo mínimo posible.
Que sea todo un riesgo, hasta que te quedes sin Internet y la pila del PC re juegue una mala pasada con la fecha/hora del sistema.
Que haya que estar conectado a las comprobaciones de hacienda de correspondencia de nifs/nombres.

Y otros problema lógicos que se me ocurren que puede pasar y te quedas en bragas ante la aeat por que ellos dicen que tú tienes que tenerlo todo atado, hasta lo imposible.
Por ejemplo, les hice una consulta de que existe un margen de tiempo de caché de grabación al disco en el que se puede perder el dato impreso, y que incluso ante una avería se pierda y no he haya dado tiempo a enviarlo ni hacer copia. Y si el cliente se ha llevado su qr nos podemos meter en un lío y contestan que la ley antifraude obliga a blablabla.

[Logan05]

Empezado por ermendalenda

... cuando esto les toque a los miles de desarrolladores de programas hechos con mucho esfuerzo para empresas con programas muy específicos y que ha costado muchísimo tiempo y el desarrollador diga que en esto no se mete, va a haber un gran problema, se van a cargar el particular ecosistema de desarrollos y obligarán a las empresas a comprar softwares a multinacionales que no atenderán las demandas de estas empresas como estaban acostumbrados, en cuando a rapidez y de tú a tú y ya sabemos como trabajan los desarrollos de programas distribuidos a media y gran escala.
Me temo que va a haber repercusiones políticas. Al final no sé si merece la pena adelantarse tanto. Peor claro el miedo a que nos pille el toro nos puede a todos.

En esa situación me encuentro yo, tengo ocho programas de facturación super SUPER a medida, cada uno para un solo cliente, estoy entre que me pille el toro y dejar el negocio, porque esto de negocio ya tenía poco antes, pero ahora me parece que será una ruina total. Lastima que ya tampoco me dejan prejubilarme.....

[bmfranky]

Empezado por ermendalenda

Que va.
Lo he hecho 2 o 3 veces rompiendo encadenamiento y sd lo come todo. Que raro que a unos sí y a otros no.

Ya, pasan cosas muy raras ya os comentaba que es como si hubieran servidores con varias versiones del programa que usen para atender a las peticiones, porque contetan de formas demasiodo diferentes.

[ermendalenda]

Empezado por bmfranky

Ya, pasan cosas muy raras ya os comentaba que es como si hubieran servidores con varias versiones del programa que usen para atender a las peticiones, porque contetan de formas demasiodo diferentes.

Puedes poner como haces el enlace de donde de como haces sl la peticion del soap. A ver si es qu3 estoy poniendo algo diferente.

[ermendalenda]

A ver si me explico,
Si enviamos un registro y después una subsanacion sin rechazo previo y esta última nos la rechaza, se supone que su queremos volver a mandar la subsanacion es sin rechazo previo, no?
O sea, los rechazos de las subsanaciones no hay que tenerlos en cuenta al intentar reenviarlo correctamente pero nosotros si tenemos que tener en cuenta que nos lo ha rechazado

[ermendalenda]

Enviamos una factura, anulamos por error otra y la enviamos, y además pertenece a otro periodo impositivo la que hemos anulado por error.
Supongo que hay que volver a emitir una nueva de la que hemos anulado ¿con la fecha de la anterior?, aparte del lío de hablar con el cliente que lo mismo está en SII y ya se la ha declarado.
Ahora el cliente tiene que anular esa factura del SII (y que lo haga)
Vaya lio no?
PROHIBIDO EQUIVOCARSE.

[bmfranky]

Empezado por ermendalenda

Enviamos una factura, anulamos por error otra y la enviamos, y además pertenece a otro periodo impositivo la que hemos anulado por error.
Supongo que hay que volver a emitir una nueva de la que hemos anulado ¿con la fecha de la anterior?, aparte del lío de hablar con el cliente que lo mismo está en SII y ya se la ha declarado.
Ahora el cliente tiene que anular esa factura del SII (y que lo haga)
Vaya lio no?
PROHIBIDO EQUIVOCARSE.

Hola, simplemente haces un alta por subsanacion , con todos los datos de la factura anulada, segun la operativa, obtienes.

OK(5) = Reactiva(vuelve a dejar de alta y en vigor) el registro de facturación anulado existente, sustituyendo completamente el registro de facturación registrado con los nuevos datos recibidos

Lo acabo de leer en el documento de validaciones.

[bmfranky]

Empezado por ermendalenda

A ver si me explico,
Si enviamos un registro y después una subsanacion sin rechazo previo y esta última nos la rechaza, se supone que su queremos volver a mandar la subsanacion es sin rechazo previo, no?
O sea, los rechazos de las subsanaciones no hay que tenerlos en cuenta al intentar reenviarlo correctamente pero nosotros si tenemos que tener en cuenta que nos lo ha rechazado

Hola, en el documento de validaciones pone esto:

ALTA POR RECHAZO DE
SUBSANACIÓN
· Al ta pa ra la s ubs a na ci ón de un regi s tro de
fa ctura ci ón que ya es tá regis tra do en l a AEAT y cuya
s ubs a na ci ón pos teri or fue recha za da .
· Es l a s ubs a na ción de da tos cua ndo no s e exi ge l a
emis i ón de una fa ctura rectifica tiva (u otro
meca ni s mo contempl a do en el Regl a mento de
Fa ctura ci ón).



· <Subs a na ci on>=S
· <Recha zoPrevi o>=S


VERI*FACTU
· La cla ve úni ca del regis tro de fa ctura ci ón
debe exi s tir previa mente en la AEAT.
· El a lta con s ubs a na ci ón del regi s tro de
fa ctura ción fue recha za da .
Con él s e deja cons tancia de los
nuevos da tos que deben s er tenidos
en cuen

[ermendalenda]

Empezado por bmfranky

Hola, en el documento de validaciones pone esto:

Ok gracias
Anotado

[pablog2k]

Empezado por ermendalenda

Que va.
Lo he hecho 2 o 3 veces rompiendo encadenamiento y sd lo come todo. Que raro que a unos sí y a otros no.

buenas, yo acabo de hacer unas pruebas y si que me comprueba el encadenamiento:

-subo la factura A12 (encadena con la A11), respuesta OK.
-subo la factura A13 (me invento el encadenamiento, pongo que encadena con la B1234 que ni siquiera existe, me invento los valores del nodo Encadenamiento.RegistroAnterior), respuesta Aceptada con errores, error en la huella.
-subo la factura A13 como subsanación, poniendo bien los valores de Encadenamiento (Encadena con A12, relleno bien IdEmisorFactura,NumSerieFactura,FechaExpedicionFactura y Huella) , respuesta OK.
-subo la factura A14 (encadena con la A13, con la huella de la subsanación de la A13), respuesta OK.

[sglorka]

Empezado por pablog2k

buenas, yo acabo de hacer unas pruebas y si que me comprueba el encadenamiento:

-subo la factura A12 (encadena con la A11), respuesta OK.
-subo la factura A13 (me invento el encadenamiento, pongo que encadena con la B1234 que ni siquiera existe, me invento los valores del nodo Encadenamiento.RegistroAnterior), respuesta Aceptada con errores, error en la huella.
-subo la factura A13 como subsanación, poniendo bien los valores de Encadenamiento (Encadena con A12, relleno bien IdEmisorFactura,NumSerieFactura,FechaExpedicionFactura y Huella) , respuesta OK.
-subo la factura A14 (encadena con la A13, con la huella de la subsanación de la A13), respuesta OK.

El encadenamiento siempre tiene que ser con el registro generado anteriormente en orden cronológico para el mismo SIF. La tercera operación que has hecho, -subo la factura A13 como subsanación, poniendo bien los valores de Encadenamiento (Encadena con A12, relleno bien IdEmisorFactura,NumSerieFactura,FechaExpedicionFactura y Huella) , respuesta OK.

no debería ser correcta ya que no estás encadenando con el registro anterior de factura A13 que sí fue aceptado, aunque con errores. Para subsanar una huella no puedes saltarte la cadena cronológica aunque parezca que en realidad no estás subsanando nada. Esto ya lo he consultado con el correo de Verifactu. Si te responde Ok en porque ellos internamente habrán decidido eso pero saben perfectamente que el encadenamiento está mal

[pablog2k]

Empezado por sglorka

El encadenamiento siempre tiene que ser con el registro generado anteriormente en orden cronológico para el mismo SIF. La tercera operación que has hecho, -subo la factura A13 como subsanación, poniendo bien los valores de Encadenamiento (Encadena con A12, relleno bien IdEmisorFactura,NumSerieFactura,FechaExpedicionFactura y Huella) , respuesta OK.

no debería ser correcta ya que no estás encadenando con el registro anterior de factura A13 que sí fue aceptado, aunque con errores. Para subsanar una huella no puedes saltarte la cadena cronológica aunque parezca que en realidad no estás subsanando nada. Esto ya lo he consultado con el correo de Verifactu. Si te responde Ok en porque ellos internamente habrán decidido eso pero saben perfectamente que el encadenamiento está mal

no acabo de entender lo que dices:
subo la A12 encadena con A11, ok
subo A13 encadena con B21324(inventada), Aceptada con errores (arregla la huella me dicen)
subo A13 corregida que encadena con A12 (huella ok ) contesta OK
subo A14 encadena A13, contesta OK
el orden cronológico lo he seguido.
precisamente lo que he arreglado es el encadenamiento de la A13 que apuntaba a una inventada y le e dicho que apunte a la A12 que cronológicamente es la anterior

[sglorka]

Empezado por pablog2k

no acabo de entender lo que dices:
subo la A12 encadena con A11, ok
subo A13 encadena con B21324(inventada), Aceptada con errores (arregla la huella me dicen)
subo A13 corregida que encadena con A12 (huella ok ) contesta OK
subo A14 encadena A13, contesta OK
el orden cronológico lo he seguido

Para formar la huella en la tercera operación, ¿ Qué huella anterior estás tomando, la de el registro de alta inicial de A13 o la de A12 ?
Sólo puedes coger la del alta inicial de A13

[pablog2k]

Empezado por sglorka

Para formar la huella en la tercera operación, ¿ Qué huella anterior estás tomando, la de el registro de alta inicial de A13 o la de A12 ?
Sólo puedes coger la del alta inicial de A13

yo me guardo en base de datos de cada registro enviado, el valor del campo Huella (el SHA256 calculado de 64 caracteres), entonces cuando hago el siguiente registro, relleno los datos de encadenamiento asi:

Código Delphi [-]
  ARegistroFactura[0].RegistroAlta.Encadenamiento.RegistroAnterior := SistemaFacturacion.EncadenamientoFacturaAnteriorType.Create;
  ARegistroFactura[0].RegistroAlta.Encadenamiento.RegistroAnterior.IdEmisorFactura := 'B97486070';
  ARegistroFactura[0].RegistroAlta.Encadenamiento.RegistroAnterior.NumSerieFactura := 'A12';
  ARegistroFactura[0].RegistroAlta.Encadenamiento.RegistroAnterior.FechaExpedicionFactura := '23-10-2024';
  ARegistroFactura[0].RegistroAlta.Encadenamiento.RegistroAnterior.Huella := 'EA1128619C488A282B3B544EBFEB2FE0BDDAC52C12CA7BD75019EDE49AAE6ED5';

En mi caso , cuando subo la primera vez el A13, pongo los datos de encadenamiento de A12 bien , pero el numserieFactura lo pongo mal a propósito. Genero la huella de A13 y subo el registro.
Hacienda me contesta que está mal, que lo arregle.
Vuelvo a subir A13, como subsanacion, ahora rellenando bien RegistroAnterior.NumSerieFactura , genero la huella y la guardo. Envío y Hacienda contesta OK.
Genero la A14, con la huella buena de la A13, la subo y OK
creo que los pasos que he seguido son los normales a la hora de arreglar un error de encadenamiento (subes una factura, te dice aceptada pero arregla el encadenamiento, lo arreglas, guardas huella bien hecha, subes a hacienda, responde OK)

[sglorka]

Empezado por pablog2k

yo me guardo en base de datos de cada registro enviado, el valor del campo Huella (el SHA256 calculado de 64 caracteres), entonces cuando hago el siguiente registro, relleno los datos de encadenamiento asi:

ARegistroFactura[0].RegistroAlta.Encadenamiento.RegistroAnterior := SistemaFacturacion.EncadenamientoFacturaAnteriorType.Create;
ARegistroFactura[0].RegistroAlta.Encadenamiento.RegistroAnterior.IdEmisorFactura := 'B97486070';
ARegistroFactura[0].RegistroAlta.Encadenamiento.RegistroAnterior.NumSerieFactura := 'A13';
ARegistroFactura[0].RegistroAlta.Encadenamiento.RegistroAnterior.FechaExpedicionFactura := '23-10-2024';
ARegistroFactura[0].RegistroAlta.Encadenamiento.RegistroAnterior.Huella := 'EA1128619C488A282B3B544EBFEB2FE0BDDAC52C12CA7BD75019EDE49AAE6ED5';

En mi caso , cuando subo la primera vez el A13, pongo los datos de encadenamiento de A12 bien , pero el numserieFactura lo pongo mal a propósito. Genero la huella de A13 y subo el registro.
Hacienda me contesta que está mal, que lo arregle.
Vuelvo a subir A13, como subsanacion, ahora rellenando bien RegistroAnterior.NumSerieFactura , genero la huella y la guardo. Envío y Hacienda contesta OK.
Genero la A14, con la huella buena de la A13, la subo y OK
creo que los pasos que he seguido son los normales a la hora de arreglar un error de encadenamiento (subes una factura, te dice aceptada pero arregla el encadenamiento, lo arreglas, guardas huella bien hecha, subes a hacienda, responde OK)

¿ De qué registro estás cogiendo la huella anterior para generar la huella de A13 cuándo la subes como subsanación ?

[antoine0]

Empezado por sglorka

El encadenamiento siempre tiene que ser con el registro generado anteriormente en orden cronológico para el mismo SIF. La tercera operación que has hecho, -subo la factura A13 como subsanación, poniendo bien los valores de Encadenamiento (Encadena con A12, relleno bien IdEmisorFactura,NumSerieFactura,FechaExpedicionFactura y Huella) , respuesta OK.

no debería ser correcta ya que no estás encadenando con el registro anterior de factura A13 que sí fue aceptado, aunque con errores. Para subsanar una huella no puedes saltarte la cadena cronológica aunque parezca que en realidad no estás subsanando nada. Esto ya lo he consultado con el correo de Verifactu. Si te responde Ok en porque ellos internamente habrán decidido eso pero saben perfectamente que el encadenamiento está mal

Estoy contigo sobre lo que es lo correcto: si el SIF ha generado A13malo, debe encadenar la siguiente (A13bueno) con este mismo A13malo, no con A12.
Y estoy seguro que esta secuencia (A13bueno encadenada con A13malo y marcada subsanación) será aceptada por AEAT.

Ahora bien, puede haber caso de operatividad que permiten secuencias como:

• se genera A12 limpiamente
• se empieza a generar un A13, hay un problema, el sistema se raya, envía un A13malo y al mismo tiempo se cae (incluso puede llegar a no recuperar la respuesta al envío de A13malo)
• se recupera el sistema, en la base la cadena tiene entonces A12 como última (el SIF no sabe nada de A13)
• se envía la siguiente, A13bueno, encadenada con A12
• este envío está descartado por AEAT ya que "A13" ya existe en el sistema de AEAT (aunque ¡no existe en el SIF!)
• se reenvía A13bueno como subsanación (sin cambiar nada)

Visto desde la AEAT, la secuencia será efectivamente la que lo que ha probado @pablog2K. Y creo que es admisible (aunque se necesitan dos incidentes, que se raye y que se caiga).

[sglorka]

Empezado por antoine0

Estoy contigo sobre lo que es lo correcto: si el SIF ha generado A13malo, debe encadenar la siguiente (A13bueno) con este mismo A13malo, no con A12.
Y estoy seguro que esta secuencia (A13bueno encadenada con A13malo y marcada subsanación) será aceptada por AEAT.

Ahora bien, puede haber caso de operatividad que permiten secuencias como:

• se genera A12 limpiamente
• se empieza a generar un A13, hay un problema, el sistema se raya, envía un A13malo y al mismo tiempo se cae (incluso puede llegar a no recuperar la respuesta al envío de A13malo)
• se recupera el sistema, en la base la cadena tiene entonces A12 como última (el SIF no sabe nada de A13)
• se envía la siguiente, A13bueno, encadenada con A12
• este envío está descartado por AEAT ya que "A13" ya existe en el sistema de AEAT (aunque ¡no existe en el SIF!)
• se reenvía A13bueno como subsanación (sin cambiar nada)

Visto desde la AEAT, la secuencia será efectivamente la que lo que ha probado pablo2K. Y creo que es admisible (aunque se necesitan dos incidentes, que se raye y que se caiga).

Bueno esta situación, en teoría, no podría darse, y no me refiero a que se caiga el sistema, me refiero a esta suposición que haces "se recupera el sistema, en la base la cadena tiene entonces A12 como última (el SIF no sabe nada de A13)". Si en el paso anterior has podido enviar A13 y la ha aceptado la Aeat, es por que la tienes registrada en tu sistema, que luego no te enteres de la respuesta porque el sistema se haya caido no es problema porque volverías a enviar A13 (se supone que tu algoritmo la tiene marcada como no enviada) y te daría registro duplicado en la Aeat y aquí no ha pasado nada.
En mi cabeza no cabe que un registro que se envía a la Aeat no esté almacenado en el Sif. El código que se desarrolle para tal cometido, al menos, debe asegurar este punto.

[ermendalenda]

Empezado por sglorka

Bueno esta situación, en teoría, no podría darse, y no me refiero a que se caiga el sistema, me refiero a esta suposición que haces "se recupera el sistema, en la base la cadena tiene entonces A12 como última (el SIF no sabe nada de A13)". Si en el paso anterior has podido enviar A13 y la ha aceptado la Aeat, es por que la tienes registrada en tu sistema, que luego no te enteres de la respuesta porque el sistema se haya caido no es problema porque volverías a enviar A13 (se supone que tu algoritmo la tiene marcada como no enviada) y te daría registro duplicado en la Aeat y aquí no ha pasado nada.
En mi cabeza no cabe que un registro que se envía a la Aeat no esté almacenado en el Sif. El código que se desarrolle para tal cometido, al menos, debe asegurar este punto.

Si de ha enviado seguramente puedas consultarla cuando hagan la web, debes generar la factura a13 de nuevo y enviarla como subsanacion, si r3cibes la r3spuesta que ya está en el sistema tienes que recibir esa notificación y saber que tienes que hacer.
El problema es que hayas emitido la factura con su qr y no haya dado tiempo a enviarla antes de la avería y es un escenario posible y un potencial problema aquí no cabe subsanacion.