Tengo un problema que me ha surgido hoy con un cliente, y no sé qué decirle para arreglar el lío que ha provocado...

Resulta que, por despiste, entró en el año/ejercicio 2023 en vez de en el 2024 (nuestro software separa los ejercicios en bases de datos diferentes), y se puso a hacer ventas.
Es decir, hizo facturas en la empresa de 2023 con fecha de 2024 y las envió a TicketBAI.

Lo peor de todo es que TicketBAI se las tragó sin rechistar. No le importó el encadenamiento, ni la fecha del ejercicio, ni el número de factura no correlativo... Nada. Enviadas y aceptadas.

Claro, al darse cuenta, ha ido a la empresa de 2024, y al hacer una venta, casualmente el número de factura ya se había enviado, y ahora TicketBAI responde con "factura duplicada".

En fin, un disparate que no sé muy bien cómo arreglar...

¿Puedo hacer en 2024 una rectificativa de una factura de 2023? ¿Debe el cliente anular las facturas que envió y volver a hacerlas bien? ¿Al anular una factura, eso me permite volver a enviar una nueva factura con el mismo número?

Y la más importante...

¿No debería TicketBAI evitar que ocurra esto, o cosas similares? Yo creo que dejar toda la responsabilidad a los desarrolladores no es buena idea. Nosotros no podemos contemplar, ni siquiera imaginar, todos los disparates que puede cometer un cliente. Si el requisito, exigencia, prohibición, etc. lo pone TicketBAI, que sean ellos quienes devuelvan un error, y no nosotros tener que prever todo lo que pueda pasar y evitar el envío.

Vamos, digo yo.

Araba por ejemplo desde hace poco empezó a dar los errores con las fechas de expedición, fecha de operación y fecha actual precisamente para evitar estos problemas.

En mi opinión debería de anular todas las facturas enviadas erróneamente. Eso si, misma combinación de serie y número no te la van a aceptar, pues la factura va a seguir constando en Hacienda, como anuladas, pero con el número original, se puede comprobar en la web. Así que tendrá que utilizar una nueva numeración para ellas. A principios de año anulamos unas 300 facturas por el tema de la fecha de expedición, y esos números han quedado ahí. Y si, se pueden hacer rectificativas en 2024 de facturas de 2023, sin problema, identificándolas correctamente en numeración y fecha de expedición, que es lo que comprueban para localizar la factura rectificada.

Si optas por la opción de anular (que no se si es la correcta) siempre puedes volver a generarlas con una SERIE diferente.
Si haces rectificativas creo que no hay problema porque sea de otro ejercicio; Si haces una el 31 de Diciembre, deberías poder rectificarla una semana después (que ya es el año siguiente).

Por lo pronto la clienta va a contactar con su delegación a ver qué le dicen.

Opciones siempre hay, pero en estos casos sería mucho más fácil que la propia delegación respondiera al envío con un "ojo, que hemos detectado algo que no cuadra" en vez de dejar que seamos nosotros quienes prevean cualquier circunstancia que pueda darse.
Ahora habrá que estar haciendo anulaciones, o rectificativas, rehaciendo las facturas, envíos... Y encima el cliente ya habrá hecho y enviado facturas nuevas después del desastre, así que más se complica.

Hola,

Mi consejo es ponerse en contacto con la Hacienda Foral correspondiente, explicarles el problema y pedirles cual es la solución más conveniente.
En general, siempre que me he puesto en contacto con la sección de TicketBAI de alguna de las Haciendas Forales me han dado soluciones efectivas (y sobre todo dentro de normativa)

Saludos

Buenas,


Tengo una duda con el tema de la fecha operación.


Si una factura tiene la fecha de emisión/factura diferente a la de operación en el QR cuál de las dos fecha iría?


Gracias

Para TicketBai es la ficha de expedición. Para Verifactu habrá que esperar a la normativa.

Gracias keys

Cambios/Devoluciones en ventas de mostrador (TPV)
 

¿Cómo hacéis vosotros los cambios y/o devoluciones en un software de punto de venta, por ejemplo, para una tienda de ropa, que solo emite tíckets a público en general?

