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

[ermendalenda]

Empezado por Ramon88

Hay algo que no veo claro, estoy preguntándolo pero no me contestan.


Subes una factura, da Rechazada, ese número de factura, no esta en su sistema, pero tu ya lo has utilizado. En el caso de facturas simplificadas estas deben ser correlativas tambien. No puedes seguir subiendo facturas por que ya da error de encadenamiento.



¿Como actuas en este caso?

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.

[unomasmas]

Empezado por Ramon88

Hay algo que no veo claro, estoy preguntándolo pero no me contestan.

Subes una factura, da Rechazada, ese número de factura, no esta en su sistema, pero tu ya lo has utilizado. En el caso de facturas simplificadas estas deben ser correlativas tambien. No puedes seguir subiendo facturas por que ya da error de encadenamiento.

¿Como actuas en este caso?

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

[keys]

Empezado por Ramon88

Hay algo que no veo claro, estoy preguntándolo pero no me contestan.


Subes una factura, da Rechazada, ese número de factura, no esta en su sistema, pero tu ya lo has utilizado. En el caso de facturas simplificadas estas deben ser correlativas tambien. No puedes seguir subiendo facturas por que ya da error de encadenamiento.



¿Como actuas en este caso?

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

[unomasmas]

Empezado por keys

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

[HerensugeBeltz]

Empezado por Ramon88

Hay algo que no veo claro, estoy preguntándolo pero no me contestan.


Subes una factura, da Rechazada, ese número de factura, no esta en su sistema, pero tu ya lo has utilizado. En el caso de facturas simplificadas estas deben ser correlativas tambien. No puedes seguir subiendo facturas por que ya da error de encadenamiento.



¿Como actuas en este caso?

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.

[misteradrian]

Empezado por Sistel

Hola misteradrian,

Hace tiempo hice una comparativa de precios de Sello de Empresa:.
Sello de empresa Izenpe: 288,55 € - 3 años : 96,18 €/año
Sello de empresa FNMT: 360 €/año

Saludos

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.

[Ramon88]

Empezado por keys

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

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

[dimony]

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í

curl.exe 

--insecure --cert-type P12 --cert C:\tmp\certificado.p12:pass_certificado 

-H "Accept-Encoding:gzip" 

-H "Content-Encoding:gzip" 

-H "Content-Type:application/octet-stream" 

-H "eus-bizkaia-n3-version:1.0" 

-H "eus-bizkaia-n3-content-type:application/xml" 

-H "eus-bizkaia-n3-data:{\"con\":\"LROE\",\"apa\":\"2\",\"inte\":{\"nif\":\"B00000000\",\"nrs\":\"EMPRESA S.L.\"},\"drs\":{\"mode\":\"240\",\"ejer\":\"2021\"}}" 

-v "https://sarrerak.bizkaia.eus/N3B4000M/aurkezpena" 

--data-binary "@c:\tmp\LROE_PJ_240_FacturasRecibidasConSG_B0000000_20211022071352.gz" 

--output C:\tmp\respuesta.gz

pero me encuentro con el siguiente error

 upload completely sent off: 840 out of 840 bytes
* schannel: client wants to read 102400 bytes
* schannel: encdata_buffer resized 103424
* schannel: encrypted data buffer: offset 0 length 103424
* schannel: encrypted data got 964
* schannel: encrypted data buffer: offset 964 length 103424
* schannel: decrypted data length: 935
* schannel: decrypted data added: 935
* schannel: decrypted data cached: offset 935 length 102400
* schannel: encrypted data buffer: offset 0 length 103424
* schannel: decrypted data buffer: offset 935 length 102400
* schannel: schannel_recv cleanup
* schannel: decrypted data returned 935
* schannel: decrypted data buffer: offset 0 length 102400
< HTTP/1.1 200 OK
< Date: Fri, 22 Oct 2021 07:59:35 GMT
< Server: JBoss-EAP/7
< Content-Encoding: gzip
< eus-bizkaia-n3-identificativo: 7548212
< X-Powered-By: Undertow/1
< eus-bizkaia-n3-codigo-respuesta:
< eus-bizkaia-n3-numero-registro:
< eus-bizkaia-n3-tipo-respuesta: Correcto
< Content-Type: application/xml;charset=UTF-8
< Content-Length: 592
<
Warning: Binary output can mess up your terminal. Use "--output -" to tell
Warning: curl to output it to your terminal anyway, or consider "--output
Warning: <FILE>" to save to a file.
* Failed writing body (0 != 592)
* Closing connection 0
* schannel: shutting down SSL/TLS connection with sarrerak.bizkaia.eus port 443
* schannel: clear security context handle
* Rebuilt URL to: C:\tmp\respuesta.gz/
* Port number ended with '\'
* Closing connection -1

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.

