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

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

Yo te diría que cambies el código para no coger el body de un fichero. La mayoría de los problemas de cambio de codificación son al pasar por diferentes pasos.
Intenta generarlo en memoria (Stream) y asignarlo al componente directamente sin pasar por fichero.

[Gherardo]

Muchas gracias Neftalí.

Antes lo hacia con un filestream y me hacia lo mismo, ya no se que hacer, probaré con los componentes que me comenta keys.

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

Empezado por Gherardo

Antes lo hacia con un filestream y me hacia lo mismo, ya no se que hacer, probaré con los componentes que me comenta keys.

A nosotros nos pasó (en uno de los casos) y al final lo que hicimos fue, grabar a disco en hexadecimal después cada uno de los pasos, desde la generación hasta el envío.
Al final detectamos una asignación que nos cambiaba la codificación.

[sEngine]

Solo queria dar las gracias a Bilbur por el firmador.php que puso por aquí

Estaba usando el autofirma y es mas lento que.... por lo que obviamente los clientes se quejaban.
Con el firmador.php lo hace super rapido. Lo he subido a un subdominio de una web nuestra para que se pueda usar desde fuera, y ya que lo tenia hecho, he puesto que si por lo que sea no puede conectar a la web, use el autofirma

[espinete]

Buenas...

Desde ayer nuestros clientes no pueden hacer envíos de TicketBAI (Gipuzkoa). Obtienen el siguiente error al hacer el envío:

Server Certificate invalid or nor present

¿Se trata de un error general de Gipuzkoa o es que ha cambiado algo casualmente ayer? ¿Le pasa a alguien más?

[keys]

Empezado por espinete

Buenas...

Desde ayer nuestros clientes no pueden hacer envíos de TicketBAI (Gipuzkoa). Obtienen el siguiente error al hacer el envío:

Server Certificate invalid or nor present

¿Se trata de un error general de Gipuzkoa o es que ha cambiado algo casualmente ayer? ¿Le pasa a alguien más?

Yo creo que es un problema de hacienda. A nuestros clientes también les estas pasando. En el entorno de pruebas también me ha dado el mismo error pero parece que ya funciona.

[rkinformatika]

Empezado por keys

Yo creo que es un problema de hacienda. A nuestros clientes también les estas pasando. En el entorno de pruebas también me ha dado el mismo error pero parece que ya funciona.

El certificado del servidor de la Hacienda de Gipuzkoa se habia caducado:

Common Name (CN)
*.egoitza.gipuzkoa.eus
Organization (O)
INFORMATIKA ZERBITZUEN FORU ELKARTEA - SOCIEDAD FORAL DE SERVICI
Organizational Unit (OU)
<Not Part Of Certificate>
Issued By
Common Name (CN)
EAEko Herri Administrazioen CA - CA AAPP Vascas (2)
Organization (O)
IZENPE S.A.
Organizational Unit (OU)
AZZ Ziurtagiri publikoa - Certificado publico SCA
Validity Period
Issued On
Thursday, November 10, 2022 at 2:10:24 PM
Expires On
Sunday, December 10, 2023 at 2:10:24 PM

Me confirmaron por email los técnicos de gipuzkoa.

[keys]

Empezado por rkinformatika

El certificado del servidor de la Hacienda de Gipuzkoa se habia caducado:

Common Name (CN)
*.egoitza.gipuzkoa.eus
Organization (O)
INFORMATIKA ZERBITZUEN FORU ELKARTEA - SOCIEDAD FORAL DE SERVICI
Organizational Unit (OU)
<Not Part Of Certificate>
Issued By
Common Name (CN)
EAEko Herri Administrazioen CA - CA AAPP Vascas (2)
Organization (O)
IZENPE S.A.
Organizational Unit (OU)
AZZ Ziurtagiri publikoa - Certificado publico SCA
Validity Period
Issued On
Thursday, November 10, 2022 at 2:10:24 PM
Expires On
Sunday, December 10, 2023 at 2:10:24 PM

Me confirmaron por email los técnicos de gipuzkoa.

Menos mal que están preparados

[espinete]

Buenas!

Estoy haciendo ahora la implementación de ZUZENDU para Gipuzkoa. Hasta ahora no me ha hecho falta integrarlo, y de hecho sigo teniendo dudas de si realmente es necesario, pero por si acaso me gustaría tenerlo todo previsto.

¿Alguien podría explicarme en qué casos se debe usar exactamente? Me lío entre anulación de factura, zuzendu y baja de zuzendu.

