FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#541
|
||||
|
||||
Sin saber nada de TicketBAI la lógica me dice que el responsable de cumplir con la normativa es el programa que emite la factura originalmente y efectivamente hay muchas cosas de las que no se ha hablado como son facturas emitidas por webs, balanzas, registradoras, terminales móviles y tantos millones de dispositivos que andan por el mundo haciendo facturas simplificadas. No estaría mal ir enterándose de qué pasará con esas cosas.
Saludos.
__________________
Be water my friend. |
#542
|
||||
|
||||
En TicketBAI cualquier dispositivo que emita facturas (BALANZAS, TPV, Etc..) se tiene que adaptar a TicketBAI. Me imagino que en verifactu ocurrirá lo mismo.
|
#543
|
||||
|
||||
En el caso de TicketBAI (que por algo lleva el prefijo de Ticket) cuando tú entregas un ticket, ya debe llevar impreso el QR con toda la información necesaria para que el usuario pueda validar esa factura en la web de hacienda. Por lo tanto el terminal que emite ese ticket (o el software asociado) son los que deben realizar la emisión/generación/envío de esa factura.
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#544
|
||||
|
||||
Cita:
En realidad es que TicketBAI se ha implementado (y por eso lleva el prefijo Ticket) para los negocios "pequeños" que generan tickets. Que son los que hasta ahora se les "descontrolaban" (en cuando a ventas y fiscalidad). Lo que pretenden es que todos esos negocios (bares, restaurantes, peluquerías, tiendas pequeñas, chinos,....) que hasta ahora te daban un ticket (no una factura) y a final de mes nadie sabía realmente lo que facturaban, ahora estén fiscalizadas igual que las grandes.
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#545
|
||||
|
||||
Cita:
Te cuento cómo hemos resuelto nosotros los mismos escenarios que tú comentas en caso de nuestros clientes en TicketBAI: Cita:
Para el caso de nuestros clientes con tienda online Wordpress-Woocommerce que emiten facturas directamente desde esa aplicación, sólo tienen que instalar nuestro plugin que hará todos los procesos, incluida la generación del PDF de la factura con los códigos TBAI y QR y el envío automático, inmediato, del XML firmado la factura a Hacienda Foral. Cita:
Por lo cual cualquier equipo emisor de facturas (incluidos TPVs, balanzas electrónicas o cualquier otro) debe tener conexión a Internet. No pueden almacenarse las facturas para enviarse posteriormente. Cita:
Aparte, pueden emitirse, posteriormente, facturas completas sustitutivas de facturas simplificadas (llamadas habitualmente facturas de canje de tickets) que agrupen a varias. Pero es una nueva factura y no exime del envío de las primeras. Hay responsabilidad por parte del obligado tributario (la persona física o jurídica que debe emitir las facturas) así como por parte de la empresa desarrolladora del software garante TicketBAI (que debe haber obtenido licencia para ello). El software no debe tener posibilidad de contabilidad "B", ni de borrado de facturas o de manipulación de facturas. Una factura emitida es algo casi sagrado e intocable porque va encadenada mediante firma con la anterior y posterior. Las sanciones son suficientemente fuertes como para que a nadie se le ocurra infringir las normas. Saludos |
#546
|
||||
|
||||
Hola a todos.
Se supone que hay que evitar que los datos se alteren, pero si el usuario si es un poco listo podrá entrar en el fichero físico de la base de datos por su cuenta y borrar un registro. Nuestra base da datos esta en firebird 2.5 y podemos cambiar la clave el usuario e incluso borrar el usuario SYSDBA. Pero si el usuario se lleva el fichero de la base de datos a otro ordenador con el mismo motor podrá acceder con el Usuario maestro (SYSDBA). La pregunta es si hay alguna forma de evitar esto en firebird o si en alguna versión más reciente ha cambiado esto. |
#547
|
||||
|
||||
Un usuario no puede tener acceso a la BD para llevársela, copiarla ni nada por el estilo.
Por algo es un sistema cliente/servidor, los clientes no tienen que saber ni dónde está la BD. Los clientes/terminales/usuarios no deben tener acceso al servidor. El servidor no puede tener compartida carpetas ni nada que permita a cualquiera entrar y copiar la BD. Firebird solamente necesita tener abierto el puerto 3050 en el servidor, nada más. Aparte de eso, es un tema que se ha tratado otras veces, a ver si lo encuentro... para no repetir lo mismo en este hilo que no trata sobre eso. |
#548
|
|||
|
|||
Cita:
Opino como tú. Lo mejor es utilizar una arquitectura cliente/servidor donde el usuario no tenga acceso alguno al servidor donde se guardan las facturas. La aplicación le muestra los datos que deba ver, cuando los pida, y punto pelota. Saludos |
#549
|
||||
|
||||
Cita:
Estoy de acuerdo con lo que decís, el sistema ya esta configurado de esa manera. Pero al tratarse de una aplicación comercial, es el usuario el que instala la aplicación en su servidor y lógicamente tiene acceso a todos los ficheros de su sistema. Un Saludo. |
#550
|
||||
|
||||
A ver si encuentro esos enlaces...
|
#551
|
|||
|
|||
Cita:
Puedes importar posteriormente las facturas a otro ERP para gestionar la contabilidad y ese ERP puede estar separado del que emite las facturas. Si un empleado, empresa o autónomo, separa ese dispositivo de facturación de la generación de tiquets o facturas verificadas con su qr y no emite el xnl ni lo envía ni lo guarda con intención de no declararla, lógicamente, el distribuidor del software y/o empresa i staladora/mantenimiento no tienen responsabilidad siempre que no se haya participado en facilitarlo, que el software no tenga alguna trampa demostrable. Aún así entiendo que habrá situaciones dudosas, pero se entiende que so hay duda razonable cualquier acusación se quedará en nada. Saludos |
#552
|
||||
|
||||
Cita:
De todas formas no hace falta algo tan complejo. Simplemente en una tienda que emitía tickets, bastaba con "tirar a la basura" 1 de cada tres tickets que te han pagado en efectivo. Ahora eso ya no será posible, porque el ticket debe lllevar el QR y eso significa que ha entrado en el sistema, se ha generado y se ha enviado a hacienda (y el usuario podrá escanearlo y comprobarlo). A no ser que no entregarás nada al cliente y a posteriori lo hicieras "desaparecer" (pero eso no es nada habitual). Yo creo que en ese caso, si el cliente ha "tocado" la balanza y el sistema informático no ha facilitado las trampas, no es responsabilidad del software, sí del cliente.
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#553
|
|||
|
|||
Cita:
Pero centrando en tema y sentar bases de trabajo (corríjanme si me equivoco): 1º El software que emite la factura tiene que generar inmediatamente el XML y un QR que identifique la factura. Se supone que el XML ya tiene que tener la huella generada y el encadenamiento. 2º Esas facturas emitidas pueden ser recogidas por otro software, como un ERP o una Contabilidad. Lo único obligatorio para estos receptores de facturas es que tenga registrado el XML generado por el SIF, el XML no debe ser generado (o recarlculado) a posteriori por ningún otro software. 3º La comunicación a los servidores de hacienda lo puede hacer cualquiera de los programa: el SIF que emite la factura, el que ERP que procesa la estadística, el SGA que gestiona la logística o la CONTABILIDAD que fiscaliza los ingresos. (¿existe algún plazo de entrega de dichas facturas?, ¿debe ser en tiempo real, al día siguiente o antes de 4 días, como el SII?) 4º La base de datos de facturas emitidas es responsabilidad nuestra (su acceso, seguridad, fiabilidad, transparencia...) por lo tanto dejar la base de datos en un "portátil" de un cliente no es aceptable... (no estoy pensando en grandes empresas ni en pymes... seguro que todos las tenemos bien controlados sus servidores... hablo de lo que hay que plantearle a pequeños autónomos que tienen una panadería, un ultramarino, una pescadería, un quiosco de prensa....) ¿Este planteamiento es correcto? ¿Un sistema calificado como VERI*FACTU puede NO enviar las facturas en tiempo real?
__________________
Amar al mundo apasionadamente. |
#554
|
||||
|
||||
Quiero recordar que en una charla que dieron los de hacienda sobre este tema aclararon que, aunque el software siempre debe de estar preparado para enviar los datos, es decisión del usuario final enviarlos o no. Por supuesto aclararon que los que enviaran datos estarían menos controlados que los que no.
__________________
Be water my friend. |
#555
|
|||
|
|||
Cita:
Contesto a tus preguntas (suponiendo que el reglamento de Verifactu sea, al final, similar al de TicketBAI) 1º Sí 2º Sí 3º En TicketBAI de Álava y Gipuzkoa el envío debe ser inmediato (en el mismo momento de generar la factura). En Batuz-TicketBAI de Bizkaia en los mismos plazos de las declaraciones de IVA (trimestral en la mayoría de los casos, mensual en algunos otros y en 4 días para los anteriormente obligados al SII, al que también sustituye) 4º Parece poco aconsejable dejar la base de datos de facturas emitidas al alcance del cliente (que seguro que tiene un cuñado que sabe manipularlas). Me parece que lo razonable es que se transfieran a un sistema más seguro y que se considere que las facturas "legales" son las almacenadas en dicho sistema seguro. Cita:
Por lo que .... mejor enviar que estar recibiendo visitas frecuentes inoportunas. Saludos |
#556
|
||||
|
||||
Cita:
En realidad el QR se puede generar en cualquier momento, hasta en el momento justo de imprimir, porque no cambia, es independiente del momento en el que se genere. Lo que sí debe ser inmediato es el XML. Cita:
El encadenamiento justo es para asegurar que una vez generada la factura N, la (N-1) ya no se va a modificar (y así recursivamente hacia atrás). Cita:
Por ahora para la LeyAntifraude parece que se podrá optar por enviar automáticamente (VERI*FACTU) o bajo petición cuando hacienda lo solicite. Cita:
Otro tema es como gestionar la seguridad en cuanto a copias de seguridad.
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. Última edición por Neftali [Germán.Estévez] fecha: 22-09-2022 a las 10:30:28. |
#557
|
|||
|
|||
3º La comunicación a los servidores de hacienda lo puede hacer cualquiera de los programa: el SIF que emite la factura, el que ERP que procesa la estadística, el SGA que gestiona la logística o la CONTABILIDAD que fiscaliza los ingresos. (¿existe algún plazo de entrega de dichas facturas?, ¿debe ser en tiempo real, al día siguiente o antes de 4 días, como el SII?)
Hay que esperar al reglamento definitivo con todas las pautas bien definidas en su Doctrinas. Lo que pienso que van a decir es que debes enviarlo loables posible teniendo en cuenta las reglas de mínimos de facturas y tiempos, que esas reglas te las podrán ir cambiando después de cada enviom 4º La base de datos de facturas emitidas es responsabilidad nuestra (su acceso, seguridad, fiabilidad, transparencia...) por lo tanto dejar la base de datos en un "portátil" de un cliente no es aceptable... (no estoy pensando en grandes empresas ni en pymes... seguro que todos las tenemos bien controlados sus servidores... hablo de lo que hay que plantearle a pequeños autónomos que tienen una panadería, un ultramarino, una pescadería, un quiosco de prensa....) Está claro que existen unas normas de seguridad mínima de acceso a datos y la nueva ley te dice que hay que intentar evitar la modificación de los mismos, pero Si seleccionas la modalidad de envío te vas a evitar muchos quebraderos de cabeza. Si te sirve, mi software t4abaja en local pero lo que hago es enviar cada venta en un XML a un servidor externo con in servicio REST que guarda todas las ventas y el se encargará de enviarlas a verifactu. Con lo cual tengo garantizada la inviolabilidad. |
#558
|
||||
|
||||
Hola a tod@s.
Entonces... para ir aclarándome que me he despistado un poco de este tema. El asunto está en que a todas las facturas/facturas simplificadas de venta hay que ponerle una marca determinada, firmarlas y a partir de ahí no se podrán modificar. Por otro lado el programa tiene que tener la capacidad de enviarlas a un webservice y es el cliente el que decide si las envía o no. ¿Es correcto este resumen? Gracias y un saludo.
__________________
Be water my friend. |
#559
|
|||
|
|||
Cita:
En Verifactu está aún por definir hasta que se publique el reglamento. Te puedo contar cómo se hace en TicketBAI (supongo de Verifactu al final será algo similar): - Recopilas todos los datos de la factura (emisor, destinatario, líneas de detalle, régimen de IVA del emisor, serie, número, fecha, hora, etc) - Creas un XML que contiene esa información junto con parte de la firma de la factura anterior + los datos de la licencia de software garante TicketBAI - Firmas ese XML con un certificado digital - Obtienes un código TBAI y un código QR, a partir de la firma del XML y los imprimes en la factura - Envías el XML firmado de forma inmediata (salvo en Bizkaia, que con Batuz tienes un tiempo algo mayor) En Verifactu parece ser que van a dejar la opción de que no envíes, pero que a cambio de que tengas la puerta abierta para que te visite el inspector de Hacienda, un día sí y otro también, para comprobar el correcto encadenamiento de las facturas. Saludos |
#560
|
|||
|
|||
Cita:
Yo por ejemplo, que como la mayoría de vosotros, soy desarrollador, no voy a incluir la opción de no enviar por 3 motivos evidentes: 1.no quiero problemas, 2.no quiero problemas, 3.no quiero problemas. Por otro lado los tipos de facturas hay algunos mas: Factura Simplificada Factura Normal Factura Simplificada Rectificativa Factura Rectificativa de Factura normal Factura recapitulativa Factura de canje/sustituiva Te lo digo por que cada tipo debe tener su numero de serie Última edición por ermendalenda fecha: 22-09-2022 a las 21:32:44. |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Hijo de Informáticos | gluglu | Humor | 3 | 13-03-2007 11:05:35 |
Adictos informaticos ... | Trigger | Humor | 2 | 11-10-2004 12:18:32 |
Nosotros los Informáticos | Trigger | Humor | 1 | 10-10-2004 14:58:09 |
Patrón de los Informáticos. | obiwuan | Varios | 20 | 10-09-2003 14:44:54 |
Chistes Informaticos | jhonny | Humor | 2 | 11-08-2003 21:59:09 |
|