¿Hacéis rectificativas o solo un nuevo tícket en negativo? ¿Si hacéis rectificativas, el usuario debe indicar el tipo de rectificativa, motivo, etc. y el nº de tícket original al que rectifica?

Nuestro software simplemente emite la factura simplificada en negativo (si es una devolución), como una factura más: correlativa, misma serie, etc. Al ser ventas a público en general (sin indicar datos del cliente), no ha habido problema nunca.
Y de hecho TicketBAI las acepta sin ningún aviso, y hasta que yo sé, nunca se han quejado.

Pero un cliente ahora dice que no debería ser así y se nos ha planteado la duda. ¿Realmente debemos crear todo el proceso de rectificativas, en un software de punto de venta que se supone que debe ser lo más "básico" y rápido posible, exigiendo indicar a qué factura rectifica, guardando en otra serie, etc.?

¿Cómo lo hacéis vosotros?

Para facturas normales obviamente sí hacemos todo el proceso correcto, creando rectificativas, dando opción a indicar el motivo, tipo de rectificativa, etc. Pero en venta al público no veo un poco engorroso e innecesario para el usuario.

No creo que tenga que ver con TBAI necesariamente, creo que es más tema facturación, pero buscando un poco por Internet encuentras cosas como estas:

¿Qué son las facturas rectificativas?

Las facturas rectificativas son un documento que sirve para corregir una factura original, añadir algún dato incompleto o indicar devoluciones de mercancías. Ya que por ley no podemos alterar una factura que ya ha sido emitida, debemos crear esta factura rectificativa para realizar cualquier cambio o añadir más datos.

O esta:


Tipos de facturas rectificativas

Existen diferentes tipos de facturas rectificativas que se utilizan en la contabilidad y facturación de una empresa. A continuación, describimos los principales:

1. Factura rectificativa por error en el importe: se emite cuando se ha cometido un error en el importe facturado, ya sea porque se ha cobrado de más o de menos.
2. Factura rectificativa por error en los datos del cliente: se emite cuando se ha facturado a un cliente equivocado o se han incluido datos incorrectos en la factura original.
3. Factura rectificativa por devolución de mercancía: se emite cuando se devuelve un producto o mercancía que ya ha sido facturado y se necesita corregir la factura original.
4. Factura rectificativa por descuento posterior: se emite cuando se aplica un descuento después de haber emitido la factura original.
5. Factura rectificativa por anulación de factura original: se emite cuando se anula la factura original por algún motivo, como por ejemplo la devolución de la mercancía o el servicio.

link:https://www.holded.com/es/blog/factu...tos-utilidades

De todas, formas si hay alguien experto en facturación que diga, porque yo no lo soy...

Lo digo porque, en ningún comercio en el que yo haya hecho un cambio o una devolución, me han dado un tícket que diga "factura rectificativa". De hecho solo veo "factura simplificada" y los artículos en negativo cambiados y los nuevos en positivo.

Tengo ahora mismo delante un tícket de Leroy Merlín y otro de Zara Home, por poner un ejemplo.

Por eso hacía hincapié en lo de "punto de venta" de venta al público en general.

Y en cualquier caso, si no están permitidas las ventas en negativo... ¿por qué las admite TicketBAI? Tantos avisos y errores con tonterías como que falta el código postal, y esto que es más "serio" se las traga sin problema?

Revisa este link (que además es de la AEAT).


Facturas de rectificación
1. Supuestos de rectificación
Se deberá expedir una factura rectificativa ....
....

No obstante, hay dos excepciones a estos requisitos:

Cuando la modificación de la base imponible sea consecuencia de la devolución de mercancías o de envases y embalajes y por la operación en la que se entregaron se hubiese expedido factura o factura simplificada, no será necesaria la expedición de una factura o factura simplificada rectificativa, sino que se podrá practicar la rectificación en la factura que se expida por una operación posterior que tenga el mismo destinatario siempre que el tipo impositivo aplicable a todas las operaciones sea el mismo, con independencia de que el resultado sea positivo o negativo.