He visto que la estructura es casi exactamente igual que la del envío de una Factura, y por lo que he leído, es para "subsanar" envíos que hayan sido rechazados previamente; y que el envío se hace a una URL distinta a la de Alta de Facturas, etc.
En el diagrama que hay en la web de Gipuzkoa indica que cuando el envío de una factura devuelva "avisos de errores" y el error tiene "reflejo en la factura" (vete tu a saber qué quieren decir con eso), hay que subsanarla con un "zuzendu modificar". Pero...
¿A qué errores se refieren exactamente? ¿Por qué no me ha hecho falta hasta ahora hacer un envío de zuzendu, con cientos de clientes enviando facturas desde hace más de un año? ¿Para qué casos concretos habría que hacer esto?

Extraído de la documentación:

Cuando el fichero de alta TicketBAI o el fichero de subsanación del fichero de
alta TicketBAI sea recibido con aviso de errores que no exijan la emisión de una
factura rectificativa, pero sean consecuencia de no superar las validaciones de
consolidación del resto de datos que deban informarse en el fichero, se deberá
generar un fichero de modificación que será enviado a través del servicio
zuzendu.
Asimismo, cuando el fichero de alta TicketBAI o el fichero de subsanación del
fichero de alta TicketBAI ha sido recibido sin errores y, sin embargo, el
contribuyente considera necesario modificar la información que contiene el
mismo, siempre y cuando no se trate de una causa que exija la emisión de una
factura rectificativa, se podrá generar un fichero de modificación que será
enviado a través del servicio zuzendu.

Y espérate, que después de leer que hay diferencias entre "modificar" y "subsanar" y, por si fuera poco confuso:
- Ficheros de subsanación de los ficheros de alta TicketBAI.
- Ficheros de modificación de los ficheros de alta TicketBAI.
- Ficheros de modificación de los ficheros de subsanación de los ficheros de alta TicketBAI

No sé si es que estoy realmente cansado de todo este tema, pero la verdad es que ahora mismo no se me ocurre un caso concreto en el que sea necesario enviar una modificación/zuzendu, y mucho menos, una "baja de zuzendu".
Lo que está claro es que dejar que el propio usuario final pueda enviar zuzendus cuando le de la gana, no es buena idea.

[DemonAscun]

Empezado por espinete

Buenas!

Estoy haciendo ahora la implementación de ZUZENDU para Gipuzkoa. Hasta ahora no me ha hecho falta integrarlo, y de hecho sigo teniendo dudas de si realmente es necesario, pero por si acaso me gustaría tenerlo todo previsto.

¿Alguien podría explicarme en qué casos se debe usar exactamente? Me lío entre anulación de factura, zuzendu y baja de zuzendu.

He visto que la estructura es casi exactamente igual que la del envío de una Factura, y por lo que he leído, es para "subsanar" envíos que hayan sido rechazados previamente; y que el envío se hace a una URL distinta a la de Alta de Facturas, etc.
En el diagrama que hay en la web de Gipuzkoa indica que cuando el envío de una factura devuelva "avisos de errores" y el error tiene "reflejo en la factura" (vete tu a saber qué quieren decir con eso), hay que subsanarla con un "zuzendu modificar". Pero...
¿A qué errores se refieren exactamente? ¿Por qué no me ha hecho falta hasta ahora hacer un envío de zuzendu, con cientos de clientes enviando facturas desde hace más de un año? ¿Para qué casos concretos habría que hacer esto?

Extraído de la documentación:

Cuando el fichero de alta TicketBAI o el fichero de subsanación del fichero de
alta TicketBAI sea recibido con aviso de errores que no exijan la emisión de una
factura rectificativa, pero sean consecuencia de no superar las validaciones de
consolidación del resto de datos que deban informarse en el fichero, se deberá
generar un fichero de modificación que será enviado a través del servicio
zuzendu.
Asimismo, cuando el fichero de alta TicketBAI o el fichero de subsanación del
fichero de alta TicketBAI ha sido recibido sin errores y, sin embargo, el
contribuyente considera necesario modificar la información que contiene el
mismo, siempre y cuando no se trate de una causa que exija la emisión de una
factura rectificativa, se podrá generar un fichero de modificación que será
enviado a través del servicio zuzendu.

Y espérate, que después de leer que hay diferencias entre "modificar" y "subsanar" y, por si fuera poco confuso:
- Ficheros de subsanación de los ficheros de alta TicketBAI.
- Ficheros de modificación de los ficheros de alta TicketBAI.
- Ficheros de modificación de los ficheros de subsanación de los ficheros de alta TicketBAI

