Cita:
Empezado por trumbolt
El problema que veo es que si tienes un error en el envío, borras el xml y estás "sacando" esa factura digamos del correcto encadenamiento. Si la borras, ¿cómo gestionas luego eso?. Aparte que si tienes que imprimir la factura (y necesitas el QR) cómo lo haces cpon esa factira cuyo envio ha fallado? Lo digo porque necesitas la firma para eso.
Teóricamente según TBAI, el software garante tiene que ser capaz de emitir una factura (firmarla e imprimir su QR) sin necesidad de conectarse con ellos (que era el principal problema que había al principio).
En mi caso, hemos desligado la generación, firmado e impresión de la factura del envío que va por un servicio de cola que únicamente se encarga de enviar las facturas que va generando el software y notifica posibles errores para luego poder solventarlos de manera manual, que es la única manera que hemos encontrado ya que automatizar algo es prácticamente imposible ...
|
Yo hago algo parecido: un programa crea el xml en una carpeta compartida en la red y luego otro programa gestiona la cola firmando, enviando el fichero y luego comunicando al programa de facturación el resultado.
La idea de borrar el xml es para eliminarlo de la lista de ficheros pendientes de firmar y enviar. Tras hacerlo, notifico a la factura que ha habido un error y que hay que volver a generar el fichero y, por tanto, no puede imprimirse. Después de borrar el fichero, el programa continúa con la cola. Esto te permite seguir trabajando y te asegura que el QR impreso siempre es correcto. Lo peor que puede pasar es que los servidores TBai no funcionen y los clientes se tengan que ir sin el tiquet o esperarse un rato.
La diferencia que veo con tu método es que se corre el riesgo de que el el fichero sea rechazado y no ingrese en su sistema. Estarías imprimiendo un QR que apunta a una URL inexistente y se estaría rompiendo el encadenamiento real.