Eso seria lo ideal, pero si el "apollardado" la declara por ejemplo por SII, y el emisor la anula poor SII... la ley de Murphy con muchas transsacciones se cumple y muchas veces.

Coño el de las tostadas terreras... ;-), si la verdad es que se esta complicando la cosa, cosa mala, habra que ver como evoluciona el tema , como comentais vosotros, menos mal que personalmente, no entregare una factura sin revisar hasta el fondo del water...

Sí, aquí se juntan el coño de la Bernarda con el pito del sereno y sale la polla vinagre ( ;P)

Y siguiendo con las "pajas mentales" se me ocurre otro tema. Una empresa que emita por defecto facturas simplificadas al hacer la misma se subirá al servidor. ¿Qué pasa si luego viene el cliente y quiere que se le emita una factura de esa factura simplificada? Porque no creo que se suban las dos :confused:


Saludos

Pero eso si lo contempla la normativa, se hace una sustivutiva "F3" F3 Factura emitida en sustitución de facturas simplificadas facturadas y declaradas
Osea, que si se suben las 2.

Efectivamente, una sustitutiva, se sube también, pero evidentemente fiscalmente no es otra carga. Y va con otra serie diferente con su numeración.
Pero aquí va otro tema que es un error de datos en la sustitutiva, te permite anularla? Supongo que sí, pero se te libera en el servidor la simplif8cada para emitir otra sustitutiva o tendrán líos con eso?

A raiz de esto, las sustitutivas de tipo F3, la simplificada que se convierte en ordinaria, ¿lleva una serie a parte o continuaría con la serie de las facturas ordinarias?

Ejemplo:

Factura simplificada numero 500
Las facturas ordinarias van por el 305
Esta es la decima factura simplificada que pasa a ser ordinaria.

Se convierte la factura simplificada a ordinaria por el tipo F3, entonces ¿la nueva factura sería la 306 de la ordinaria? o llevaría otra numeración distinta de las de tipo F3, en este caso la número 10 del tipo F3.

Esto es lo que no tengo claro.

Debe estar en otra serie, no es ni simplificada ni ordinaria, es una serie especifica para las sustitutivas que también van de solipandi.
Así lo tengo yo:
Serie 1: Simplificada
Serie 2: Ordinarias
Serie 3: Sustitutivas de simplificadas
Serie 4: Rectificativas de Simplificadas(Pueden ser por diferencia o por sustitución-no confundir con sustitutiva-)
Serie 5: Rectificativas de ordinarias (Pueden ser por diferencia o por sustitución-no confundir con sustitutiva-)

A esto añadele la serie por comercio/Centro de Coste/Delegacion y tpv/terminal dentro del mismo cif
Ejemplo
Serie 25.1.1 = Comercio nº25 Tpv1, Simplificada
Serie 25.2.1 = Comercio nº25 Tpv2, Simplificada
Serie 25.2.2 = Comercio nº25 Tpv2, Ordinaria

Hola,

Las facturas sustitutivas de facturas simplificadas (antes llamadas facturas de canje de tickets) son facturas completas normales (no facturas rectificativas).
No he leído, por ningún sitio, que deban ir en una serie diferente del resto de las facturas completas. Y, por tanto, en principio, deberían llevar la numeración de las facturas completas normales.
Aunque puede ser muy útil separarlas en otra serie diferente, al igual que pueden emplearse oras series para separar facturas de distintos terminales, distintas tiendas del mismo negocio o distintos vendedores. Pero eso es voluntario.

Lo que sí es importante es que para temas de contabilidad y fiscalidad no se consideren las facturas simplificadas que hayan sido sustituidas por facturas sustitutivas de facturas simplificadas.

Saludos.

Gracias, me queda mucho más claro.

Gracias, yo casi que prefiero separarlas en una serie distinta.

Ya no existen las facturas de canje ? ahora serán sustitutivas ?

Saludos

