TICKET BAI (TicketBAI); Nuevo sistema de la Agencia Tributaria del Pais Vasco

[iMia]

Empezado por Sistel

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

Muchas gracias,

Sí, si sabemos sobre "lo mejor" y "lo posible" ...

Pero hasta para los clientes, ven que al equivocarse, lo anulan y lo vuelven a hacer y ya está. Si les metemos que los albaranes han sido rectificados, que generan movimientos de estoc que rectifican, documentos rectificados, que tienen dos estados (física cuántica) el original y el rectificado, Factura rectificativa, con una seria a parte, o como lo tengas que hacer en el sistema de gestión, etc etc se vuelven más locos aún o les da un ictus..., si ya les cuesta seguir albarán->factura->Firma->QR-> envío a TBAI ... ni te digo el flujo de las rectificativas y eso que sólo les he implementado las rectificativas por sustitución.

Es que sin legislación de por medio, no entendía cómo les dicen que no pueden hacer abonos...

Seguro que les han dicho "que es mejor", "más conveniente" o "adecuado" o algo así... y ya se lo han tomado de la tremenda...

gracias...

[pablog2k]

Empezado por iMia

Muchas gracias,

Sí, si sabemos sobre "lo mejor" y "lo posible" ...

Pero hasta para los clientes, ven que al equivocarse, lo anulan y lo vuelven a hacer y ya está. Si les metemos que los albaranes han sido rectificados, que generan movimientos de estoc que rectifican, documentos rectificados, que tienen dos estados (física cuántica) el original y el rectificado, Factura rectificativa, con una seria a parte, o como lo tengas que hacer en el sistema de gestión, etc etc se vuelven más locos aún o les da un ictus..., si ya les cuesta seguir albarán->factura->Firma->QR-> envío a TBAI ... ni te digo el flujo de las rectificativas y eso que sólo les he implementado las rectificativas por sustitución.

Es que sin legislación de por medio, no entendía cómo les dicen que no pueden hacer abonos...

Seguro que les han dicho "que es mejor", "más conveniente" o "adecuado" o algo así... y ya se lo han tomado de la tremenda...

gracias...

A lo que se refieren los técnicos que te dijeron eso (y lo que te dicen también los técnicos de hacienda, que estamos hartos de discutir con ellos), es que tú no puedes hacer un abono (vamos a llamar abono a una factura en negativo), que no sea una rectificativa. Toda factura en negativo (abono) , debe de ser una rectificativa, en su serie correspondiente (nada de en la misma serie que las facturas normales), y debes indicar a quien rectificas.
Otra cosa es que hagas facturas en negativo en tu serie normal y las subas al ticketbai, SII, o donde sea, y trague, pero en teoría, está mal

[iMia]

Empezado por pablog2k

A lo que se refieren los técnicos que te dijeron eso (y lo que te dicen también los técnicos de hacienda, que estamos hartos de discutir con ellos), es que tú no puedes hacer un abono (vamos a llamar abono a una factura en negativo), que no sea una rectificativa. Toda factura en negativo (abono) , debe de ser una rectificativa, en su serie correspondiente (nada de en la misma serie que las facturas normales), y debes indicar a quien rectificas.
Otra cosa es que hagas facturas en negativo en tu serie normal y las subas al ticketbai, SII, o donde sea, y trague, pero en teoría, está mal

No me lo dijeron directamente a mi, se lo dijeron a un cliente, este se lo dijo a nuestro asistente, y este me lo dijo a mi... (el juego del teléfono... )

Ahora y, tal y como lo explicas, lo veo perfectamente lógico. Mil gracias!

Ahí si podría intervenir yo si se ponen muy farrucos los técnicos... que sería desde la aplicación, en la generación de facturas, si es un abono, hacer que sea en la serie rectificativa y que indiquen la factura que abona.... y ya estaría...

Gracias de nuevo.

[YellowStone]

Empezado por iMia

No me lo dijeron directamente a mi, se lo dijeron a un cliente, este se lo dijo a nuestro asistente, y este me lo dijo a mi... (el juego del teléfono... )

Ahora y, tal y como lo explicas, lo veo perfectamente lógico. Mil gracias!

