Respuesta correcta cuando debería ser ¿incorrecta?

[Sandy656]

Hola a todos.

Partiendo de un registro, por ejemplo el ticket 1500 que se ha enviado con todos los datos correctos y devuelto como correcto.

Creamos el ticket 1501. Rellenamos el xml con los datos del registro anterior(1500).Se envía a la AEAT. Respuesta correcta.
Creamos el ticket 1502. Rellenamos el xml con los datos del registro anterior(1501). NO se envía.
Creamos el ticket 1503. Rellenamos el xml con los datos del registro anterior(1502 que no se ha enviado). Se envía a la AEAT. Respuesta correcta.

¿No debería devolver incorrecta ya que la AEAT no tiene el ticket 1502 que no se ha enviado?

[bmfranky]

Empezado por Sandy656

Hola a todos.

Partiendo de un registro, por ejemplo el ticket 1500 que se ha enviado con todos los datos correctos y devuelto como correcto.

Creamos el ticket 1501. Rellenamos el xml con los datos del registro anterior(1500).Se envía a la AEAT. Respuesta correcta.
Creamos el ticket 1502. Rellenamos el xml con los datos del registro anterior(1501). NO se envía.
Creamos el ticket 1503. Rellenamos el xml con los datos del registro anterior(1502 que no se ha enviado). Se envía a la AEAT. Respuesta correcta.

¿No debería devolver incorrecta ya que la AEAT no tiene el ticket 1502 que no se ha enviado?

Con los datos del registro anterior a que te refieres, a realizar el encadenamiento?, si encadenas con los datos de un registro no enviado, si que te dara un error.
Si te refieres que al enviar el anterior dio error de x, pero si aceptado, deveras encadenar con ese registro aunque erroneo y subsanar el error lo antes posible.
si te refieres a que rechazaron el envio o no subio por falta de rer, fallo del servicio, etc.. no "Puedes/Deves" enviar el siguiente, has de enviar en sucesion cronologica los envios.

[Sandy656]

Hola.
Efectivamente está encadenado con un registro que no se ha enviado.
He realizado estas pruebas varias veces y siempre me devuelve lo mismo.
Al enviar el ticket 1503 con los datos de encadenamiento del registro anterior (1502 que no se ha enviado) me lo devuelve como correcto. Sin más datos.

[bmfranky]

Empezado por Sandy656

Hola.
Efectivamente está encadenado con un registro que no se ha enviado.
He realizado estas pruebas varias veces y siempre me devuelve lo mismo.
Al enviar el ticket 1503 con los datos de encadenamiento del registro anterior (1502 que no se ha enviado) me lo devuelve como correcto. Sin más datos.

Pues ya ves, justo es uno de los casos que hasta ahora siempre tenian en cuenta que los datos de encadenamiento les constaran en el sistema, seguro que no da aceptado con errores o algo asi?

[Sandy656]

He realizado varias pruebas y siempre me da como correcto
La respuesta que me da es la siguiente, he ocultado el nombre y el nif. No me deja poner enlaces así que he puesto ENLACE donde van los enlaces de la AEAT.

Código PHP:

<?xml version="1.0"?>
ENLACE
  <env:Header/>
  <env:Body Id="Body">
    <tikR:RespuestaRegFactuSistemaFacturacion [color="YellowGreen"]ENLACE[/color]
[color="YellowGreen"]ENLACE
ENLACE
[/color]      <tikR:CSV>A-KM3GEZTKVGPXQV</tikR:CSV>
      <tikR:DatosPresentacion>
        <tik:NIFPresentador>XXXXXXXXXX</tik:NIFPresentador>
        <tik:TimestampPresentacion>2024-11-08T16:32:29+01:00</tik:TimestampPresentacion>
      </tikR:DatosPresentacion>
      <tikR:Cabecera>
        <tik:ObligadoEmision>
          <tik:NombreRazon>XXXXXXXXX</tik:NombreRazon>
          <tik:NIF>XXXXXXXXXC</tik:NIF>
        </tik:ObligadoEmision>
      </tikR:Cabecera>
      <tikR:TiempoEsperaEnvio>60</tikR:TiempoEsperaEnvio>
      <tikR:EstadoEnvio>Correcto</tikR:EstadoEnvio>
      <tikR:RespuestaLinea>
        <tikR:IDFactura>
          <tik:IDEmisorFactura>XXXXXXXXXX</tik:IDEmisorFactura>
          <tik:NumSerieFactura>21027</tik:NumSerieFactura>
          <tik:FechaExpedicionFactura>08-11-2024</tik:FechaExpedicionFactura>
        </tikR:IDFactura>
        <tikR:Operacion>
          <tik:TipoOperacion>Alta</tik:TipoOperacion>
        </tikR:Operacion>
        <tikR:EstadoRegistro>Correcto</tikR:EstadoRegistro>
      </tikR:RespuestaLinea>
    </tikR:RespuestaRegFactuSistemaFacturacion>
  </env:Body>