No sé si es que estoy realmente cansado de todo este tema, pero la verdad es que ahora mismo no se me ocurre un caso concreto en el que sea necesario enviar una modificación/zuzendu, y mucho menos, una "baja de zuzendu".
Lo que está claro es que dejar que el propio usuario final pueda enviar zuzendus cuando le de la gana, no es buena idea.

Te estas complicando mucho..jjejeej es más fácil de lo que parece:
- Alta
- Si no entra la Alta normal la metes por SUBSANACIÓN del servicio Zuzendu-Alta-Subsanar-V5
- Para modificar la factura, por modificación del servicio Zuzendu-Alta Modificar-V5.
- Baja
- Si no entra la Baja normal puedes meterla por SUBSANACION del servicio Zuzendu-Anulación

Resumen: zuzendu modificar para cuando quieras modificar algún dato, subsanar alta cuando todavía no esta en sus sistema y subsanar baja para darla de baja.

[skatologiko]

Buenos días, ¿alguien está teniendo hoy problemas en Guipúzcoa? Parece que nos está tardando en transmitir los tickets (unos sí y otros no)

[Sistel]

Empezado por skatologiko

Buenos días, ¿alguien está teniendo hoy problemas en Guipúzcoa? Parece que nos está tardando en transmitir los tickets (unos sí y otros no)

Hola,

Sí. Parece que está caído.

Saludos

[iMia]

Si, está dando timeouts

[espinete]

Empezado por DemonAscun

Te estas complicando mucho..jjejeej es más fácil de lo que parece:
- Alta
- Si no entra la Alta normal la metes por SUBSANACIÓN del servicio Zuzendu-Alta-Subsanar-V5
- Para modificar la factura, por modificación del servicio Zuzendu-Alta Modificar-V5.
- Baja
- Si no entra la Baja normal puedes meterla por SUBSANACION del servicio Zuzendu-Anulación

Resumen: zuzendu modificar para cuando quieras modificar algún dato, subsanar alta cuando todavía no esta en sus sistema y subsanar baja para darla de baja.

Si, ese es el protocolo, pero lo que no entiendo es en qué casos concretamente se debe hacer una "subsanación".
Si no entra un Alta normal, no basta con volver a intentarlo? Hacienda aún no tiene la factura, no? Otra cosa es que se haya enviado PERO con avisos/errores y Hacienda se la haya tragado (que debería ser problema de ellos por habérsela comido, pero bueno).

Es decir, si se envía una factura, pero con error/aviso, ahí entiendo que sí haya que hacer una "subsanación", después de haber corregido la causa del error. Imagino que dependerá de qué tipo de error sea exactamente.

Luego está lo de "modificar una factura". Lo siento, pero sigo sin entender la diferencia. En ambos casos (subsanar y modificar) lo que tenemos que hacer es modificar algo en la factura. ¿En qué casos concretos se requiere subsanación y en qué casos modificación?

Subsanación si Hacienda se traga una factura incorrecta y modificación si nosotros voluntariamente queremos reenviarla? ¿Para esto último no sería más correcto una rectificativa? Al menos eso es lo que nos ha reiterado Hacienda últimamente: "Modificar mal. Rectificativa bien"...

Y siguiendo con las exigencias de tener que hacer rectificativas... ¿por qué entonces se permiten las "bajas"?

[Sistel]

Empezado por espinete

Si, ese es el protocolo, pero lo que no entiendo es en qué casos concretamente se debe hacer una "subsanación".
Si no entra un Alta normal, no basta con volver a intentarlo? Hacienda aún no tiene la factura, no? Otra cosa es que se haya enviado PERO con avisos/errores y Hacienda se la haya tragado (que debería ser problema de ellos por habérsela comido, pero bueno).

Es decir, si se envía una factura, pero con error/aviso, ahí entiendo que sí haya que hacer una "subsanación", después de haber corregido la causa del error. Imagino que dependerá de qué tipo de error sea exactamente.

Luego está lo de "modificar una factura". Lo siento, pero sigo sin entender la diferencia. En ambos casos (subsanar y modificar) lo que tenemos que hacer es modificar algo en la factura. ¿En qué casos concretos se requiere subsanación y en qué casos modificación?

