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

[Ramon88]

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

Modifico los parámetros que has enviado para iguarlarlos con los mios:

Código PHP:

Accept-Encoding:gzip
Content-Encoding:gzip
eus-bizkaia-n3-version: 1.0
eus-bizkaia-n3-content-type: application/xml
eus-bizkaia-n3-data: {"con":"LROE","apa":"1.1","inte":[{"nif":"A99800237","nrs":"GLe7VAi7qZ","ap1":"PuWn2yvAaQ","ap2":"BjvRzNGZq5"}],"drs":[{"mode":"140","ejer":"2021"}]}
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Content-Type: application/octet-stream 


Las llaves no se porque aparecen en tus parámetros, porque el conjunto no es un único parámetro, sino que son diferentes parámetros como HEADERS. Uno de ellos sí es un JSON.
¿No lo estarás enviando todo como un único JSON?

Si pongo la cabacera Accept me da error:
El encabezado 'Accept' se debe modificar con la propiedad o metodo adecuados.

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

Nosotros los añadimos así:

Código Delphi [-]
// Estas dos son como propiedades del componente
CompEnvioRESTClient.Accept := 'application/json, text/plain; q=0.9, text/html;q=0.8,';
CompEnvioRESTClient.AcceptCharset := 'utf-8, *;q=0.8';
// El resto como headers
CompEnvioRESTClient.AddParameter('Accept-Encoding', 'gzip', pkHTTPHEADER);
CompEnvioRESTClient.AddParameter('Content-Encoding', 'gzip', pkHTTPHEADER);
CompEnvioRESTClient.AddParameter('Content-Type', 'application/octet-stream', pkHTTPHEADER, [poDoNotEncode]);
CompEnvioRESTClient.AddParameter('eus-bizkaia-n3-version', '1.0', pkHTTPHEADER);
CompEnvioRESTClient.AddParameter('eus-bizkaia-n3-content-type', 'application/xml', pkHTTPHEADER, [poDoNotEncode] );
CompEnvioRESTClient.AddParameter('eus-bizkaia-n3-data', JSON, TRESTRequestParameterKind.pkHTTPHEADER, [poDoNotEncode]);

Y es resultado es este:

Código Delphi [-]
Accept-Encoding=gzip
Content-Encoding=gzip
Content-Type=application/octet-stream
eus-bizkaia-n3-version=1.0
eus-bizkaia-n3-content-type=application/xml
eus-bizkaia-n3-data={"con": "LROE","apa": "1.1","inte": {"nif": "_CIF_","nrs": "_RAZON_SOCIAL_"},"drs":{"mode": "240","ejer": "2021"}}

[tejano]

Os informamos que a partir del 30 de noviembre se va a habilitar la validación de la licencia en el Entorno real en modo de pruebas (el cual estará disponible hasta el 10 de diciembre de 2021) con el objetivo de que se pueda verificar el correcto funcionamiento de los sistemas de cara a la apertura del Entorno real a partir del 1 de enero de 2022.

Es imprescindible, que de cara al 1 de enero de 2022, tengáis verificados los datos de la licencia a utilizar. Si los datos de la licencia no son correctos, provocará el rechazo de las anotaciones, tanto del alta como de la anulación, del subcapítulo 1.1 del LROE.

Cuando hablamos de los datos de la licencia, nos referimos a los datos del Software de facturación incluido en la Huella TicketBAI:



Todos los campos deben coincidir EXACTAMENTE con los datos proporcionados en el alta realizada en el Registro de Software Garante. Para identificar el Nombre del software con el que fue dado de alta, basta con revisar el documento de notificación enviado, donde aparece junto con la Licencia TicketBAI otorgada y el NIF de la empresa desarrolladora:

[skatologiko]

Buenas, me estoy volviendo loco para añadir todas las líneas de detalle con la librería Chilkat, ya que en Guipuzcoa hay que detallar la factura.
Si utilizo el método UpdatechildContent siempre se me actualiza el mismo IDDetalleFactura ¿Cómo puedo crear diferentes elementos de IDDetalleFactura? He probado con NewChild y NewChild2, pero no cierra el elemento anterior
¿Qué método utilizáis?

