Duda Encadenamientos

[gcqZW]

En el caso de que envies un xml vacio o no informes del encadenamiento, como se seguiría el encadenamiento??? Alta por rechazo previo seguro, pero que habría que poner en el RegistroAnterior ??
Podria ser hacer el hash de:
IDEmisorFactura=&NumSerieFactura=&FechaExped icionFactura=&TipoFactura=&CuotaTotal=&ImporteTotal=&Huella=&FechaHoraHusoGenRegistro=
sin dato alguno??

[diegorgm]

Hola!

Entiendo que hay que encadenar todos los registros independientemente de si han sido aceptados o rechazados. Esto incluye los registros con error soapenv:Server y Client?

Por ejemplo, envío una factura (A) correcta. Al enviar una segunda factura (B) la encadeno con la (A). Si la (B) me da error de tipo soapenv:Server, con cual encadeno una tercera (C), ¿con la (A) o la (B)?. Me surge la misma duda con el caso de error de tipo soapenv:Client para la factura B.

[sglorka]

Empezado por diegorgm

Hola!

Entiendo que hay que encadenar todos los registros independientemente de si han sido aceptados o rechazados. Esto incluye los registros con error soapenv:Server y Client?

Por ejemplo, envío una factura (A) correcta. Al enviar una segunda factura (B) la encadeno con la (A). Si la (B) me da error de tipo soapenv:Server, con cual encadeno una tercera (C), con la (A) o la (B). Me surge la misma duda con el caso de error de tipo soapenv:Client para la factura B.

La generación del RF y su envío a la Aeat son dos procesos independientes pero ordenados en el tiempo. Primero debes generar el RF y luego enviarlo. Siguiendo esta lógica, el encadenamiento de tu RF es independiente del resultado del envío. Siempre debes encadenar con el último RF generado por tu SIF

[ermendalenda]

Empezado por sglorka

La generación del RF y su envío a la Aeat son dos procesos independientes pero ordenados en el tiempo. Primero debes generar el RF y luego enviarlo. Siguiendo esta lógica, el encadenamiento de tu RF es independiente del resultado del envío. Siempre debes encadenar con el último RF generado por tu SIF

Sí, correcto aunque haya dado error no puedes cambiar a toro pasado el encadenamiento, el error te ha podido datos después de encadenar la siguiéndote, otra cosa es que si la del error es un error estructural tengas que subsanarlos o anularla, en cuyo caso tienes que generar un nuevo registro encadenado al último, pero sin borrar la que tienes mal.
En la Sede de verifactu tendrán un registro menos xon un salto pero detectaron que habrá otro registro de subsanacion o anulación en referencia a ese salto

[gcqZW]

La generación del RF y su envío a la Aeat son dos procesos independientes pero ordenados en el tiempo. Primero debes generar el RF y luego enviarlo. Siguiendo esta lógica, el encadenamiento de tu RF es independiente del resultado del envío. Siempre debes encadenar con el último RF generado por tu SIF

Pero y si no tienes datos en el ultimo RF generado???

[sglorka]

Empezado por gcqZW

Pero y si no tienes datos en el ultimo RF generado???

No sé qué quieres decir con esto. No sé que es un RF sin datos

[gcqZW]

imaginate que me rechazan un Rf en el cual no he informado de los datos necesarios para el encadenamiento, el siguiente Rf que genere debería generar una huella con los datos del Rf previo, pero en este caso no tiene. Habria que hacer el hash de:

IDEmisorFactura=&NumSerieFactura=&FechaExpedicionFactura=&TipoFactura=&CuotaTotal=&ImporteTotal=&Hue lla=&FechaHoraHusoGenRegistro=(aquí si que habría datos)

asi sin datos???