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

[Sanduzelai]

Hola,
tengo una duda técnica a ver si me podéis aclarar.
Actualmente tengo funcionando el ticketbai Gipuzkoa y quiero empezar a implementar el de Alava (espero que no sea muy diferente...).
Para el de Gipuzkoa me base en el firmador.php de nuestro querido amigo bilbur ya que no controlo para nada ese tema y tenia:

Código PHP:

const POLITICA_FIRMA_GIP = array(
            "name" => "Politica de firma TicketBAI 1.0",
            "url" => "https://www.gipuzkoa.eus/ticketbai/sinadura",  
            "digest" => "dTtPpv4fWTcejeVx7+91ILruFX3HysbngBlllJm4i/E="
        ); 


Leyendo la documentación técnica de Alava veo que pone:
Política de firma: https://ticketbai.araba.eus/tbai/sinadura/
Hash de la política de Firma: 4Vk3uExj7tGn9DyUCPDsV9HRmK6KZfYdRiW3StOjcQA=

¿Ese hash te lo tienen que dar ellos o se calcula de alguna forma?
Lo pregunto mas que nada por entender mejor y saber si tengo que cambiarlo si el dia de mañana cambia la politica de firma o algo asi...


Igual la pregunta es un poco básica pero voy sacándome las castañas del fuego como buenamente puedo...

[bilbur]

Empezado por Sanduzelai

Hola,
tengo una duda técnica a ver si me podéis aclarar.

¿Ese hash te lo tienen que dar ellos o se calcula de alguna forma?
Lo pregunto mas que nada por entender mejor y saber si tengo que cambiarlo si el dia de mañana cambia la politica de firma o algo asi...


Igual la pregunta es un poco básica pero voy sacándome las castañas del fuego como buenamente puedo...

La firma con cualquier política de firma (BIZ, GIP, ARA) es válida para las tres provincias
El hash te lo dan ellos (aparece en su web de política de firma)


Suerte

[keys]

Empezado por Sanduzelai

Hola,
tengo una duda técnica a ver si me podéis aclarar.
Actualmente tengo funcionando el ticketbai Gipuzkoa y quiero empezar a implementar el de Alava (espero que no sea muy diferente...).
Para el de Gipuzkoa me base en el firmador.php de nuestro querido amigo bilbur ya que no controlo para nada ese tema y tenia:

Código PHP:

const POLITICA_FIRMA_GIP = array(
            "name" => "Politica de firma TicketBAI 1.0",
            "url" => "https://www.gipuzkoa.eus/ticketbai/sinadura",  
            "digest" => "dTtPpv4fWTcejeVx7+91ILruFX3HysbngBlllJm4i/E="
        ); 


Leyendo la documentación técnica de Alava veo que pone:
Política de firma: https://ticketbai.araba.eus/tbai/sinadura/
Hash de la política de Firma: 4Vk3uExj7tGn9DyUCPDsV9HRmK6KZfYdRiW3StOjcQA=

¿Ese hash te lo tienen que dar ellos o se calcula de alguna forma?
Lo pregunto mas que nada por entender mejor y saber si tengo que cambiarlo si el dia de mañana cambia la politica de firma o algo asi...


Igual la pregunta es un poco básica pero voy sacándome las castañas del fuego como buenamente puedo...

El proceso es el mismo en Alava que en Gipuzkoa, lo unico que cambia es la politica de firma y los servidores a los que envías. El hash esta en la documentacion de Alava.

Código Delphi [-]
     'https://ticketbai.araba.eus/tbai/sinadura/';
     '88E82F917EFFC8720345188FCBF2D84345149FB415F3FD750F50456ECF3232E4';
     'https://ticketbai.araba.eus/tbai/sinadura/';

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

Empezado por APO

Código PHP:

const POLITICA_FIRMA_GIP = array(
            "name" => "Politica de firma TicketBAI 1.0",
            "url" => "https://www.gipuzkoa.eus/ticketbai/sinadura",  
            "digest" => "dTtPpv4fWTcejeVx7+91ILruFX3HysbngBlllJm4i/E="
        ); 


Leyendo la documentación técnica de Alava veo que pone:
Política de firma: https://ticketbai.araba.eus/tbai/sinadura/
Hash de la política de Firma: 4Vk3uExj7tGn9DyUCPDsV9HRmK6KZfYdRiW3StOjcQA=

