Ley antifraude 2021 (VERIFACTU) - Programas informáticos

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

Creo que hay un pequeño lio de varias cosas aquí.
Empezando por el título, aquí nohay sustitutivas, aquí estas intentando hacer una rectificativa por sustitucion de una factura f1.
Las sustitutivas (f3) son emitidas para sustituir las de tipo f2.
Para las facturas por sustitución no hay que hacer anulaciones, algún compañerote lo podrá explicar mejor, ya que las rectificativas que yo tengo son por diferencias no hago de sustitución
El caso que has planteando estas aplicando una doble negativa, al anular y emitir un abono y se te quedaría todo a 0, como si no hubieras emitido nada.
Además las facturas rectificativas por sustitución también tienen 2 formas de hacerlas y dependiendo de lo que quieras hacer o mejor se adapte a tu software, es mejor qur lo veas claro.es un punto un poco lioso en el reglamento

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