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

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

[Irreo]

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

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

El encadenamiento está en el orden de la imagen, sí, no por fecha:

1713 -> 1712 -> 1711

En nuestro caso por un lado tenemos una aplicación de Windows que está en los puntos de venta, que es la que genera una factura, asigna la fecha, etc.. y luego la envía a un API intermedio (PHP) que está en un servidor. Este API simplemente recibe facturas, las encola, y las envía, poniendo el encadenamiento según van entrando en cola.

La factura 1713 ha tardado 3 minutos en enviarse a la cola (desde Windows), y creo que es porque es una factura completa. Me da que la aplicación de Windows está generando la factura, con su fecha y todo, y después en tienda se han puesto a introducir datos de cliente.

El tema es que (aparte del API) en esta aplicación yo solo me he encargado de hacer una función que envía los datos al API (esta función recopila los datos de la factura, genera un objeto JSON, etc. y lo envía al API).

Pero el resto de funcionalidades ya existentes, más relacionadas con clientes/pedidos etc. están fuera de mi "jurisdicción".

Les voy a pedir que entren en la Sede Electrónica a ver si hay alguna alarma.

En cualquier caso, les voy a pedir que la fecha de expedición se guarde justo antes de llamar a mi función.

De todas formas, preguntaba por saber si alguien más envía facturas así y no pasa nada.

La numeración entiendo que da igual mientras haya encadenamiento correcto (1600 -> 1607 -> 1606...), pero que la fecha de emisión no siga el orden de la numeración ya lo veo más raro...