¿Ese hash te lo tienen que dar ellos o se calcula de alguna forma?
Lo pregunto mas que nada por entender mejor y saber si tengo que cambiarlo si el dia de mañana cambia la politica de firma o algo asi...

Ese es el HASH que te dan ellos (como tú bien dices en la documentación).
Cada tributación tiene el suyo (para PRE y para PRO). Y ya se ha cambiado alguna vez.
En nuestro caso y en previsión de futuros cambios está guardado en un campo de la B.D.

[Sanduzelai]

Muchas gracias a todos por la aclaración!

[Irreo]

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

Ese es el HASH que te dan ellos (como tú bien dices en la documentación).
Cada tributación tiene el suyo (para PRE y para PRO). Y ya se ha cambiado alguna vez.
En nuestro caso y en previsión de futuros cambios está guardado en un campo de la B.D.

Buenos días,

Estoy leyendo estos últimos mensajes mencionando esto, y me estoy quedando un poco a cuadros.

Primero, no tengo recuerdo de haber aplicado en ningún sitio lo de la política de firma.

He buscado en el código, y en efecto veo que en el "firmador.php" está el hash "dTtPpv4fWTcejeVx7+91ILruFX3HysbngBlllJm4i/E=".

Antes de pasarme a esta librería, estuve usando Chilkat 9.5 para PHP, que funcionaba, y no tengo recuerdo de haber puesto ningún string... excepto que haya sido algo que hice muy a los inicios, hace meses, y ya ni me acuerde.

En cualquier caso, llevamos en producción enviando facturas desde el 24 de octubre, y no he cambiado nada en el firmador. Es decir, que estoy usando el mismo hash de "política de firma" que estaba usando en el entorno de desarrollo.

De hecho lo único que hice el día que pasamos al entorno de producción fue poner el número de licencia correcto, así como todo el tema de HuellaTBAI, pero poco más...

¿Me tengo que preocupar?

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

En el primer mensaje tenemos las políticas de firma.
https://www.clubdelphi.com/foros/sho...97&postcount=1

Creo que deben estar actualizadas (si no es así comentadlo).

Empezado por Irreo

De hecho lo único que hice el día que pasamos al entorno de producción fue poner el número de licencia correcto, así como todo el tema de HuellaTBAI, pero poco más...

¿Me tengo que preocupar?

Yo miraría de actualizarlas.
Recuerdo que nosotros estuvimos un tiempo enviando también con una política antigua sin problemas, hasta que un día empezó a quejarse (no recuerdo en qué tributación).
Supongo que aquel día alguien activó esa validación. Que no se esté quejando ahora no quiere decir que cualquier día no empiece a hacerlo.

[rci]

Hola!

Vosotros como habéis planteado el tema del zuzendu subsanar? Me refiero al caso que un fichero ticketBAI se ha rechazado por errores en el XML, "Fichero no cumple el esquema XSD".
Mostráis al usuario el codigo XML del fichero TicketBAI original (sin firmar) para que el mismo lo edite y corrija y se pueda enviar al servicio Zuzendu?

Porque claro, las posibilidades de errores a corregir pueden ser muchísimas para programar cada caso... y supongo que hará falta la interacción con el usuario para indicar el dato correcto... o no.
No me parece factible que el usuario de nuestro programa corrija a mano el XML con errores
Ando un poco perdido en este tema.

Gracias!

[Irreo]

Empezado por rci

Hola!

Vosotros como habéis planteado el tema del zuzendu subsanar? Me refiero al caso que un fichero ticketBAI se ha rechazado por errores en el XML, "Fichero no cumple el esquema XSD".

Mostráis al usuario el codigo XML del fichero TicketBAI original (sin firmar) para que el mismo lo edite y corrija y se pueda enviar al servicio Zuzendu?

Porque claro, las posibilidades de errores a corregir pueden ser muchísimas para programar cada caso... y supongo que hará falta la interacción con el usuario para indicar el dato correcto... o no.

Por un lado, el XML que se envía no es sin más el original sin firmar. Aunque mantiene la estructura original, la definición del fichero y el bloque de "Cabecera" cambian.