Ahí si podría intervenir yo si se ponen muy farrucos los técnicos... que sería desde la aplicación, en la generación de facturas, si es un abono, hacer que sea en la serie rectificativa y que indiquen la factura que abona.... y ya estaría...

Gracias de nuevo.

Por poner un ejemplo, en una facturación de crédito del mes pasado, le facturo 50 albaranes del mes a un cliente, con un saldo positivo para nuestra empresa, a cobrar, de 2000 euros.

Me devuelve varias cosas este mes de distintos albaranes, que yo le pongo en nuevos albaranes en negativo, le facturo los albaranes a fin de mes, y resulta que que el resultado le sale a favor del cliente, negativo 100 euros, por ejemplo. ¿No puedo enviar esa factura porque su resultado es negativo?

¿Qué pretenden que haga? Es absurdo.

[keys]

Empezado por YellowStone

Por poner un ejemplo, en una facturación de crédito del mes pasado, le facturo 50 albaranes del mes a un cliente, con un saldo positivo para nuestra empresa, a cobrar, de 2000 euros.

Me devuelve varias cosas este mes de distintos albaranes, que yo le pongo en nuevos albaranes en negativo, le facturo los albaranes a fin de mes, y resulta que que el resultado le sale a favor del cliente, negativo 100 euros, por ejemplo. ¿No puedo enviar esa factura porque su resultado es negativo?

¿Qué pretenden que haga? Es absurdo.

Si una factura da negativo, lógicamente es por que te esta rectificando algo que le vendiste antes. Por lo tanto hay que hacer una rectificativa, esto es así ahora con TicketBai y antes de ticketBai. Otra cosa es que nadie lo hiciera así. Para controlar todo esto es uno de los motivos que salió TicketBAI, ya que antes cada uno hacía lo que quería con el reglamento de facturación. De hecho en las declaraciones de IVA, las facturas con importe negativo hay que llevarlas a las casillas de rectificación.

[espinete]

Todo esto de las facturas en negativo tiene teloa. Ya llevamos una semana con la duda, y ya hubo debate el año pasado, y lo seguirá habiendo en el futuro...

Que sí, que entendemos que hacer una rectificativa sería lo "ideal", pero no siempre es posible, y la responsabilidad no debería recaer siempre sobre nosotros. Hay muchos casos en los que no se puede hacer una rectificativa:
- Empresa con varias tiendas en las que un cliente puede cambiar/devolver un tícket en cualquiera de ellas. Las otras tiendas no tienen acceso al tícket original, porque está almacenado en otra tienda, así que no podrán obtener los datos de ese tícket original (firma), obligatorios para la rectificativa.
- Si el resultado final de la operación es exactamente el mismo, y además es más rápido, intuitivo, etc. tanto para el cliente final como para el usuario. ¿Qué problema hay?
- Si no está permitido hacer ventas en negativo... ¿Por qué lo permiten? ¿Por qué no da error?
- ¿Por qué SII sí permite hacer facturas en negativo y TicketBAI no?

Nosotros hemos optado por dar a elegir al usuario cómo quiere hacer el cambio/devolución. Quien quiera hacerlo con rectificativas, que lo haga. Es más lío, menos intuitivo y requiere varios pasos previos de más, pero si insisten, que lo hagan.

En nuestro caso concreto, con un cliente de Gipuzkoa, ha pasado lo siguiente:
- Envió una factura ordinaria #25
- Rectificó dicha factura, #1R
- Envió un tícket (simplificada) #25D
- Rectificó dicho tícket: #2R

Según él, aún no lo he confirmado, le dicen que no puede haber dos rectificativas que anulen la misma factura, PERO NO ES LA MISMA.

Yo dudo mucho que le hayan dicho eso, pero es lo que nos tiene preocupados y lo que ha desencadenado todo este lío, porque ahora no sabemos qué hacer. Con haber hecho el cambio/devolución con una venta en negativo, y en positivo el nuevo artículo, no hubiera pasado nada y todos contentos.
Todos menos Gipuzkoa.

[pablog2k]

