Respuesta correcta cuando debería ser ¿incorrecta?

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

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.

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