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

[bmfranky]

Empezado por seccion_31

bueno... a ver

la huella no puede ser calculada hasta finalizar la factura, o casi. Lo normal seria esperar a tenerla finalizada. (digo lo normal).

Aquí haces tu factura, y la envías inmediatamente, en el momento del envío, mientras compone el objeto SOAP el registro de Facturacion (x cada factura, antes de su envío), hay un evento que te indica la huella calculada, ahí ya se puede archivar, pero además cuando finalice, o no el envío, completo o no completo, con fallos o sin ellos, puedes todavía recoger las huellas: hablamos de 1 segundo como mucho entre un proceso u otro.

Se podría considerar como una parte del proceso de Facturacion la generación de las huellas, antes de su envío, que ocurre automáticamente al finalizar la factura. (en mi caso).

Evidentemente las huellas se calculan antes, o se recogen vía evento, o al finalizar el envío.

No creo que haya problemas ahí.

Tambien:

Se podría simular un envío, obtener las huellas y archivarlas ¿y después? enviarlas. no le veo sentido.

Estando en verifactu el envio debe ser inmediato. Creo que cumplimos.

Hola, en el momento que imprimes/guardas la factura la huella ya la has de tener, no puedes calcularla despues, puesto que los datos han de ser los mismos que van en el QR, por eso decia de calcular la huella antes.


Yo por mi parte , calculo la huella en el mismo evento de preimpresion de la factura, al mismo tiempo que genero el QR, asi me aseguro que todos los datos concuerden, al finalizar la impresion, justo despues de realizar el envio , si hay error de envio** , lo muestro y almaceno , en mi caso como una proforma, porque me resulta mas facil despues reeenviarla , al no tener implementado el servicio de envio separado.


Como no he impreso, guardado la factura, la genero de 0 creando todos los campos.

*A ver , lo de el error de envio , lo saco de la consulta a la aeat, para ver si el servicio esta activo, lo hago antes de preimprimir ni nada la factura, es que creo que no me he explicado correctamente.

*Este sistema solo lo uso si no se ha podido realizar el envio porque no hay conexion, en caso de error de otro tipo, imprimo y guardo todo de forma normal, para poder realizar la Subsanacion 0 reenvio como sea correcto, sea con una rectificativa o lo que sea menester.

[seccion_31]

Empezado por bmfranky

Hola, en el momento que imprimes/guardas la factura la huella ya la has de tener, no puedes calcularla despues, puesto que los datos han de ser los mismos que van en el QR, por eso decia de calcular la huella antes.


Yo por mi parte , calculo la huella en el mismo evento de preimpresion de la factura, al mismo tiempo que genero el QR, asi me aseguro que todos los datos concuerden, al finalizar la impresion, justo despues de realizar el envio , si hay error de envio** , lo muestro y almaceno , en mi caso como una proforma, porque me resulta mas facil despues reeenviarla , al no tener implementado el servicio de envio separado.


Como no he impreso, guardado la factura, la genero de 0 creando todos los campos.

*A ver , lo de el error de envio , lo saco de la consulta a la aeat, para ver si el servicio esta activo, lo hago antes de preimprimir ni nada la factura, es que creo que no me he explicado correctamente.

*Este sistema solo lo uso si no se ha podido realizar el envio porque no hay conexion, en caso de error de otro tipo, imprimo y guardo todo de forma normal, para poder realizar la Subsanacion 0 reenvio como sea correcto, sea con una rectificativa o lo que sea menester.

Por comentar temas, a ver....

Los datos que van en el QR son diferentes a la huella. La huella contiene algunos mas. NO es recomendable, pero puedes imprimir una factura con su QR sin tener la huella calculada. Yo no lo haria, pero se puede.

El servicio activo no te garantiza al 100% que se vaya a ejecutar el alta, pero esta bien. (El resto de procesos que haces ya depende de cada uno, hasta ahi)

Ya me he explicado, para aclarar un poco mas, para los que usan el componente:

1) Haces la factura
2) Aqui podrias calcular tu QR sin problemas
3) Añades la factura al componente
4) Se ordena el envio
5) (durante la preparacion del envio se genera la huella y se envia por evento, para guardarla en cada factura)
6) Se envia a la AEAT
7) (y aqui tambien se pueden recoger las huella/s generadas, para guardarlas en la factura)
8) Imprimes


Quizas incluya una funcion "libre de envio" que devuelva la huella en cualquier momento.

Personalmente En mi caso, siempre envio antes de imprimir. La factura se queda enviada, o pendiente. La pendiente, se reenviara cuando sea técnicamente posible: ahora con las huellas actuales y anteriores guardadas, no hay problema alguno. Envias y ya. Se marcara incidencia si el tiempo supera en 2 minutos el establecido en la huella.

Y Validar el NIF antes de empezar mejor
Y Validar si esta activa la AEAT mejor

Saludos !

[seccion_31]

aun asi, y no os molesteis mucho todavia hay un caso sobre encadenamientos, no dudas del componente:



a ver si alguien tiene paciencia:


facturas


sesion 1:
Factura 4 fallida en el envio por fallo de internet encadena con 3



sesion 2: <- aqui ya funciona internet, nos ponemos a facturar

Factura 5 encadena con 4
Factura 6 encadena con 5
Factura 4 encadena con 3 <- reenvío la 4 cuando vemos que ya funciona internet, (hemos enviado 2 delante)

Factura 7 encadena con ?

[rci]

Empezado por seccion_31

aun asi, y no os molesteis mucho todavia hay un caso sobre encadenamientos, no dudas del componente:



a ver si alguien tiene paciencia:


facturas


sesion 1:
Factura 4 fallida en el envio por fallo de internet encadena con 3



sesion 2: <- aqui ya funciona internet, nos ponemos a facturar

Factura 5 encadena con 4
Factura 6 encadena con 5
Factura 4 encadena con 3 <- reenvío la 4 cuando vemos que ya funciona internet, (hemos enviado 2 delante)

Factura 7 encadena con ?

Cuando se crea la factura 7, su registro de facturación tiene que estar encadenado con el último registro de facturación creado (del mismo obligado tributario y mismo SIF).
Probablemente será el registro de facturación de alta de la factura 6, pero podría no serlo, podría ser una eventual subsanación de la factura 1 por ejemplo.

El encadenamiento no tiene nada que ver con el envío.
Al crear una factura debes crear el registro de facturación de alta y guardar en algún sitio (una tabla por ejemplo) los datos del último registro de facturación creado.
Cuando se crea otro registro de facturación (ya sea de alta de una nueva factura, de anulación, de subsanación) se encadena con el último registro de facturación creado.

El envío de registros de facturación no afecta al encadenamiento. Los registros de facturación creados y no enviados, se van enviando cuando toque, siguiendo el control de flujo que indica la ley

[bmfranky]

Empezado por rci

Cuando se crea la factura 7, su registro de facturación tiene que estar encadenado con el último registro de facturación creado (del mismo obligado tributario y mismo SIF).
Probablemente será el registro de facturación de alta de la factura 6, pero podría no serlo, podría ser una eventual subsanación de la factura 1 por ejemplo.

El encadenamiento no tiene nada que ver con el envío.
Al crear una factura debes crear el registro de facturación de alta y guardar en algún sitio (una tabla por ejemplo) los datos del último registro de facturación creado.
Cuando se crea otro registro de facturación (ya sea de alta de una nueva factura, de anulación, de subsanación) se encadena con el último registro de facturación creado.

El envío de registros de facturación no afecta al encadenamiento. Los registros de facturación creados y no enviados, se van enviando cuando toque, siguiendo el control de flujo que indica la ley

Empezado por seccion_31

aun asi, y no os molesteis mucho todavia hay un caso sobre encadenamientos, no dudas del componente:



a ver si alguien tiene paciencia:


facturas


sesion 1:
Factura 4 fallida en el envio por fallo de internet encadena con 3



