FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
|||
|
|||
Gracias Neftali. Nuevas dudas:
- El IDENTIFICATIVO_TBAI se supone que es el CIF o algo similar??? - El CODIGO_CRC es un código de redundancia que genera la administración o el programa? Si lo genera la administración... hasta que no está subido no se puede imprimir el QR ¿Correcto?
__________________
Amar al mundo apasionadamente. |
#2
|
||||
|
||||
Correcto. En el caso de TBAI es el CIF con el que se ha generado la factura.
Cita:
Se supone que este será algo similar. Al final de lo que se trata es de que ese QR tenga una URL con unos datos mínimos para encontrar la factura que está almacenada en hacienda.
__________________
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. |
#3
|
|||
|
|||
Gracias de nuevo!!!! Empezaré a generar así el QR (con una URL inventada) para ir maquetando el sistema de facturación. Como he comentado, quiero sacar el SIF como un módulo externo al ERP... es decir, quiero que mi ERP no pueda emitir facturas... pero tiene que saber, es decir, registrar, qué facturas se han emitido (para la gestión del cobro, envío de facturas (EDI, FacturaE, email, correo...) contabilización y listados), por lo que no sé si al final el ERP tendrá que estar también certificado... o autocertificado.... a ver si sueltan más documentación de cómo las empresas deben emitir, imprimir y comunicar las facturas.
__________________
Amar al mundo apasionadamente. |
#4
|
||||
|
||||
Si, para probar a generarlo/imprimirlo, por ahora que no hay documentación, puedes hacerlo con cualquier URL, aunque sea siempre la misma.
Y luego una vez impresa la factura/ticket probar a escanearlo con el móvil para ver si funciona.
__________________
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. |
#5
|
|||
|
|||
Sin pretender abusar de los que ya os habéis peleado con el TicketBai... ¿Cómo se gestionan las facturas que son emitidas por otros softwares y que son importadas al ERP? Por poner ejemplos:
- Prestashop, wordpress, wooCommerce.... Nuestro ERP recibe las facturas ya hechas y las incorpora al fichero de facturación. ¿Tiene que estar el Presta preparado para Veri*factu? - Tengo con una distribuidora de pescado y marisco que vende a restaurantes y hoteles... pero además tiene un restaurante, y el programa de restauración (comandas, tickets y cobro) lo gestiona otra empresa... y las facturas simplificadas se importan a nuestro ERP. Imagino que esta empresa hará la comunicación con H.P... pero el tratamiento fiscal de dichas facturas lo hace nuestro ERP. ¿Podemos almacenar facturas de otros sistemas sin presentarlas? - Una cadena de pescaderías tienen balanzas inteligentes. Hacen facturas simplificadas y por la noche transmiten las ventas realizadas que se incorporan como una única factura recapitulativa por cada balanza... por cierto, una vez un pillo aprendió a resetear una de las balanzas y de las 3 balanzas del local sólo se recibían ventas de dos de ellas. La tercera nunca tenía ventas. ¿Tenemos responsabilidad en esos casos? ¿Cómo habéis resuelto estas situaciones con el TicketBai?
__________________
Amar al mundo apasionadamente. |
#6
|
||||
|
||||
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. |
#7
|
||||
|
||||
En TicketBAI cualquier dispositivo que emita facturas (BALANZAS, TPV, Etc..) se tiene que adaptar a TicketBAI. Me imagino que en verifactu ocurrirá lo mismo.
|
#8
|
||||
|
||||
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. |
#9
|
||||
|
||||
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. |
#10
|
||||
|
||||
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 |
#11
|
||||
|
||||
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. |
#12
|
|||
|
|||
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 |
#13
|
||||
|
||||
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. |
#14
|
|||
|
|||
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. |
|
|
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 |
|