Cita:
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
Código:
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.
Código:
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.