Aquí hay que entender el concepto de factura, que no es más que un documento que certifica una venta de un bien/servicio.
Entonces, partiendo de esa base, lo que hacienda dice es: Porque estás vendiendo algo con unidades negativas? Para mi ( y para Hacienda claro ) , no tiene sentido hacer una venta con unidades negativas:
- Mira soy esta empresa X, te vendo -1 unidades de este producto.
Tiene sentido vender -1 de algo? para mi no.
Que dice hacienda?
- Oye, estás vendiendo -1 unidades, algo ha pasado verdad? Ah vale, lo haces porque el cliente no se ha quedado el material, o ha habido un error... lo que sea, pues dime a quien rectificas.
Para mi tiene todo el sentido del mundo.
Pero si, de toda la vida se han hecho facturas en negativo con normalidad ( lo que no hace que sea correcto ).

respecto al caso de espinete, siento decirte que sí es tu responsabilidad que se pueda hacer una rectificativa e indicar a quien rectificas:
"- Empresa con varias tiendas en las que un cliente puede cambiar/devolver un ticket en cualquiera de ellas. Las otras tiendas no tienen acceso al ticket original, porque está almacenado en otra tienda, así que no podrán obtener los datos de ese ticket original (firma), obligatorios para la rectificativa."
Que esas tiendas tengan bases de datos en local (y por lo tanto no tienen acceso entre ellas), es tú problema, que has provocado tú al desarrollar un software y hacer una instalación que no permite comunicación entre tiendas , y deberás resolverlo tú.
Tienes varias opciones:
- no permites devoluciones en tiendas distintas.
- haces que tu programa funcione online.
- haces que las 3 tiendas (o las que sean) se conecten a un server común donde esta tu software y la misma base de datos (cada pc con una sesión distinta). Así tenemos nosotros a algún cliente de ticketbai, cada tienda usa una serie distinta, haces sus rectificativas en la serie de rect. de la serie normal (A-RA, B-RB, C-RC), encadenamiento propio... y sin problemas.

Yo entiendo que muchas veces lo que piden desde hacienda,ticketbai, SII o plataforma que sea, no se adecua a nuestros softwares o formas de trabajar (exe generado con delphi, base de datos firebird en local...etc), pero al final eso es cosa nuestra por haber elegido este lenguaje de programación y ese sistema de gestión de base de datos.

[espinete]

Empezado por pablog2k

Aquí hay que entender el concepto de factura, que no es más que un documento que certifica una venta de un bien/servicio.
Entonces, partiendo de esa base, lo que hacienda dice es: Porque estás vendiendo algo con unidades negativas? Para mi ( y para Hacienda claro ) , no tiene sentido hacer una venta con unidades negativas:
- Mira soy esta empresa X, te vendo -1 unidades de este producto.
Tiene sentido vender -1 de algo? para mi no.
Que dice hacienda?
- Oye, estás vendiendo -1 unidades, algo ha pasado verdad? Ah vale, lo haces porque el cliente no se ha quedado el material, o ha habido un error... lo que sea, pues dime a quien rectificas.
Para mi tiene todo el sentido del mundo.
Pero si, de toda la vida se han hecho facturas en negativo con normalidad ( lo que no hace que sea correcto ).

respecto al caso de espinete, siento decirte que sí es tu responsabilidad que se pueda hacer una rectificativa e indicar a quien rectificas:
"- Empresa con varias tiendas en las que un cliente puede cambiar/devolver un ticket en cualquiera de ellas. Las otras tiendas no tienen acceso al ticket original, porque está almacenado en otra tienda, así que no podrán obtener los datos de ese ticket original (firma), obligatorios para la rectificativa."
Que esas tiendas tengan bases de datos en local (y por lo tanto no tienen acceso entre ellas), es tú problema, que has provocado tú al desarrollar un software y hacer una instalación que no permite comunicación entre tiendas , y deberás resolverlo tú.
Tienes varias opciones:
- no permites devoluciones en tiendas distintas.
- haces que tu programa funcione online.
- haces que las 3 tiendas (o las que sean) se conecten a un server común donde esta tu software y la misma base de datos (cada pc con una sesión distinta). Así tenemos nosotros a algún cliente de ticketbai, cada tienda usa una serie distinta, haces sus rectificativas en la serie de rect. de la serie normal (A-RA, B-RB, C-RC), encadenamiento propio... y sin problemas.

