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

[ermendalenda]

Empezado por adolphsys

Gracias por vuestra respuesta.

Desde mi humilde punto de vista, es más transparente y trazable las facturas de cargo y abono, aunque quede "raro" no enviarlas al cliente. Pero hay que admitir que también es "raro" y sospechoso la existencia de huecos o "facturas marcadas como anuladas" ...

Hoy en día, con la normativa vigente, ante una inspección tributaria, prefiero no tener que justificar huecos en la numeración de facturas de venta...

Yo por ejemplo emito facturas sustitutivas de las simplificadas, si el vendedor se equivoca(que pasa muy a menudo) ANULO la sustitutiva y libero las simplificadas para hacer una nueva sustitutiva, en este caso la anulación es lo más rápido y transparente, se vé claro que ha habido un error.

[Sistel]

Hola,

Ya se ha abierto el plazo de presentación de observaciones al proyecto de RD del Reglamento de Digitalización Facturación por parte de la Agencia Tributaria.
Podéis ver el texto en https://www.hacienda.gob.es/Document...talizacion.pdf
La cosa va a traer cola ... para nosotros.

Saludos

[Casimiro Notevi]

Empezado por Sistel

Hola,
Ya se ha abierto el plazo de presentación de observaciones al proyecto de RD del Reglamento de Digitalización Facturación por parte de la Agencia Tributaria.
Podéis ver el texto en https://www.hacienda.gob.es/Document...talizacion.pdf
La cosa va a traer cola ... para nosotros.
Saludos

Es fácil: "Los obligados tributarios que ... utilicen sistemas informáticos para el cumplimiento de la obligación de facturación ".
¡Hala!, aquí está la solución de toda la vida:
Oiga, que yo no sé usar un aparato de esos tan modernos y eso de interné qué es:

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

Empezado por Sistel

Ya se ha abierto el plazo de presentación de observaciones al proyecto de RD del Reglamento de Digitalización Facturación por parte de la Agencia Tributaria.
Podéis ver el texto en https://www.hacienda.gob.es/Document...talizacion.pdf

Voy a copiar este mensaje al hilo sobre la ley antifraude para programas informáticos, que creo que es más adecuado.

[keys]

Muchas gracias.

Esto parece que es como el TicketBAI que han sacado en las forales.

No obstante, los obligados tributarios a que se refiere el artículo 3.1 de dicho Reglamento deberán
tener operativos los sistemas informáticos adaptados a las características y requisitos que se
establecen en el citado Reglamento y en su normativa de desarrollo a partir del 1 de enero de
2024

PArece que de momento nos dan tiempo.

Los obligados tributarios que, de acuerdo con el artículo 3 de este Reglamento, utilicen
sistemas informáticos para el cumplimiento de la obligación de facturación podrán remitir
voluntariamente a la Agencia Estatal de Administración Tributaria, de forma automática y segura
por medios electrónicos, todos los registros de facturación generados por los sistemas
informáticos a que se refiere la letra a) del artículo 7 de este Reglamento de acuerdo con las
especificaciones técnicas que se establezcan para la remisión

Parece que el envio de los registros a hacienda será voluntario y no obligatorio como en las forales. Aunque el sistema tiene que poder hacerlo.

Pero habrá que seguir esperando a que desarrollen la ley.

[ermendalenda]

Por lo que he leído es replica de ticketbai y le añaden más movidas sobre todo el Registro de instalación, actualizaciones y eventos con garantía de inalterabilidad y trazabilidad así que a currar un poco más no nos vayamos a quedar dormidos.

[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

[thinkows]

Empezado por misteradrian

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.

Sí,sí era problema suyo me imagino que tendrán algún problema.

Saludos

[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.

[misteradrian]

Empezado por thinkows

Sí,sí era problema suyo me imagino que tendrán algún problema.

Saludos

Me acaban de decir esto:

Debido a labores de mantenimiento, desde ayer a la tarde la validación de la firma estaba fallando y se ha decido deshabilitar temporalmente (a las 10:50) dicha validación, por lo que ahora ya no os debería dar error en la firma.

La que nos espera.

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

Empezado por misteradrian

Debido a labores de mantenimiento, desde ayer a la tarde la validación de la firma estaba fallando y se ha decido deshabilitar temporalmente (a las 10:50) dicha validación, por lo que ahora ya no os debería dar error en la firma.

¿En qué tributación?

[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

[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

[JAARROCA]

Empezado por elguille

Hola, he creado el XML con las chillkat y he validado las firmas con las utilidades para verificarlas y en principio estan correctas, pero al enviarlo a Guipuzcoa recibo
Error: El fichero de alta TicketBAI no cumple el esquema XSD. No se ha podido procesar el mensaje. Detalle del error: Content is not allowed in prolog
Creo que este error es debibo a los tag de definicion, yo empleo estos que he copiado de post anteriores y no consigo ver donde he metido la pata.



He validado el XML contra el xsd mediante -link freeformatter - y recibo el mismo error, los ficheros de ejemplo que has enviado tambien dan el mismo error al validarlos, no acabo de entender como puede ser que a ti no den error, ¿alguien es capaz de ver donde esta el problema?

Adjunto zip con el xml y el codigo que empleo.

Gracias y saludos

hola, soy nuevo en el foro y andaba buscando soluciones a mi problema, y lo que te pasaba a ti es exactamente lo mismo que he probado yo. Si subo o pruebo en -link freeformatter - Detalle del error: Content is not allowed in prolog
Pero si en esa web en vez de subir los archivos pego el contenido de XML y XSD me indica que si cumple el esquema. ¿Podrias por favor indicarme como solucionaste tu problema?

[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.

[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...

[APO]

Empezado por JAARROCA

hola, soy nuevo en el foro y andaba buscando soluciones a mi problema, y lo que te pasaba a ti es exactamente lo mismo que he probado yo. Si subo o pruebo en -link freeformatter - Detalle del error: Content is not allowed in prolog
Pero si en esa web en vez de subir los archivos pego el contenido de XML y XSD me indica que si cumple el esquema. ¿Podrias por favor indicarme como solucionaste tu problema?

Hola, he verificado el XML del fichero del ejemplo y creo que el problema está en la primera línea del XML.

En el fichero la primera línea está así:
<T:TicketBai xmlns:T="urn:ticketbai:emision" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd">

Y debería ser así:
<T:TicketBai xmlns:T="urn:ticketbai:emision" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ticketbai:emision ticketBaiV12.xsd">

Es decir, la última parte es lo que veo diferente de los envíos que hago yo, y que en mi caso son aceptados. Espero que te sirva de ayuda.

[keys]

Hola a todos.

¿Alguien esta haciendo el modelo 140 entero? Hay una serie de capitulos que no estan funcionando aún. Como el 6 de provisiones y suplidos y el 7 Otra información con transcendencia tributaría.

El 7 no importa tanto ya que es para final de año, ¿pero el 6?, que estais hadiendo en este caso.

Un Saludo.