Por otro lado, si hay un error en el XML, significa que hay un problema en el software que lo ha generado, o bien en la propia factura.

Es decir, corregir un XML a mano y enviarlo puede ser algo factible cuando tienes que enviar YA algo, y no tienes otra cosa preparada.

Lo correcto es corregir el problema que ha motivado un XML erróneo.

Por ejemplo, si le faltan las líneas de detalle, hay que enviarlo a Zuzendu-Subsanar. De nada sirve que abras el XML y las agregues a mano, porque te va a volver a pasar.

O abres la factura desde tu aplicación y agregas las líneas de detalle, y vuelves a enviarla, o bien corriges la programación que ha impedido la generación de unas líneas de detalle que sí existían.

En conclusión, ahora mismo no se me ocurre un motivo o razón justificada para editar un XML a mano.

Por ejemplo, en el sistema que tengo montado si hay un problema con el envío, me guardo el código de error, y además marco esa factura como a rectificar, o enviar a Zuzendu (según el error original), para saber qué hacer con ella. Además, dejo un registro de todos y cada uno de los envíos, con el XML original y el firmado para cada caso, con la respuesta obtenida. Pero cada intento de envío genera un XML y un registro nuevo, es decir, jamás reutilizo un XML ya generado.

[rci]

Empezado por Irreo

Por un lado, el XML que se envía no es sin más el original sin firmar. Aunque mantiene la estructura original, la definición del fichero y el bloque de "Cabecera" cambian.

Por otro lado, si hay un error en el XML, significa que hay un problema en el software que lo ha generado, o bien en la propia factura.

Es decir, corregir un XML a mano y enviarlo puede ser algo factible cuando tienes que enviar YA algo, y no tienes otra cosa preparada.

Lo correcto es corregir el problema que ha motivado un XML erróneo.

Por ejemplo, si le faltan las líneas de detalle, hay que enviarlo a Zuzendu-Subsanar. De nada sirve que abras el XML y las agregues a mano, porque te va a volver a pasar.

O abres la factura desde tu aplicación y agregas las líneas de detalle, y vuelves a enviarla, o bien corriges la programación que ha impedido la generación de unas líneas de detalle que sí existían.

En conclusión, ahora mismo no se me ocurre un motivo o razón justificada para editar un XML a mano.

Por ejemplo, en el sistema que tengo montado si hay un problema con el envío, me guardo el código de error, y además marco esa factura como a rectificar, o enviar a Zuzendu (según el error original), para saber qué hacer con ella. Además, dejo un registro de todos y cada uno de los envíos, con el XML original y el firmado para cada caso, con la respuesta obtenida. Pero cada intento de envío genera un XML y un registro nuevo, es decir, jamás reutilizo un XML ya generado.

Tienes razón Irreo, el usuario no puede editar el XML.

El caso es este, todavía no hemos desarrollado zuzendu y se ha rechazado una factura por un cif enviado con un guion, por un bug del programa. Ya hemos corregido el programa para no permitirlo pero claro, tenemos que enviar esa factura de alguna forma.
La idea es que no se rechacen facturas pero siempre puede ocurrir algo..


Vamos a ver como lo hacemos.



Muchas gracias

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

Empezado por rci

Vosotros como habéis planteado el tema del zuzendu subsanar? Me refiero al caso que un fichero ticketBAI se ha rechazado por errores en el XML, "Fichero no cumple el esquema XSD".
Mostráis al usuario el codigo XML del fichero TicketBAI original (sin firmar) para que el mismo lo edite y corrija y se pueda enviar al servicio Zuzendu?

No me parece correcto/lógico/seguro/... dar acceso al XML para que se modifique antes de enviar.
¿Podrías cambiar los importes y enviarlo? ¿entonces lo que envías no "cuadraría" con la factura?

No le veo sentido sinceramente y creo que te puede provocar muchos más problemas y errores de los que vas a solucionar.

[rci]

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

No me parece correcto/lógico/seguro/... dar acceso al XML para que se modifique antes de enviar.
¿Podrías cambiar los importes y enviarlo? ¿entonces lo que envías no "cuadraría" con la factura?

No le veo sentido sinceramente y creo que te puede provocar muchos más problemas y errores de los que vas a solucionar.