Sí. Yo también.

Ahora se llaman facturas sustitutivas de factures simplificadas.
Y son facturas completas (con datos del destinatario) normales. No son facturas rectificativas.

Facturas Simplificadas con datos
 

No debemos olvidar que las facturas simplificadas también pueden llevar datos para poder deducir el iva, art. 7 - 2 del reglamento de facturacion contenido de las facturas simplificadas.

"2. A efectos de lo dispuesto en el artículo 97.Uno de la Ley del Impuesto, cuando el destinatario de la operación sea un empresario o profesional y así lo exija, el expedidor de la factura simplificada deberá hacer constar, además, los siguientes datos:

a) Número de Identificación Fiscal atribuido por la Administración tributaria española o, en su caso, por la de otro Estado miembro de la Unión Europea, así como el domicilio del destinatario de las operaciones.

b) La cuota tributaria que, en su caso, se repercuta, que deberá consignarse por separado.

3. También deberán hacerse constar los datos referidos en el apartado anterior, cuando el destinatario de la operación no sea un empresario o profesional y así lo exija para el ejercicio de cualquier derecho de naturaleza tributaria."

Por lo que se podría hacer una rectificativa de la factura simplificada a realizar el canje y una nueva factura simplificada con datos para enviar al destinatario.

En relación con las series, el reglamento obliga a que en las facturas completas se cree una serie diferente para las facturas rectificativas art 6 - 1 - a) - 2º

"No obstante, será obligatoria, en todo caso, la expedición en series específicas de las facturas siguientes:
1.º Las expedidas por los destinatarios de las operaciones o por terceros a que se refiere el artículo 5, para cada uno de los cuales deberá existir una serie distinta.
2.º Las rectificativas.
3.º Las que se expidan conforme a la disposición adicional quinta del Reglamento del Impuesto sobre el Valor Añadido, aprobado por el artículo 1 del Real Decreto 1624/1992, de 29 de diciembre.
4.º Las que se expidan conforme a lo previsto en el artículo 84, apartado uno, número 2.º, letra g), de la Ley 37/1992, de 28 de diciembre, del Impuesto sobre el Valor Añadido.
5.º Las que se expidan conforme a lo previsto en el artículo 61 quinquies, apartado 2 del Reglamento del Impuesto sobre el Valor Añadido, aprobado por el artículo 1 del Real Decreto 1624/1992, de 29 de diciembre."


Si embargo en las factura simplificadas crear una serie para las facturas rectificativas es opcional art 7 -1 - a)

"Se podrán expedir facturas simplificadas mediante series separadas cuando existan razones que lo justifiquen y, entre otros, en los siguientes casos:
1.º Cuando el obligado a su expedición cuente con varios establecimientos desde los que efectúe sus operaciones.
2.º Cuando el obligado a su expedición realice operaciones de distinta naturaleza.
3.º Las expedidas por los destinatarios de las operaciones o por terceros a que se refiere el artículo 5, para cada uno de los cuales deberá existir una serie distinta.
4.º Las rectificativas."

Y no hay que olvidar que la creación de una serie necesita una justificación razonada.

Una pregunta, mi programa emite 2 series de facturas distintas una de venta y otra de reparaciones, tendria que crear 2 series distintas de rectificativas, o seria posible emitir una misma serie de rectificativas sobre las 2 anteriores?