Yo entiendo que muchas veces lo que piden desde hacienda,ticketbai, SII o plataforma que sea, no se adecua a nuestros softwares o formas de trabajar (exe generado con delphi, base de datos firebird en local...etc), pero al final eso es cosa nuestra por haber elegido este lenguaje de programación y ese sistema de gestión de base de datos.

Discrepo en algunas cosas...

Lo primero: Hacienda sí permite ventas en negativo. Lo puedes leer claramente aquí:
https://sede.agenciatributaria.gob.e...ificacion.html

Mira el apartado de excepciones:

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.

Por no hablar de que el SII sí lo permite.

Dile ahora tu a un cliente que lleva 30 años trabajando de una manera, que ya no puede permitir devoluciones en tiendas distintas. ¿Eso también es responsabilidad nuestra por permitirlo? ¿Te va a obligar Hacienda a cómo debe trabajar un software?
Hacer que mi programa funcione online suena fácil decirlo. Tenemos versión online, pero convertir en online un software de escritorio con más de 20 años es imposible. No voy a pelearme con Hacienda explicándoles que tenemos clientes que todavía usan una versión de 2005, por ejemplo.

Podemos hablar también del concepto de "rectificativa", que en el 95% de los casos, se utiliza para rectificar errores (datos fiscales, forma de pago, etc.).
¿Que un cliente quiera cambiar o devolver un producto, es un error?

Recuerda que en nuestro caso concreto, estoy hablando de un cambio o devolución de una prenda, en un comercio de venta al público, que solo emite tíckets.
Si empresas como Leroy Merlín, Zara o cualquier multinacional lo hace con ventas en negativo, SIN indicar en ningún caso que sea una rectificativa, sin serie "R", etc. que no vengan a responsabilizarme a mi de nada.

[espinete]

Empezado por pablog2k

Aquí hay que entender el concepto de factura, que no es más que un documento que certifica una venta de un bien/servicio.
Entonces, partiendo de esa base, lo que hacienda dice es: Porque estás vendiendo algo con unidades negativas? Para mi ( y para Hacienda claro ) , no tiene sentido hacer una venta con unidades negativas:
- Mira soy esta empresa X, te vendo -1 unidades de este producto.
Tiene sentido vender -1 de algo? para mi no.
Que dice hacienda?
- Oye, estás vendiendo -1 unidades, algo ha pasado verdad? Ah vale, lo haces porque el cliente no se ha quedado el material, o ha habido un error... lo que sea, pues dime a quien rectificas.
Para mi tiene todo el sentido del mundo.
Pero si, de toda la vida se han hecho facturas en negativo con normalidad ( lo que no hace que sea correcto ).

respecto al caso de espinete, siento decirte que sí es tu responsabilidad que se pueda hacer una rectificativa e indicar a quien rectificas:
"- Empresa con varias tiendas en las que un cliente puede cambiar/devolver un ticket en cualquiera de ellas. Las otras tiendas no tienen acceso al ticket original, porque está almacenado en otra tienda, así que no podrán obtener los datos de ese ticket original (firma), obligatorios para la rectificativa."
Que esas tiendas tengan bases de datos en local (y por lo tanto no tienen acceso entre ellas), es tú problema, que has provocado tú al desarrollar un software y hacer una instalación que no permite comunicación entre tiendas , y deberás resolverlo tú.
Tienes varias opciones:
- no permites devoluciones en tiendas distintas.
- haces que tu programa funcione online.
- haces que las 3 tiendas (o las que sean) se conecten a un server común donde esta tu software y la misma base de datos (cada pc con una sesión distinta). Así tenemos nosotros a algún cliente de ticketbai, cada tienda usa una serie distinta, haces sus rectificativas en la serie de rect. de la serie normal (A-RA, B-RB, C-RC), encadenamiento propio... y sin problemas.

Yo entiendo que muchas veces lo que piden desde hacienda,ticketbai, SII o plataforma que sea, no se adecua a nuestros softwares o formas de trabajar (exe generado con delphi, base de datos firebird en local...etc), pero al final eso es cosa nuestra por haber elegido este lenguaje de programación y ese sistema de gestión de base de datos.