[Ramon88]

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

Nosotros los añadimos así:
Código Delphi [-]// Estas dos son como propiedades del componente CompEnvioRESTClient.Accept := 'application/json, text/plain; q=0.9, text/html;q=0.8,'; CompEnvioRESTClient.AcceptCharset := 'utf-8, *;q=0.8'; // El resto como headers CompEnvioRESTClient.AddParameter('Accept-Encoding', 'gzip', pkHTTPHEADER); CompEnvioRESTClient.AddParameter('Content-Encoding', 'gzip', pkHTTPHEADER); CompEnvioRESTClient.AddParameter('Content-Type', 'application/octet-stream', pkHTTPHEADER, [poDoNotEncode]); CompEnvioRESTClient.AddParameter('eus-bizkaia-n3-version', '1.0', pkHTTPHEADER); CompEnvioRESTClient.AddParameter('eus-bizkaia-n3-content-type', 'application/xml', pkHTTPHEADER, [poDoNotEncode] ); CompEnvioRESTClient.AddParameter('eus-bizkaia-n3-data', JSON, TRESTRequestParameterKind.pkHTTPHEADER, [poDoNotEncode]);



Y es resultado es este:
Código Delphi [-]Accept-Encoding=gzip Content-Encoding=gzip Content-Type=application/octet-stream eus-bizkaia-n3-version=1.0 eus-bizkaia-n3-content-type=application/xml eus-bizkaia-n3-data={"con": "LROE","apa": "1.1","inte": {"nif": "_CIF_","nrs": "_RAZON_SOCIAL_"},"drs":{"mode": "240","ejer": "2021"}}

Según me han contestado, el problema lo tengo en los [] en el Json. Voy a ver si puedo quitarlos y lo pruebo.


Una duda que tengo, cuando subo una anulación, esta no lleva consecutivo, entonces la siguiente factura que subes, tiene que hacer referencia a alguna factura? a la anterior de la anulación?

[keys]

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

No se si es lo mismo (no creo, pero por si acaso), pero si son certificados que están instalados en la máquina (no como usuario local), hay problemas al acceder a ellos.
Necesitas elevación de permisos.

Hola a todos.

Ejecutando como administrador pasa lo mismo.

Haciendo pruebas tontas he visto que si lo ejecuto desde un programa de pruebas (.exe) funciona correctamente, pero desde una dll que es donde lo tenemos todo metido no. He copiado todo a una carpeta nueva y FUNCIONA, es decir copio y pego toda la carpeta del programa y funciona bien desde una dll.

Magia

[ermendalenda]

Empezado por keys

Hola a todos.

Ejecutando como administrador pasa lo mismo.

Haciendo pruebas tontas he visto que si lo ejecuto desde un programa de pruebas (.exe) funciona correctamente, pero desde una dll que es donde lo tenemos todo metido no. He copiado todo a una carpeta nueva y FUNCIONA, es decir copio y pego toda la carpeta del programa y funciona bien desde una dll.

Magia

Comprueba Sí la dll es win32 o win64, si es win32 y el sistema es de 64 seguramente tengas que meter la dll en windows\syswow64 en vez de system32 y registra lo allí como administrador con regsvr32.exe

[keys]

Empezado por ermendalenda

Comprueba Sí la dll es win32 o win64, si es win32 y el sistema es de 64 seguramente tengas que meter la dll en windows\syswow64 en vez de system32 y registra lo allí como administrador con regsvr32.exe

La dll es la misma tanto en una carpeta como en otra, lo único que hago es copiar todo el programa de una carpeta a otra y funciona. Algo ha pasado con los permisos en la carpeta original.

Además no las puedo registrar por que no son registrables. Al final me vale con moverle el programa a otra carpeta.

[Sistel]

Empezado por Ramon88

