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

[adolphsys]

Empezado por espinete

Hola.

Sigo liado con las facturas rectificativas, y leer lo que dice la Agencia Tributaria en su web no es que me aclare todas las dudas, la verdad:
://sede.agenciatributaria.gob.es/Sede/impuestos-tasas/iva/iva-libros-registro-iva-traves-aeat/preguntas-frecuentes/2-registro-cuestiones-comunes.html?faqId=f28c6c3d02bc9510VgnVCM100000dc381e0aRCRD

Según entiendo, y a modo de resumen, pueden ser de dos tipos, “por sustitución” y “por diferencias”, a elegir por el usuario:

1. Factura rectificativa “por sustitución”: Hay dos formas de hacerlo:
1.A: Creando una sola factura en la que se indiquen los importes correctos (base imponible, cuota y en su caso recargo) y los importes rectificados, respecto de la factura original.
- Emitimos una nueva factura, en otra Serie, con el importe/datos correctos
- Codigo de Rectificativa: "Rx", Tipo "S"
- Se deben rellenar los campos BaseRectificada, CuotaRectificada y CuotaRecargoRectificada
- Se debe indicar a qué factura rectifica: FacturasRectificadasSustituidas.NumFactura, FacturasRectificadasSustituidas.SerieFactura, etc.
1.B: Creando dos facturas
- Emitimos primero una factura ordinaria en negativo (Tipo "F1"), para "anular" la incorrecta. En ningún momento se indica que esta factura sea Rectificativa (Tipo "Rx", ni "S" ni "I" ni nada)
- Emitimos otra factura, esta sí se debe indicar como Rx y tipo "S"
- En esta segunda factura, los campos BaseRectificada, CuotaRectificada y CuotaRecargoRectificada van a 0 (o no se indican)
- En esta segunda factura se debe indicar también a qué factura rectifica: FacturasRectificadasSustituidas.NumFactura, FacturasRectificadasSustituidas.SerieFactura, etc.

2. Factura rectificativa "por diferencias": A simple vista, parece más fácil de entender y realizar.
Según la AEAT, se deberá informar directamente del importe de la rectificación en una sola factura rectificativa y no se debe informar de los campos “base rectificada”, “cuota rectificada”, etc.
Consiste simplemente en emitir una nueva factura con "la diferencia" que haya con respecto a la original.
- Código "Rx", Tipo "I"
- NO se requiere indicar nada en BaseRectificada, CuotaRectificada y CuotaRecargoRectificada
- Se debe indicar a qué factura rectifica: FacturasRectificadasSustituidas.NumFactura, FacturasRectificadasSustituidas.SerieFactura, etc.

Dicho esto, me surgen varias preguntas...

¿Por qué alguien haría una "por susticución" del tipo B, que requiere hacer dos facturas, en lugar de cualquier otro tipo que requiere hacer solo una? ¿Hay algún caso concreto que te obligue a usar esa opción?
¿La opción 1.A no sería lo mismo que la 2, salvo por tener que indicar BaseRectificada, CuotaRectificada, etc.?
En la opción 1.B... esa primera factura en negativo, de la que tanto hemos hablado en el foro (si es del todo "legal" o no)... ¿en qué quedamos? Nos dicen que lo correcto es hacer siempre rectificativas pero en este ejemplo dicen que podemos hacer una en negativo primero y luego una rectificativa?
Esa factura en negativo, que lo que hace es "anular" la original (para que la suma entre ambas sea cero), no la catalogan como "rectificativa", así que debe ir en la misma serie de facturación que la original. De hecho no es de Código "Rx".

Creo que mi cabeza en realidad se está poniendo en la mente del usuario final en vez de en la mía como desarrollador. Debería simplemente seguir las normas, preparar la aplicación para que las cumpla, y dejarme de hacerme preguntas fiscales

Pues eso... ¿alguien puede confirmarme si esto es correcto? ¿cómo hacéis vosotros las rectificativas, permitís al usuario final elegir entre las tres opciones u obligáis a hacerlo de una forma específica y punto?

