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

[elcharlie]

Parece ser, que el Servidor de Pruebas de araba ya está operativo, y han habilitado la comprobación del código QR en la siguiente url base: https://pruebas-ticketbai.araba.eus/tbai/qrtbai/
Yo he hecho la prueba y me da el error 'Parámetros Incorrectos", estoy seguro que genero la url correctamente (no es por ser un sobrao, pero genero las url de los QR de las otras diputaciones de la misma manera, y no tengo problemas), pero por si acaso, ¿habéis probado vosotros si os funciona bien?

[edari]

Empezado por elcharlie

Parece ser, que el Servidor de Pruebas de araba ya está operativo, y han habilitado la comprobación del código QR en la siguiente url base: https://pruebas-ticketbai.araba.eus/tbai/qrtbai/
Yo he hecho la prueba y me da el error 'Parámetros Incorrectos", estoy seguro que genero la url correctamente, pero por si acaso, ¿habéis probado vosotros si os funciona bien?

Mismo caso que tú

[elcharlie]

Empezado por edari

Mismo caso que tú

Ok, gracias por la comprobación. Esperaremos a que lo arreglen...

[YellowStone]

Empezado por Noe277

Esto es un problema de ellos habrá que decirles, el caso es que creo que esta en el redondo.
1 x 1,446 también da error pero 1, 44 lo hace bien. 1,45 también hace mal el problema es como redondean.

El problema está en pedir que la etiqueta <ImporteTotal> venga con el impuesto incluido y luego seguramente validan que la suma de los "importes totales" sea igual al importe de la factura, y eso es un error (creo que por parte de ellos, Álava en este caso, porque la misma factura con los mismos importes Guipúzcoa la da por válida). No se puede sacar el IVA por cada línea de la factura, porque el IVA se debe calcular sobre el importe final de la factura, y no línea a línea, porque por los redondeos va a descuadrar si o si en muchos casos. ¿Qué hacemos? ¿Metemos una línea de detalle con el posible descuadre del centimillo?

[ermendalenda]

Empezado por misteradrian

Hola de nuevo lo primero de todo gracias por tu contestación.
Quizás no me expresé del todo bien. Efectivamente el firmador es una maravilla y funciona correctamente.
El caso es que yo tengo puesto mi editor de textos y los datos que obtengo en la base de datos en ISO8859-1 y el envío los requiere siempre en UTF-8.
Entonces cuando hay tildes se me transforman a caracteres extraños (Pasa lo mismo si en cualquier campo como el nombre lleva alguna tilde).
Y pues cuando lo visualizo y lo paso a chillkat o lo envío para ticketbai Gipuzkoa , los errores de la firma venían derivados de esos caracteres extraños por la codificación derivadas de las tildes.
Resumiendo, problemas de derivados de codifcación.

Lo único me ha surgido una duda nueva a ver si alguien me la puede responder.
¿La variable digest dentro del nuevo array POLITICA_FIRMA_ALAVA como lo puedo calcular?

Un saludo y mil gracias de nuevo de verdad,
sin este foro no podría estar tirando este proyecto hacia delante.

Teniendoo en cuenta que no sé php y he probado con este comando

$certIssuer = str_replace("ó", "o", $certIssuer);
pero no entiendo por que no funciona, mientras alguien diga por que no va y si siempre vas a firmar con ese tipo de certificados puedes forzar y cambiar esto en el firmador.php:

$certIssuer = implode(', ', array_reverse($certIssuer));
por:
$certIssuer='CN=AC Representacion, OU=CERES, O=FNMT-RCM, C=ES';

[sEngine]

Empezado por elcharlie

Parece ser, que el Servidor de Pruebas de araba ya está operativo, y han habilitado la comprobación del código QR en la siguiente url base: https://pruebas-ticketbai.araba.eus/tbai/qrtbai/
Yo he hecho la prueba y me da el error 'Parámetros Incorrectos", estoy seguro que genero la url correctamente (no es por ser un sobrao, pero genero las url de los QR de las otras diputaciones de la misma manera, y no tengo problemas), pero por si acaso, ¿habéis probado vosotros si os funciona bien?