En esta página de la AEAT, en el ejemplo de "factura rectificativa por sustitución", se indica que también se pueden hacer facturas ordinarias en negativo (la opción 2):

https://sede.agenciatributaria.gob.e...00dc381e0aRCRD

...y luego hacer la rectificativa.

Por lo tanto, sí, se pueden hacer ventas en negativo.

Otra cosa es que para dormir tranquilos, prefiramos que el software soporte todas las opciones posibles, y que el cliente elija.
Pero poder, se puede, diga lo que diga Gipuzkoa.

[pablog2k]

ojo que no es lo mismo rectificativas sustitutivas que por diferencias, la 'sustitutiva' sustituye a la otra , y la de 'por diferencias' es la de toda la vida de 'abono' (negativo).
Respecto a lo que dices, si tienes razón, en la normativa lo permite, pero nosotros estamos cansados de discutir con hacienda sobre el tema, y es como pegarse contra un muro:
-facturas en negativo son rectificativas
y de ahí no salen.
Al final preferimos 'enseñar' a los clientes a que si les devuelven hago hagan una rect. indicando a quien rectifican (facilitando el proceso, con un buscador eliges la factura/ticket original y se te genera una rect. que es un espejo pero en negativo, y ya de ahí quitas o pones y confirmas factura/ticket).
De hecho para un cliente es más fácil elegir el documento origen mediante un buscador, y que al darle a 'aceptar' le haga ya la factura en negativo, que tener que meter a mano todas las líneas de los productos que le están devolviendo, con unidades negativas...etc

[pablog2k]

de todas formas espinete, creo que en tu caso lo que pasa que ticketbai se está liando con esto:
- Envió una factura ordinaria #25
- Rectificó dicha factura, #1R
- Envió un tícket (simplificada) #25D
- Rectificó dicho tícket: #2R

y no tiene nada que ver con poder hacer facturas en negativo, siendo rectificativas o no.
Tienes los xml de envío y respuesta de cada registro que envías a ticketbai?
Podrías ver, cuando enviaste la factura rectificada 1R, si indicabas a quien estabas rectificando, y que datos.
Y lo mismo para el envío de la factura 2R, y comparar a ver que datos has enviado en el caso de 1R y 2R

[espinete]

Empezado por pablog2k

de todas formas espinete, creo que en tu caso lo que pasa que ticketbai se está liando con esto:
- Envió una factura ordinaria #25
- Rectificó dicha factura, #1R
- Envió un tícket (simplificada) #25D
- Rectificó dicho tícket: #2R

y no tiene nada que ver con poder hacer facturas en negativo, siendo rectificativas o no.
Tienes los xml de envío y respuesta de cada registro que envías a ticketbai?
Podrías ver, cuando enviaste la factura rectificada 1R, si indicabas a quien estabas rectificando, y que datos.
Y lo mismo para el envío de la factura 2R, y comparar a ver que datos has enviado en el caso de 1R y 2R

El problema se ha complicado porque el cliente es un señor mayor que no entiende muy bien lo que le han dicho de Gipuzkoa, y nos lía a nosotros también.

Él llevaba tiempo trabajando normal, haciendo y enviando tanto facturas como facturas simplificadas, sin problema. Cuando había que hacer una devolución, hasta ahora hacía una venta en negativo (no rectificativa) y listo. Se enviaba a TicketBAI sin problema y sin quejas de nadie.

El problema surgió porque, según él (yo lo dudo), le llamaron de TicketBAI para decirle que "no podía hacer ventas en negativo, que tenía que hacer rectificativas."
A mí eso de que le hayan llamado me parece raro, pero bueno. Además, si no puede, pues que TicketBAI muestre un aviso al menos, y que no se trague la factura negativa sin más. Si tanto exigen, que lo avisen.

Total, que el cliente se asustó y lo que hizo fue una rectificativa del tícket: Factura Rectificativa 1R que rectifica al tícket 25D.

