Cita:
Empezado por newtron
Es buena idea validar de forma "TOTAL" la factura antes de guardarla pero se me ocurre que eso puede traer algún problema que otro:
1- Entiendo que la factura debe de tener su número para poder validarla, si por lo que sea hay algún error y no dejáis guardarla/enviarla entiendo que el proceso se atasca. En ambientes de red, si otro está facturando por otro sitio entiendo que debería de dejarle enviar la factura siendo correcta y esta llevará un número posterior. Si al final la factura atascada no se puede llevar a término por el motivo que sea tendremos un problema y no sé si también aunque al final se envíe si se hace con una fecha+hora posterior a una factura posterior.
|
En C# .Net (no se si será igual en Delphi) el proceso de salvar una factura se hace dentro de una misma transacción de base de datos.
Dentro de ese proceso se busca el numero que le toca en una tabla de contadores y se actualiza esa tabla para que la siguiente factura no coja el mismo número.
Dentro de esa misma transacción también se crea el registro de facturación, con el número asignado y también dentro de esa transacción se hacen las validaciones.
Si alguna validación falla, se lanza un error y el proceso de salvar se cancela y se deshace toda la transacción (RollBack).
Por lo tanto no se guarda la venta, no se guarda registro de facturación pero tampoco se guarda la información del contador, el numero de factura que toca.
De esta forma, si "al segundo siguiente" otro ordenador quiere salvar una factura, hará el mismo proceso y cogerá el mismo número que el SIF quería utilizar para la factura que ha fallado en la validación, el que toca en ese momento.
Si ese segundo ordenador no tiene errores podrá salvar la factura.
El primer ordenador, que no ha podido salvar por un error en la validación, cuando corrija el problema y vuelva a salvar la factura, cogerá otro numero (el que toque) y si no hay errores pues salvará la factura y el registro de facturación con los nuevos datos.
Cita:
Empezado por newtron
2- Igualmente si hay "bulla" y una factura se "atasca" se puede atascar igualmente la cosa con otros clientes que haya esperando.
|
El único "bloqueo" ocurre en el lapso de tiempo que el SIF intenta salvar la factura (incluido todo el proceso de crear el registro de facturación y validarlo) pero habitualmente es muy rápido.
Cita:
Empezado por newtron
3- Si por el motivo que sea no hay internet se debe de poder emitir la factura aunque se envíe posteriormente con incidencia (es mi opinión).
|
No hace falta internet para nada, la validación que comento solo comprueba los valores del registro de facturación que se está creando en memoria.
Seguro que se puede mejorar y también seguramente encontraremos algunos problemas pero de momento está funcionando.
Cita:
Empezado por bmfranky
Yo personalmente, como no tengo pensado emitir facturas sin que haya conexion, uso el sistema de validacion que han implementado para los no verifactu, que es el mismo que se usa para el verifactu, si pasa la verificacion, ya guardo , envio e imprimo la factura con total seguridad de que es correcta, si no lo es , como aun estoy en fase de *diseño de la misma, pues puedo correjir lo que haga falta, e incluso salir sin guardar nada descartando cualquier cambio, en la base de datos, puesto que la factura no se ha finalizado....
|
Esta también es una buena idea, pero si que necesita internet. Pero la idea es la misma. Si falla la validación no se guarda ni se "ocupa" el número.
Esta idea tiene de bueno que las validaciones realmente las hace la AEAT y seguramente son las mismas que se harán al enviar. A parte que cuando AEAT hace cambios en las validaciones, de esta forma no tienes que cambiar nada y con la función que hemos hecho (que también puede tener errores en nuestro código), en cada cambio de la AEAT, tenemos que mantener la función que valida. Esperemos que no cambien mucho.
Saludos