Esto me hace dudar, parece que diga que puedes modificar la original, pero el problema es que no podemos enviar modificaciones a TBAI (como se hace al SII).
No se...

Lo correcto sería hacer una factura rectificativa. Pero en la practica casi nadie las hace o las hacía. Lo que hacen muchos es generar una factura nueva con los importes en negativo.

El sistema se las traga por que nadie dice que esten mal.

Casualmente acababa de encontrar esa misma información en la web de AEAT, que dice lo siguiente:

Creo recordar que de esto ya se habló hace (mucho) tiempo en el foro, y recuerdo que alguien dijo que "Por ahora me están aceptando las facturas en negativo sin problema".

Es que si hay que decirle a los usuarios, que cuando hagan un cambio o una devolución, tienen que indicar tipo, motivo, etc. no sé, no lo veo claro, la verdad.
Pero vamos, si hay que hacerlo, pues a apechugar...

No dice que tengas que enviar la misma factura modificada. Sino que tienes que enviar una nueva con los importes en negativo o en positivo. Que es lo que hace zara como dice el compañero. Pero sólo en esos casos, sino tienes que hacer una rectificativa.

El problema es que tengo un cliente un poco... enterao... que dice que eso no puede ser así, que está mal. Y no, mal, lo que se dice MAL, no está.

Y lo peor... estoy seguro de que si hablo con las diputaciones, una me va a decir que está bien y otra que está mal :rolleyes:

Exacto. No se trata de una modificación de la original. De hecho, ni siquiera es un error en los datos.

Por no hablar de que lo más fácil, rápido e intuitivo es que, en el mismo tícket que se le da al cliente, aparezca todo: los artículos devueltos/cambiados en negativo, y los nuevos (si los hay) en positivo.

Pero vamos, si no se han puesto de acuerdo las diputaciones en dos años, es normal que nosotros tengamos todavía dudas al respecto.

Pues entonces tu cliente tendrá que hacer una rectificativa si es lo que quiere. Nosotros en nuestro caso es el cliente el que decide hacer una rectificativa o hacer una factura con importes negativos.

En teoría toda factura rectificativa en negativo (es decir abonos) tiene que ir a una serie y con una numeración aparte de las ordinarias. Otra cosa es que la gente lo cumpla o no, pero nosotros siempre se lo decimos a nuestros clientes, cualquier factura en negativo es un abono, va a la serie de rectificativas, indicas a quien rectificas y genera una numeración distinta.
Respecto al TPV, a la hora de genera tickets, si hay que hacer devolución o abono, nosotros tenemos un botón que le das y te pregunta a que ticket estas rectificando, lo eliges y te hace una copia del ticket original pero con todo en negativo. De ahí ya quitas cosas si no va a devolver todo, o la dejas tal cual si es un abono entero, cierras ticket y arreando. Fácil, rápido, y cumple con ticketbai.
Si el cliente quiere devolver cosas y llevarse otras nuevas, PRIMERO se hace la devolución (esto genera la rectificativa etc), y luego se hace el ticket con lo que se va a llevar nuevo. Te evitas líos e historias.

La normativa de facturación lo regula según el caso.
No hay diferencia para los casos de simplificadas y ordinarias, pero si tienen que ser diferentes las series de lss rectificativas.
Te pongo algún ejemplo,
1.Cambio de mercancia:
* Puedes hacer dentro del mismo tiquet(normal) el negativo y el positivo, para según el caso, si no hay mezclas de tipos de iva, o si el total de los ivas son positivos. Si todos los items son del mismo tipo de iva incluso te puede dar negativo si al menos hay un ítem positivo, del mismo iva.
*puedes hacer la rectificativa por un lado y el positivo por otro.

2.devolución sin cambio
*solo es posible la rectificativa.

Nota:
Las rectificativas llevan otra serie tanto para ordinarias como para simplificadas y diferentes entre ellas, o sea, no se pueden mezclar las series rectificativas de las simplificadas con las rectificativas de las ordinarias.

Yo es que sigo sin ver que un cambio o devolución, en un comercio, requiera hacer una rectificativa. Según la normativa de facturación (el link está más arriba) dice que no es necesario. O al menos eso es lo que yo entiendo.