El problema es que la versión del software que tiene el cliente, permite tener dos historiales distintos: uno para tickets y otro para facturas ordinarias, por separado, con su propia enumeración independiente.
Y claro, ya tenía OTRA factura rectificativa "1R", pero que rectificaba a una factura ordinaria.

Así que ahora mismo tiene una 1R , que rectifica a una ordinaria, y una 1R que rectifica a una simplificada, porque en su versión actual esto era posible: las ordinarias se guardan sin serie y las simplificadas con la serie "D", en su caso.

Así que se ha liado. La solución sería simplemente anular la última 1R y hacer otra, la 2R, o bien usar otra serie distinta a la "R" para las rectificativas de simplificadas.
Pero claro, esto es muy difícil de explicar a mucha gente. Ten en cuenta que todavía hay clientes que ni siquiera saben lo que es un certificado digital, y de un día para otro necesitan tener uno para poder enviar TicketBAI.

[espinete]

Empezado por pablog2k

ojo que no es lo mismo rectificativas sustitutivas que por diferencias, la 'sustitutiva' sustituye a la otra , y la de 'por diferencias' es la de toda la vida de 'abono' (negativo).
Respecto a lo que dices, si tienes razón, en la normativa lo permite, pero nosotros estamos cansados de discutir con hacienda sobre el tema, y es como pegarse contra un muro:
-facturas en negativo son rectificativas
y de ahí no salen.
Al final preferimos 'enseñar' a los clientes a que si les devuelven hago hagan una rect. indicando a quien rectifican (facilitando el proceso, con un buscador eliges la factura/ticket original y se te genera una rect. que es un espejo pero en negativo, y ya de ahí quitas o pones y confirmas factura/ticket).
De hecho para un cliente es más fácil elegir el documento origen mediante un buscador, y que al darle a 'aceptar' le haga ya la factura en negativo, que tener que meter a mano todas las líneas de los productos que le están devolviendo, con unidades negativas...etc

Exacto. Y por este motivo me imagino que sí permiten enviar facturas en negativo, porque incluso en la web de TicketBAI Gipuzkoa ponen el mismo ejemplo, indicando en los pasos que puedes enviar una factura ordinaria en negativo y luego crear la rectificativa.
Por lo que, poder, se puede:
https://www.gipuzkoa.eus/es/web/ogas...tuci%C3%B3n-s-

Mira la "modalidad 2: Factura rectificativa sustitutiva en dos pasos"

Se emite una factura ordinaria normal con importe negativo, y después, se emite OTRA factura, esta sí rectificativa.

Pero sí que te permiten enviar una ordinaria en negativo.

Yo lo único que quiero decir con esto, es que los manuales, legislación, etc. prestan a confusión. Si estuviera todo bien explicado, no habría tanto debate.
Lo de las rectificativas siempre ha dado de qué hablar, mucho antes de que existiera TicketBAI. Ya era un lío aclararse con tanto tipo de rectificativa, tanto ejemplo, según el caso, etc. imagínate ahora con TicketBAI y el envío obligatorio, o cuando empiece VeriFactu dentro de un año.

Lo he dicho siempre: meter en el mismo saco un simple cambio o devolución en un comercio, con "errores en la factura", no es buena idea.
Sobre todo teniendo en cuenta que el 50% de las operaciones diarias que se realizan en España en un comercio, son cambios y devoluciones.

[iMia]

Empezado por espinete

......

El problema surgió porque, según él (yo lo dudo), le llamaron de TicketBAI para decirle que "no podía hacer ventas en negativo, que tenía que hacer rectificativas."
A mí eso de que le hayan llamado me parece raro, pero bueno. Además, si no puede, pues que TicketBAI muestre un aviso al menos, y que no se trague la factura negativa sin más. Si tanto exigen, que lo avisen.

...

A eso me refería yo, si a alguien le habían dado ese toque... por que un cliente mio dice que tambien se lo han dicho...

[ermendalenda]

Empezado por MaeseKvothe

Gracias por la respuesta. Ya había leído esa parte, pero no me queda del todo claro a qué llaman ellos centro de facturación, en mi caso que es una pasarela ¿se considera sólo un centro porque el servidor cuenta como dispositivo único o como ellos ya lo tienen separado son varios centros que se conectan a la pasarela?


