Llamalo mejor "eventos"

Yo también estaría interesado. Pero de blockchain etc soy novato total...

Exacto, como pone el compi lo llama registro de eventos


4. El sistema informático deberá contar con un registro de eventos que recoja automáticamente
todas las interacciones con dicho sistema informático, las operaciones realizadas con él y los
sucesos producidos durante su uso

Quiero entender que eso sólo afecta todo lo que se refiera a "facturación" (es decir, lo que concierne a la AEAT).
En el caso de TBAI (que parece lógico), esto afecta sóo estrictamente a los campos que "le interesan a la hacienda vasca" (los que se envían).
Lo digo por aclarar, es que ese "TODAS" creo que no queda claro y puede llevar a confusión.

NOTA: O al menos eso "quiero" entender yo. Habrá que esperar a que lo aclaren.

Yo entiendo que todo es de todo, no solo de facturación y tiene lógica, para ver si hay algo raro oculto...
Además ya que se pone un log.. Pues mejor de todo, es mi opinión.

Saludos.

Pero estamos dentro de un contexto de ley antifraude, que se refiere a "facturación".
¿Crees que esto me debe obligar a almacenar eventos de todos mis cambios en todas mis tablas?
Pienso en tablas como (por poner alguna): REPRESENTANTES, LOGOS, POBLACIONES, PAISES, CODIGOS_ISO, OFERTAS, CONTACTOS, DIRECCIONES_ENVIO, EMBALAJES, FASES, PIEZAS, INMUEBLES,...

Yo no le veo sentido ni justificación a que la ley antifraude me obligue a guardar "logs" de las operaciones realizadas en la tabla FASES (por poner un ejemplo).

¿Algo "oculto" en mi mantenimiento de provincias? (por decir algo)

Si tienes una Base Bases de Datos de cliente con 6GB/400 tablas y X operaciones diarias, la decisión no es tan sencilla como "ya que lo ponemos, lo ponemos a todo".
Piensa que eso implica no sólo cambios en la aplicación, sino seguramente en otros muchos aspectos.
Lo primero que se me ocurre es ¿Cómo puede crecer esa Base de Datos si a las 400 tablas les debo añadir "eventos" para todas las operaciones?

¿Porqué pienso esto? (lo dicho anteriomente)
Me baso en la experiencia de TicketBAI (y en la idea final que se ha implementado), en donde ellos quieren asegurar al final, que una factura no pueda ser modificada de ninguna forma, una vez emitida.

Esto dicho así, parece que significa que una vez generada una factura la debes poner en "sólo-lectura".
La respuesta de ellos fue que no.
Se puede modificar una factura emitida/enviada/Aceptada siempre y cuando no alteres los campos que afectan a TBAI. Si en tu factura incluyes NOTAS, REPRESENTANTES, CENTROSDECOSTE, LOGO, DIR_ENVIO, ALARMAS, RIESGO, DOMICILIACIONESBANCARIAS,... (por decir algo), puedes modificarlos sin problemas. A ellos esos campos NO LES INTERESAN (sólo los que afectan a la generación del XML de la factura).

Por eso creo que la "idea" en este caso irá por el mismo camino. Creo que cuando hablan de TODO, se refieren a temas de facturación (además de otros temas genéricos que tienen sentido, como login de usuarios, inicio y fin,...); Lo que pueda afectar a un fraude a la AEAT. Pero que yo modifique un CODIGO_ISO o una PROVINCIA no puede afectar a eso.

De todas formas, como ya hemos dicho, creo que nos estamos adelantando. Lo único que hay es un decreto ley (o documentación legal), no hay documentación técnica y por lo tanto técnicamente creo que no se debería empezar a desarrollar nada.

Hola.

Yo pienso lo mismo que neftali, esta ley antifraude es referente a la facturación. Si tienes un programa de diseño grafico, pero que además genera facturas (ejemplo tonto) no es lógico que tengas que guardar en un log todos los eventos de tu aplicación.

De todas formas como el dice, habrá que esperar a que saquen más información.

También de acuerdo con Neftali. Frecuentemente los usuarios me preguntan ¿quién ha borrado este descuento? ¿quién ha cambiado el nombre de este producto?... y se nos ocurrió meter un trigger en todas las tablas que registraran en un log las sentencias SQL que se generan desde la sesión de cada usuario.... lo probamos en un cliente que tenía una base de datos de 3 gb, 340 tablas, algunas con más de 100 campos. A la semana tenía 55 gb. cientos de registros diarios de gran peso. Desechamos la idea. Sólo guardamos las inserciones, borrados, y la última vez que se modificó cada registro, así como el último usuario que operó con ese registro.

Hemos intentado hablar con la AEAT y las personas que nos han atendido coinciden en que es un proyecto y hay que esperar que se haga el reglamento etc.
Voy coincidiendo con vosotros que las logs deben ser de los datos vinculados con facturación , que no son pocos. Ya que el proyecto hace demasiadas referencias genéricas. Por que habla de eventos de los 'sistemas informáticos' que se usen para la facturacion y eso puede ser muchisimo o algo lógico.