Si hay que hacerlo para estar más tranquilo, pues vale, pero yo lo veo innecesario. Un cambio o devolución no es un error, o un dato incorrecto, etc. Meter los cambios/devoluciones en el mismo paquete que la corrección de errores o datos fiscales incorrectos, presta a confusión.

Por lo pronto haremos una opción configurable y que sea el cliente quien elija. La responsabilidad no puede ser solo nuestra.

A ese link me remito cuando me he intentado explicar. Yo entiendo en el final del párrafo , que según el caso podrás integrarlo en una factura con productos en positivo y no siempre. Depende de ese tipo de iva de los productos positivos/negativos
El alma de este, párrafo, que por cierto lo han explicado fatal, es que "la rectificación" un positivo con un negativo dentro de la misma factura, aunque el resultado sea negativa tengan el mismo tipo de iva
Es más que no haya líneas con otro tipo de iva, si no tampoco podrías hacerla.bsi lo controlas con algoritmos no hace falta que el operador elija. Por que seguro lo hace mal. Y siemp4e igual.
De todas formas el 90% de los programas lo hace bajo tu interpretación, así que de momento no creo que se metan demasiado. El el SII por ejemplo tuvieron que eliminar la obligación de poner a que factura rectificaba por el lio que tuvieron.
Eso sí, desde que leí la norma lo apliqué y viene de pm ese control para que tengan que seleccionar factura y ítem que rectifican, con lo cual me olvido de errores por cambio de precio o marcar otro producto en megativo

Hola,

Coincido con los colegas que te han contestado antes.

No siempre es posible hacer una factura rectificativa, en un TPV, por una devolución.
Hay casos de comercios que tienen varios TPVs y no están interconectados (incluso están en distinto local), por lo que es difícil encontrar los datos de la factura simplificada (ticket) original de la venta.

Y siempre hay casos de un cliente habitual que te viene a devolver algo sin ticket.
Y, lógicamente, no vas a perder un buen cliente porque no traiga el ticket.
Así que lo más habitual, en estos casos, es factura simplificada (ticket) de importe negativo y punto pelota.

Las Haciendas conocen, de sobra, esta problemática y no se meten en exigir que se haga siempre factura rectificativa y aceptan una factura de importe negativo en estos casos.

Si tienes un cliente "pijo" que te exige que tu software de TPV emita siempre, en esos casos, factura rectificativa, tienes 2 opciones:
1- Incluir esa opción en el software de TPV.
2- Decirle que si no le gusta cómo funciona tu software de TPV que se busque otro.

Saludos

Ya cada uno que valore como quiere dormir de tranquilo, está claro que no te vana a empapelar por eso, pero si a un cliente tuyo le pillan otra cosa le van a revisar de p a pa y si el software no cumple alguna normativa, lo que le sanciones al cliente, por cada factura o tiquet mal emitido, el cliente te lo va a reclamar a ti. Y ahí no le vas a poner decir búscate otro software.
Una inspección puede ser muy jodida.
Por otro lado, para las simplificadas, el cierto lo que decís que puede ser complicado por lo de distintos tpvs, para eso, según el tipo de negocio, se suelen repetir lss referencias vendidas, por lo rato puedes poner un buscador de esa referencia en los tiquets de ese tpv ala, rectificativa por diferencias, en ese caso es indiscutible que cumplas la normativa.

No había caído en la problemática de los tíckets emitidos en otra tienda, y tienes razón.

Y otras circunstancias que me han venido a la cabeza durante el fin de semana y que parece ser que TicketBAI no ha tenido en cuenta.

Yo entiendo que sería ideal hacerlo así, con una rectificativa, pero en el día a día es muy complicado llevarlo a cabo. Y por eso entiendo que por ahora están dejando enviar facturas en negativo.
Además, si contablemente el resultado final es exactamente el mismo, y es mucho más intuitivo tanto para el usuario como para el cliente, etc. ¿dónde está el problema?