Según me han contestado, el problema lo tengo en los [] en el Json. Voy a ver si puedo quitarlos y lo pruebo.
Una duda que tengo, cuando subo una anulación, esta no lleva consecutivo, entonces la siguiente factura que subes, tiene que hacer referencia a alguna factura? a la anterior de la anulación?

Hola Ramon88,

Mi opinión:
La referencia de una nueva factura debe ser a la factura anterior, esté o no anulada.
La anulación sólo es un estado fiscal para que Hacienda no considere sus importes a efectos IVA, IRPF, IS, etc.
Pero una factura anulada es una factura válida para TicketBAI con su serie, número, fecha y firma como las demás.
Aparte de que una factura puede anularse en cualquier momento, aunque haya otras posteriores.

Se admiten opiniones alternativas.

Saludos

[keys]

Empezado por Sistel

Hola Ramon88,

Mi opinión:
La referencia de una nueva factura debe ser a la factura anterior, esté o no anulada.
La anulación sólo es un estado fiscal para que Hacienda no considere sus importes a efectos IVA, IRPF, IS, etc.
Pero una factura anulada es una factura válida para TicketBAI con su serie, número, fecha y firma como las demás.
Aparte de que una factura puede anularse en cualquier momento, aunque haya otras posteriores.

Se admiten opiniones alternativas.

Saludos

Totalmente de acuerdo. De hecho la anulación puedes subirla en cualquier momento, por ejemplo después de subir la factura siguiente que apunta a la que anularás en un futuro.

[Ramon88]

Bueno mi error 400 era debido a los '[' ']' del Json... los he quitado y ya no da el error 400.


También puede dar error 400 por el certificado / CIF utilizado, lo digo por si alguien tiene este error 400 sepa por donde pueden ir los tiros.

[ermendalenda]

Empezado por keys

La dll es la misma tanto en una carpeta como en otra, lo único que hago es copiar todo el programa de una carpeta a otra y funciona. Algo ha pasado con los permisos en la carpeta original.

Además no las puedo registrar por que no son registrables. Al final me vale con moverle el programa a otra carpeta.

Hola eso me ocurrió tb con Windows 10 con una dll y después de varios días tuve que cambiarle el nombre. Empezó a no gustarle a Windows 10 sin motivo aparente.

[espinete]

Sigo pensando que un cambio o devolución en un punto de venta no debería requerir una rectificativa, sino una simple factura ordinaria (en negativo o positivo según sea cambio, devolución, etc.).

Y para intentar aclararlo al 100%, le he enviado a las tres haciendas forales varios supuestos que creo que no han tenido en cuenta, pero que se dan a diario en miles de comercios minoristas.
Me refiero a las cadenas de tiendas o franquicias con varias tiendas en distintas localidades e inlcuso en distintas provincias.

Se trata de casos en los que considero que emitir una rectificativa es inviable. Resumiendo:

* Persona que compra en ZARA Gipuzkoa (Tienda A) una camisa y la devuelve o la cambia en OTRO ZARA de Gipuzkoa
* Persona que compra en ZARA MADRID y devuelve o cambia en ZARA Gipuzkoa

¿Cómo sabe la Tienda que hace la devolución, qué factura tiene que rectificar, su encadenamiento, etc. si ellos NO tienen esa factura en el programa?

(No me digan que ZARA lo sabe porque lo tienen todo centralizado porque no es verdad. Además es solo un ejemplo, muchas otras tiendas no lo tienen centralizado ni de coña, ni les puedes obligar a tenerlo).

Cada tienda tiene su propia facturación, con su enumeración correlativa e independiente, etc. pero muchas cadenas permiten devolver/cambiar productos en toda España, por lo que no sé cómo podrían emitir una rectificativa si no la tienen en su base de datos. ¿Obligas al usuario a escribir los datos a mano a partir del tícket? Suerte con eso.

Publicaré las respuesta que me den las tres haciendas forales (suerte con esto también).

Un saludo

[ermendalenda]

Empezado por espinete

Sigo pensando que un cambio o devolución en un punto de venta no debería requerir una rectificativa, sino una simple factura ordinaria (en negativo o positivo según sea cambio, devolución, etc.).