Ya lo hemos comentado varias veces: paciencia, paciencia, paciencia, no hay prisa, no vale la pena hacer nada, es todavía un borrador del gobierno, en hacienda no saben todavía nada hasta que esté aprobado, y tal y como van las cosas creo que tardará.

Hola oscarperez-1980, cuenta también conmigo, me parece buena idea.

En cuanto al registro de eventos, coincido con vosotros en que tiene que ser orientado a facturación (creación de la factura en la bb.dd, creación del xml, firma, envío...). Pero es cierto que despista lo de registrar también el login del usuario, que todos lo relacionamos con la conexión al ERP. Así que si lo orientamos al "programa de facturación", el login del usuario puede referirse a la apertura del formulario de facturación, y el logout cuando cierra ese formulario.

Voy con la mayoría, me parece poco creíble considerar que el «sistema informático» siga la integralidad del sistema de información y por tanto lo de registrar «todo».
Sin embargo, no creo que la interpretación arriba siga la correcta, al menos en la idea de quién ha escrito el borrador: pone en el 9.4 (pág. 12), la énfasis es mía:
Si enumera los dos eventos, será que no deben ser la misma cosa; pero sería lo que resulta de interpretar la entrada en el formulario de facturación como log in.
Por tanto creo que tu interpretación es demasiado restrictiva.

Pero era bien intentarlo. ||-||

Por cierto alguno ha visto por ahí en algún foro a Óscar Pérez?
Le he enviado un documento a tipo para ir empezando con el proyecto este de compartir el documento y no veo señales de vida.
En fin espero que sea algo leve.
Los que sigan interesados en participar que me dejen su email y comparto y ya vamos dando forma a un documento

No obligados los que hacen SII
 

Parece que no había leído bien y los programas que tengan los obligados al SII, tiene pinta de que se van a librar de los QR, VERIFACTU, envío inmediato, XMLS, etc.

Re: No obligados los que hacen SII
 

No lo sé; puedo entenderse de dos maneras:

1. cómo lo dices, con los registros del SII en la AEAT no hay que hacer nada más, estos registros cumplen ya la opción «subir los datos a Hacienda»
2. solo dice qué por uno que esté en el SII, la parte del sistema de facturación que se sube en la web y está hospedada por AEAT cumple todos los requisitos del artículo 8; solo le queda todo el resto del sistema de facturación, la parte que está en los servidores de la empresa antes de subir los registros al SII

La verdad es qué con las especificaciones saldremos probablemente de dudas, ya que si hay cualquier cosa encima del SII, por ejemplo en la definición de registro, no creo que se pudiera sostener la opción 1. ¡Paciencia!

Efectivamente, hasta que no esté redactado y re-re-recorregido no saldremos de dudas, pero es lo que dices, parece que solo se refiere a una parte, o quizás no..
A mi me parecería extraño que el SII estuviera por encima, ya que al final el nuevo reglamento es una presentación más detallada y permite que posteriormente se haga automáticamente algunas de las declaraciones.

Evento ley Antifraude
 

Por si a alguien le interesa para saber algo más sobre este tema. Sage ha sacado un Webinar de una hora para el día 05/04/2022.

https://www.sage-conference.com/even...c6Mzg5ODIwNjM=

Saludos

Gracias por el aviso. Estos de Sage siempre con un marketing muy agresivo y algo estupidos (lo digo por el punto 3 del temario: "Ticket Babi" :eek:)

Gracias tejano, lo veremos a ver si saben más que nosotros del tema...

Una pregunta, sabéis si en el proyecto de las 19 páginas hacen referencia a que el software va a tener que estar certificado Con un certificado de software? Por no rellerlo de nuevo
Gracias

Hombre, ya me dirás cuando llegues a
TICKET BABI como sistema pionero, no sé si te saca de dudas.
Era broma será un error tipográfico:D

De momento no dice nada de eso. Pero luego veremos en el desarrollo de la ley. De todas formas nosotros desde que hicimos TBAI todo el software que distribuimos lo enviamos firmado. No es nada complicado.

OK. Muchas gracias, te preguntaré si finalmente hace falta y si eres tan amable de orientarme.
Saludos

Reglamento facturacion 2012
 

Buenos días, estoy afinando lgunos detalles que se me habían escapado respecto al reglamento de facturación de 2012 para prepararlo todo para el VeriFactu. Me ha surgido una pregunta por si alguien que emita facturas simplificadas sabe la respuesta, me he encontrado 2 formas distintas de hacer una factura de los tiquetss,:
1. Factura canje: cuando el tiquet es anterior al mes en curso.
2. Factura recapitulativas. Se pueden agregar varios tiquets del mismo mes siempre que el mes de emisión sea el mismo o máximo al día 1t del mes siguiente para emitir las a empresas.

Mi pregunta es,¿ en la factura de canje puedo poner varios tiquets(facturas simplificadas)

Tienes un privado.

Pero se sabe algo del verifactu??!!.

Saludos.

No aun no. Mi pregunta es sobre el reglamento de facturación y sobre una factura en papel o pdf.
Si tengo topd bien respecto al reglamento de facturación cuando esté VeriFactu, que creo que no va a tardar, lo tendré más fácil.

