Ermendalenda dijo:

Me sirve... tenía planeado algo así... recibir las facturas en un servidor propio y encargarnos nosotros de realizar el envío a Hacienda. Pero me preocupa que el usuario use mi programa en dos puestos con series diferentes y a uno de ellos le borre las DNS o bloquee su salida a internet, por ejemplo, provocando que sólo me llegue una de las series. No sé si Hacienda clasificaría como software de doble uso un sistema así. Realmente sería sencillo seguir trabajando con "B", ya que lo normal en ventas del día a día (bares y tiendecitas) es que nadie solicite el ticket impreso, o te presenten un "ticket proforma" sin QR...

Gracias.

Entiendo entonces que todavía no se puede hacer ninguna prueba. Lo que también hay que tener en cuenta y se me olvidaba es activar un log de entrada/salida por usuarios, creo, ¿no?.

Saludos.

La ley dice lo siguiente no solo un log de entrada/salida de usuarios.

Y en cuanto un usuario te pida un ticket "correcto" ya la tienes liada...
Si le das un ticket sin QR (cuando esté estandarizado) te va a decir que "eso que es". ¿Tendrás opción de generar con QR y sin QR?
¿Le dirás que con QR no puedes?
Si es un ticket que presenta a una empresa (gastos de empresa) te dirá que ese ticket no es válido, que quiere el "bueno".

No se, yo no lo veo nada fácil.
Que habrá o se inventarán formas, seguro, pero fácil no lo veo y menos sin la complicidad del software informático. Por eso el incapié en las multas a las empresas desarrolladoras que facilitene sas trampas.

Tiquismiquis.... :p

[/quote]

En los restaurantes sobre todo cuando pides la cuenta te dan un papel que pone "Proforma" o "Preventa" o cualquier tontería de esas. Imagino que la mayoría de la gente (yo por ejemplo) pagan y se van pero imagino también que si pides el ticket te lo harán con su numeración correcta y tan felices. Lo que no entiendo es cómo la AEAT con lo que son no se meten en ese comportamiento y empiezan a dar estacazos.

Saludos.

Yo en en el servidor tengo varias comprobaciones:
Compruebo de nuevo la estructura contra el xsd, compruebo encadenamiento compruebo que ko haya saltos de numerador de cada serie, compruebo que en esa caja/comercio se hayan enviado ventas después de las últimas 30 horas anteriores(si voy mandando un correo todos los días durante 1 semana).

Yo en en el servidor tengo varias comprobaciones:
Compruebo de nuevo la estructura contra el xsd, compruebo encadenamiento compruebo que ko haya saltos de numerador de cada serie, compruebo que en esa caja/comercio se hayan enviado ventas después de las últimas 30 horas anteriores(si no voy mandando un correo todos los días durante 1 semana).

Si ves que pueden clonar equipos y quitarlos se la red puedes poner un límite de registros de facturas sin enviar y bloquear con clave

En los restaurantes sobre todo cuando pides la cuenta te dan un papel que pone "Proforma" o "Preventa" o cualquier tontería de esas. Imagino que la mayoría de la gente (yo por ejemplo) pagan y se van pero imagino también que si pides el ticket te lo harán con su numeración correcta y tan felices. Lo que no entiendo es cómo la AEAT con lo que son no se meten en ese comportamiento y empiezan a dar estacazos.

Saludos.[/quote]


A ver, ya sabemos que hay de todo, pero también te digo que yo creo que con la caña de inspecciones que estan haciendo,cada vez menos.
Son varias las razones por las que se hace así, créeme que ya les gustaría a la mayoría de los restauradores ahorrar en papel y no dar 2 viajes a las mesas.
1. Dar la posibilidad al cliente de repasar el tiquet sin tener después que nadar haciendo rectificativas, tanto de productos servidos como de precio. Ya que el camarero se ha podido equivocar. Y a gi te gustará repasarlo pero el camarero no puede estar a tu lado hasta que esté todo correcto por eso se deja el Preventa o previo tiquet o comanda o como quieran llamarlo cada uno

2.dar la posibilidad al cliente de pedir algo más y poner en la misma cta por que en el último instante ha llegado alguien
3. Dar la posibilidad al cliente de poder dividir la cta entre varios comensales y darle a cada uno su ticket, que eso lo pueden decidir después de ver el total.
4.que al grabar el tiquet quede reflejado correctamente la forma de pago, tanto como para imprimir como para la gestión interna.
5. Que al restaurador le permita solucionar un "sinpa" sin cerrar el tiquet y pagando más impuestos de la cuenta