Subsanación si Hacienda se traga una factura incorrecta y modificación si nosotros voluntariamente queremos reenviarla? ¿Para esto último no sería más correcto una rectificativa? Al menos eso es lo que nos ha reiterado Hacienda últimamente: "Modificar mal. Rectificativa bien"...

Y siguiendo con las exigencias de tener que hacer rectificativas... ¿por qué entonces se permiten las "bajas"?

Hola,

Para aclarar cuando hacer una rectificativa, un Zuzendu de modificación o un Zuzendu de subsanación, viene muy bien este gráfico que anexo.

Saludos

[Sistel]

Empezado por espinete

¿por qué entonces se permiten las "bajas"?

Hola,

Hay veces que no tiene mucho sentido hacer rectificativas sino anular la factura y hacerla de nuevo.
Ejemplos:

- Vendes un pantalón y en el momento de entregar la factura al cliente, te das cuenta de que has puesto jersey.
Anulas la factura, la rompes antes de entregarla al cliente y vuelves a hacerla bien.

- Haces una factura de 100€ y a continuación te das cuenta de que se te había quedado trabada la tecla del cero y te aparece 1.000.000€ como importe.
Anulas la factura, desencajas la tecla bloqueada y vuelves a hacer la factura.

- Después de hacer una factura te das cuenta de que has puesto como destinatario a un ex-cliente de hace muchos años (con el que quedaste a mal).
Ni se te ocurriría enviarle la factura emitida y una rectificativa.
Anulas la factura y eliges bien el destinatario al hacer la nueva.

- Estás cobrándole a un cliente en la tienda y, en el último momento, cuando vas a darle la factura, el cliente te dice que se arrepiente y no quiere el producto.
Anulación al canto.

Hay infinidad de casos en los que no es lógico hacer una rectificativa sino una anulación.

Saludos

[espinete]

Entiendo los casos, y de hecho sería lo lógico. Pero... ¿no se supone que esto implicaría ir en contra de lo que precisamente Hacienda no quiere que hagamos?

Cómo demuestra el empresario que esa factura realmente no se llegó a entregar al cliente final? ¿No estaríamos permitiendo defraudar/esconder esa factura?

Al anular/baja una factura... ¿su número queda libre de nuevo para hacer otra factura usando ese mismo número?

[joselugrk]

Hola,

Tengo un problema con un Cliente. Todo ha ido correctamente hasta que han realizado una factura Simplificada Cualificada a un Cliente de Francia.

Al realizar la comunicación de esa factura simplificada cualificada (cliente francés) ha dado el siguiente error “B4_2000027 LA FACTURA CONTIENE UN TIPO DE DESGLOSE INCORRECTO. HA DE SER A NIVEL DE OPERACIÓN CUANDO LA FACTURA ES COMPLETA Y, ADEMÁS, EXISTE DESTINATARIO EXTRANJERO (TIPO IDOTRO O QUE SEA NIF QUE EMPIECE POR N) O LA CLAVE DE IVA ES 02.”

¿Se puede hacer una factura simplificada cualificada para un cliente extranjero? En caso afirmativo, ¿Cómo se debería crear el fichero XML para enviarlo a Batuz?

NOTA: Tengo otro cliente, un Hotel, que realiza facturas completas y cuando son clientes extranjeros funciona el envío correctamente.

Adjunto el fichero XML del envío del Sin Software Garante y la respuesta.

Saludos y muchas gracias,
Joselu

[keys]

Hola a todos.

No se si os esta pasando a vosotros, pero últimamente al mandar facturas a TicketBAI está dando muchos errores de certificados. Como por ejemplo

001 Certificado remitente incorrecto (revocado o no homologado)
Error en la respuesta del servidor (200) N3_0000007 No existe un apoderamiento para la pareja de interesado y representante indicada.
AVISO: Certificado remitente no válido para emisor factura

Luego en un rato lo vuelven a intentar y funciona. Gracias.

[iMia]

Empezado por keys

Hola a todos.

No se si os esta pasando a vosotros, pero últimamente al mandar facturas a TicketBAI está dando muchos errores de certificados. Como por ejemplo

001 Certificado remitente incorrecto (revocado o no homologado)
Error en la respuesta del servidor (200) N3_0000007 No existe un apoderamiento para la pareja de interesado y representante indicada.
AVISO: Certificado remitente no válido para emisor factura

Luego en un rato lo vuelven a intentar y funciona. Gracias.

A un cliente nuestro también le pasó ayer.
Volver a enviar sin cambiar ni una coma y arreglado...

raro...