Al final haremos una opción para que sea el usuario quien elija. Luego se quejarán de que ahora hay que hacer más pasos que antes. Les diré que vayan a llorar a la playa...

Tengo una pequeña duda sobre los plazos y la obligatoriedad de Batuz. En mi caso hablo de Bizkaia para el modelo 240.

¿Las fechas de obligatoriedad afectan sólo al capitulo de facturas emitidas o también a la parte de compras, gastos, etc.?

Los plazos son para todo. Si entras en Batuz entras en todo no solo en TicketBAI.

Buenas , en Guipúzcoa tenemos el siguiente problema con la codificacióndesde el principio , nos estamos volviendo locos y no encontramos la solución. A ver si alguien puede arrojarme luz
Nuestro programa está hecho en visual basic y utilizamos las librerías chilkat para transmitir, así como un certificado de la FNMT de representación de mi cliente

El código con el que enviamos cada ticket o factura es el siguiente. Como se ve, estamos transmitiendo con codificación utf-8.

Dim Resp As ChilkatHttpResponse
Call http.setRequestHeader("Content-Type", "application/xml")
Set Resp = http.PostXml(Url, sbXml.GetAsString, "utf-8")

El texto del archivo una vez firmado con el certificado de Representación incluye la siguiente línea ( el acento de la o no lo ponemos nosotros, si no la librería en el momento de firmar):
<ds:X509IssuerName>CN=AC Representación, OU=CERES, O=FNMT-RCM, C=ES</ds:X509IssuerName>

Pero a la Hacienda Foral de Guipúzcoa le llega lo siguiente :
<ds:X509IssuerName>CN=AC Representación, OU=CERES, O=FNMT-RCM, C=ES</ds:X509IssuerName>

El ticket se genera correctamente con el QR y se puede consultar sin problemas, pero todos los lunes recibimos una notificación de Ticket Bai diciendo que 19 tickets (cada semana) son incorrectos por error en la verificación de firma. obviamente se transmiten todos por igual pero esos 19 son los que comprueban de manera aleatoria

Nos ha surgido otro problema con respecto a las rectificativas de facturas simplificadas, debido a una característica opcional de nuestro software (que utiliza la mayoría de clientes, de hecho).

Nuestro software permite realizar facturas ordinarias y tíckets (TPV), y el usuario elige si quiere enumeración independiente para cada cosa.
Es decir, las facturas ordinarias se guardan en un historial, con su enumeración correlativa, y los tíckets en otro historial, con otra enumeración correlativa.

El problema surge con las facturas rectificativas:

- Si hago una rectificativa de una factura ordinaria #25, ésta se guardará con el número 1 en la serie "R", rectificando la factura 25.
- Si casualmente luego hago una rectificativa de la factura simplificada #25, ésta se guardará con el número 2 en la serie "R", rectificando a la factura simplificada 25

El problema es que TicketBAI Gipuzkoa me dice que no puede haber dos rectificativas que rectifican a la "misma" factura, aunque en realidad no es la misma: una es ordinaria y otra es simplificada.
Y además, añaden que no puedo guardar las rectificadas de simplificadas en otra serie. Es decir, dicen que todas tienen que ir en la serie "R".

¿En serio te obligan a usar solo una serie?

Lo ideal sería que tanto facturas ordinarias como simplificadas se guardaran en el mismo historial, con numeración correlativa, sin importar si son facturas o tíckets. Pero esto es opcional en nuestro software, y el 99% de los clientes lo tienen separado.
Decirles ahora que lo guarden todo junto va a ser una locura.

Todo esto surge a raíz de la "obligación" se hacer rectificativas para los tíckets en vez de una simple venta en negativo. La verdad es que el tema ya me está cansando un poco.

Hola, No puedes tener dos facturas con el #25, aunque una sea simplificada y otra normal. Fíjate que la segunda que presentes te estará devolviendo una aviso y la primera que presentas ya no vale. Lo que te dice ahora es que la #25 no se puede rectificar dos veces (lógicamente).

El problema parte de que Gipuzkoa si le envías la misma factura #25 dos veces (con fechas distintas) no genera un error, sino un aviso. Y se quedan con la última que envías.