Hacienda sigue llamandolas sustitutivas o de canje.
Antes incluso podias hace una simplificada nominativa, o sea, pillar la simplificada o tiquet, agregarle los datos del cliente y listo, no habia que emitir una nueva factura.
Todo esto ya hace años que lo han limitado, la de canje es lo mismo que la sustitutiva, pero es muy importante que esté informado de que factura/s simplificada/s proviene, por que una sustitutiva puede venir de 1 o varios tiquets(simplificadas).
A tener en cuenta:
-Te pueden pedir una sustitutiva de simplificadas de hasta de 4 años de antiguedad(máximo).
-En la sustituva hay que informar a que serie y numero de simplificadas pertenece y la fecha de emisión de cada simplificada
-Si haces una sustitutiva de varias simplificadas, esas simplificads deben pertenecer al mismo periodo (mes-año), no se pueden mezclar simplificadas del distintos periodos en una sustitutiva(no confundir con las facturas recapitulativas), esto quiere decir que si un cliente viene con una carpeta de decenas de tiquets, tienes que tener en cuenta (en el software) que no se puedan mezclar meses, recomiendo que lo controleis por soiftware por que el usuario no va a controlarlo.
-El máximo de la suma de simplificadas para una sustitiva no puede ser superior a 3000Euros, hay que controlarlo cuando estes asignando varias simplificadas.
-En cuanto a efectos fiscales, no tiene efectos fiscales para el expedidor (en cuanto a devengo IVA ni IRPF) pero SÍ afecta a los 347 y aquí se complica un poco, por que si te piden una factura sustitutuva de hace 2 años y la suma facturada a ese cliente en el año del servicio consumió mas de 3005,06 Euros (Lo que eran las 500.000ptas antiguamente), hay que hacer una complementaria de los 347, tanto el emisor como el receptor.
-Es un tipo de factura distinta y se informa como F3.
-Para el receptor de la factura, el objetivo principal es la deducción del IVA, que no se pudo deducir con la simplificada.

Saludos

Hola,

Gracias Ermendalenda por aclarar algunos aspectos.
Aunque me parece que hay un error (o no he entendido bien lo que comentas):
Creo que cada factura simplificada no puede superar los 3.000 euros, pero la factura sustitutiva de simplificadas (que es una factura completa) no tiene límite de importe.

Saludos

LLevas razón con la duda, lo paso a la asesoria para ver por que me dieron esa información. De momento me comentan que tenga cuidado con la suma de efectivos por que del mismo dia/cliente no pueden pasar los 1000euros (Una estupidez, por que si no piden la sustitutiva teoricamente no se entera ni el tato)
Me van a mirar lo de los 3000 euros y te contesto, esa miusma duda me chirrió a mi cuando me lo dijeron, me lo van a confirmar,

Aver una cuestion, al hacer la recapitulativa/sustiutiva, si te lo ha pagado con tarjeta, bien pero como sea en efectivo, la liamos con lo de mas de 1000€ en efectivo al pagar una factura, por mucho que aleguemos que heran muchas pequeñas , no?

La norma dice que se deberá crear una serie aparte para las rectificativas, no dice que hay que crear una serie de rectificativas por cada serie de facturas que se tenga, por lo que entiendo que con una serie para todas las rectificativas es suficiente.

Esto no significa que no puedas hacer varias serie de facturas rectificativas de la misma forma que haces varias series para facturas normales.

Exactamente.

Por mucho que pongamos en el software que limite las ventas de efectivo a 1000euros el usuario puede dividir la factura en varias.
Esto es controlable en las facturas nominativas, pero en las simplificadas no,
Entronces, imagina que te venga un cliente que paga una comida de personal de por ejemplo 1200 euros, como el software "no deja", al vendedor se le ocurre hacer 2 tiquets, y ahora llega el cliente y le pide factura, ya la hemos liado.
A nivel informatico se podria controlar pero yo el unico control que meteria es que no pueda hacer documentos de mas de 1000euros en efectivo y que una sustituiva de varios tiquets no lleguen a los 1000euros de efectivo del mismo dia, o , si veis que es mucho lio, un solo tiquet por cada sustitutiva. El resto (para mi) es problema del usuario/empresario. Si no esto se hace interminable.

Si con una serie es suficiente, correcto, es opcional.
A nivel sustiututiva y ordinaria no sé si puede ser la misma serie.
En ambos casos yo prefiero tenerlas divididas por más claridad, ya que no tengo un camPo para tipo de factura y otro con la serie y así elimino 1 campo.

