Correcto, gran problema. O dejan un margen de fallos y se fuerza manualmente la siguiente o vamos a tener muchas incidencias y vamos a necesitar una línea 24h 365 días a la semana.

Así es como lo entiendo yo: El rechazo puede ser por varios motivos. A grandes rasgos:

1) Error del certificado usado para la conexión. Códigos 1 y 7 de Gipuzkoa. Solución: Cambiar el certificado e intentar subir nuevamente el mismo fichero de alta Ticket-BAI.
2) Error por problemas en el propio fichero Ticket-BAI (Rechazado para subsanar). Son los códigos de error 2, 3, 4 y 17 de Gipuzkoa. En Gipuzkoa se usará el servicio Zuzendu (cuando nos lo abran) para subsanarlos. En Álava supongo que sea similar. En Bizkaia, creo que habría que enviar la factura nuevamente con las oportunas correcciones en el modelo sin software garante.
3) Los otros códigos de rechazo que quedan de Gipuzkoa (5: Factura ya registrada y 6: Servicio no disponible) se explican por sí mismos.
4) Los errores de validación de negocio: En Gipuzkoa se solventarán enviando un fichero de modificación a Zuzendu o haciendo una factura rectificativa, según cada caso. En Araba supongo que igual. En Bizkaia, sigo entendiendo que lo que en Gipuzkoa se hace a través de Zuzendu, aquí será con la emisión de la factura siguiendo las especificaciones para software no garante...

Si da rechazada tienes que corregirla y volverla a enviar. Ya que la factura la has emitido. A parte tu sistema debería controlar para que no de rechazada nunca ;).

Por cierto mas noticias.

https://www.diariovasco.com/economia...192954-nt.html
https://www.gipuzkoa.eus/es/-/sei-hi...epea-gipuzkoak

Era esperable, pero nos han hecho sudar. Me gustaría saber, eso sí, qué habra pesado más en la decisión: La fragilidad del sistema o la bronca de la ciudadanía ante la inminente puesta en marcha sin poder hacer pruebas adecuadamente...

FAQ de una Hacienda Foral:
8.9 ¿Qué hay que hacer si la anotación del fichero TicketBai ha sido rechazada
al enviarse a Hacienda?

Si la anotación del fichero TicketBAI ha sido rechazada al enviarse a Hacienda por incumplimiento de esquema o de validaciones, debe operarse del siguiente modo:

En todo caso, la información de la operación debe remitirse, superando las correspondientes validaciones. Si hay información que no puede llegar por incumplimiento de las validaciones, debe llegar la información más relevante.

Si hay que modificar alguno de los contenidos de la factura a que se refiere el artículo 15 del Reglamento de facturación: Se deberá generar además una factura rectificativa, generando el fichero TicketBAI correspondiente y remitiendo la información.

Cuando se trate de una operación incorrecta (casos excluidos de poder emitir una factura rectificativa) deberá realizarse además una anulación de la operación original y, si procede, deberá generarse una nueva factura, generando un fichero TicketBAI.

Hola Sistel,
he estado preguntando a varias empresas y
muchas me ofrecen lo mismo por 100 € el año.
Aunque claro no sabemos si esos certificados funcionan para este tema de TicketBAI, a pesar de tener la misma extensión.

Pero tienes razón la más barata sigue siendo Izenpe.
Un saludo y gracias por la info.

Sisi, eso de que tu sistema debe de controlar que nunca de rechazada es muy bonito. Pero hay muchas maneras de que un cliente final pueda ''liarla''.

Fallo salida en Curl
 

Hola buenos dias,haber si alguien me puede echar un cable a cerca del envio del LROE.


Resulta que realizo el envio de los ficheros comprimidos con cURL, algo tal que así
pero me encuentro con el siguiente error

el envio del fichero llega a realizarse, al menos lo veo en el portal de batuz, pero no logro que los resultados se me lleven al fichero comprimido que le indico, de tal manera que no tengo manera de comprobar que se ha enviado correctamente y que no.


Algún alma caritativa sabria indicarme que hago mal.

No entiendo muy bien, cuando da rechazada, su sistema no guarda el fichero, por lo que no puedes anular esa factura por que en su sistema no existe.


Resumiendo:
Cuando de rechazada paralizamos la subida de facturas, hasta que nos llame el cliente para ver que coj... ha pasado, solucionarlo, subirla de nuevo manualmente, subir las demas facturas que hayan realizado mientras teniamos una rechazada y ya seguir con la marcha habitual...

INCREIBLE pero cierto! Al cliente final le va a suponer un aumento de 150€ decían? serán mensuales...

Yo creo que aunque una se rechace, puedes y debes seguir facturando, seguir generando ficheros TBAI y seguir enviando las siguientes. La primera dará "posible error de encadenamiento" porque todavía no habrán recibido la anterior.
Pero cuando puedas enviar la que se ha rechazado, con zuzendu (subsanar o modificar) para Araba y Gipuzkoa, o vía la opción... sin software garante... de bizkaia, ese "posible" error de encadenamiento ya no será real porque ya estará enviada la que se rechazo, por lo tanto entiendo y espero que esto no sea un problema de inspecciones para el obligado tributario.


El tema está en cuando salga zuzendu... como lo podremos hacer, porque yo no acabo de imaginarme como corregiremos cada caso de rechazo... coger el xml original rechazado y corregir el xml "a mano" para cada caso :eek:


Como muy bien ha dicho Keys, la clave seria que no se produjeran rechazos que requieran modificación del xml y posterior envío por la otra vía (sin firmar)


