Da igual el contenido del registro, yo lo hago , encadeno 3 series de facturas, F1 de reparacion FR1, F1 de materiales FV1, y F2 de contado FC1, aparte de cuando haga las R que tambien lo hare.



Al calcular el nuevo hash de encadenamiento usas el contenido del anterior, sea cual sea.(Hojo siempre del mismo NIF/Empresa)

Siempre se encadena con el ultimo registro enviado, da igual si es correcto, Incorrecto o Aceptada con Errores.

Tambien da igual el tipo de factura y el tipo de registro Alta o Anulacion.

Lo mejor es guardar los datos del ultimo registro enviado y con eso construyes el siguiente.

yo creo que no es el último enviado, sino el último registro de facturación generado

A buen entededor pocas palabras bastan.

Se entiende que ultimo enviado = ultimo generado.

Vamos a ver, que lo entienda bien: (otro caso, espero que el ultimo)

si envio la F3 con error en DNI y es la ultima del envio, y da resultado Incorrecto....

¿ El siguiente envio de la F3 ira enlazado con la huella de la F3 que dio errores (Incorrecta) ? (¿y en teoria no esta en la AEAT?)


hoy me he quedado sorprendido, porque hasta ahora no lo entendia asi.

Las que dan errores, No se quedan en la AEAT ¿no?, esto me descoloca un poco, a mi esto de enlazar me cuadraba con las aceptadas, o aceptas con errores, pero con las incorrectas... ahi ya me quede.

Saludos y gracias a todos

Hola, realmente lo que se encadenan son los registros que crea tu SIF, que se almacenan inmutables , no los que acepta o no la AEAT.

Para la aeat, el registro anterior con o sin errores , es el que hay que tener en cuenta para encadenar.

Osea creas el REgistro, lo almacenas, lo envias, se rechaza, creas otro registro , que soluciona los errores del registro enviado, encadenas con el anterior de la lista, sea o no correcto, enviado o no, rechazado o no, y continuas con la serie.

Mira en mi caso, hubo un error en el envio.

Correcto, tienes que utilizar para el encadenamiento esos datos sean del tipo que sean y sin o con errores!

Exacto. Así es. Pensad que un auditor de Hacienda nos puede pedir (y debemos tener disponibles para ellos de forma sencilla desde la interface del programa) un registro de facturación, que no dejan de ser los registros que crea el SIF y que deben almacenarse inmutables, independientemente si los ha aceptado Verifactu o no. Además, esta es nuestra garantía de que nosotros (como mínimo) intentamos hacer las cosas de forma correcta.

En esta captura se ve , que tube que modificar a huevos por un fallo mio al enviar, si veis es el mismo numero de factura, distinto contenido, la anterior no reza en la AEAT para nada.


Me pase de 3.000€, Si lo se la forma correcta es una rectificativa, pero aun no las implemento.

gracias a todos

ahora si, ya quedo claro.


la semana que viene publicare una nueva version con los tres flags nuevos para permitir la correccion del registro, como he indicado.

Saludos !

Perdona mi indiscreción y este pequeño off-topic, pero...¿eso es el Heidi? En caso de que uses MySQL, te sugiero que, si almacenas (al igual que yo) los xml de cada registro, a la hora de hacer el INSERT/UPDATE, uses el comando COMPRESS(Campo_xml). Y cuando quieras visualizarlo, simplemente UNCOMPRESS(campo_xml). De esta forma tu registro de facturación ocupará bastante menos y será más rápido de consultar. Además este proceso prácticamente no agrega tiempo de procesado a la base de datos.

Creo que eso es lo correcto.

No es por ser puristas, pero [rci] tiene razón (piensa siempre en sistemas verifactu y no-verifactu).
En Verifactu es posible que generado=enviado, pero en No-Verifactu no se envía nada y tal vez alguien se esté liando con eso.

Se entiende que en un sistema NO verifactu no envias mientras no haya requerimiento, sigues facturando y claro es el utlimo generado, y ese es el que hay que tener en cuenta.

Y como decia lo he echo sobre la base de ultimo registro generado = ultimo registro enviado en el caso de Verifactu y con el planteamiento que hacian los compañeros.

Lo importante aqui es que quede claro el concepto de lo que hay que utilizar.

No hombre, nada que perdonar, se agradece 100% cualquier consejo, en cuanto mi otro trabajo me deje volver a ponerme al tajo con esto, pienso implementarlo.
Gracias.

Ya tengo el codigo corregido. Pero....

1 He enviado una factura con error: A24033 , adrede. La unica del paquete
2 Me ha sido rechazada. Incorrecto. La archivo en el registro.
3 Corrijo la factura
4 Cuando intento enviarla de nuevo pongo como anterior su misma version fallida: (es decir huella rechazada, numero rechazado: ella misma la A24033 )

y me devuelve esto:

3002 No existe el registro de facturación.

...

Saludos !

Si te han rechazado el registro anterior no existe en la aeat. registro previo N.
Ten encuenta que lo que no existe es el registro, no los datos de la factura, que es lo que usas para hacer el encadenamiento.

Si el primer registro que enviastes de esa factura te lo devuelven como Incorrecto y no se registra en la AEAT, la subsanacion tienes que hacerlo con:
Subsanacion=S
RechazoPrevio=X

Si, por el contrario, el pimer registro te lo acepta y mandas un segundo por subsanacion y te lo rechaza tienes que hacelo para el siguiente:
Subsanacion=S
RechazoPrevio=S

Por lo general, si el registro esta en la AEAT y en caso de Subsanacion=S, RechazoPrevio=S, si no esta en la AEAT y es una subsanacion RechazoPrevio=X

efectivamente, ya esta funcionando. gracias !!

tengo que comprobar los encadenamientos, pero ya esta. Cuando actualice el componente, ya se podra hacer asi.

slds !

Me gustaria facilitar estos encadenamientos en el componente, pero todavia no tengo claro si es muy seguro y factible.

Deberias crearte una tabla o algun tipo de fichero donde guardar los datos de ultimo registro generado, en cuanto a los campos IDEMISOR, NUMSERIEFACTURA, FECHAEXPEDICION Y HUELLAANTERIOR, y de esta forma siempre que generes el registro nuevo obtienes los datos de este y al mismo tiempo guardas los del Nuevo en esta misma tabla o fichero, puedes tener en la tabla o fichero un solo registro con estos datos, si inicialmente no hay ninguno, no existe registro anterior, y por lo tanto el registro anterior sera igual a Primerregistro=S e insertas los nuevos, si por el contrario existe el registro coges esos datos y editas para poner los nuevos.

ahora me doy cuenta que no necesito el registro anterior en el array de facturas

solo necesitaria el registro inicial como huella anterior del primer registro del array (o ninguno si es primer envio) del paquete de envio.

el array va ordenado cronologicamente (por orden de llegada) y el registro anterior, esta simplemente en j-1

al termino se guarda la ultima, que sera la inicial del siguiente paquete de envio. Y listo. Teniendo en cuenta su estado por subsanacion y rechazoprevio.