^\||/Creo que es la opción más viable

Hola, personalmente acabo de hablar con una compañera de una tienda de motos, que me indicaba que no pasa nada, con agrupar los tiquets pagados en mano en una unica factura, puesto que los tiquets, se pagaron por separado, y se declararon por parte del comercio, en las fechas separadas, que ella lo esta haciendo desde hace varios años y en su dia lo consulto, y sin problema hasta ahora.
Halguien que entienda mas del tema nos lo puede aclara mejor?
Me refiero al tema de que suba mas de los 1000€, perdon por no especificar.

En fechas separadas no hay problema
Incluso si haces la sustitutiva de las 2 juntas.
No había aclarado bien

Verifactu en comercio como Hosteleria
 

Muy buenas a tod@s,

Antes de nada felicitaros por la labor tan brutal que estáis haciendo entre todos, y aquí que me sumo con dudas y aportando lo que pueda y más.

Comentaros por si es de interes, entiendo que ya es conocido, que ayer hicimos la consulta a la administración y aunque la ley entra en vigor el día 5 de diciembre no es de cumplimiento obligatorio 'hasta' el 1 de julio del 2025.
Por lo que hace referencia a la plataforma de pruebas, como sabéis, aún no está disponible, nos han dicho que este mes estaría pero llevan dando largas mucho tiempo.

Una de las miles de dudas que tenemos es en comercios como hostelería donde se generan muchos y muchos tiquets, facturas simplificadas, como estas se deben reportar a Verifactu.
En nuestro soft al final del día, o bien a petición del usuario, se hace un fin de día donde a parte de otros procesos se genera una factura de resumen donde se incluyen todas las ventas 'anónimas' que es la factura que actualmente se está reportando al gestor para temas de declaraciones de IVA.
La duda es que como hay la obligación de imprimir el código QR para la trazabilidad Verifactu deducimos que cada tíquet, factura simplificada, debe llevar su QR por lo que se deben reportar a Verifactu todas los tiquets, facturas simplificadas, aunque sabemos que no hace falta reportar una a una sino que se pueden reportar en bloque.

Gracias por adelantado y aportaremos todo aquello que podamos a la comunidad.
Saludos,

Hola,

Sí. El proceso en TPVs de comercios y hostelería que generan muchos tickets de venta es problemático.
Nosotros estamos dando servicio a cerca de 300 TPVs (principalmente de bazares, bares, cafeterías y restaurantes) en el País Vasco que, como sabrás, utiliza, desde hace tiempo, TicketBAI, que es muy similar a lo que se va a implantar, proximamente, para toda España, con Verifactu.
(Por supuesto, va a existir la modalidad No-Verifactu, pero dada su complejidad y los peligros que entraña, mi consejo es olvidarse de esa modalidad, en el caso de TPVs de pequeño comercio y hostelería, y centrarse en la modalidad Verifactu)

Lo primero que debes tener en cuenta es que cada ticket generado (actualmente los "tickets" se llaman facturas simplificadas) debe ser tratado de forma individual.
Debe incluir su código QR y debe ser enviada su información, de forma inmediata (nada más generarse) al sistema Verifactu de la Agencia Tributaria.

Ya sé que esto romperá tus esquemas pensados para agrupar los tickets de cada día y procesarlos después. Pero es lo que hay.
Cada "ticket" es una factura simplificada individual. Y debe ser tratada de forma inmediata.

Para lo que podamos ayudarte, por aquí tienes, en este foro, a un buen grupo de colegas dispuestos a ayudarte con tus dudas.

Saludos y Bienvenido.

Mil gracias por tu, vuestro, ofrecimiento.

Sustitutivas
 

