![]() |
![]() |
| 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
|
|||
|
|||
|
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. |
|
#2
|
|||
|
|||
|
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. |
|
#3
|
|||
|
|||
|
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. |
|
#4
|
|||
|
|||
|
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. |
|
#5
|
||||
|
||||
|
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) |
|
#6
|
|||
|
|||
|
Cita:
Pero al final no vas a evitar la pérdida datos... si haces una copia a las 10 de la mañana y otra a las 12 (poniéndonos muy optimistas), perderás los tickets/facturas creados en esas 2 horas. Y dependiendo del negocio, pueden ser 1-10-50-100 documentos tranquilamente. Con lo cual estás en el caso inicial de este hilo. No veo nada fácil como evitar la pérdida de datos: habrá empresas en las que se puedan poner métodos más fiables (y más caros) pero en otros no podrás pasar como mucho de la copia diaria. Este es el principal motivo por el que nosotros descartamos hacer el modo No Verifactu |
|
#7
|
|||
|
|||
|
Perdonad, pero... esto de la pérdida de facturas y demás que tiene que ver con Veri*factu?
Acaso en el 2022 no se podían perder las facturas? Que si, que estamos con el SIF y demás, pero le estáis dando bombo a unos temas que ya existían antes de Veri*factu e incluso antes del Reglamento de Facturación (o como se llame). Que si primero hago los registros de facturas a partir de los RF que recupero de Hacienda.... no será que primero hago los registros de RF que son precisamente lo que estoy recuperando de hacienda? Y después ya veremos como recupero las facturas, que sin su detalle tendrán la misma información que los RF !!!!! Entonces, para que recuperar regenerar los registros de facturas si estoy duplicando la información que ya está en los RF? Lo que necesito para enviar el siguiente XML lo tengo en los RF recuperados (incluido el último número de factura), no me hacen falta los registros de facturas. Si aparece una devolución pues la gestionaré a mano con lo que tenga, pero si no estaré desarrollando para 4 devoluciones en un supuesto de pérdida de facturas? Cuantas facturas se han perdido en los últimos 10 años? Estoy matando moscas a cañonazos? Da la sensación que la facturación se ha inventado ahora con Veri*factu. No sé si me explico bien. Y disculpad mi atrevimiento. |
|
#8
|
|||
|
|||
|
No solo no es nuevo, ahora el sistema tiene que garantizar la conservación, y lo unico que te libras en no conservar son los registros enviados, me rrmito a la ley antifraude.
|
|
#9
|
||||
|
||||
|
Cita:
Y eso ninguno de nosotros lo queremos.
__________________
El recuerdo es la prisión en la que el alma sueña pasado, cuando no vive el presente, ni quiere un futuro. |
![]() |
| 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 |
|