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

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

Empezado por espinete

¿Alguien me explica qué es un "Ingreso con factura SIN software garante"? ¿Acaso el software garante tiene que permitir enviar facturas que NO se hayan registrado en el propio software? ¿O es que lo estoy entendiendo mal?

Creo que ya lo ha explicado [Sistel]; La opción de "sin SG" viene a ser algo así como una puerta de escape a todas las facturas que no se pueden codificar (por diferentes errores/problemas) por el caso normal (con SG).

Digamos que el 95% o el 98% de las facturas son "normales" y luego hay un porcentaje pequeño que son especiales, de determinados sectores o (como han dicho) que por lo que sea dan error.
Para eso se ha inventado el caso de "sin Software Garante".

Personalmente lo veo demasiado complejo, pero...


Eso sí, no os quiero desanimar, pero cuando lleguéis al tema de efectivo (percibido de más de 6000€) ya veréis...
Hay una forma de hacerlo fácil y luego la que han implementado ellos. (no se si reir o llorar...)

NOTA: Lo siento por el "spoiler", pero también tenía ganas de desahogarme...

[keys]

Creo que unos días habrá novedades en Bizkaia, y no puedo decir mas.

[Eric Mtz]

Empezado por keys

Creo que unos días habrá novedades en Bizkaia, y no puedo decir mas.

Cuenta, cuenta, que aquí estamos en confianza (Guiño, guiño, codo, codo).

[JVelezGarcia]

Hola, soy nuevo en el foro y estoy haciendo un envío LROE240 con dos facturas al servidor de pruebas y me devuelve INCORRECTO con el error
"Error al descomprimir el fichero.Not in GZIP format".
Me he puesto en contacto con ellos vía email y me dicen que el valor del parámetro Content-Length no coincide con el valor del tamaño del fichero que se envía.
El tamaño del fichero gzip es de 12840 bytes, pero si pongo ese valor se queda pensando y no termina nunca.
Si no pongo dicho parámetro ( Content-Lenght ) me indican que reciben un tamaño de 26 y no tengo ni idea de donde sale ese valor.
A ver si alguien puede darme un poco de luz con respecto al valor de ese parámetro y al mensaje de error.

Por cierto estoy usando curl desde línea de comandos.

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

Hola y bienvenido a este foro.

Empezado por JVelezGarcia

...estoy haciendo un envío LROE240 con dos facturas al servidor de pruebas y me devuelve INCORRECTO con el error
"Error al descomprimir el fichero.Not in GZIP format".

Por cierto estoy usando curl desde línea de comandos.

Será más fácil si indicas el commando que estás utilizando para el envío; Así alguien que haya utilizado CURL te puede ayudar.
Por lo que parece, o no estás enviando el archivo correctamente o no cuadra con la longitud que indicas. De todas formas, esto es una suposición.

[josepmestre]

Buenos días a todos,


¿alguien ha usado el programa CURL desde linea de comandos para enviar las facturas a Gipuzkoa ?


Si fuera así, ¿ podría poner un ejemplo del mismo ?


Gracias

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

Empezado por josepmestre

Buenos días a todos,
¿alguien ha usado el programa CURL desde linea de comandos para enviar las facturas a Gipuzkoa ?
Si fuera así, ¿ podría poner un ejemplo del mismo ?

Revisa páginas anteriores del foro, hay más usuarios que lo han usado y han puesto ejemplos.


Aquí tienes algunos, aunque hay más...


* Opción4: Utilizando commandos CURL
(https://www.clubdelphi.com/foros/sho...215&postcount=769)
(https://www.clubdelphi.com/foros/sho...215&postcount=737)
(https://www.clubdelphi.com/foros/sho...215&postcount=746)

[christianphp]

Hola buenas , se que llego un poco tarde al grupo pero tengo el error del titulo , lo curioso es que después de darme ese error cambio el valor de la etiqueta por un entero aleatorio y no me da error , parece que solo falla la primera vez que envío pero no las siguientes , estoy en el entorno de pruebas , gracias .

[JoseLeeTo]

Hola a todos.

Llevo ya un tiempo con el tema de Batuz, y creía estar volviéndome loco yo solo hasta que he encontrado este foro y he visto que somos muchos así.
Qué locura.

He desarrollado todo el sistema de TBai y de LROE para Vizcaya (ya hice los mismo desde el 2015 para la aplicación BILA), y hasta ahora solamente están disponibles las operaciones con Ingresos y Gastos, Bienes de Inversión y Agrupaciones de Bienes. El resto de epígrafes (Cobros, Pagos, RECC...) no están todavía expuestos)

En Guipuzcoa, estoy teniendo un problema que no se me ha dado en Vizcaya.

El error que me está dando es que no puede validar las referencias URI de la firma:
Básicamente: "El mensaje ha sido modificado en tránsito o la firma no está bien realizada -- Reference URI="#Certificate1" failed to verify. Reference URI="#SignedProperties-1909873269" failed to verify"

Y es que no entiendo cómo pueden tener diferentes criterios de validación de firma. En Vizcaya la misma firma es válida, pero no en Guipuzcoa.

¿A alguien más le ha ocurrido, y puede echarme una mano a qué puede ser debido?

Gracias a todos.
Saludos.

[josepmestre]

A mí me daba un error similar, <Descripcion>El mensaje ha sido modificado en tránsito o la firma no está bien realizada -- Reference URI="#Signature-d4d0ea3e-5409-4a0a-b5dd-f7c339abd340-SignedProperties" failed to verify. [src/xml2signatureobj.cpp(315)] - (10606)</Descripcion>, y es debido a que el valor CN del campo de firma IssuerName contiene un acento. Poniendo otro certificado funciono correctamente.


Envié un mensaje a la hacienda de Gipuzkoa y no me han respondido.

Empezado por JoseLeeTo

En Guipuzcoa, estoy teniendo un problema que no se me ha dado en Vizcaya.

El error que me está dando es que no puede validar las referencias URI de la firma:
Básicamente: "El mensaje ha sido modificado en tránsito o la firma no está bien realizada -- Reference URI="#Certificate1" failed to verify. Reference URI="#SignedProperties-1909873269" failed to verify"

Y es que no entiendo cómo pueden tener diferentes criterios de validación de firma. En Vizcaya la misma firma es válida, pero no en Guipuzcoa.

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

Empezado por JoseLeeTo

"El mensaje ha sido modificado en tránsito o la firma no está bien realizada

Busca en páginas anteriores, ya ha salido ese mensaje.
En nuestro caso estaba generado:
a) Por una mala codificación del fichero ANSI/UTF8 entre la firma y el envío
b) Por caracteres extraños en el fichero (ÑÁÉ,...)