Buenas
Me contestan de la asesoría lo que pensáis.
Una factura sustitutiva no tiene limite de importe, pero ojo, la sustitutiva de varios tiquets que sumen en el mismo día más de 1000euros en efectivo, sí que puede ser un problema, ya que están en el mismo cliente, y aunque la normativa no está muy clara al respecto, o sea, estoy haciendo varios tiquets de menos de mil euros, puede ser objeto de un requerimiento, pero para ello también tiene que cruzar la forma de pago, que no la mandamos a verifactu, pero ante un requerimiento antes de que salga verifactu piden los tiquets, y ahí si puede salir el problema.

Una cosa a colacion, yo personalmente , en prevision a la "Obligatoriedad" futura de implementar las facturas electronicas entre Empresas/Autonomos y seguramente en un futuro todas, aprobechando que estoy remodelando mi programa de facturacion, he añadido la forma de pago, obligaroria, asi lo tengo ya añadido por lo que haga falta, asi como siempre incluyo una casilla en la que indico si la factura es de "Venta, Reparacion,Abono, etc, por si acaso, nunca se guardan bastantes registros...


Otra cosa, hasta ahora las cuotas de itv, las incluia a final de factura , sin añadirle iva ni nada, como "Cobrada a nombre de cliente", por no desglosar porque a la cuaota de trafico no se le deve añadir IVA.
Sabeis como lo tendria que incluir ahora en verifactu y en las futuras facturas electronicas?, Gracias como siempre por vuestras respuestas.

Buenas, ha salido la Oden Ministrerial??

Si no estoy equivocada (no conozco nada a las ITVs), estos "cobrado a nombre del cliente" son suplidos. Si es así, no entran en la base imponible de la factura (art. 78. Tres. 3º Ley 37/1992, y de aquí no soportan IVA), y no hay que reportarlos a Hacienda. Pero se supone que se debe entregar al cliente, junto con tu factura, el justificante del pago que has realizado en nombre de tu cliente.

Respecto de las facturas electrónicas, es una muy buena pregunta. Aprovecho que no es el foro adecuado para no contestar :p

Si, la copia que te da la itv del pago, va a nombre del cliente siempre, yo no lo incluiria en la factura, pero luego el pago si lo hacen con tarjeta o transferencia no cuadra, por eso lo apunto en la factura, de ahi preguntar como , puesto que como exento de IVA, no creo, o no se que clase de exencion apñlicar.

Una puntualización a lo que dice [sistel] y podemos comentarlo si estoy equivocado.
Como bien dice, los tickets se tratan a nivel Individual, cada uno con su QR y su registro de facturación, pero el envío puede ser agrupado (o eso creo yo). Es decir, puedes hacer un envío de n Registros de facturación juntos.

Es más, hay que tener el sistema previsto para hacerlo así, porque la AEAT tiene previsto que en momentos de saturación, te puedan obligar a esperar "t" segundos o que el envio tenga como mínimo "n" registros.

Concretamente el esquema de funcionamiento segun la documentación es este:

2. Los sistemas informáticos «VERI*FACTU» deberán implementar un mecanismo de control de flujo basado en el tiempo de espera entre envíos, el cual tomará inicialmente el valor de 60 segundos, y en el número máximo de registros admitidos en cada envío.
Los mensajes de respuesta de la Agencia Estatal de Administración Tributaria informarán sobre el valor de este parámetro, el cual deberá ser tenido en cuenta para el siguiente envío.

El número máximo de registros a remitir en cada envío queda determinado por el diseño de registro incluido en el apartado 2.2 del anexo.

El funcionamiento será el siguiente:
a) El sistema informático realiza el envío del primer conjunto de registros de facturación a la Agencia Estatal de Administración Tributaria.
b) La Agencia Estatal de Administración Tributaria devuelve, entre otros datos, un valor actualizado del parámetro de tiempo de espera «t» entre envíos.
c) Para poder realizar el siguiente envío, el sistema informático deberá esperar a que transcurran «t» segundos desde el anterior envío o deberá esperar a tener acumulados un número de registros de facturación igual al límite establecido en el diseño de registro para cada envío, la circunstancia que ocurra primero.
d) El sistema informático realiza un nuevo envío cumpliendo con lo establecido en la letra c). En la respuesta puede recibir una nueva actualización del valor del parámetro «t»