a mi tampoco me va, mismo error

[misteradrian]

Empezado por ermendalenda

Teniendoo en cuenta que no sé php y he probado con este comando

$certIssuer = str_replace("ó", "o", $certIssuer);
pero no entiendo por que no funciona, mientras alguien diga por que no va y si siempre vas a firmar con ese tipo de certificados puedes forzar y cambiar esto en el firmador.php:

$certIssuer = implode(', ', array_reverse($certIssuer));
por:
$certIssuer='CN=AC Representacion, OU=CERES, O=FNMT-RCM, C=ES';

Yo también probé eso ayer, pero tiene que llevar tilde para que al enviar el XML a Gipuzkoa te lo reconozca de la FNMT.
Si quieres que el primero te vaya tendrás que hacer un utf8_decode ó un utf8_encode, dependiendo de en que codificación te encuentres.


Pero que de verdad, está ya solucionado con lo que escribí esta mañana no te preocupes.
Era el tema de la codificación de mis datos, que no estaban en UTF8.

[thinkows]

Empezado por YellowStone

El problema está en pedir que la etiqueta <ImporteTotal> venga con el impuesto incluido y luego seguramente validan que la suma de los "importes totales" sea igual al importe de la factura, y eso es un error (creo que por parte de ellos, Álava en este caso, porque la misma factura con los mismos importes Guipúzcoa la da por válida). No se puede sacar el IVA por cada línea de la factura, porque el IVA se debe calcular sobre el importe final de la factura, y no línea a línea, porque por los redondeos va a descuadrar si o si en muchos casos. ¿Qué hacemos? ¿Metemos una línea de detalle con el posible descuadre del centimillo?

Yo lo consulté y esto me respondieon :

Buenos días Jordi


Hemos revisado el contenido de su fichero y los importes son correctos.

El error se está dando en las líneas en las que el importe es menor de 1 euro. Al trabajar con importes pequeños y despreciar los decimales se ha provocado esta situación.

Vamos a solucionarlo en breve.

Cuando lo hayamos solucionado se lo comunicaremos.

Gracias por su colaboración

Un saludo

[edari]

Estoy mirando el resto de ficheros del LROE y se me caen los pantalones abajo


modelo 240.



altas Facturas recibidas
altas Intracomunitarias
altas Cobros

altas Pagos
altas Importes superiores a 6000 euros


(y creo que no me afectan más)


Entiendo que estos ficheros no hay que hacer transformarlos en base64 si no que se generan directamente, se comprimen y se suben (en mi caso con el curl) desde ya la gestión contable de nuestros programas.



En el zip de ejemplos que tiene Batuz no veo ejemplos de estos. Están en algún otro sitio?






Gracias

[keys]

Empezado por edari

Estoy mirando el resto de ficheros del LROE y se me caen los pantalones abajo


modelo 240.



altas Facturas recibidas
altas Intracomunitarias
altas Cobros

altas Pagos
altas Importes superiores a 6000 euros


(y creo que no me afectan más)


Entiendo que estos ficheros no hay que hacer transformarlos en base64 si no que se generan directamente, se comprimen y se suben (en mi caso con el curl) desde ya la gestión contable de nuestros programas.



En el zip de ejemplos que tiene Batuz no veo ejemplos de estos. Están en algún otro sitio?






Gracias

Se envían como tu dices, no hay ejemplos. Yo solo he encontrado de emitidas.

[espinete]

Hola a todos/as...

Por fin he podido generar, firmar, enviar, (consultar) y anular facturas a las tres delegaciones. El problema que me encuentro ahora es con Bizkaia, que permite enviar varias facturas en el mismo envío, en lugar de una a una como Gipuzkoa y Araba.

Si envío varias facturas de golpe en el mismo envío/fichero... ¿cómo obtengo el Nº, serie y firma de la factura anterior si aún no he recibido respuesta hasta que se envíen todas?