</env:Envelope>

Algo se me escapa o ¿ algo estoy haciendo mal?

[Sandy656]

Perdonad compañeros. Estaba equivocado.

Si que da error lo que ocurre es que yo enviaba enlazado el registro anterior , de una base de datos, donde buscaba el último registro marcado como correcto. El que no se envía no se marca como correcto y lo ignora buscando el último correcto.

Lo siento. Si se puede. borrar este hilo para no hacer peder el tiempo a nadie. Ha sido una metedura de pata mía.

Un saludo

[sglorka]

Empezado por Sandy656

Perdonad compañeros. Estaba equivocado.

Si que da error lo que ocurre es que yo enviaba enlazado el registro anterior , de una base de datos, donde buscaba el último registro marcado como correcto. El que no se envía no se marca como correcto y lo ignora buscando el último correcto.

Lo siento. Si se puede. borrar este hilo para no hacer peder el tiempo a nadie. Ha sido una metedura de pata mía.

Un saludo

No deberías eliminar este hilo ya que puede ayudar a mucha gente. Da igual el encadenamiento anterior que pongas, Verifactu sólo te va a informar que el registro es correcto si cumple con las reglas de validación ( de negocios y sintácticas ) y mientras esté bien calculada la huella en tu registro, independientemente de si tu huella anterior es incorrecta, para el sistema el registro está ok.
Luego habría que entrar en que no está encadenada correctamente con el registro anterior, pero eso es trabajo de la Aeat, analizarán porqué ocurre, cuántas veces, en qué momentos y si te tienen que llamar a capítulo lo harán.
Piensa que cuando te rechazan un registro y los posteriores te los aceptan, no te da error de Huella de los posteriores verdad ?

[Neftali [Germán.Estévez]]

Empezado por Sandy656

Partiendo de un registro, por ejemplo el ticket 1500 que se ha enviado con todos los datos correctos y devuelto como correcto.

Creamos el ticket 1501. Rellenamos el xml con los datos del registro anterior(1500).Se envía a la AEAT. Respuesta correcta.
Creamos el ticket 1502. Rellenamos el xml con los datos del registro anterior(1501). NO se envía.
Creamos el ticket 1503. Rellenamos el xml con los datos del registro anterior(1502 que no se ha enviado). Se envía a la AEAT. Respuesta correcta.

Empezado por Sandy656

Efectivamente está encadenado con un registro que no se ha enviado.
He realizado estas pruebas varias veces y siempre me devuelve lo mismo.
Al enviar el ticket 1503 con los datos de encadenamiento del registro anterior (1502 que no se ha enviado) me lo devuelve como correcto. Sin más datos.

Yo creo que es correcto, tal y como lo han diseñado, pensando en los envíos de forma asíncrona.

Son cosas diferentes, una el registro y otra el encadenamiento.

Que a ti te devuelvan que el registro es correcto, no quiere decir que luego internamente no controlen los encadenamientos. En el caso que tú has puesto, es posible que en primera instancia, el registro 1501 no se haya enviado por algún problema. Luego una vez que lo envíes todo estará cuadrado. Lo importante a nivel de facturación es que los encadenamientos como los has definido son correctos.

[Neftali [Germán.Estévez]]

Por favor, utilizar el TAG de código cuando añadáis código delphi y el de [php] (por ejemplo) cuando añadáis un XML.

[Basset]

Empezado por Sandy656

Hola a todos.

Partiendo de un registro, por ejemplo el ticket 1500 que se ha enviado con todos los datos correctos y devuelto como correcto.

Creamos el ticket 1501. Rellenamos el xml con los datos del registro anterior(1500).Se envía a la AEAT. Respuesta correcta.
Creamos el ticket 1502. Rellenamos el xml con los datos del registro anterior(1501). NO se envía.
Creamos el ticket 1503. Rellenamos el xml con los datos del registro anterior(1502 que no se ha enviado). Se envía a la AEAT. Respuesta correcta.

¿No debería devolver incorrecta ya que la AEAT no tiene el ticket 1502 que no se ha enviado?

Os dejo lo que me contestó el Departamento de Informática Tributaria:

"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 está en nuestro tejado.

En este tipo de situaciones, tenga en cuenta que el XML generado no se puede modificar, sino que debe permanecer inalterado, según se describe en el reglamento. Se debe generar un nuevo registro, de alta por rechazo, o el que corresponda, con su nueva huella, etc y no se debe volver a enviar el mismo registro rechazado."


Saludos.