Hola espinete, si te sirve de ayuda, nosotros usamos la opción 2 "rectificativa por diferencias" en todos los casos.

- Si hay que anular el 100% de una factura de 1200 € => rectificativa por diferencias -1200 € indicando la factura que se rectifica, y que el usuario haga una nueva ordinaria.
- Si hay que rectificar parcialmente una factura emitida => rectificativa por diferencias por el importe correspondiente en positivo o negativo.
- No usamos el servicio "anulación de facturas" porque no puede reenviarse el mismo número de factura a Hacienda.

Sería muy fácil darle a elegir al usuario la opción "sustitución" o "diferencias", pero si ya nos vuelven locos con dudas, si ponemos aún más opciones, más dudas, más llamadas... Además con el SII ya lo estamos haciendo de esta forma y hasta el momento no ha habido incidencias.

[thinkows]

Buenos días, os funcionan correctamente las pruebas en Bizkaia ? ayer enviaba sin problemas y hoy :

response status code: 200 OK
response body:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:LROEPJ240FacturasEmitidasConSGAltaRespuesta xmlns:ns2="https://www.batuz.eus/fitxategiak/batuz/LROE/esquemas/LROE_PJ_240_1_1_FacturasEmitidas_ConSG_AltaRespuesta_V1_0_1.xsd">
<Cabecera>
<Modelo>240</Modelo>
<Capitulo>1</Capitulo>
<Subcapitulo>1.1</Subcapitulo>
<Operacion>A00</Operacion>
<Version>1.0</Version>
<Ejercicio>2022</Ejercicio>
<ObligadoTributario>
<NIF>A99802704</NIF>
<ApellidosNombreRazonSocial>4YUFFiRkH5hP4QDzEtm4npiQMxeHe5</ApellidosNombreRazonSocial>
</ObligadoTributario>
</Cabecera>
<Registros>
<Registro>
<Identificador>
<IDFactura>
<SerieFactura>F1</SerieFactura>
<NumFactura>202100923</NumFactura>
<FechaExpedicionFactura>28-01-2022</FechaExpedicionFactura>
</IDFactura>
</Identificador>
<SituacionRegistro>
<EstadoRegistro>Incorrecto</EstadoRegistro>
<CodigoErrorRegistro>B4_2000070</CodigoErrorRegistro>
<DescripcionErrorRegistroES>La firma no cumple los requisitos de la política de firma TicketBAI.(Atributo política de firma incorrecto. - (10641))</DescripcionErrorRegistroES>
<DescripcionErrorRegistroEU>Sinadurak ez ditu betetzen TicketBAI sinaduraren politikaren baldintzak.(Atributo política de firma incorrecto. - (10641))</DescripcionErrorRegistroEU>
</SituacionRegistro>
</Registro>
</Registros>
</ns2:LROEPJ240FacturasEmitidasConSGAltaRespuesta>

Con su certificado y no he modificado nada desde ayer ....

[sEngine]

Acabo de probarlo yo tambien y me da el mismo error

Empezado por thinkows

Buenos días, os funcionan correctamente las pruebas en Bizkaia ? ayer enviaba sin problemas y hoy :

response status code: 200 OK
response body:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:LROEPJ240FacturasEmitidasConSGAltaRespuesta xmlns:ns2="https://www.batuz.eus/fitxategiak/batuz/LROE/esquemas/LROE_PJ_240_1_1_FacturasEmitidas_ConSG_AltaRespuesta_V1_0_1.xsd">
<Cabecera>
<Modelo>240</Modelo>
<Capitulo>1</Capitulo>
<Subcapitulo>1.1</Subcapitulo>
<Operacion>A00</Operacion>
<Version>1.0</Version>
<Ejercicio>2022</Ejercicio>
<ObligadoTributario>
<NIF>A99802704</NIF>
<ApellidosNombreRazonSocial>4YUFFiRkH5hP4QDzEtm4npiQMxeHe5</ApellidosNombreRazonSocial>
</ObligadoTributario>
</Cabecera>
<Registros>
<Registro>
<Identificador>
<IDFactura>
<SerieFactura>F1</SerieFactura>
<NumFactura>202100923</NumFactura>
<FechaExpedicionFactura>28-01-2022</FechaExpedicionFactura>
</IDFactura>
</Identificador>
<SituacionRegistro>
<EstadoRegistro>Incorrecto</EstadoRegistro>
<CodigoErrorRegistro>B4_2000070</CodigoErrorRegistro>
<DescripcionErrorRegistroES>La firma no cumple los requisitos de la política de firma TicketBAI.(Atributo política de firma incorrecto. - (10641))</DescripcionErrorRegistroES>
<DescripcionErrorRegistroEU>Sinadurak ez ditu betetzen TicketBAI sinaduraren politikaren baldintzak.(Atributo política de firma incorrecto. - (10641))</DescripcionErrorRegistroEU>
</SituacionRegistro>
</Registro>
</Registros>
</ns2:LROEPJ240FacturasEmitidasConSGAltaRespuesta>