Y para intentar aclararlo al 100%, le he enviado a las tres haciendas forales varios supuestos que creo que no han tenido en cuenta, pero que se dan a diario en miles de comercios minoristas.
Me refiero a las cadenas de tiendas o franquicias con varias tiendas en distintas localidades e inlcuso en distintas provincias.

Se trata de casos en los que considero que emitir una rectificativa es inviable. Resumiendo:

* Persona que compra en ZARA Gipuzkoa (Tienda A) una camisa y la devuelve o la cambia en OTRO ZARA de Gipuzkoa
* Persona que compra en ZARA MADRID y devuelve o cambia en ZARA Gipuzkoa

¿Cómo sabe la Tienda que hace la devolución, qué factura tiene que rectificar, su encadenamiento, etc. si ellos NO tienen esa factura en el programa?

(No me digan que ZARA lo sabe porque lo tienen todo centralizado porque no es verdad. Además es solo un ejemplo, muchas otras tiendas no lo tienen centralizado ni de coña, ni les puedes obligar a tenerlo).

Cada tienda tiene su propia facturación, con su enumeración correlativa e independiente, etc. pero muchas cadenas permiten devolver/cambiar productos en toda España, por lo que no sé cómo podrían emitir una rectificativa si no la tienen en su base de datos. ¿Obligas al usuario a escribir los datos a mano a partir del tícket? Suerte con eso.

Publicaré las respuesta que me den las tres haciendas forales (suerte con esto también).

Un saludo

Buen caso. Gracias. Esperamos la respuesta.

[Sistel]

Empezado por espinete

Sigo pensando que un cambio o devolución en un punto de venta no debería requerir una rectificativa, sino una simple factura ordinaria (en negativo o positivo según sea cambio, devolución, etc.).

Y para intentar aclararlo al 100%, le he enviado a las tres haciendas forales varios supuestos que creo que no han tenido en cuenta, pero que se dan a diario en miles de comercios minoristas.
Me refiero a las cadenas de tiendas o franquicias con varias tiendas en distintas localidades e inlcuso en distintas provincias.

Se trata de casos en los que considero que emitir una rectificativa es inviable. Resumiendo:

* Persona que compra en ZARA Gipuzkoa (Tienda A) una camisa y la devuelve o la cambia en OTRO ZARA de Gipuzkoa
* Persona que compra en ZARA MADRID y devuelve o cambia en ZARA Gipuzkoa

¿Cómo sabe la Tienda que hace la devolución, qué factura tiene que rectificar, su encadenamiento, etc. si ellos NO tienen esa factura en el programa?

(No me digan que ZARA lo sabe porque lo tienen todo centralizado porque no es verdad. Además es solo un ejemplo, muchas otras tiendas no lo tienen centralizado ni de coña, ni les puedes obligar a tenerlo).

Cada tienda tiene su propia facturación, con su enumeración correlativa e independiente, etc. pero muchas cadenas permiten devolver/cambiar productos en toda España, por lo que no sé cómo podrían emitir una rectificativa si no la tienen en su base de datos. ¿Obligas al usuario a escribir los datos a mano a partir del tícket? Suerte con eso.

Publicaré las respuesta que me den las tres haciendas forales (suerte con esto también).

Un saludo

Hola espinete,

Yo también espero ansioso la respuesta que te den porque es un tema que me interesa (y también a mis clientes) muchísimo.
Gracias.

Saludos

[ermendalenda]

Empezado por espinete

Sigo pensando que un cambio o devolución en un punto de venta no debería requerir una rectificativa, sino una simple factura ordinaria (en negativo o positivo según sea cambio, devolución, etc.).

Y para intentar aclararlo al 100%, le he enviado a las tres haciendas forales varios supuestos que creo que no han tenido en cuenta, pero que se dan a diario en miles de comercios minoristas.
Me refiero a las cadenas de tiendas o franquicias con varias tiendas en distintas localidades e inlcuso en distintas provincias.