sesion 2: <- aqui ya funciona internet, nos ponemos a facturar
<<<- La cola de envios empieza aqui, sino seguramnete dara error cuando estemos en produccion.

Factura 5 encadena con 4
Factura 6 encadena con 5
Factura 4 encadena con 3 <- reenvío la 4 cuando vemos que ya funciona internet, (hemos enviado 2 delante)<<<< MAL

Factura 7 encadena con 6 no ha de reencadenar nada

Hola, como bien dice @rci, lo que has de guardar son los registros ya encadenados, independientemente de si se enviaron o no, has de crear unas tablas, ya sea con el XML complero del registro de facturacion completo, creo que desde c# lo mas facil, o todos los datos para recrearlo al enviar, pero ya completado.


Deves hacer 2 cosas en ese supuesto, inmediatamente enviar lo pendiente , en este caso el registro de factura 4 que ya esta correctamente encadenado, indicando en la cabecera e el fallo en el envio, y esperar los x, segundos para empezar a enviar los registros encolados despues.


Aunque puedes esperar a enviar cuando tengas mas registros , no te lo recomiendo.

[seccion_31]

Empezado por bmfranky

Hola, como bien dice @rci, lo que has de guardar son los registros ya encadenados, independientemente de si se enviaron o no, has de crear unas tablas, ya sea con el XML complero del registro de facturacion completo, creo que desde c# lo mas facil, o todos los datos para recrearlo al enviar, pero ya completado.


Deves hacer 2 cosas en ese supuesto, inmediatamente enviar lo pendiente , en este caso el registro de factura 4 que ya esta correctamente encadenado, indicando en la cabecera e el fallo en el envio, y esperar los x, segundos para empezar a enviar los registros encolados despues.


Aunque puedes esperar a enviar cuando tengas mas registros , no te lo recomiendo.

Efectivamente,

Si, eso entraria en la logica del programa. Colocar los pendientes primero. (el componente no tiene base de datos) (la demo hace uso de una base de datos basica demostrativa, no entra en esta complicacion).

Aun asi, me asegurare que si en un paquete de envio hay varios pendientes, siempre se coloque la huella anterior correcta. Lo cual minoraria el problema, porque el envio seria correcto.

Basicamente ya esta echo. Me falta probarlo bien.

gracias a todos !

[bmfranky]

Empezado por seccion_31

Efectivamente,

Si, eso entraria en la logica del programa. Colocar los pendientes primero. (el componente no tiene base de datos) (la demo hace uso de una base de datos basica demostrativa, no entra en esta complicacion).

Aun asi, me asegurare que si en un paquete de envio hay varios pendientes, siempre se coloque la huella anterior correcta. Lo cual minoraria el problema, porque el envio seria correcto.

Basicamente ya esta echo. Me falta probarlo bien.

gracias a todos !

Una solucion patatera que se me ocurre es , al fallar el envio, generar en un directorio temporal, los registros pendientes de envio, con su xml completo, al comprobar que ya hay conexion, verificar si el directorio tiene contenido, y entonces automaticamente, antes de permitir empezar a factura, cargar todas las facturas pendientes en orden, y al cargar/enviar la ultima establecer esos datos como los correctos para el encadenamiento.

[bmfranky]

Empezado por seccion_31

Efectivamente,

Si, eso entraria en la logica del programa. Colocar los pendientes primero. (el componente no tiene base de datos) (la demo hace uso de una base de datos basica demostrativa, no entra en esta complicacion).

Aun asi, me asegurare que si en un paquete de envio hay varios pendientes, siempre se coloque la huella anterior correcta. Lo cual minoraria el problema, porque el envio seria correcto.

Basicamente ya esta echo. Me falta probarlo bien.

gracias a todos !

Para dejarlo mas funcional, porque no añades en la base de datos donde guardas la configuracion, los datos del ultimo registro generado, asi siempre puedes cojer de alli los datos para generar el siguiente, sin preocuparte de si se envio o no, esa parte la puede atender el programa fuera del la DLL, la dl unicamente dedicarse a generar los registro y encadenarlos.