Con su certificado y no he modificado nada desde ayer ....

[thinkows]

Empezado por sEngine

Acabo de probarlo yo también y me da el mismo error

Lo dicho, todo esto es muy cansino ....

Muchas gracias, por probarlo.

[programadorphp7]

Empezado por thinkows

Lo dicho, todo esto es muy cansino ....

Muchas gracias, por probarlo.

Hola,
A mi me ha dado también el mismo problema, no se si será fallo de ellos o han añadido alguna validación nueva que no estaban realizando y ahora nos mandan este fallo...

[programadorphp7]

Empezado por programadorphp7

Hola,
A mi me ha dado también el mismo problema, no se si será fallo de ellos o han añadido alguna validación nueva que no estaban realizando y ahora nos mandan este fallo...

Hola, Hoy he probado a enviar los mismos archivos que el viernes me dieron problema y ya ha funcionado bien así que fue algún problema en el sistema de LROE que ya han solucionado

[sEngine]

Empezado por thinkows

Lo dicho, todo esto es muy cansino ....

Muchas gracias, por probarlo.

Lo que si que he comprobado que se esta dando de alta. El QR funciona.

[thinkows]

Empezado por sEngine

Lo que si que he comprobado que se esta dando de alta. El QR funciona.

Sí,sí yo también.... pero no me fio nada ....

Gracias.

[musinho]

Hola,

Alguien sabe si en caso de anulación de una factura, hay que generar una factura en pdf con su qr? la verdad me parece raro porque el contenido de la generación de qr es el mismo que la factura original, pero no se si se me escapa algo.

Y para tema de encadenamiento, está factura anulada hay que tenerla en cuenta o no? aquí más de lo mismo, entiendo que no ya que el número de factura de la anulada es el mismo que la original.

Pero bueno, tengo estas dudas a ver si alguien puede decirme algo.

Milesker

[misteradrian]

Hola muy buenas a todos.

Estoy ya probando en producción en los entornos de producción de Gipuzkoa y de Alava.

Y tirando facturas en Alava no me da ningún problema, pero en Gipuzkoa me sale el error.

007 Certificado remitente no válido para emisor factura

Les he escrito un correo pero nada.
¿Sabéis por qué puede ser?

Un saludo y gracias de antemano.
Adrián

[misteradrian]

Empezado por misteradrian

Hola muy buenas a todos.

Estoy ya probando en producción en los entornos de producción de Gipuzkoa y de Alava.

Y tirando facturas en Alava no me da ningún problema, pero en Gipuzkoa me sale el error.

007 Certificado remitente no válido para emisor factura

Les he escrito un correo pero nada.
¿Sabéis por qué puede ser?

Un saludo y gracias de antemano.
Adrián

Hola a todos,
me respondo con la respuesta qué me han dicho ellos.

El error que recibís es porque el certificado de remitente no esta asociado con el emisor de la factura, esto es porque el emisor de factura que habéis creado es ficticio.
El certificado remitente debe ser del emisor, de su colaborador social o su representante.


La cosa es que según lo que he visto en la documentación FAQ 6.9
si somos colaboradores sociales a efectos fiscales tributamos nosotros en vez de nuestros clientes.