Creo que no conoces Andalucía :D
Edito: ¡¡¡Pero si somos casi vecinos!!!

Jefe supongo que sí eres moderador podrás ver mi ubicación aproximada. Jeje.
Bueno ya sabes que conozco Andalucía, pero aún conozco más grandes empresas que Dan servicios informáticos a los restauradores y sé como están actuando y aquí no se la juegan

Tan sólo veo una IP y curiosamente tenemos el mismo ISP, por lo que debemos estar muy, muy cerca.

Pues ya te digo yo a ti que la mayoría de las veces pago y con la vuelta viene el mismo papelito que me han traido al principio en vez de traerme un ticket formal.

Uh... igual el problema es mío que solo voy a antros :D:D

A mí sólo me dan un ticket "formal" cuando pago con tarjeta, y además preguntan ¿quieres ticket?

No es eso. Yo gestiono mucho de restauración y para hacer el software me remango en los restaurantes y cafeterías.
El dueño del restaurante puede decirle a los camareros que cuando paguen ponga n la factura 1000 veces pero en cuanto se da la vuelta el camarero trae la vuelta con wl tiquetprevio y como comprenderás, el propietario dl restaurante tiene mil prioridades por ejemplo atender bien a la clientela y tener un margen aceptable bueno o muy bueno lo que no a a estar es sancionado a los empleados por esa "mala" actuación, el cliente que necesita tiquet o factura ya se preocupa de pedirlo y si no al siguiente día con decir wl importe y la hora a la que le atendieron ya le pueden imprimir el tiqiet o factura (que ya estaba grabado correctamente)
Esto lqo vivo constantemente y yo mismo he intentado que se cumpla dar el tiquet SIEMPRE.

Claro, y cuanta gente se queja de que se emiten yiquets sin pedirlo que estamos talando árboles.
Hay que ponerse en todos los lugares.
Si te fijas además en muchos lugares que te dicen si quieres tiquet te dan copia del datáfono pero no el tiquet de la compra. No hay formación y los márgenes comerciales de la mayoría de los negocios no dan para dar formación, van a lo minimo.
Es difícil encontrar el equilibrio, entre lo que necesita el cliente y por las cosas que se queja. Si se le da todo necesitas dar más servicio con el aumento de costes y por tanto se refleja en el tiquet y finalmente el cliente se pira al bar de la esquina por precio.

Pues no sé que deciros, yo creo que la expedición de una factura/factura simplificada es obligatoria en todas las transacciones menos alguna excepción. Y no creo que los bares sea el caso de excepción.

Cierto, pero no podemos ser más papistas que el Papa, tendríamos que empapelar a todo el mundo cada vez que no la den.
También te digo que cuando empiece verifactu ya verás como la AEAT se encarga de que la solicite todo dios.
De todas formas la normativa a la que te refieres tiene un pelín de lio fíjate:
Obligación de facturar
Los empresarios y profesionales están obligados a expedir factura y copia de ésta por las entregas de bienes y prestaciones de servicios que realicen en el desarrollo de su actividad y a conservar copia de la misma. También deben expedir facturas en los supuestos de pagos anticipados, excepto en las entregas intracomunitarias de bienes exentas.

Asimismo, otras personas y entidades que no tengan la condición de empresarios o profesionales están obligadas a expedir y conservar facturas u otros justificantes de las operaciones que realicen.

1. Supuestos de expedición obligatoria de factura
Siempre y en todo caso, los empresarios y profesionales están obligados a expedir una factura en los siguientes supuestos:

Cuando el destinatario sea un empresario o profesional que actúe como tal.

Cuando el destinatario de la operación así lo exija para el ejercicio de cualquier derecho de naturaleza tributaria.

Exportaciones de bienes exentas del IVA (salvo las realizadas en las tiendas libres de impuestos).

Como casi todo... abierto a interpretaciones.

Y yo ahora me pregunto. Si se va a dar la opción de no enviar la información imagino que no habrá que imprimir el QR porque no habrá datos en la aeat y esto me lleva a pensar que si no se imprime el QR ¿no habrá mucha suspicacia por parte de los clientes?

Yo creo que el QR hay que imprimirlo siempre no solo cuando es VERI*FACTU y asi hacienda irá guardando esa información para luego cotejarla cuando pida los datos a los que no envían.

Lógicamente el resultado que de hacienda a esos códigos QR será distinto para los que envían las facturas que para los que no.

Así usan a los contribuyentes como inspectores.