Nosotros queremos coger las validaciones de negocio publicadas en cada diputación foral y antes de salvar la venta y por lo tanto antes de crear el fichero ticketBAI, pasar nosotros esas validaciones y si no se cumplen informar al usuario que lo corrija en la venta, porque si no se corrige será una factura rechazada.
Esa es la idea pero .... es complicado :(


Corregidme por favor si me equivoco en algún punto.



Muchas gracias

Yo lo que interpreto es que la factura rechazada sí queda registrada en el sistema, pendiente de corrección, de forma que la siguiente factura que envíes, en mi opinión, debería apuntar a la rechazada como factura anterior. Por eso esperan que:
- Corrijas esa factura original
- Una vez corregida, la anules o emitas otra rectificativa, según el caso.

Solucionado
 

Ya esta resuelto el problema :).
Resulta que "--output" lo he sustituido por ">" y ha funcionado a la perfección.

Esto me dicen:

O sea, si lo he entendido bien, aparate del Zuzendu está por publicar otro procedimiento ?

"En el caso de que la factura no fuese correcta con un error material en la misma, el procedimiento para dicho caso está todavía por publicar." :D:D

De ahí el aplazamiento .... nos vamos a extinguir pronto :cool::cool:

Factura simplificada cualificada y destinatario no nacional => TipoDesglose?
 

Hola, si tenemos una factura simplificada cualificada (con los datos del destinatario) y el destinatario no es nacional, como informais el desglose? a nivel de operación o de factura?

Yo pienso que el desglose tiene que ser a nivel de operación porque el destinatario no es nacional, si lo hago de esta forma Araba y Gipuzkoa lo aceptan sin errores pero Bizkaia da el siguiente error:
B4_2000027
TipoDesglose: La factura contiene un Tipo de desglose incorrecto. Ha de ser a nivel de operación cuando sea una factura completa y el destinatario sea extranjero (IDOtro o NIF que empiece por N). En cualquier otro caso, el desglose ha de ser a nivel de factura.

Parece ser que hay alguna incompatibilidad entre factura simplificada y desglose por tipo de operación para Batuz.

Envié un correo a las tres agencias preguntando y de Araba me contestaron:
De Bizkaia me contestaron:
De Gipuzkoa no me han contestado y pregunté hace un mes... Deben estar muy ocupados :rolleyes:


En fin, ¿tengo que hacer otra particularidad dependiendo de la diputación foral?


Muchas gracias


Saludos

QR -> URL encoding y CRC
 

Hola, he estado haciendo pruebas al generar la ruta para el QR y al final creo que Araba funciona de una forma y Bizkaia y Gipuzkoa de otra.


Estaba haciendo pruebas de QR para Araba y en un caso me contestó lo de "parámetros incorrectos". El identificador TBAI de esa factura tiene una barra /
En mi proceso para generar el QR hacia URL encoding de los valores para construir la URL y después generaba el CRC.

Para Bizkaia y Gipuzkoa esto es correcto y funciona. Pero para Araba no, pregunté y me contestaron que el CRC lo tengo que calcular antes del URL encoding.
Si lo hago de esta forma ya funciona pero claro... preferiria hacerlo siempre igual :o


Probando probando también vi que si no hago URL encoding en ningún momento, y no sustituyo la barra por %2F también funciona y funciona haciendo lo mismo para las tres diputaciones, lo cual me gusta, pero claro, en la documentación dice que tenemos que hacer el encoding y supongo que habrá algún otro carácter que no sea aceptado en una URL y falle si no lo recodifico.


Volví a preguntar a Araba y me contestaron:


Vosotros estais filtrando los valores que pasamos como parámetros en la URL del QR o no? Antes y después de generar el QR dependiendo de la diputación?:p



Muchas gracias y disculpad por tantas preguntas


Saludos

Muy excepcional, eso quisieran y quisieramos.

Eso es una putada de hilera de grabación.


En ello estamos cuando programamos,



Esto menos mal que me lo he hecho.



Únicamente creo que no es la palabra correcta, eso se usa para cuando hay que hacer algo rápido y sencillo.



Ah, sin prisa, estaremos pendientes, no tenemos nada que hacer

Acceder a los datos del certificado del emisor
 

Buenas tardes, estamos intentando hacer las máximas validaciones previas posibles antes de generar la factura y habíamos pensado en comparar los datos del certificado digital con los datos que proporciona el usuario sobre el obligado tributario. Así comprobar que los datos del emisor de la factura coinciden con el certificado digital que utilizamos tanto para firmar como para enviar. Básicamente comprobar que el NIF y la razón social coinciden.
Pero los datos que hay dentro del certificado no los estamos obteniendo de forma clara... no vemos un campo donde haya el NIF y otro con la razón social... hay varias propiedades de texto con múltiples datos dentro...
A parte es diferente para cada certificado, si es de persona física, si es de representante .... :confused:


¿Vosotros hacéis esta comprobación?
¿Alguien sabe cómo obtener el NIF y la razón social de forma clara de dentro de un certificado?

Utilizamos C#, ya tenemos el certificado en un objeto de tipo X509Certificate2

Muchas gracias y buen fin de semana!

Tendrá que ser así porque hoy me han dicho en Araba hablando de los ficheros XSD de que disponemos para la validación previa (ticketBaiV1-2.xsd) que "básicamente son validaciones de estructura y formato. Las validaciones funcionales las vais a tener que implementar vosotros". Por validaciones funcionales se refiere a las validaciones que generan un error de negocio...

Sobre el servicio Zuzendu, se tratará de enviar un fichero XML (creo recordar que sin necesidad de firma) con las correcciones (subsanaciones o modificaciones) que haya que hacer.

¿Cómo lo has hecho? ¿Podemos tener los pasos que has dado (o directamente el código)? Gracias