Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[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 ?

[pablog2k]

Empezado por sglorka

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

de A12, que es la que subí cronológicamente antes de la A13.
Relleno el encadenamiento de la A13 con los datos de la A12 (numserie,fecha,huella) , que fueron los datos que puse mal y me dijeron que los arreglara, y sobre ese registro, genero la huella y la guardo en el registro de A13, para cuando haga la A14

[sglorka]

Empezado por pablog2k

de A12, que es la que subí cronológicamente antes de la A13.
Relleno el encadenamiento de la A13 con los datos de la A12 (numserie,fecha,huella) , que fueron los datos que puse mal y me dijeron que los arreglara, y sobre ese registro, genero la huella y la guardo en el registro de A13, para cuando haga la A14

La Huella anterior que debes coger para formar el registro de subsanación de A13 es la huella del registro de A13 que te aceptaron con errores

[pablog2k]

Empezado por sglorka

La Huella anterior que debes coger para formar el registro de subsanación de A13 es la huella del registro de A13 que te aceptaron con errores

creo que no es correcto lo que me comentas, ya que la huella anterior según su documentación es lo siguiente:
Primeros 64 caracteres de la huella o «hash» del registro de facturación anterior (sea de alta o de anulación) generado en este sistema informático.
en mi opinión, si yo subo la factura A12, luego la A13, y me la aceptan con errores, si voy a subsanar A13, el registro de facturación anterior es A12, no A13 que subí previamente pero me dio errores (me parecería mucho más lioso). De hecho hasta que no subes como subsanación el HASH o huella de A12, no te da como correcta la A13.

[rci]

Empezado por sglorka

La Huella anterior que debes coger para formar el registro de subsanación de A13 es la huella del registro de A13 que te aceptaron con errores

Empezado por pablog2k

creo que no es correcto lo que me comentas, ya que la huella anterior según su documentación es lo siguiente:
Primeros 64 caracteres de la huella o «hash» del registro de facturación anterior (sea de alta o de anulación) generado en este sistema informático.
en mi opinión, si yo subo la factura A12, luego la A13, y me la aceptan con errores, si voy a subsanar A13, el registro de facturación anterior es A12, no A13 que subí previamente pero me dio errores (me parecería mucho más lioso). De hecho hasta que no subes como subsanación el HASH o huella de A12, no te da como correcta la A13.

Yo diría que tiene razón sglorka pero a ver si alguien mas puede opinar.

[sglorka]

Empezado por pablog2k

creo que no es correcto lo que me comentas, ya que la huella anterior según su documentación es lo siguiente:
Primeros 64 caracteres de la huella o «hash» del registro de facturación anterior (sea de alta o de anulación) generado en este sistema informático.
en mi opinión, si yo subo la factura A12, luego la A13, y me la aceptan con errores, si voy a subsanar A13, el registro de facturación anterior es A12, no A13 que subí previamente pero me dio errores (me parecería mucho más lioso). De hecho hasta que no subes como subsanación el HASH o huella de A12, no te da como correcta la A13.

Te estás respondiendo tú mismo

Primeros 64 caracteres de la huella o «hash» del registro de facturación anterior (sea de alta o de anulación) generado en este sistema informático

[pablog2k]

Empezado por sglorka

Te estás respondiendo tú mismo

Primeros 64 caracteres de la huella o «hash» del registro de facturación anterior (sea de alta o de anulación) generado en este sistema informático

bueno, creo que tenemos conceptos distintos de lo que es 'factura anterior'.
Para mi la factura anterior a A13 es A12, aunque estés subsanando la A13, de hecho todo el encadenamiento (en mi opinión) está hecho para que las facturas 'físicamente' vayan 'encadenadas' unas con otras, no para que la A13 encadene con la A12, la A13 subsanada encadene con la A13 sin subsanar, la A13 subsanada dos veces encadene con la A13 subsanada una vez....
Al final conforme vayan refinando las respuestas de OK y no OK saldremos de dudas , porque según parece ahora 'traga' con casi todo

[sglorka]

Empezado por pablog2k

bueno, creo que tenemos conceptos distintos de lo que es 'factura anterior'.
Para mi la factura anterior a A13 es A12, aunque estés subsanando la A13, de hecho todo el encadenamiento (en mi opinión) está hecho para que las facturas 'físicamente' vayan 'encadenadas' unas con otras, no para que la A13 encadene con la A12, la A13 subsanada encadene con la A13 sin subsanar, la A13 subsanada dos veces encadene con la A13 subsanada una vez....
Al final conforme vayan refinando las respuestas de OK y no OK saldremos de dudas , porque según parece ahora 'traga' con casi todo

Mi recomendación es que hagas la consulta a Verifactu.

[rci]

Empezado por sglorka

Te estás respondiendo tú mismo

Primeros 64 caracteres de la huella o «hash» del registro de facturación anterior (sea de alta o de anulación) generado en este sistema informático

Empezado por pablog2k

bueno, creo que tenemos conceptos distintos de lo que es 'factura anterior'.
Para mi la factura anterior a A13 es A12, aunque estés subsanando la A13, de hecho todo el encadenamiento (en mi opinión) está hecho para que las facturas 'físicamente' vayan 'encadenadas' unas con otras, no para que la A13 encadene con la A12, la A13 subsanada encadene con la A13 sin subsanar, la A13 subsanada dos veces encadene con la A13 subsanada una vez....
Al final conforme vayan refinando las respuestas de OK y no OK saldremos de dudas , porque según parece ahora 'traga' con casi todo

A continuación mi opinión basada en una consulta a hacienda:

No es lo mismo un "registro de facturación" que una "factura".
Un registro de facturación se refiere al XML que se genera. Esto es lo que es inalterable y lo que se tiene que encadenar.
Puede haber mas de un registro de facturación para cada factura.
Al crear la factura generas un registro de facturación y lo envías, puede contestar aceptada con errores, lo corriges y generas un nuevo registro de facturación (sobre la misma factura) y lo envías, encadenado con el anterior "registro de facturación", no con la anterior factura.

Espero que alguien más de su opinión y lo aclaramos.

[bmfranky]

Empezado por sglorka

Te estás respondiendo tú mismo

Primeros 64 caracteres de la huella o «hash» del registro de facturación anterior (sea de alta o de anulación) generado en este sistema informático

Hola, creo que estais mezclando saraos,en el caso de subsanacion del encadenamiento, solo tenemos que tener en cuenta los datos de encadenamiento de esa factura/registro no los posteriores, tened en cuenta que tenemos que reenviar todo el registro igual, menos la cadena has y poner que es subsanacion/correccion, nada mas.
tened en cuenta que para los encadenamientos sucesivos, ellos tienen en cuenta, no la huella que nosotros enviamos, sino la que ellos calculan.

[delphiGar]

Empezado por sglorka

La Huella anterior que debes coger para formar el registro de subsanación de A13 es la huella del registro de A13 que te aceptaron con errores

Tienes toda la razon sglorka, la consulta la hice yo y es asi como tu dices, es decir hay que coger la huella inmedianteme anterior al ultimo registro.

Pregunta a al AEAT

Tengo 5 registros de Alta para enviar, cada uno encadenado con el anterior mediante el hash correspondiente, 
si el 2 registro me lo rechaza por ejemplo por que el tipo impositivo es incorrecto como debo actuar.

Si envio el 2 registro de nuevo ya corregido, el hash si lo calculo con el registro anterior que me dio por bueno y 
el nuevo hash sera distinto por el importe de nuevo calculado, con lo cual el encadenamiento para los registros 3, 4 y 5 tampoco sera valido. 
En este caso subsano los registros 3, 4 y 5 con el nuevo hash o envio el 2 registro encadenado con el ultimo hash del ultimo enviado como correcto y 
dejo los demas registro tal cual.

Contestacion:

Buenos días:

En el caso planteado, tenga en cuenta que para solucionar el error del registro 2 (siempre y cuando no corresponda la emisión de una factura rectificativa) deberá generar un nuevo registro de facturación de tipo "ALTA POR RECHAZO" con el error corregido. El encadenamiento siempre será en orden cronológico, por lo que este nuevo registro (siguiendo la serie, sería el registro 6) irá encadenado con el registro 5.

Efectivamente se producirá un salto en la cadena entre el registro 1 y 3 pero es algo que desde la AEAT ya se tendrá en cuenta por lo que no debe subsanar los registros posteriores con nuevas huellas.

En este tipo de situaciones, puede darse el caso de algún salto en el encadenamiento. Los registros se admitirán aunque el encadenamiento no sea el 

correcto. Aunque existan estos saltos , algo que desde la AEAT asumimos y prevemos que ocurra, tenemos la forma de detectar esta circunstancias excepcionales ya

que quedarán marcadas convenientemente 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.

[pablog2k]

bueno pues tras leer la respuesta que te dio Hacienda, veo que lleváis razón, no consideran que nº de factura sea igual que registro, y por lo tanto si subo las facturas A1 a A5, y luego modifico la A2, esta irá encadenada con A5, y luego cuando suba A6 irá encadenada con la subsanación de A2.
Personalmente me parece un lío, pero bueno, habrá que adaptarse a lo que digan.
gracias por las respuestas

[bmfranky]

Empezado por pablog2k

bueno pues tras leer la respuesta que te dio Hacienda, veo que lleváis razón, no consideran que nº de factura sea igual que registro, y por lo tanto si subo las facturas A1 a A5, y luego modifico la A2, esta irá encadenada con A5, y luego cuando suba A6 irá encadenada con la subsanación de A2.
Personalmente me parece un lío, pero bueno, habrá que adaptarse a lo que digan.
gracias por las respuestas

Entonces, lo que hay que hacer es guardar el encadenamiento en una tabla y cada vez que hacemos un envio, rectificacion o lo que sea , siempre usar los datos de la ultima entrada de la tabla, sea la que sea , podria ser abono de una factura del año pasado, da lo mismo , el ecadenamiento sera sobre los ultimos datos introducidos.

[bmfranky]

Hola siguiendo con mi ritmo, ahora me toca las sutitutivas por cliente erroneo, la operativa seria.
Siendo A mis facturas B los registros enviados a la aeat teniendo en cuanta que la factura ya se ha emitido, enviado con su respectivo rsgistro mi factura Fac001.
1-> emito una factura F1 Fac002, con las cantidades en negativo , genero mi factura A, que imprimo por si se la he enviado al cliente anterior.
Genero un registro de Anulacion Bn4 con los datos de la factura Fac001, encadenado con el registro anterior sea cual sea (por claridad n3)

2-> emito una factura F1 Fac003 con los datos ya correctos para enviar al cliente correcto.
Genero un registro de alta, Bn5 con los datos de la factura Fac003, encadenado con Bn4.


Esto seria lo correcto o en vez de la factura F1 Fac002, seria una Rectificativa R1?


Perdonad la obbiedad pero soy muy ceporro con las cosas que no he hecho nunca hasta que las comprendo.

[ermendalenda]

Empezado por delphiGar

Tienes toda la razon sglorka, la consulta la hice yo y es asi como tu dices, es decir hay que coger la huella inmedianteme anterior al ultimo registro.

Pregunta a al AEAT

Tengo 5 registros de Alta para enviar, cada uno encadenado con el anterior mediante el hash correspondiente, 
si el 2 registro me lo rechaza por ejemplo por que el tipo impositivo es incorrecto como debo actuar.

Si envio el 2 registro de nuevo ya corregido, el hash si lo calculo con el registro anterior que me dio por bueno y 
el nuevo hash sera distinto por el importe de nuevo calculado, con lo cual el encadenamiento para los registros 3, 4 y 5 tampoco sera valido. 
En este caso subsano los registros 3, 4 y 5 con el nuevo hash o envio el 2 registro encadenado con el ultimo hash del ultimo enviado como correcto y 
dejo los demas registro tal cual.

Contestacion:

Buenos días:

En el caso planteado, tenga en cuenta que para solucionar el error del registro 2 (siempre y cuando no corresponda la emisión de una factura rectificativa) deberá generar un nuevo registro de facturación de tipo "ALTA POR RECHAZO" con el error corregido. El encadenamiento siempre será en orden cronológico, por lo que este nuevo registro (siguiendo la serie, sería el registro 6) irá encadenado con el registro 5.

Efectivamente se producirá un salto en la cadena entre el registro 1 y 3 pero es algo que desde la AEAT ya se tendrá en cuenta por lo que no debe subsanar los registros posteriores con nuevas huellas.

En este tipo de situaciones, puede darse el caso de algún salto en el encadenamiento. Los registros se admitirán aunque el encadenamiento no sea el 

correcto. Aunque existan estos saltos , algo que desde la AEAT asumimos y prevemos que ocurra, tenemos la forma de detectar esta circunstancias excepcionales ya

que quedarán marcadas convenientemente 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.

Pues esto es una buena noticia dentro de todo este lío.
Gracias.