FiveTech Support Forums

FiveWiDi wrote: Duda.
He leído que no hay problema en enviar facturas a Verifactu con fecha emisión anterior a la de su envío a Verifactu.
Ahora bien, se de una persona que envía las facturas de alquiler días antes de la fecha factura (envío el dia 28 de mes, fecha factura día 1 del mes siguiente) . De esto no he encontrado nada. Si las envía a Verifactu... Qué ocurrirá?

Muchas gracias,

t= 60

Se hace un primer envio y hasta pasado t entonces no se puede volver a enviar

Pero y si en la espera se han impreso mas ? Las tiene que mandar el usuario. Pero y si se le olvida, entonces ya no seria envio "inmediato". Entonces, parece que tiene que haber un demonio enviador dando vueltas aunque tu sistema tenga un solo usuario con un pc en un rincon de una fabrica

VictorCasajuana wrote:Yo pondría como fecha Operación el día 1 y como fecha emisión 28 ya que es el día que se crea la factura.

paquitohm wrote:t= 60
Se hace un primer envio y hasta pasado t entonces no se puede volver a enviar
Pero y si en la espera se han impreso mas ? Las tiene que mandar el usuario. Pero y si se le olvida, entonces ya no seria envio "inmediato". Entonces, parece que tiene que haber un demonio enviador dando vueltas aunque tu sistema tenga un solo usuario con un pc en un rincon de una fabrica

FiveWiDi wrote: Ahí está la cosa; lo puedes enviar más tarde si te lo dice Hacienda, pero y si lo decides tu?

FiveWiDi wrote: El tema del demonio, yo le meteré un TIMER que avise si hay envíos pendientes, y que el usuario le de al botón. De paso el TIMER tendrá en cuenta el 'retardo' que nos haya indicado Verifactu en el último envío.

FiveWiDi wrote: Este desarrollo parecía relativamente sencillo, pero debe contemplar situaciones que no se pueden dejar que se resuelvan a mano, la 'liarían parda' los usuarios.

FiveWiDi wrote: Por ejemplo debe haber un historial de xml enviados que se relacionen con las facturas que en ellos se tratan, no es una relación 1 factura a 1 xml. Siempre es bueno tener información de lo que se ha hecho.

FiveWiDi wrote: Si en un envío hay un error se debe volver a enviar con los datos erróneos del primer envío corregidos (eso he entendido), por tanto una misma factura puede aparecer en 'n' xml diferentes. Por cierto ese envío de la corrección, cuando debe hacerse? Antes de la siguiente factura? Cuando tengamos tiempo de resolver el error?

FiveWiDi wrote: Otra cuestión. Asi como contemplar y establecer un procedimiento para tratar esos 'retardos' en el envío del xml, momento en el cual puedes tener 1 o varios xml pendientes de enviar; entonces que hago? Me los cargo todos y hago uno solo? los envío uno detrás de otro con su respectivo 'retardo'? Y me planto en el cierre de la oficina con varios xml pendientes de enviar?
Creo que estableceré un estado 'EnColaVF' y cuando se pueda enviar el xml, en ese momento lo creo con todo lo pendiente y lo envío.

Ese 'retardo' a final de mes (trimestre/año) puede ser considerable.

una opción buena para los fallos de envío es tener una cola FIFO de los XML que se han generado y cada vez que se genere uno nuevo, pues se mete en la cola y se procesa, así te aseguras la secuencialidad de los envíos. Esto, mejorable por supuesto con los timers que indicáis para que sea más transparente al usuario.

FiveWiDi wrote:

Yo pondría como fecha Operación el día 1 y como fecha emisión 28 ya que es el día que se crea la factura.

Gracias Víctor, pero no es el caso.

La factura y la operación tendran fecha de emisión día 1 de mes, pero hoy en día la envían 4 días antes.

No se... en las pruebas veremos que responde Hacienda (Verifactu).