Hola ermendalenda,

Lo que antes de llamaban "facturas de canje" es lo que ahora se llaman "facturas sustitutivas de simplificadas".
Y, por supuesto, que una "factura sustitutiva de simplificadas" puede sustituir a varias facturas simplificadas.

En el ejemplo clásico:
El dueño de un bar compra todos los días el pan en una panadería que le emite, cada día, la correspondiente factura simplificada (ticket) sin identificación de destinatario.
Al final de mes le pide a la panadería que le haga una factura completa a su nombre que englobe todas las facturas simplificadas del pan comprado todo el mes, para poder deducirse impuestos.
Esa factura es la "factura sustitutiva de simplificadas".

Y como ya habrás visto en TicketBAI, se tiene que identificar en el campo "FacturaEmitidaSustitucionSimplificada" y además tiene que identificar todas las facturas simplificadas a las que sustituye en la sección "FacturasRectificadasSustituidas" (100 facturas simplificadas, con sus serie, número y fecha).
Y, en el caso de que sean más de 100, se deben identificar, al menos, la primera y la última.

Saludos

Esas cosas son las que me molestan, si una persona ya tiene pensado pedir factura, porque no lo dice?, en las tiendas pasa igual, va después de un mes y dice aquel ticket de hace un mes... me haces factura, pero con fecha de hace un mes :) si claro........... pues que lo pidan al momento no?.

Y relacionado con ese tema, se puede hacer un albarán de cada vez que va y luego facturar los 30 albaranes a final de mes?, porque tengo entendido que en ticketbai o la normativa de Dais Vasco ya no se va a permitir, que hay que facturar en el momento de la venta, no se permite albarán??.

Gracias.

TicketBai tiene que permitir lo que diga el reglamento de facturación

No digo que no lo permita, me refiero a lo que pide la gente, quizás no lo expliqué bien. Por otro lado ticket bai cono normativa permitirá lo que la.ley permita. Pero tu programa puede no tenerlo contemplado, eso o las 100 cosas posibles, en ese caso si el cliente lo necesita pues tendrá que buscarse otro.

Saludos.

¿Se puede cambiar la forma de pago en una factura ya emitida a ticketbai?, En un TPV se equivocan y ponen la factura simplificada como contado y es con tarjeta, hay descuadre de caja.

Imagino que la forma de pago se puede cambiar, ya que no se hace referencia a la misma en el XML.

Como poner otras ventas.
 

Tengo una duda, de que forma se vende:
1.- Un bono general, es un dinero que el cliente entrega para quedar a cuenta en su ficha.
2.- un Vale, cuando se devuelve un producto y no se da el dinero se hace un "Vale".



Gracias.

Hola Oscar.
Hay obligación. De darle la factura que pidan, tiene 4 años para solicitarla.

Eso lo sé, no se eso lo que yo decía.

Te recuerdo que TicketBai es en las haciendas forales y el reglamento no va a ser el mismo que el que está haciendo la AEAT.
Por tanto esas preguntas son para el foro de ticketbai, pero te la respondo y espero que el moderador traslade ambos mensajes.
En ticketbai mientras no modifiques el xml y si vuelves a emitir la misma factura (papel o pdf...) le pongas que es duplicado.
La forma de pago no es un dato que solicite ticketbai.
En VeriFactu aún no sabemos si va a ser un dato necesario y si fuwra necesario ese dato en el XML habría que emitir una anulación y emitir una nueva o una sustitutiva o lo quE digan en las especificaciones del reglamento cuando lo hagan. Pero no creo que lo pidan.
Lo que sí va a pedir verifactu es que si hay 1 o varios pagos a cta se ponga la fecha de cda pago.

En resumen a ticketbai no le afecta que cambies en tu base de datos la forma de pago una vez generado el ticketbai, pero si le afectanotros campos, como por ejempo cambio de cliente.
Saludos.

OK ok.
Si te refieres que algunos clientes son un pelin "trabajosos"
Totalmente de acuerdo.
Y cuando vienen de algún ayuntamiento pidiendo facturas ni te digo.

El bono, ssegún la ley de facturación, tendrías que declararlo haciendo una factura ya que estas teniendo un ingreso y hay que declarar ese movimiento. No recuerdo ahira si hay que ponerle un iva, creo que si, si ya sabes de antemano que va a comprar ya puedes desglosar el IVA. cuando se haga la compra puedes hacer 2 cosas, o creas una línea en la misma factura para cada uno de los tipos impositivos desglosado tratando el pago con Bon como si fuera un descuento. O hacer una factura adicional rectificativa solo con los pagos en bono en negativo.
El vale.es el mismo tratamiento que cualquier forma de pago, efectivo, tarjeta.

Correcto.
Ese campo no va en el XML y por lo tanto puedes cambiarlo.

(pero esta pregunta deberías hacerla en el hilo corespondiente a TicketBAI)

Muchas gracias por las respuestas.

Sorry me equivoqué de tema.

Hola a todos.

En la charla de ayer de Sage, se les escapó un dato que no se si es verdad o no (igual ellos tienen más información). Dijeron que todo esto era obligatorio a partir de enero de 2014. :)