También lo que he visto que hay posibilidad de hacer un convenio con el cliente que hay que firmar y enviar a hacienda.

Por lo tanto, por lo que veo es
Hay que pedir un certificado por cliente o hay que hacer un escrito por cliente una de dos.

¿Me podéis confirmar alguno si esto es así?

Un saludo y gracias de antemano.

[misteradrian]

Empezado por thinkows

Buenos días, os funcionan correctamente las pruebas en Bizkaia ? ayer enviaba sin problemas y hoy :

response status code: 200 OK
response body:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:LROEPJ240FacturasEmitidasConSGAltaRespuesta xmlns:ns2="https://www.batuz.eus/fitxategiak/batuz/LROE/esquemas/LROE_PJ_240_1_1_FacturasEmitidas_ConSG_AltaRespuesta_V1_0_1.xsd">
<Cabecera>
<Modelo>240</Modelo>
<Capitulo>1</Capitulo>
<Subcapitulo>1.1</Subcapitulo>
<Operacion>A00</Operacion>
<Version>1.0</Version>
<Ejercicio>2022</Ejercicio>
<ObligadoTributario>
<NIF>A99802704</NIF>
<ApellidosNombreRazonSocial>4YUFFiRkH5hP4QDzEtm4npiQMxeHe5</ApellidosNombreRazonSocial>
</ObligadoTributario>
</Cabecera>
<Registros>
<Registro>
<Identificador>
<IDFactura>
<SerieFactura>F1</SerieFactura>
<NumFactura>202100923</NumFactura>
<FechaExpedicionFactura>28-01-2022</FechaExpedicionFactura>
</IDFactura>
</Identificador>
<SituacionRegistro>
<EstadoRegistro>Incorrecto</EstadoRegistro>
<CodigoErrorRegistro>B4_2000070</CodigoErrorRegistro>
<DescripcionErrorRegistroES>La firma no cumple los requisitos de la política de firma TicketBAI.(Atributo política de firma incorrecto. - (10641))</DescripcionErrorRegistroES>
<DescripcionErrorRegistroEU>Sinadurak ez ditu betetzen TicketBAI sinaduraren politikaren baldintzak.(Atributo política de firma incorrecto. - (10641))</DescripcionErrorRegistroEU>
</SituacionRegistro>
</Registro>
</Registros>
</ns2:LROEPJ240FacturasEmitidasConSGAltaRespuesta>

Con su certificado y no he modificado nada desde ayer ....

Me está pasando lo mismo ahora en el entorno de pruebas con Gipuzkoa sin yo haber cambiado nada.
Increible

[misteradrian]

Empezado por thinkows

Buenos días, os funcionan correctamente las pruebas en Bizkaia ? ayer enviaba sin problemas y hoy :

response status code: 200 OK
response body:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:LROEPJ240FacturasEmitidasConSGAltaRespuesta xmlns:ns2="https://www.batuz.eus/fitxategiak/batuz/LROE/esquemas/LROE_PJ_240_1_1_FacturasEmitidas_ConSG_AltaRespuesta_V1_0_1.xsd">
<Cabecera>
<Modelo>240</Modelo>
<Capitulo>1</Capitulo>
<Subcapitulo>1.1</Subcapitulo>
<Operacion>A00</Operacion>
<Version>1.0</Version>
<Ejercicio>2022</Ejercicio>
<ObligadoTributario>
<NIF>A99802704</NIF>
<ApellidosNombreRazonSocial>4YUFFiRkH5hP4QDzEtm4npiQMxeHe5</ApellidosNombreRazonSocial>
</ObligadoTributario>
</Cabecera>
<Registros>
<Registro>
<Identificador>
<IDFactura>
<SerieFactura>F1</SerieFactura>
<NumFactura>202100923</NumFactura>
<FechaExpedicionFactura>28-01-2022</FechaExpedicionFactura>
</IDFactura>
</Identificador>
<SituacionRegistro>
<EstadoRegistro>Incorrecto</EstadoRegistro>
<CodigoErrorRegistro>B4_2000070</CodigoErrorRegistro>
<DescripcionErrorRegistroES>La firma no cumple los requisitos de la política de firma TicketBAI.(Atributo política de firma incorrecto. - (10641))</DescripcionErrorRegistroES>
<DescripcionErrorRegistroEU>Sinadurak ez ditu betetzen TicketBAI sinaduraren politikaren baldintzak.(Atributo política de firma incorrecto. - (10641))</DescripcionErrorRegistroEU>
</SituacionRegistro>
</Registro>
</Registros>
</ns2:LROEPJ240FacturasEmitidasConSGAltaRespuesta>