Muchas gracias,

VictorCasajuana wrote:una opción buena para los fallos de envío es tener una cola FIFO de los XML que se han generado y cada vez que se genere uno nuevo, pues se mete en la cola y se procesa, así te aseguras la secuencialidad de los envíos. Esto, mejorable por supuesto con los timers que indicáis para que sea más transparente al usuario.

Paquitohm wrote: Si, lo que comentas parece lo mejor: El .xml se genera justo cuando se puede enviar y no antes, es decir, la "cola" ha de ser de envios pendientes (facturas) y no de .xml(s)
Salu2

paquitohm wrote: Rizando el rizo rizado
Una cosa que puede ser de segundo o incluso primer nivel: Hacer un proceso, para todos las facturas enviadas, que compruebe la diferencia de tiempo entre la creacion de la factura y su envio y que muestre aquellos con una diferencia muy grande. Esto inicialmente estará muy bien en la fase de pruebas, para ver que todo funciona como es debido. Despues valdrá al usuario para cuando se produzcan fallos de infraestructura y se envian las facturas con demasiado retardo y probablemente tenga que explicar/justificar a la agencia el motivo de ese retardo

VictorCasajuana wrote:Mi duda es, que si hay una factura que no se ha enviado por algún motivo, entrará en la cola y hasta que no se envíe, el resto de facturas quedarán a la espera, correcto?

VictorCasajuana wrote: Una buena idea sería que todo xml a enviar, aya a la cola y la cola procese, me refiero a que no haya un envío directo y si no funciona entonces enviarlo a la cola, esto podría provocar errores de secuencia en los envíos.

VictorCasajuana wrote: Por cierto, ya que estamos con el envío de los XML, para evitar errores, vais a chequearlos antes con los XSD correspondientes? esto podría reducir el nº de problemas.

FiveWiDi wrote:

Mi duda es, que si hay una factura que no se ha enviado por algún motivo, entrará en la cola y hasta que no se envíe, el resto de facturas quedarán a la espera, correcto?

Yo así lo haré. No enviaré una factura si su anterior no se ha enviado.
Permitiré que el usuario deje en "Stand By" el 'proceso' Verifactu, pero podrá seguir facturando; cuando vuelva a activar Verifactu se enviarán las facturas por orden, estableciéndose en el momento de la creación del XML el vínculo entre una factura, su anterior y su siguiente.

FiveWiDi wrote:

Una buena idea sería que todo xml a enviar, aya a la cola y la cola procese, me refiero a que no haya un envío directo y si no funciona entonces enviarlo a la cola, esto podría provocar errores de secuencia en los envíos.

No crearé XML si no son para enviarse en ese momento ya sea con 1 o varias facturas a la vez. No le veo sentido y si riesgo a tener XML creados pendientes de enviar, si debo y quiero enviar las facturas por orden.

VictorCasajuana wrote: Por cierto, ya que estamos con el envío de los XML, para evitar errores, vais a chequearlos antes con los XSD correspondientes? esto podría reducir el nº de problemas.

Estaría bien, pero no se como se hace.

paquitohm wrote: Validacion XML vs XSD: Rafa Carmona lo implementó: https://www.fivetechsoft.com/forums/viewtopic.php?t=31745
Salu2

paquitohm wrote:Hola a todos los Vfactureros,
Como yo lo veo:
En ticketbai al menos eso no es posible porque en el QR que se imprime va un trozo de la firma del xml. Creo que el xml de Vfactu no se ha de firmar, pero dudo que no incluyan algo en el QR que ligue QR impreso con xml. Es "curioso" como este "detalle" determina tanto la forma en que tenemos que hacer el diseño del software y por eso nos conviene tenerlo bien claro

Hola,

He perdido los links de Hacienda Pública Española para consultar información al respecto del desarrollo y requisitos de Verifactu.

No los tendrá alguien a mano?

Muchas gracias,