Lo explico mejor...

En un mismo fichero, envío 100 facturas de golpe. Si en "SignatureValueFirmaFacturaAnterior", etc. debo poner la firma de la factura anterior, nº, serie... que se haya enviado correctamente... ¿cómo sé si ésta efectivamente se envió correctamente, si aún no he obtenido la respuesta de este envío masivo?

Obviamente puedo incluir ese dato, y el nº, serie, etc. de la factura anterior independientemente de que ésta se haya enviado correctamente o no, y esperar al resultado final y actuar en consecuencia (marcándolas como "no enviadas").
Pero claro, desde que falle un envío (por ejemplo, cuando vaya por la 25), las otras 75 darán todas error. No veo lógico hacerlo así.

Otra opción es enviarlas de una en una y listo, como con Gipuzkoa y Araba, pero no sé si será una opción elegante teniendo en cuenta que han habilitado el envío masivo por algún motivo, no?

Espero haberme explicado bien. Sin duda creo que el envío "de una en una" permite controlar más los envíos, ya que puedes incluso hacer comprobaciones antes de enviar, etc.

¿Cómo lo hacéis vosotros?

[adolphsys]

Empezado por espinete

Hola a todos/as...

Por fin he podido generar, firmar, enviar, (consultar) y anular facturas a las tres delegaciones. El problema que me encuentro ahora es con Bizkaia, que permite enviar varias facturas en el mismo envío, en lugar de una a una como Gipuzkoa y Araba.

Si envío varias facturas de golpe en el mismo envío/fichero... ¿cómo obtengo el Nº, serie y firma de la factura anterior si aún no he recibido respuesta hasta que se envíen todas?

Lo explico mejor...

En un mismo fichero, envío 100 facturas de golpe. Si en "SignatureValueFirmaFacturaAnterior", etc. debo poner la firma de la factura anterior, nº, serie... que se haya enviado correctamente... ¿cómo sé si ésta efectivamente se envió correctamente, si aún no he obtenido la respuesta de este envío masivo?

Obviamente puedo incluir ese dato, y el nº, serie, etc. de la factura anterior independientemente de que ésta se haya enviado correctamente o no, y esperar al resultado final y actuar en consecuencia (marcándolas como "no enviadas").
Pero claro, desde que falle un envío (por ejemplo, cuando vaya por la 25), las otras 75 darán todas error. No veo lógico hacerlo así.

Otra opción es enviarlas de una en una y listo, como con Gipuzkoa y Araba, pero no sé si será una opción elegante teniendo en cuenta que han habilitado el envío masivo por algún motivo, no?

Espero haberme explicado bien. Sin duda creo que el envío "de una en una" permite controlar más los envíos, ya que puedes incluso hacer comprobaciones antes de enviar, etc.

¿Cómo lo hacéis vosotros?

Hola, el proceso de encadenamiento de las facturas se hace en la emisión (facturación propiamente dicha), no en el envío.

[adolphsys]

Empezado por elcharlie

Parece ser, que el Servidor de Pruebas de araba ya está operativo, y han habilitado la comprobación del código QR en la siguiente url base: https://pruebas-ticketbai.araba.eus/tbai/qrtbai/
Yo he hecho la prueba y me da el error 'Parámetros Incorrectos", estoy seguro que genero la url correctamente (no es por ser un sobrao, pero genero las url de los QR de las otras diputaciones de la misma manera, y no tengo problemas), pero por si acaso, ¿habéis probado vosotros si os funciona bien?

Yo tampoco puedo comprobar facturas en Araba, también me da parámetros incorrectos...

[espinete]

Empezado por adolphsys

Hola, el proceso de encadenamiento de las facturas se hace en la emisión (facturación propiamente dicha), no en el envío.

Es decir, que cuando genere el XML de la factura, incluyo los datos de la factura anterior independientemente de que ésta se haya enviado correctamente o no?
Y ya luego, cuando obtenga la respuesta del envío masivo, las marco como "erróneas"?