Es decir, puede decidir enviar registros de forma individual (nosotros lo hacemos así porque nuestras empresas no generan tickets y el volumen ens más pequeño), pero también puedes hacer envíos agrupados de hasta 1000 registros. Y aunque nosotros no lo hagamos, nuestro sistema debe estar preparado par ello.


En este documento lo tienes todo explicado:
https://terawiki.clubdelphi.com/Otro...Web_v0.3.0.pdf

6.3.1.1.Mecanismo de control de flujo.

6.4.2. Respuesta de alta y anulación de registros de facturación.
Todos los registros de facturación de la remisión tienen estado “Correcto”.
Ya asume que puedes enviar N registros en un envío de Alta o Anulación

3.Esquema general de funcionamiento.
...
El número máximo de registros por envío es de 1.000.
La unidad de información, representada por un registro de facturación, podrá ser
aceptada, rechazada o aceptada con errores, consecuencia de las validaciones que se
realizan en el momento de la remisión.

Efectivamente. Según se entiende los tickets hay que enviarlos de forma unitaria independientemente que al enviar se envíen por paquetes de n tickets/facturas. Hay que tener cuidado con esto porque en el SII si que hay una manera de enviar en un solo registro un grupo de tickets indicando desde-hasta y los totales pero esto parece que no se aplica en VeriFactu.


Saludos.

Hola,

Efectivamente los envíos deben hacerse respetando el control de flujo que marque Verifactu.
Creo que dicho control de flujo ya no tendrá en cuenta el envío de un número mínimo de facturas en bloque, sino sólo el tiempo.
En caso contrario, se podría dar el caso de que se quedase esperando un número mínimo de facturas que puede ser que no se alcance en muchos días (o meses)

Si al final es así, sólo control de tiempo, aunque se permita el envío por bloque de facturas, mi opinión es que, si no es obligatoria dicha agrupación en bloque para su envío, es preferible enviar una a una para tener mejor control por nuestra parte.

En TicketBAI-BATUZ también se permite la agrupación de facturas en un envío.
Pero nosotros los enviamos individualmente, lo que nos permite un mejor control.

Saludos

Por lo que yo entiendo el control del número de facturas a enviar creo que será un número máximo, no mínimo. Es decir, que si te devuelve un valor 10 en el número de facturas y tienes solo 3 para enviar podrías enviar esas 3, lo que no deberías de enviar serían 13. En el caso de tener 13 para enviar se deberían de enviar esas 10 máximas y en la respuesta te dirá cómo puede enviar las posibles restantes que pudieras tener pendientes.


Saludos.

El control de flujo se hará sólo con un parámetro "t" en segundos. El número de ítems a enviar ya está limitado por diseño (1000 registros). Esto lo aclararon en la presentación de principio de año.

Artículo 16. Especificaciones técnicas de la remisión voluntaria

Control de flujo de remisión de registros para los sistemas Veri*factu.

• Muy probablemente simplificará para contemplar solo un factor de tiempo. El máximo de registros a remitir por envío ya está limitado a 1.000 registros (limitado por Diseño de Registro).
• El parámetro no variaría con frecuencia. Una vez definido será estable. No se pretende complicar la implementación de los SIF.
• El tiempo máximo entre envíos se fijará tomando como unidad “segundos”. El valor del parámetro no está pensado para contemplar horas ni días.
• Ejemplo: Valor t=60. El SIF deberá remitir todos los registros de facturación generados en el último minuto.
• El control de flujo no tendrá aplicación “práctica” para empresas con escasos volúmenes de facturación, ya que no superarán el umbral definido.

^\||/ Gracias por la aclaración.