También me suenan problemas con alguna de las firmas, relacionados con esto que está en la documentación. Revisa que lo tienes correcto:

3. 5. Reglas de uso de algoritmos
Se podrán utilizar cualquiera de los algoritmos basados en RSA admitidos en ETSI TS 119 312 V1.3.1.
Como mínimo se exige:
─ Tamaño de la clave será estrictamente superior a 1024.
─ SHA256 o versiones superiores.

[JoseLeeTo]

Empezado por JoseLeeTo

Hola a todos.

Llevo ya un tiempo con el tema de Batuz, y creía estar volviéndome loco yo solo hasta que he encontrado este foro y he visto que somos muchos así.
Qué locura.

He desarrollado todo el sistema de TBai y de LROE para Vizcaya (ya hice los mismo desde el 2015 para la aplicación BILA), y hasta ahora solamente están disponibles las operaciones con Ingresos y Gastos, Bienes de Inversión y Agrupaciones de Bienes. El resto de epígrafes (Cobros, Pagos, RECC...) no están todavía expuestos)

En Guipuzcoa, estoy teniendo un problema que no se me ha dado en Vizcaya.

El error que me está dando es que no puede validar las referencias URI de la firma:
Básicamente: "El mensaje ha sido modificado en tránsito o la firma no está bien realizada -- Reference URI="#Certificate1" failed to verify. Reference URI="#SignedProperties-1909873269" failed to verify"

Y es que no entiendo cómo pueden tener diferentes criterios de validación de firma. En Vizcaya la misma firma es válida, pero no en Guipuzcoa.

¿A alguien más le ha ocurrido, y puede echarme una mano a qué puede ser debido?

Gracias a todos.
Saludos.

Solucionado.

Trabajo con C#, pero en Delphi entiendo que se puede hacer perfectamente. Efectivamente, tenía que ver con el Charset.

