Cita:
Empezado por jalvar28
He notado lo mismo (ya lo comento en un post previo). El sistema acepta facturas incluso si están encadenadas con números inexistentes. Por ejemplo, si le proporcionas una factura con el formato '00001/pepitodelospalotes/2024', la procesa sin alertar de ningún error. Esto refleja una falta de validación adecuada, y no me parece serio que no se revisen estos detalles básicos.
var encadenamientoFacturaAnterior = new EncadenamientoFacturaAnteriorType();
encadenamientoFacturaAnterior.IDEmisorFactura = cifEmisor;
encadenamientoFacturaAnterior.NumSerieFactura = "00001/pepitodelospalotes/2024";//numero factura nunca añadida anteriormente
encadenamientoFacturaAnterior.FechaExpedicionFactura = "02-02-2024";//fecha factura anterior
encadenamientoFacturaAnterior.Huella = "7F3D68A9B8C39A1D29C7B4F54E6FA318CBD26317F02C89DF1A6477E3952D8F3E";//huella generada por ia
Lo acepta como correcto.
|
Gracias por responder, acabo de ver que exponías lo mismo la semana pasada.
Le he consultado este tema de la validación de los encadenamientos al correo de consultas de la aeat y me acaban de responder esto:
Buenos días:
Aunque existan saltos en la cadena de registros de facturación, algo que desde la AEAT asumimos y prevemos que ocurra, tenemos la forma de detectar esta circunstancias excepcionales ya que quedarán marcadas convenientemente con los indicadores de la operativas comentadas y serán fáciles de trazas 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 corresponde a la AEAT.
Atentamente,
Atención al Usuario
Departamento de Informática Tributaria