Mi duda surge porque en esa misma segunda pregunta ellos indican:
"Si son necesarios varios procesos de facturación (se podrían asimilar a centros de facturación) para dar respuesta a varios usuarios concurrentes de una misma empresa de forma paralela, se debería encadenar en orden temporal dentro de cada proceso o centro de facturación, con independencia de la serie. En este caso, debe existir un número acotado de procesos o colas de facturación, asociado al número de usuarios concurrentes por empresa emisora de facturas."


Y mi mayor duda es, si el encadenamiento puede ser distinto en base a los centros de facturación y en ningún lugar se indica el centro, ¿cómo comprueban ellos que estás realizando correctamente el encadenamiento?

Te han respondido que cada centro de facturación su encadenamiento.
En el xml debes poner numero de instalacion (o nombre) que puedes hacerlo coincidir con el centro

[rci]

Hola, necesito enviar facturas de Ventanilla Única (OSS) con el IVA de otro país de la UE a TicketBAI.
En la documentación solo encuentro que existe la clave 17 pero no explica nada más.
En la documentación de SII hay una FAQ de como enviarlo pero los esquemas de TicketBAI no tienen los mismos campos en este punto.

Mi duda principal es que valor poner en el campo Importe del bloque DesgloseTipoOperacion.Entrega.DetalleNoSujeta
He conseguido enviar algunas facturas de OSS a TicketBAI y han sido aceptadas tanto si indico la base imponible como si indico el importe total de la factura con el IVA del país de la UE.
Supongo que no se valida pero claro... preferiría saber que esperan recibir. Imagino que lo correcto es poner la base.

De momento solo he probado enviar a Bizkaia, probaré las otras a ver si en alguna se valida y tengo mas pistas.

Alguien tiene mas información de como enviarlo?

Muchas gracias!!

[keys]

Empezado por rci

Hola, necesito enviar facturas de Ventanilla Única (OSS) con el IVA de otro país de la UE a TicketBAI.
En la documentación solo encuentro que existe la clave 17 pero no explica nada más.
En la documentación de SII hay una FAQ de como enviarlo pero los esquemas de TicketBAI no tienen los mismos campos en este punto.

Mi duda principal es que valor poner en el campo Importe del bloque DesgloseTipoOperacion.Entrega.DetalleNoSujeta
He conseguido enviar algunas facturas de OSS a TicketBAI y han sido aceptadas tanto si indico la base imponible como si indico el importe total de la factura con el IVA del país de la UE.
Supongo que no se valida pero claro... preferiría saber que esperan recibir. Imagino que lo correcto es poner la base.

De momento solo he probado enviar a Bizkaia, probaré las otras a ver si en alguna se valida y tengo mas pistas.

Alguien tiene mas información de como enviarlo?

Muchas gracias!!

Sólo hay que poner la base.

[Sistel]

Empezado por keys

Sólo hay que poner la base.

Hola,

Coincido con el colega Keys.
Los de TicketBAI no quieren ni oír hablar de IVAs de otros países.
Te dicen que esos IVAs son tema de Ventanilla Única.
Que para ellos, de esas facturas, sólo base imponible.

Saludos

[rci]

Empezado por keys

Sólo hay que poner la base.

Empezado por Sistel

Hola,

Coincido con el colega Keys.
Los de TicketBAI no quieren ni oír hablar de IVAs de otros países.
Te dicen que esos IVAs son tema de Ventanilla Única.
Que para ellos, de esas facturas, sólo base imponible.

Saludos

Muchas gracias keys y Sistel por vuestras respuestas

Buen fin de semana!

[rci]

El día que pregunté en el foro, también envié la consulta a todas las agencias tributarias vascas. Hoy me han contactado desde Gipuzkoa y me han dicho lo siguiente:

A parte de la clave de régimen especial 17 también se tiene que indicar la clave "IE – Sujeto a Impuesto Extranjero" como causa de no sujeción dentro del bloque No Sujeta.DetalleNoSujeta

Me han remitido a las FAQs 13.1 y 13.18

Las otras agencias no me han contestado pero imagino que será lo mismo.

Muchas gracias