Con su certificado y no he modificado nada desde ayer ....

Hola de nuevo,

¿Lo solucionaste al final?

Es que me acaba de pasar lo mismo con sus certificados, no he tocado nada en le firma y he comprobado que la codificación es UTF-8.

De todos modos les he enviado correo,
cualquier cosa os digo.

Gracias de antemano como siempre.

[HerensugeBeltz]

Últimamente la Hacienda de Gipuzkoa nos está enviando correos avisándonos de fallos en el envío de ficheros realizados con nuestra aplicación (no nos dice si son envíos de pruebas o de producción, o nuestros o de algún cliente).

El caso es que nos hemos planteado la siguiente cuestión y me gustaría saber vuestra opinión: ¿qué ocurre cuando un cliente se da de baja? Nuestro modelo de negocio es tipo 'renting': el cliente paga por el uso de la aplicación, soporte técnico, actualizaciones, etc. pero cuando se da de baja no le cortamos el uso de la aplicación: se queda sin soporte ni actualizaciones.

En estos casos, cuando por ejemplo TicketBAI implemente nuevas validaciones o cambie la versión del XSD, ¿nos seguirán comunicando errores en los envíos? ¿seguimos siendo responsables del (mal) uso de la aplicación que pueda hacer el cliente?

Lanzo esta reflexión a las ondas...

[batuzail]

Hola,
Pregunta sencilla, más fiscal que de programación. Las facturas simplificadas deben de ir obligatoriamente en una serie de facturas especifica para ellas, o basta con marcar una opción en la factura y que vaya a la serie normal?


Gracias

[Sistel]

Empezado por batuzail

Hola,
Pregunta sencilla, más fiscal que de programación. Las facturas simplificadas deben de ir obligatoriamente en una serie de facturas especifica para ellas, o basta con marcar una opción en la factura y que vaya a la serie normal?
Gracias

Hola batuzail,

En principio, leyendo detenidamente el Reglamento de Facturación no parece que deban ir, obligatoriamente, en series diferentes.
Pero hubo una Resolución Vinculante de la Dirección General de Tributos que interpretó que sí debían ir en series diferentes:
https://www.iberley.es/resoluciones/...6-2016-1439218

Aparte, si es simplificada, debe llevar en el XML del TicketBAI marcada la correspondiente opción:

<FacturaSimplificada>S</FacturaSimplificada>

Saludos

[adolphsys]

Empezado por batuzail

Hola,
Pregunta sencilla, más fiscal que de programación. Las facturas simplificadas deben de ir obligatoriamente en una serie de facturas especifica para ellas, o basta con marcar una opción en la factura y que vaya a la serie normal?


Gracias

Obligatoriamente no, pero es recomendable si existen facturas ordinarias.

A la único que "obliga" el reglamento de facturación es a diferenciar la serie de rectificativas. Y lo pongo entrecomillado porque el 90% de las empresas que me he encontrado lo meten todo a saco a una sola serie, y no me consta que se les haya multado en inspecciones tributarias por este motivo, aunque se trata de una falta.

[Neftali [Germán.Estévez]]

Empezado por HerensugeBeltz

El caso es que nos hemos planteado la siguiente cuestión y me gustaría saber vuestra opinión: ¿qué ocurre cuando un cliente se da de baja? Nuestro modelo de negocio es tipo 'renting': el cliente paga por el uso de la aplicación, soporte técnico, actualizaciones, etc. pero cuando se da de baja no le cortamos el uso de la aplicación: se queda sin soporte ni actualizaciones.