Se trata de casos en los que considero que emitir una rectificativa es inviable. Resumiendo:

* Persona que compra en ZARA Gipuzkoa (Tienda A) una camisa y la devuelve o la cambia en OTRO ZARA de Gipuzkoa
* Persona que compra en ZARA MADRID y devuelve o cambia en ZARA Gipuzkoa

¿Cómo sabe la Tienda que hace la devolución, qué factura tiene que rectificar, su encadenamiento, etc. si ellos NO tienen esa factura en el programa?

(No me digan que ZARA lo sabe porque lo tienen todo centralizado porque no es verdad. Además es solo un ejemplo, muchas otras tiendas no lo tienen centralizado ni de coña, ni les puedes obligar a tenerlo).

Cada tienda tiene su propia facturación, con su enumeración correlativa e independiente, etc. pero muchas cadenas permiten devolver/cambiar productos en toda España, por lo que no sé cómo podrían emitir una rectificativa si no la tienen en su base de datos. ¿Obligas al usuario a escribir los datos a mano a partir del tícket? Suerte con eso.

Publicaré las respuesta que me den las tres haciendas forales (suerte con esto también).

Un saludo

De todas formas los temas de facturación, no ticketbai, si quieres una Respuesta rápida, tiene que ser consulta telefónic, y pasa a ser una respuesta sin validez oficial.
Si quieres esperar a la escrita te va a tardar varios meses, eso me dijeron en una consulta a la Aeat.

[adolphsys]

Empezado por espinete

Sigo pensando que un cambio o devolución en un punto de venta no debería requerir una rectificativa, sino una simple factura ordinaria (en negativo o positivo según sea cambio, devolución, etc.).

Y para intentar aclararlo al 100%, le he enviado a las tres haciendas forales varios supuestos que creo que no han tenido en cuenta, pero que se dan a diario en miles de comercios minoristas.
Me refiero a las cadenas de tiendas o franquicias con varias tiendas en distintas localidades e inlcuso en distintas provincias.

Se trata de casos en los que considero que emitir una rectificativa es inviable. Resumiendo:

* Persona que compra en ZARA Gipuzkoa (Tienda A) una camisa y la devuelve o la cambia en OTRO ZARA de Gipuzkoa
* Persona que compra en ZARA MADRID y devuelve o cambia en ZARA Gipuzkoa

¿Cómo sabe la Tienda que hace la devolución, qué factura tiene que rectificar, su encadenamiento, etc. si ellos NO tienen esa factura en el programa?

(No me digan que ZARA lo sabe porque lo tienen todo centralizado porque no es verdad. Además es solo un ejemplo, muchas otras tiendas no lo tienen centralizado ni de coña, ni les puedes obligar a tenerlo).

Cada tienda tiene su propia facturación, con su enumeración correlativa e independiente, etc. pero muchas cadenas permiten devolver/cambiar productos en toda España, por lo que no sé cómo podrían emitir una rectificativa si no la tienen en su base de datos. ¿Obligas al usuario a escribir los datos a mano a partir del tícket? Suerte con eso.

Publicaré las respuesta que me den las tres haciendas forales (suerte con esto también).

Un saludo

Hola espinete, no esperes gran cosa en cuanto a la respuesta de ninguna Hacienda, cuando yo les he planteado algo similar me han contestado lo siguiente:

Kaixo,

En primer lugar, disculpas por el retraso en contestar.
En cuanto a las cuestiones planteadas, responder que Batuz y TicketBai no modifican ni la normativa de IVA ni el reglamento de facturación. Por tanto, los casos en que se puede emitir una factura rectificativa son los mismos que hasta ahora, y serían casos diferentes en los que se permite la anulación de una operación. Recomendamos ver las preguntas frecuentes 19, 20 y 54 en la web https://www.batuz.eus/es/preguntas-frecuentes
Sobre la forma de emitir una factura rectificativa, se dan dos opciones: por diferencias o por sustitución. Recomendamos ver las preguntas frecuentes 45 y 47 a 54.
También quisiéremos explicar el proceso de funcionamiento de TicketBai y de Batuz, para aclarar que la emisión de una factura, rectificativa o no, no está vinculado a la remisión y a la aceptación o no del envío por Hacienda (no está vinculado a que esté subida y aceptada).
...
bla, bla, bla... no pongo más por no aburrir a la audiencia...


