Demo con código Verifactu.dll para (delphi 7)

[delphiGar]

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.

[rci]

Empezado por delphiGar

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

[delphiGar]

Empezado por rci

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.

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

Empezado por rci

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

Creo que eso es lo correcto.

Empezado por delphiGar

Se entiende que ultimo enviado = ultimo generado.

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.

[delphiGar]

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

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.

[seccion_31]

Empezado por delphiGar

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.

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

[bmfranky]

Empezado por seccion_31

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 ?


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.

[DarkDudae]

Empezado por bmfranky

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.

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.

[bmfranky]

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.

[DarkDudae]

Empezado por bmfranky

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.

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.

[bmfranky]

Empezado por DarkDudae

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.

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.

[seccion_31]

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 !

[delphiGar]

Empezado por seccion_31

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

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