![]() |
![]() |
| Paypal | FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
|||||||
| Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Buscar | Temas de Hoy | Marcar Foros Como Leídos |
![]() |
|
|
Herramientas | Buscar en Tema | Desplegado |
|
|
|
#1
|
|||
|
|||
|
Cita:
Cita:
Es tan 'defraudador' enviar una factura mal numerada que deje huecos, como enviar RF cuyas huellas no permiten la trazabilidad de los envíos. |
|
#2
|
|||
|
|||
|
En mi caso contemplo 2 posibilidades, por que estoy solo:
1. Me pilla de vacaciones, reinstalacion rapida con nuevo numero de instalacion, solo teniendo en cuenta que los nuneradores de lss series sigan por el ultimo envio y si se pone dificil pues otra serie nueva, al haber una nueva instalaxion el encadenamiento es sin registro anterioe y ya cuando vuelva veo si hay que recuperar algo y mandarlo como subsanacion. 2- si veo que se puede arregkar rapido y no estiy en otro fregado, ya tengo consultas de lo enviado, recuperacion de copias etc. El estar solo hay que considerar los planes B. |
|
#3
|
|||
|
|||
|
El hecho de que Hacienda ya tenga constancia de las facturas no te exime de la responsabilidad de tenerla también en tu SIF, porque siempre puede venir un cliente final que quiera hacer un cambio o devolución, y necesitarás esa factura (que has perdido) para hacerle la rectificativa, o incluso para consultar qué se le vendió, etc.
Nosotros creo que optaremos por hacer una opción en el SIF que permita "importar facturas no existentes desde la AEAT" o algo así, que cree los registros en la base de datos de facturas del SIF (si no existen ya, claro) pero que no se vuelvan a enviar a Hacienda. Además, es la única forma de hacer que el software siga la numeración correlativa de facturas y no empiece por la 451 (que ya la tiene Hacienda) sino por la que realmente toca (la 501). No hay forma de engañar al software para que empiece por otro número no correlativo. O como sugirió alguien: instalación nueva y cuando se haga la primera factura, entonces sí te pregunta por qué número quieres empezar, y ahí le pones el 501. Pero claro, dejar que el usuario haga todo esto él solo es complicado, y no tenemos 3 o 4 clientes sino miles, así que hay que intentar hacerlo lo más intuitivo posible, rápido, transparente, etc. tanto para ellos como para nosotros. Madre mía, se va a liar ![]() |
|
#4
|
|||
|
|||
|
Hay que crear un algoritmo que importemos los RF´s de la AEAT donde estan todos los datos y volcar los datos en la tabla de Facturas y cuando termine el bucle, empezamos a volcar a la tabla de RF´s. El primer criterio que tenemos que tener en cuenta es el tipo de Factura.
-Si es una F1 sabemos que tenemos que volcar todos los datos, incluso los datos del cliente. -Si es una F2 sabemos que tenemos que volcar sin datos de cliente. Los datos están, lo que hace falta es volverlos a colocar en nuestro SIF. Si se fijáis en un registro del libro de registro o repositorio que tiene la AEAT, veréis todos los datos que nos hace falta para completar un registro de nuestra tabla de "Facturas" menos los conceptos, pero algo es algo. Si se completan las Facturas correctamente incluso se podrá rectificar. En la tabla de Facturas tendríamos que poner un concepto inventado, solo un concepto porque esa factura recuperada solo tendrá una línea de detalle. Creo que entre todos haremos una buena cabeza. |
|
#5
|
|||
|
|||
|
En efecto, está todo menos los conceptos, y el cliente los necesitará (por si le viene un cliente a hacer un cambio o devolución).
Lo que está claro es que serán situaciones de causa mayor, así que la responsabilidad no debería recaer toda sobre nosotros. Vamos, digo yo. Nosotros tenemos que hacer funcionar el software, y que siga haciendo sus envíos a VeriFactu, así que deberíamos centrarnos en eso. Que el cliente pierda el contenido de las facturas ya NO es responsabilidad nuestra. Lo que tenemos que conseguir es que pueda seguir enviando a VeriFactu sin errores, continuar con la numeración correlativa de facturas y respetar el encadenamiento. Todavía no me he puesto a analizarlo con calma, pero creo que vamos bien encaminados: un botón/opción en el software, semi-escondido, para que en casos como este se puedan "importar RFs no existentes desde la AEAT". Al hacerlo, creamos en nuestras tablas de facturas los datos estrictamente necesarios, de forma que NO generen otro RF/envío, y obteniendo por lo tanto el último encadenamiento enviado, para continuar desde ahí. Luego está la parte en la que al restaurar/recuperar una copia de seguridad antigua, no deberíamos sobrescribir la tabla que usemos para guardar los RFs enviados. Esa debería prevalecer siempre la versión más reciente, aunque también podrían importarse sus datos desde la AEAT. En fin, cuando me ponga en serio intentaré ver los pros y contras o si hay alguna forma mejor de conseguirlo. |
|
#6
|
|||
|
|||
|
Según que cliente, pero a un cliente de Retail con un problema de perdida de datos, y que le digss que es su problema, minimo adios cliente.
Vake que le recuperes como mencionas un par de registros o tres por que la subida al cloud es mas lenta que a verifactu. Pero una copia en la nube y constante para los que trabajan en software de escritorio, hoy en dia es fundamental. |
|
#7
|
|||
|
|||
|
Cita:
Ambos tienen sus pros y sus contras. Lo que bajo ningún concepto vamos a aceptar es ser responsables de los PCs de los clientes. La mayoría no sabe ni buscar un archivo en el Explorador de Windows aunque lleven 20 años usando un PC. Sinceramente, no quiero clientes así, que usan un PC con Windows XP o 7 desde hace años, sin prestarle un mínimo de cuidado, mantenimiento, etc. creyendo que "eso va a funcionar siempre", lleno de virus, con el teclado manchado desde hace meses con teclas que no funcionan y que encima me culpen a mí de haber perdido los datos tras no haber hecho copias de seguridad en la vida. No, señor. Los datos los tienes tu en tu PC, no yo. |
|
#8
|
||||
|
||||
|
Hola, ya se que me diréis que es una burrada, pero forzar al cliente a hacer copias de seguridad cada X,(Yo las hago al salir del programa , pero soy muy neurótico y de momento tardan unos minutos), no seria una opción también?, haber puede ser una función en segundo plano, para que el cliente no se de ni cuenta, al final de cuentas, han de invertir en métodos para evitar apagones y demás, un pequeño cloud para hacer copias de seguridad, tampoco es que sea una barbaridad.
Podemos hacer pequeñas copias diarias y totales semanales por ejemplo y mas ocurrencias como poner discos en espejo de los datos, etc... Otra cosa en lo que son muy claros, es que al reinstalar el programa aunque sea una copia de seguridad , se ha de poner un nuevo id, y por consiguiente empezar de nuevo el encadenamiento, así que solo hay que leer el ultimo registro enviado para saber el numero de factura, y empezar de nuevo desde ahí.
__________________
Uno se alegra de ser útil. (Isaac Asimov) |
![]() |
| Herramientas | Buscar en Tema |
| Desplegado | |
|
|
Temas Similares
|
||||
| Tema | Autor | Foro | Respuestas | Último mensaje |
| "La computación cuántica destrozará la seguridad de bancos en segundos" | navbuoy | La Taberna | 1 | 17-03-2025 15:12:55 |
| SendMessage a Ventana "Advertencia de seguridad" | JuanErasmo | API de Windows | 1 | 17-01-2008 22:05:37 |
| Como hacer que se vea "Si" en vez de "TRUE" en un DBGrid | lu9eui | C++ Builder | 2 | 07-08-2007 04:03:13 |
|