La solución ha sido en añadir en la petición la cabecera : "Content-Type" , "application/xml; charset=utf-8". Por si a alguno le sirve: sería algo así: contenido.Headers.TryAddWithoutValidation("Content-Type" , "application/xml; charset=utf-8";


Espero sirva.
Saludos.

[JoseLeeTo]

Buenos días;

Solamente en Guipuzcoa, estoy obteniendo continuamente el aviso: "010 - Posible Error de Encadenamiento". El caso es que la factura la informa como Recibida, aunque me devuelve dicho aviso. En Vizcaya, de nuevo, no obtengo aviso de error de ningún tipo.
Solo en Guipuzcoa.

He revisado el nodo del encadenamiento de la Factura anterior, y a mi parecer, es correcta. ¿A alguien más le ha pasado, o pudiera ser un error de Guipuzcoa al validar dicho dato?

Si no entendí mal, al igual que en Vizcaya, hay que meter en el nodo <SignatureValueFirmaFacturaAnterior> de la nueva factura, los 100 primeros caracteres de la firma de la factura anteriormente emitida.
Por el resto, informar la Serie, Número de Factura y Fecha de Expedición en el formato que se especifica.

A priori concuerdan los datos que estoy informando en esos nodos, pero quisiera preguntar por si acaso fuese algún error de Guipuzcoa a la hora de validarlos, ya que como digo en Vizcaya no hay problema, o tengo que seguir mirando por si algo se me hubiese escapado.

Muchas gracias.
Un saludo.

[keys]

Empezado por JoseLeeTo

Buenos días;

Solamente en Guipuzcoa, estoy obteniendo continuamente el aviso: "010 - Posible Error de Encadenamiento". El caso es que la factura la informa como Recibida, aunque me devuelve dicho aviso. En Vizcaya, de nuevo, no obtengo aviso de error de ningún tipo.
Solo en Guipuzcoa.

He revisado el nodo del encadenamiento de la Factura anterior, y a mi parecer, es correcta. ¿A alguien más le ha pasado, o pudiera ser un error de Guipuzcoa al validar dicho dato?

Si no entendí mal, al igual que en Vizcaya, hay que meter en el nodo <SignatureValueFirmaFacturaAnterior> de la nueva factura, los 100 primeros caracteres de la firma de la factura anteriormente emitida.
Por el resto, informar la Serie, Número de Factura y Fecha de Expedición en el formato que se especifica.

A priori concuerdan los datos que estoy informando en esos nodos, pero quisiera preguntar por si acaso fuese algún error de Guipuzcoa a la hora de validarlos, ya que como digo en Vizcaya no hay problema, o tengo que seguir mirando por si algo se me hubiese escapado.

Muchas gracias.
Un saludo.

A nosotros no nos esta devolviendo ese error. Te recomiento que si ya lo has revisado bien y crees que es correcto se lo envíes a la hacienda para que te digan que puede ser.

Un Saludo.

[rci]

Empezado por JoseLeeTo

Buenos días;

Solamente en Guipuzcoa, estoy obteniendo continuamente el aviso: "010 - Posible Error de Encadenamiento". El caso es que la factura la informa como Recibida, aunque me devuelve dicho aviso. En Vizcaya, de nuevo, no obtengo aviso de error de ningún tipo.
Solo en Guipuzcoa.

He revisado el nodo del encadenamiento de la Factura anterior, y a mi parecer, es correcta. ¿A alguien más le ha pasado, o pudiera ser un error de Guipuzcoa al validar dicho dato?

Si no entendí mal, al igual que en Vizcaya, hay que meter en el nodo <SignatureValueFirmaFacturaAnterior> de la nueva factura, los 100 primeros caracteres de la firma de la factura anteriormente emitida.
Por el resto, informar la Serie, Número de Factura y Fecha de Expedición en el formato que se especifica.

A priori concuerdan los datos que estoy informando en esos nodos, pero quisiera preguntar por si acaso fuese algún error de Guipuzcoa a la hora de validarlos, ya que como digo en Vizcaya no hay problema, o tengo que seguir mirando por si algo se me hubiese escapado.

Muchas gracias.
Un saludo.

Buenos días, yo creo que Bizkaia no hace esa comprobación del encadenamiento porque a mi tampoco me da el error y en las pruebas que he hecho tendria que hacerlo.
En Gipuzkoa me ha dado alguna vez pero era porque estaba haciendo pruebas y enviaba las facturas en orden incorrecto, aunque los datos de encadenamiento fueran correctos.
Ahora queria volver a probar Gipuzkoa para contestarte pero no puedo enviar, me da el error "Error en el servidor remoto: (503) Servidor no disponible."


Tu JoseLeeTo puedes enviar sin problema a Gipuzkoa ahora mismo (aunque te de el error de encadenamiento)?


Muchas gracias!

[Sistel]

Empezado por keys

Creo que unos días habrá novedades en Bizkaia, y no puedo decir mas.

Hola keys,

Nos dejas en ascuas.
¿No puedes adelantar algo?
En caso contrario, no sé si podré pegar ojo el fín de semana

Opciones:
1- Las Diputaciones Forales informan que todo era una broma (y piden disculpas por si alguien se lo tomó en serio)
2- Los servicios informáticos de las Diputaciones Forales se han hecho el harakiri grupal (FIFO o LIFO).
3- Se pospone un año más la implantación de TicketBAI (y cerveza para todos)

Saludos y buen finde

[keys]

Bueno vale.

Tengo el palpito que en Bizkaia van a retrasar batuz. No TicketBAI, solo el nuevo 140/240.

[espinete]

Empezado por keys

Bueno vale.

Tengo el palpito que en Bizkaia van a retrasar batuz. No TicketBAI, solo el nuevo 140/240.

Me cago en todo... Mira que pensé "no te metas otra vez en el foro, que acabas llorando"...

¿Qué significa eso? Que la parte de generar el TicketBAI, con el código QR, etc. sí llegará a tiempo, pero los envíos del LROE no? ¿O a qué te refieres con el nuevo 140/240?

[keys]

Empezado por espinete

Me cago en todo... Mira que pensé "no te metas otra vez en el foro, que acabas llorando"...

¿Qué significa eso? Que la parte de generar el TicketBAI, con el código QR, etc. sí llegará a tiempo, pero los envíos del LROE no? ¿O a qué te refieres con el nuevo 140/240?

Hola. Quiero decir que puede que se quede como Gipuzkoa de momento, solo envío de ticketbai. El nuevo 140/240(compras, gastos, etc ......) es lo que puede que se retrase.

De todas formas como he dicho es un palpito lo tiene que confirmar hacienda o no.

Un saludo.

[tejano]

De echo, si miras no tienen ejemplos para las facturas recibidas. El otro día les pregunte y me dijeron más o menos que era lo que había ��