Hola espinete, donde dice que 'no puedo guardar las rectificadas de simplificadas en otra serie. Es decir, dicen que todas tienen que ir en la serie "R"'??

Porque si esto es así, nosotros tendremos el mismo problema.
Ahora mismo las series de nuestro programa siempre son distintas tanto entre facturas simplificadas y otras facturas como entre rectificativas de simplificadas y rectificativas de otras facturas.
Pero claro no tenemos dos facturas 25 sin serie, tenemos una 25 con la serie vacía (facturas ordinaria) y una 25 con la serie FS (factura simplificada).

De momento no tenemos constancia de ninguna queja ni de ningún error al enviar a TicketBAI

Gracias

Hola, rci.

Nuestro cliente ha hablado con Gipuzkoa y es lo que le han dicho, pero de ahí a que sea cierto, hay una gran diferencia.
Yo no veo ningún problema en usar una serie "R" para las rectificativas de ordinarias y una serie "V" o lo que sea para las rectificativas de simplificadas.
Vamos, como si uso 20 series para lo que me de la gana, eso a ellos no debería importarles nada.

Pues entonces tenemos un problema gordo. La mayoría de clientes lo han preferido hacer así: separar los historiales/numeración, para tener las facturas por un lado y los tíckets por otro.
El software permite hacer eso desde el año 2000, y nunca ha habido problema. Que ahora no se pueda hacer eso por culpa de TicketBAI, supondrá un problema serio para los clientes que envíen a TicketBAI.

La solución sería decirles que a partir de ahora todo se guarde en el mismo historial/numeración, y punto, pero a saber con qué nuevos problemas nos encontraremos después :rolleyes:

Vamos a tener que darle muchas vueltas a este tema antes de tomar una decisión.

También puedes hacer una serie distinta para los tickets y otra para las normales.

Gracias espinete, espero que solo sea algo que ha entendido mal el cliente.


Exacto, estoy con keys.
Si como dices 'las facturas ordinarias se guardan en un historial, con su enumeración correlativa, y los tíckets en otro historial, con otra enumeración correlativa.', porque no ponerles una serie distinta para enviar a TicketBAI?

Saludos

Nosotros desde el principio hemos tenido que hacer algo diferente para Guipuzkoa.
Pasamos a codificación ANSI antes de enviar, porque si o hacemos según la documentación nos daban los avisos.

No pasa nada si el TicketBAI no lleva caracteres extraños, pero si los lleva nos daba problemas.

Buenas, hace un par de días, me han reportado que los técnicos de la hacienda foral (Guipuzkoa), están diciendo que no se pueden hacer abonos, que se tiene que hacer facturas rectificativas.

No sé si el cliente y/o nuestro asistente no han entendido el mensaje o realmente están diciendo eso. ¿Alguien ha oído algo de eso? ¿alguien conoce alguna normativa sobre el tema?

gracias.

Hola,

Por supuesto que puedes tener todas las series diferentes de facturas que quieras para organizar mejor tu negocio.
En nuestra aplicación, por defecto usamos, al menos, 5 series diferentes:
- C para facturas completas
- S para facturas simplificadas (tickets)
- CR para facturas rectificativas de facturas completas
- SR para facturas rectificativas de facturas simplificadas
- X para facturas completas de sustitución de simplificadas (antes llamadas facturas de canje)

Saludos

Hola,

Por supuesto que lo más correcto es hacer (siempre que se pueda) facturas rectificativas.
Pero, como ya habíamos comentado en este hilo, en algunos casos es imposible por no poder acceder a los datos de la factura original.
Y, en estos casos, no queda otra opción que hacer una factura negativa.

Y, hasta ahora (que yo sepa), Hacienda no ha puesto ninguna objeción a hacer facturas negativas.

Saludos

Hola, no sé si tendrá que ver con tu pregunta, pero yo tenía problemas al enviar y chilkat utilizando caracteres especiales como la ñ o acentos y tuve que utilizar el método PBinary del objeto CkHttp, con eso corregí el problema.
Espero que te pueda servir. Un saludo. Roberto Blasco.