[Ramon88]

Empezado por HerensugeBeltz

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.

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

[rci]

Empezado por Ramon88

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


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

[HerensugeBeltz]

Empezado por Ramon88

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.

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.

[dimony]

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

Empezado por dimony

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í

curl.exe 

--insecure --cert-type P12 --cert C:\tmp\certificado.p12:pass_certificado 

-H "Accept-Encoding:gzip" 

-H "Content-Encoding:gzip" 

-H "Content-Type:application/octet-stream" 

-H "eus-bizkaia-n3-version:1.0" 

-H "eus-bizkaia-n3-content-type:application/xml" 

-H "eus-bizkaia-n3-data:{\"con\":\"LROE\",\"apa\":\"2\",\"inte\":{\"nif\":\"B00000000\",\"nrs\":\"EMPRESA S.L.\"},\"drs\":{\"mode\":\"240\",\"ejer\":\"2021\"}}" 

-v "https://sarrerak.bizkaia.eus/N3B4000M/aurkezpena" 

--data-binary "@c:\tmp\LROE_PJ_240_FacturasRecibidasConSG_B0000000_20211022071352.gz" 

--output C:\tmp\respuesta.gz

pero me encuentro con el siguiente error

 upload completely sent off: 840 out of 840 bytes
* schannel: client wants to read 102400 bytes
* schannel: encdata_buffer resized 103424
* schannel: encrypted data buffer: offset 0 length 103424
* schannel: encrypted data got 964
* schannel: encrypted data buffer: offset 964 length 103424
* schannel: decrypted data length: 935
* schannel: decrypted data added: 935
* schannel: decrypted data cached: offset 935 length 102400
* schannel: encrypted data buffer: offset 0 length 103424
* schannel: decrypted data buffer: offset 935 length 102400
* schannel: schannel_recv cleanup
* schannel: decrypted data returned 935
* schannel: decrypted data buffer: offset 0 length 102400
< HTTP/1.1 200 OK
< Date: Fri, 22 Oct 2021 07:59:35 GMT
< Server: JBoss-EAP/7
< Content-Encoding: gzip
< eus-bizkaia-n3-identificativo: 7548212
< X-Powered-By: Undertow/1
< eus-bizkaia-n3-codigo-respuesta:
< eus-bizkaia-n3-numero-registro:
< eus-bizkaia-n3-tipo-respuesta: Correcto
< Content-Type: application/xml;charset=UTF-8
< Content-Length: 592
<
Warning: Binary output can mess up your terminal. Use "--output -" to tell
Warning: curl to output it to your terminal anyway, or consider "--output
Warning: <FILE>" to save to a file.
* Failed writing body (0 != 592)
* Closing connection 0
* schannel: shutting down SSL/TLS connection with sarrerak.bizkaia.eus port 443
* schannel: clear security context handle
* Rebuilt URL to: C:\tmp\respuesta.gz/
* Port number ended with '\'
* Closing connection -1

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.

[Ramon88]

Esto me dicen:

  Egun on, Buenos días
  
  Para cuando se producen rechazos por parte del servicio de recepción de TicketBAI se va a disponer de un servicio para subsanar el envío siguiendo los siguientes pasos:
  
Corregir el problema que ha producido el      rechazo
Enviar el nuevo XML corregido SIN FIRMAR al      servicio de subsanación de TicketBAI “Zuzendu”

  El rechazo de ficheros ha de ser algo muy excepcional ya que las validaciones que lo provocan son mínimas y muy básicas. Las facturas rechazadas y posteriormente subsanadas se registran en la BD con una marca especial para su posterior análisis.
  
  Siempre recomendamos a las empresas de desarrollo que antes de proceder a realizar el envío a TicketBAI el propio software haga unas comprobaciones mínimas en el XML para garantizar que no se producirá rechazo del mismo:
Validar el XML frente al esquema XSD. Esta      validación evitará la mayor parte de los problemas de rechazo
Asegurarse de que se informan los datos      básicos: número de factura, fecha de expedición, indicar una línea de      detalle como mínimo e indicar factura rectificada en rectificativa.
Comprobar que el certificado de envío es      válido y su identidad está relacionada con el emisor.
  Por lo que si la factura rechazada es correcta, únicamente habría que corregir el fichero XML a través de servicio “Zuzendu”.
  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.

[thinkows]

Empezado por Ramon88

Esto me dicen:

  Egun on, Buenos días
  
  Para cuando se producen rechazos por parte del servicio de recepción de TicketBAI se va a disponer de un servicio para subsanar el envío siguiendo los siguientes pasos:
  
Corregir el problema que ha producido el      rechazo
Enviar el nuevo XML corregido SIN FIRMAR al      servicio de subsanación de TicketBAI “Zuzendu”
  El rechazo de ficheros ha de ser algo muy excepcional ya que las validaciones que lo provocan son mínimas y muy básicas. Las facturas rechazadas y posteriormente subsanadas se registran en la BD con una marca especial para su posterior análisis.
  
  Siempre recomendamos a las empresas de desarrollo que antes de proceder a realizar el envío a TicketBAI el propio software haga unas comprobaciones mínimas en el XML para garantizar que no se producirá rechazo del mismo:
Validar el XML frente al esquema XSD. Esta      validación evitará la mayor parte de los problemas de rechazo
Asegurarse de que se informan los datos      básicos: número de factura, fecha de expedición, indicar una línea de      detalle como mínimo e indicar factura rectificada en rectificativa.
Comprobar que el certificado de envío es      válido y su identidad está relacionada con el emisor.
  Por lo que si la factura rechazada es correcta, únicamente habría que corregir el fichero XML a través de servicio “Zuzendu”.
  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.

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

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

[rci]

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:

En una factura de ese tipo (que viene regulada en el artículo 7.2 y 7.3 del Reglamento de Facturación), si el destinatario es no nacional se deberán utilizar los tipos de identificación establecidos en el Anexo I

El desglose será a nivel de operación, puesto que está así designado para cuando el destinatario es un “no nacional”. No hay incompatibilidad alguna por el hecho de ser simplificada.

De Bizkaia me contestaron:

Si la factura es simplificada, no se permite el desglose por operación, aunque se identifique un destinario extranjero con un identificador diferente al NIF.

De Gipuzkoa no me han contestado y pregunté hace un mes... Deben estar muy ocupados


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


Muchas gracias


Saludos

[rci]

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


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:

Para la generación del CRC hay que tener en cuenta la “/” pero eso no tiene que ver con la URL para poder acceder a la consulta de QR. La URL como indicáis os funcionará de ambas maneras siempre y cuando el CRC se haya generado antes del URL encoding.

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?



Muchas gracias y disculpad por tantas preguntas


Saludos

[ermendalenda]

Empezado por Ramon88

Esto me dicen:

  
  
  El rechazo de ficheros ha de ser algo muy excepcional ya que las validaciones que lo provocan son mínimas y muy básicas. Las facturas rechazadas y posteriormente subsanadas se registran en la BD con una marca especial para su posterior análisis.

Muy excepcional, eso quisieran y quisieramos.

Empezado por Ramon88

Esto me dicen:

Validar el XML frente al esquema XSD. Esta      validación evitará la mayor parte de los problemas de rechazo

Eso es una putada de hilera de grabación.

Empezado por Ramon88

Esto me dicen:

Asegurarse de que se informan los datos      básicos: número de factura, fecha de expedición, indicar una línea de      detalle como mínimo e indicar factura rectificada en rectificativa.

En ello estamos cuando programamos,

Empezado por Ramon88

Esto me dicen:

Comprobar que el certificado de envío es      válido y su identidad está relacionada con el emisor.

Esto menos mal que me lo he hecho.

Empezado por Ramon88

Esto me dicen:

 Por lo que si la factura rechazada es correcta, únicamente habría que corregir el fichero XML a través de servicio “Zuzendu”.

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

Empezado por Ramon88

Esto me dicen:

  
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.

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

[rci]

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


¿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!

[unomasmas]

Empezado por rci

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

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

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.

[unomasmas]

Empezado por ermendalenda

Comprobar que el certificado de envío es válido y su identidad está relacionada con el emisor.
Esto menos mal que me lo he hecho.

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