Tienes razón Neftali. Que el usuario edite el XML no es una opción.

Supongo que tendremos que programar una solución para cada posible error.
Muchas gracias

[josevalle]

Hola. El Hash te lo dan ellos. El que pones es el actual que lo cambiaron en mayo. Yo lo dejo modificable por si lo vuelven a cambiar.

[Sanduzelai]

Hola,
hoy he realizado mi primer envío de pruebas a la hacienda alavesa y he recibido lo siguiente:

Código PHP:

<FechaRecepcion>10-11-2022 13:29:39</FechaRecepcion>
    <Estado>00</Estado>
    <Descripcion>Recibido</Descripcion>
    <Azalpena>Jasota</Azalpena>
    <ResultadosValidacion>
      <Codigo>015</Codigo>
      <Descripcion>AVISO: NIF emisor no es correcto, no es contribuyente alavés o no está registrado en IAE</Descripcion>
      <Azalpena>OHARRA: Jaulkitzailearen IFZ ez da zuzena; ez da Arabako zergaduna edo ez dago JEZean erregistratuta</Azalpena>
    </ResultadosValidacion> 


Me registre en su día como empresa desarrolladora para enviar a la hacienda de Gipuzkoa y ahora me he dado de alta para el entorno de test de Álava. No he hecho nada más.

¿Tengo que registrarme en algún otro lado para corregir este aviso?

En el entorno de PRO de Gipuzkoa estoy funcionando bien con el mismo NIF Emisor.
No se si se me esta escapando algo para Alava...

[Sanduzelai]

Revisando la Guía del entorno de pruebas veo:

En el caso de que no se cumplan esas condiciones en el entorno de pruebas, se dará un aviso: “AVISO: NIF emisor no es correcto, no es contribuyente alavés o no está registrado en IAE”.
Este aviso no es bloqueante para hacer las pruebas. Pero si le sucede, podrá evitarlo enviando un mail a [email protected], indicando en el asunto del correo el texto “Pruebas TicketBAI: Nombre Empresa / Categoría: NIF Emisor” y aportando la siguiente información:
- NIF emisor
- Nombre y apellidos/Razón social

He mandado el correo con los datos tal y como indica para evitar que aparezca el aviso en mis pruebas, pero ahora me surge la duda:
Cuando pase al entorno de PRO, ¿me volverá a aparecer el AVISO?

Yo siempre realizo envíos de clientes:

Código PHP:

<EmitidaPorTercerosODestinatario>T</EmitidaPorTercerosODestinatario> 


[Sanduzelai]

Me respondo a mi mismo por si a alguien le viene bien.
Me han contestado esto:

Ya hemos procedido a dar de alta el NIF en el entorno de pruebas.

El aviso es porque el NIF emisor no es alavés. En producción en principio el emisor debería ser alavés. Si no es así saldrá el aviso y para solucionarlo deberá pasarse por la hacienda alavesa.

[Irreo]

Buenas,

Estaba repasando algunos envíos de facturas de hoy, y me he encontrado esto:



La numeración de facturas ya me dijeron los de Hacienda que "da igual" el orden en que se les envíen (aunque se recomienda que sean correlativos).

Lo que no me queda claro es si les va a gustar la hora....

¿Tenéis alguna experiencia con este tema? Es decir, si os haya pasado enviar alguna factura así y que no os hayan dicho nada.

Por el momento están como OK, y tampoco han llegado avisos de "posible error de encadenamiento".

Gracias.

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

Empezado por Irreo

La numeración de facturas ya me dijeron los de Hacienda que "da igual" el orden en que se les envíen (aunque se recomienda que sean correlativos).

¿Tenéis alguna experiencia con este tema? Es decir, si os haya pasado enviar alguna factura así y que no os hayan dicho nada.
Por el momento están como OK, y tampoco han llegado avisos de "posible error de encadenamiento".
Gracias.

Entiendo que el encadenamiento no es en el orden en que las estás viendo en pantalla, por lo tanto si las ordenaras por fecha/hora coincidiría con el orden del encadenamiento, por lo tanto entiendo que no hay problema.
No cuadra con el orden del primer ID de la tabla, pero sí cn la fecha/hora (no se si me explico).