Buenos días.
Los que seleccionen el método de no enviar estarán sujetos a más obligaciones, no a menos. Es decir, en un escenario de no enviar, no sólo vas a tener que generar el QR y el XML, si no que además tendrás que firmar el XML, guardarlo bien guardado eel tiempo que la ley fiscal te obligue(creo que 5 años). Disponer de una opciónnpra enviar desde hasta periodo, esos Xml, en caso de requerimiento de la AEAT

Saludos

Nodo< incidencia<
 

Se os ocurre como van a usar el nodo incidencia:
Suongo que, entre otras cosas, servirá tambien para reenviar registros de altas saltándose el encadenamiento por que en su momento no se generó adecuadamente

Supongo que todos los que tenéis preparado este log de operaciones es a través de las prestaciones que os ofrezca la base de datos que uséis cada uno, verdad?

Me temo que las bases de datos que solemos usar no tienen esa opción, la mía por lo menos no la tiene (ElevateDB) así que habrá que montar toda esa movida "a pelo".

Por si a alguien le sirve aquí hay unos componentes que dicen que hacen precisamente eso aunque yo no los he probado.

Saludos.

Nosotros vamos a almacenar esos eventos desde la aplicación.
Para determinadas operaciones que realiza el usuario (entrada/salida/activación/desactivación/...).

Lógimente cada uno tendrá que hacerlo de la mejor manera y que se lo permita su motor de base datos para no afectar mucho al rendimiento de la aplicación.

Para los que tengais firebird os paso este enlace que puede ser un buen punto de partida https://firebird21.wordpress.com/202...a-informatica/

De todas formas la ley dice los siguiente

Si la base de datos no permite registrar estas cosas, y intentan entrar en el registro de eventos. Esto no se podrá hacer ya que nuestras aplicaciones no se enteraran.

En la modificacion al proyecto de ley los requisitos de las logs y el manual lo han eliminado. Así que por eso no os preocupeis

Pues mira.... Gracias por la info.

¿Quieres decir que no hay que llevar el registro de enventos? Por que eso sería la leche.:D

¿y eso esta publicado ya?

Nosotros intentamos eso hace algunos años, para buscar "responsables" cuando hay un trabajo mal hecho.... tuvimos que quitarlo porque la base de datos crecía diariamente de una manera alarmante... Ahora sólo registramos cuando se crea, modifica o elimina un documento de venta o de compra (albarán o factura).

De todas maneras también he leído que se ha suprimido lo del manual en la última revisión, pero en lo referente al "Registro de Eventos" dice:

OM = Orden Ministerial, que todavía no ha salido ni se la espera.

Perdona a que os referis con lo del manual.

¿Qué manual? ¿Ha habido manual en algún momento :D:D?

En la documentación que hay aquí siguen estando los eventos:
https://www.agenciatributaria.es/AEA...ERI_FACTU.html

Correcto pero deja a la Orden Ministerial los detalles del mismo y las garantías de estos se prevee que sean las mismas que el registro de facturación, y aunque no esta muy claro entiendo que serán accesos vabasicos a opciones del programa grabando usuario etc, No tiene sentido crear una log de un blockchain ni d elas bases de datos de facturas, ya que la modificación, ya sea conscientemente o inconscientemente,de esos registros, rompen la cadena. Así que si hay que crean un log sobre esto será algo muy trivial pero con formato xml y otro blockchain(encadenamiento).
Por otro lado en algún lado lhe leido, lo buscaré, que los que envíen tampoco tendrán que crear esos eventos.
Y sí, al principio había referencia a hacer un manual, pero como ves, enlace actualización, han quitado las referencias al mismo.

Ya ll he encontrado.
Los que envíen tampoco tienen que tener eventos:

Y aquí, por si quedan dudas:
Hay un monton de motivos, por los cuaes, es mejor diseñar el software solo para enviar.

No he visto el enlace, pero si es de "factura electrónica", debería ir en "su" hilo.

El problema es que tengo entendido que van a estar relacionados. O sea, aunque aún está por definir el reglamento, la intencion inicial es que la factura elec6ronica sean una ampliación de verifactu(DEL XML vanos)

Yo creo que son dos cosas distintas o por lo menos estaría bien no mezclar todo. El reglamento de la factura eléctronica (definicion, formatos, xml, ...) ya esta totalmente definido. Lo que falta de definir es la obligatoriedad de uso, que a hora solo es necesaría si trabajas con una administración pública.

Creo que no es correcto, dan válidos los formatos de factura electrónicas de normativas europeas pero no sabemos si en el desarrollo reglamentario, que parece que sí, van a poner otro formato.
Boe Aprobacion Ley 18/2022 Crea y Crece: Pagina 72