Conclusión (en mi modesta opinión): Dado que el reglamento de facturación español es del año 2012, y si hasta ahora se hacían abonos (facturas en negativo) para hacer una devolución y Hacienda no se ha metido para nada con usted, siga haciéndolo.

Saludos,

[ermendalenda]

Empezado por adolphsys

Hola espinete, no esperes gran cosa en cuanto a la respuesta de ninguna Hacienda, cuando yo les he planteado algo similar me han contestado lo siguiente:

Kaixo,

En primer lugar, disculpas por el retraso en contestar.
En cuanto a las cuestiones planteadas, responder que Batuz y TicketBai no modifican ni la normativa de IVA ni el reglamento de facturación. Por tanto, los casos en que se puede emitir una factura rectificativa son los mismos que hasta ahora, y serían casos diferentes en los que se permite la anulación de una operación. Recomendamos ver las preguntas frecuentes 19, 20 y 54 en la web https://www.batuz.eus/es/preguntas-frecuentes
Sobre la forma de emitir una factura rectificativa, se dan dos opciones: por diferencias o por sustitución. Recomendamos ver las preguntas frecuentes 45 y 47 a 54.
También quisiéremos explicar el proceso de funcionamiento de TicketBai y de Batuz, para aclarar que la emisión de una factura, rectificativa o no, no está vinculado a la remisión y a la aceptación o no del envío por Hacienda (no está vinculado a que esté subida y aceptada).
...
bla, bla, bla... no pongo más por no aburrir a la audiencia...


Conclusión (en mi modesta opinión): Dado que el reglamento de facturación español es del año 2012, y si hasta ahora se hacían abonos (facturas en negativo) para hacer una devolución y Hacienda no se ha metido para nada con usted, siga haciéndolo.

Saludos,

Yo lo veo un pelin arriesgado.
Antes de ticketbai, para comprobarlo tenían que levantar inspección, ahora lo tienen a huevo, primero comprueban y a raíz de los datos mandan la inspección, van a tener muy fácil automatizar las inspecciones, me imagino por la mañana un correo automatizado(o una aplicación portable en L que les informe de las inspecciones del día y la ruta a seguir) a los inspectores de zonas por el boot de ticketbai que repasa los datos que no están según normativa. Fácil de hacer y muchos ingresos a las arcas.

[infoser101]

Alguien sabe la diferencia en la url del QR en araba?
Al consultar un QR de facturas admitida devuelve siempre el error "Parámetros incorrectos"

Si embargo, este mismo código efectúa la consulta a Gipuzkoa sin problemas

La generación del CRC se hace con toda la url previa al parámetro "cr".
La url se deja sin la / final, tal y como indica la especificación
Tampoco existen caracteres a codificar en ninguno de los ejemplos probados

Por ejemplo, los parámetros de una url que da error en el entrono de pruebas de Araba es:

id=TBAI-A78648144-210121-qcSwKs6XuYTTq-062&s=01&nf=7684&i=63.26&cr=195

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

Empezado por infoser101

Alguien sabe la diferencia en la url del QR en araba?

Prueba con el mismo código de Guipuzkoa y sin quitar la / a la URL.
Yo estoy usando esto y funciona sin problemas:

TicketBAIID:TBAI-B05430756-291121-oBvVV+V6VnNb1-158
Serie:A
NumFactura:25000
Importe:3.63
URL:https://pruebas-ticketbai.araba.eus/tbai/qrtbai/

RESULT:  https://pruebas-ticketbai.araba.eus/tbai/qrtbai/?id=TBAI-B05430756-291121-oBvVV%2BV6VnNb1-158&s=A&nf=25000&i=3.63&cr=106