Habrá que hacerlo así, pero sigo prefiriendo el envío "una a una".

[keys]

Yo creo que el problema del qr de alava es que estamos calculando mal el CRC. Mirando su ejemplo

https://pruebas-ticketbai.araba.eus/...2537.70&cr=017

Yo no consigo que me de 017. No se sobre que lo estan aplicando.

[keys]

Quizas tenga algo que ver esto de la barra. Lo estoy probando pero no me sale el mismo crc.

URL de acceso a la aplicación web de lectura del QR, específica para cada Administración tributaria:
o Araba/Álava: https://ticketbai.araba.eus/TBAI/QRTBAI (sin “/” para el cálculo del CRC).
o Bizkaia: https://batuz.eus/QRTBAI/ (con “/” al final para el cálculo del CRC).
o Gipuzkoa: https://tbai.egoitza.gipuzkoa.eus/qr/ (con “/” al final para el cálculo del CRC).

[JoseLeeTo]

Buenas tardes;

A la hora de dar de alta en Alava, desde hace unos días, a la URL:
https://pruebas-ticketbai.araba.eus/...I/v1/facturas/

.... me devuelve siempre como "Rechazado", con el error:
"El servicio de recepcion no esta disponible. Repita la operacion mas tarde"

¿Os ocurre a todos lo mismo con Alava? ¿Están caídos los servidores? ¿Se conoce alguna fecha donde se restaurarán?

Muchas gracias de antemano.
Un saludo.

[adolphsys]

Empezado por JoseLeeTo

Buenas tardes;

A la hora de dar de alta en Alava, desde hace unos días, a la URL:
https://pruebas-ticketbai.araba.eus/...I/v1/facturas/

.... me devuelve siempre como "Rechazado", con el error:
"El servicio de recepcion no esta disponible. Repita la operacion mas tarde"

¿Os ocurre a todos lo mismo con Alava? ¿Están caídos los servidores? ¿Se conoce alguna fecha donde se restaurarán?

Muchas gracias de antemano.
Un saludo.

Acabo de hacer un envío a Araba y a mi me funciona.

[YellowStone]

Empezado por keys

Quizas tenga algo que ver esto de la barra. Lo estoy probando pero no me sale el mismo crc.

La url de pruebas para los códigos QR en Álava es esta, según la guía de pruebas:


https://pruebas-ticketbai.araba.eus/tbai/qrtbai/

Pero también falla.

[rci]

Buenas tardes, nuestra aplicación está desarrollada en c# .Net y para el envío a las diputaciones forales utilizamos System.Net.HttpWebRequest


Nuestra idea es que las facturas se vayan enviando desde un servicio desatendido, que esté funcionando en el servidor.
Ya lo tenemos implementado y dentro del entorno de desarrollo funciona correctamente.

El problema lo tenemos cuando lo ejecutamos como servicio, que arranca con el usuario del sistema local (System).

En ese caso las diputaciones nos contestan con una excepción (cada una con un mensaje distinto) pero que indica que no ha encontrado el certificado de cliente para el envío.

Hemos visto que HttpWebRequest para envar a TicketBAI debe tener el certificado en el almacén de certificados del usuario (instalado en el navegador) y además debemos indicar que certificado del almacén se utilizará para el envio añadiendolo en la propiedad ClientCertificates del HttpWebRequest. Por ejemplo:

    var httpWebRequest = HttpWebRequest.CreateHttp(url);
    httpWebRequest.AllowAutoRedirect = true;
    httpWebRequest.ClientCertificates.Add(this.certificate);
    httpWebRequest.Method = "POST";
    …

Pues bien, parece que cuando ejecutamos como servicio de windows, como arranca con el usuario system, el HttpWebRequest no tiene acceso al almacén de certificados de los otros usuarios, por ejemplo el usuario con que se inicia sesión en el servidor y donde instalamos el certificado en el navegador.

Alguien que trabaje con .Net y utilice un servicio de windows para el envío nos puede echar un cable por favor?


Muchas gracias!!