En estos casos, cuando por ejemplo TicketBAI implemente nuevas validaciones o cambie la versión del XSD, ¿nos seguirán comunicando errores en los envíos? ¿seguimos siendo responsables del (mal) uso de la aplicación que pueda hacer el cliente?

No es un mal uso de la aplicación, la aplicación funciona si se tiene actualizada; Si el cliente no la tiene actualizada (porque no paga) es problema suyo.
Es como si decide no comprar ninguna aplicación y no enviar facturas, es problema suyo.

La parte buena de incluir en las aplicaciones tema "legales" (SII, Modelos de hacienda, TicketBA, ley antifraude,...) es que de alguna manera tenemos "cogidos" a nuestros clientes con las actualizaciones. Si se diseña bien el modelo de negocio, puede ser una forma de fidelizar a los clientyes, aunque en contrapartida tenemos cambios continuos y hay que lidiar con las administraciones.

[Sistel]

Empezado por HerensugeBeltz

Últimamente la Hacienda de Gipuzkoa nos está enviando correos avisándonos de fallos en el envío de ficheros realizados con nuestra aplicación (no nos dice si son envíos de pruebas o de producción, o nuestros o de algún cliente).

El caso es que nos hemos planteado la siguiente cuestión y me gustaría saber vuestra opinión: ¿qué ocurre cuando un cliente se da de baja? Nuestro modelo de negocio es tipo 'renting': el cliente paga por el uso de la aplicación, soporte técnico, actualizaciones, etc. pero cuando se da de baja no le cortamos el uso de la aplicación: se queda sin soporte ni actualizaciones.

En estos casos, cuando por ejemplo TicketBAI implemente nuevas validaciones o cambie la versión del XSD, ¿nos seguirán comunicando errores en los envíos? ¿seguimos siendo responsables del (mal) uso de la aplicación que pueda hacer el cliente?

Lanzo esta reflexión a las ondas...

Hola HerensugeBeltz,

Si por motivos de falta de pago se deja al cliente sin mantenimiento de la aplicación, creo que es muy importante comunicárselo al cliente, por escrito, para que quede constancia.

El cliente es responsable del uso que haga de la aplicación.
Pero el desarrollador del software garante se hace responsable de que la aplicación cumpla la normativa, de que se corrijan los errores que vayan apareciendo en la misma y de que se actualice cuando la normativa vaya cambiando.

En todos los ficheros TicketBAI aparece el NIF del desarrollador del software garante y su licencia.
Así que mejor cubrirse las espaldas.

Saludos

[adolphsys]

Empezado por HerensugeBeltz

Últimamente la Hacienda de Gipuzkoa nos está enviando correos avisándonos de fallos en el envío de ficheros realizados con nuestra aplicación (no nos dice si son envíos de pruebas o de producción, o nuestros o de algún cliente).

El caso es que nos hemos planteado la siguiente cuestión y me gustaría saber vuestra opinión: ¿qué ocurre cuando un cliente se da de baja? Nuestro modelo de negocio es tipo 'renting': el cliente paga por el uso de la aplicación, soporte técnico, actualizaciones, etc. pero cuando se da de baja no le cortamos el uso de la aplicación: se queda sin soporte ni actualizaciones.

En estos casos, cuando por ejemplo TicketBAI implemente nuevas validaciones o cambie la versión del XSD, ¿nos seguirán comunicando errores en los envíos? ¿seguimos siendo responsables del (mal) uso de la aplicación que pueda hacer el cliente?

Lanzo esta reflexión a las ondas...

Nosotros también trabajamos con modalidad de servicio SaaS (renting) como tú, y si llega el vencimiento y el cliente elige no renovar, lo que hacemos es poner la aplicación en "modo demo", o sea, puede entrar al ERP y consultar sus datos, exportar, sacar listados... pero no puede facturar, cerrar ejercicios contables... y claro, si no puede facturar, tampoco remitir los datos a Hacienda. Te lo apunto como idea por si te sirve...