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

[Sistel]

Empezado por Irreo

Buenas,

Gracias por la aclaración.

Acabo de mirar la documentación y en efecto veo que una factura marcada como "Simplificada" puede llevar datos de destinatario.

De todas formas, ¿esto es relativamente nuevo? No tengo recuerdo de haber leído nada sobre facturas "cualificadas" cuando estuve desarrollando esto en su momento...

Lo cierto que ahora mismo no me preocupa porque el desarrollo lo hice personalizado para la empresa para la que trabajo y con nuestras necesidades. El planteamiento que tengo es que en el momento que se rellenan datos de cliente, pasa a ser factura completa y listo, y el resto son "tickets".

Saludos.

Hola,

Creo que lo de "facturas simplificadas cualificadas" fue una denominación que empezó a utilizar la Agencia Tributaria a raiz del SII (no recuerdo haberlo leído antes). No es nada específico de TicketBAI.
Puedes verlo en los puntos 2.49 y 3.23 de las Preguntas Frecuentes sobre el SII

Ten en cuenta que si todas las facturas que emites son de un importe inferior a 3.000€ puedes emitirlas todas como facturas simplificadas (lo que tú aún llamas con su antigua denominación de "tickets") independientemente de que tengan o no datos del destinatario. Y así te ahorras tener 2 tipos y series diferentes de facturas.

Saludos

[MaeseKvothe]

¿A alguien le está dando problemas Bizkaia hoy?
De pronto lo que estaba funcionando ahora me da el error "The remote certificate is invalid because of errors in the certificate chain: PartialChain"

[albertolp]

En el entorno de pruebas de Bizcaya me sale esto, el día 13/06/23 se envío correctamente sin ningún cambio.

The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.

[edari]

Empezado por MaeseKvothe

¿A alguien le está dando problemas Bizkaia hoy?
De pronto lo que estaba funcionando ahora me da el error "The remote certificate is invalid because of errors in the certificate chain: PartialChain"

A entorno de pruebas, que es lo único que puedo probar me sube correctamente.


Si subes tú a pruebas ahora y te sube también mal revisa a ver si ves algo del certificado de marras

[albertolp]

Empezado por albertolp

En el entorno de pruebas de Bizcaya me sale esto, el día 13/06/23 se envío correctamente sin ningún cambio.

The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.

Nombre común (CN) pruesarrerak.bizkaia.eus
Organización (O) BIZKAIKO FORU ALDUNDIA / DIPUTACION FORAL DE BIZKAIA
Unidad organizativa (OU) <No incluido en el certificado>
Nombre común (CN) EAEko Herri Administrazioen CA - CA AAPP Vascas (2)
Organización (O) IZENPE S.A.
Unidad organizativa (OU) AZZ Ziurtagiri publikoa - Certificado publico SCA

Emitido el miércoles, 14 de junio de 2023, 13:32:54
Vencimiento el sábado, 13 de julio de 2024, 13:32:54

Desde el navegador veo esto, desde el 14/06/2023 hicieron un cambio de certificado. Que coincide con el envío correcto del 13 y hoy da el error.

[MaeseKvothe]

Empezado por edari

A entorno de pruebas, que es lo único que puedo probar me sube correctamente.


Si subes tú a pruebas ahora y te sube también mal revisa a ver si ves algo del certificado de marras

Yo estoy con el entorno de pruebas y no hay manera. Me da error todo, consultas, envíos, etc.
No sé ni por donde tirar, porque con ese mensaje entiendo que el error en certificado es de ellos, no mío.

[Sistel]

Hola,

El pasado sábado 24 de junio, todos los XML de TicketBAI enviados a Hacienda Foral de Álava entre las 12:31 y las 16:21h me dieron errores.
Me afectó a 105 facturas con código de respuesta 008 (AVISO: Error en verificación de firma) y a 94 facturas con código 998 (Certificado válido únicamente en caché caducada)

Hoy he hablado con TicketBAI de Álava.
Parece que el culpable, una vez más, ha sido el sistema de verificación de certificados y firmas que usan de IZENPE.
(Peor servicio que el de IZENPE es difícil de encontrar)

De las 94 facturas con código 998 me han dicho que sin problemas, las dan como buenas.
Las 105 facturas con código 008 he tenido que enviarlas, de nuevo, a través del servicio ZUZENDU.

¡¡ Gracias IZENPE por evitar que nos aburramos !!

Saludos.

[Sanduzelai]

Buenos días,
voy a meterme a desarrollar el tema del envío a la hacienda de Bizkaia para los casos en los que "no todo haya ido bien".
Estoy leyendo la documentación de la web de Batuz y en Preguntas frecuentes pone:

En el caso de Bizkaia, siempre que no se trate de un supuesto en que sea necesario anular la factura o rectificarla, la operativa deberá ser la siguiente: teniendo en cuenta que el fichero TicketBAI no puede volver a generarse y que debe remitirse su información, esta remisión deberá realizarse con el mensaje web correspondiente a los subcapítulos “Ingresos con facturas emitidas sin Software garante” (para las personas físicas) y “Facturas emitidas sin Software garante” (para las personas jurídicas).

¿Cuáles son esos supuestos en los que hay que mandar una rectificativa o una de anulación?

[MaeseKvothe]

Empezado por Sanduzelai

Buenos días,
voy a meterme a desarrollar el tema del envío a la hacienda de Bizkaia para los casos en los que "no todo haya ido bien".
Estoy leyendo la documentación de la web de Batuz y en Preguntas frecuentes pone:


¿Cuáles son esos supuestos en los que hay que mandar una rectificativa o una de anulación?

Anulación es para cuando se ha emitido la factura por error. Es decir, nunca ha llegado a ser una factura válida. La mayoría de sistemas ni contemplan esta posibilidad.
La rectificativa es para modificar o cancelar una factura. Por ejemplo porque no le habías aplicado un descuento y recibes la queja/aviso o porque te quiere cancelar parte o toda la factura (te devuelve elementos o desestima servicios).
Ninguno de esos temas viene impuesto por la validación del TBAI ni el LROE, son procedimientos financieros estándar.

[Sanduzelai]

Gracias por la aclaración

[Sanduzelai]

Hola,
me surge otra cuestión.
Me comentan desde Batuz lo siguiente respecto a la corrección de errores:

Cuando una factura expedida mediante el sistema TicketBAI es rechazada en el subcapítulo 1.1 - Facturas emitidas con software garante, la información de la operación se tendrá que enviar por el subcapítulo 1.2 – Facturas emitidas sin software garante, superando las validaciones. Es decir, en el subcapítulo 1.2 se tendrán que corregir los errores que han provocado que la factura no se pueda anotar en el subcapítulo 1.1 (por ejemplo, si el NIF del destinatario no cumple el algoritmo del NIF). De este modo la operación que no se ha podido registrar mediante el subcapítulo 1.1 quedaría anotada en el LROE y presentada en Hacienda. Si el error no es de la numeración o la serie de la factura, la factura se informará en el subcapítulo 1.2 con la misma numeración y serie con la que se haya expedido.

En este caso, ¿esta factura corregida tendría encadenamiento?

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

Empezado por Sanduzelai

En este caso, ¿esta factura corregida tendría encadenamiento?

Las facturas enviadas SinSG (capítulo 1.2) son co un formato diferente y no llevan encadenamiento.
Te adjunto un fichero enviado de esta forma:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<lrpjfessgamp:LROEPJ240FacturasEmitidasSinSGAltaModifPeticion xmlns:lrpjfessgamp="https://www.batuz.eus/fitxategiak/batuz/LROE/esquemas/LROE_PJ_240_1_2_FacturasEmitidas_SinSG_AltaModifPeticion_V1_0_1.xsd">
  <Cabecera>
    <Modelo>240</Modelo>
    <Capitulo>1</Capitulo>
    <Subcapitulo>1.2</Subcapitulo>
    <Operacion>A00</Operacion>
    <Version>1.0</Version>
    <Ejercicio>2023</Ejercicio>
    <ObligadoTributario>
      <NIF>S0950331I</NIF>
      <ApellidosNombreRazonSocial>Empresa T3</ApellidosNombreRazonSocial>
    </ObligadoTributario>
  </Cabecera>
  <FacturasEmitidas>
    <FacturaEmitida>
      <Destinatarios>
        <IDDestinatario>
          <NIF>S7292711D</NIF>
          <ApellidosNombreRazonSocial>CASA JUAN</ApellidosNombreRazonSocial>
          <CodigoPostal>08009</CodigoPostal>
        </IDDestinatario>
      </Destinatarios>
      <VariosDestinatarios>N</VariosDestinatarios>
      <EmitidaPorTercerosODestinatario>N</EmitidaPorTercerosODestinatario>
      <CabeceraFactura>
        <SerieFactura></SerieFactura>
        <NumFactura>1</NumFactura>
        <FechaExpedicionFactura>28-06-2023</FechaExpedicionFactura>
        <FacturaSimplificada>N</FacturaSimplificada>
        <FacturaEmitidaSustitucionSimplificada>N</FacturaEmitidaSustitucionSimplificada>
      </CabeceraFactura>
      <DatosFactura>
        <DescripcionFactura>art 0</DescripcionFactura>
        <ImporteTotalFactura>3630.00</ImporteTotalFactura>
        <Claves>
          <IDClave>
            <ClaveRegimenIvaOpTrascendencia>01</ClaveRegimenIvaOpTrascendencia>
          </IDClave>
        </Claves>
      </DatosFactura>
      <TipoDesglose>
        <DesgloseFactura>
          <Sujeta>
            <NoExenta>
              <DetalleNoExenta>
                <TipoNoExenta>S1</TipoNoExenta>
                <DesgloseIVA>
                  <DetalleIVA>
                    <BaseImponible>3000.00</BaseImponible>
                    <TipoImpositivo>21.00</TipoImpositivo>
                    <CuotaImpuesto>630.00</CuotaImpuesto>
                    <TipoRecargoEquivalencia>0.00</TipoRecargoEquivalencia>
                    <CuotaRecargoEquivalencia>0.00</CuotaRecargoEquivalencia>
                    <OperacionEnRecargoDeEquivalenciaORegimenSimplificado>N</OperacionEnRecargoDeEquivalenciaORegimenSimplificado>
                  </DetalleIVA>
                </DesgloseIVA>
              </DetalleNoExenta>
            </NoExenta>
          </Sujeta>
        </DesgloseFactura>
      </TipoDesglose>
    </FacturaEmitida>
  </FacturasEmitidas>
</lrpjfessgamp:LROEPJ240FacturasEmitidasSinSGAltaModifPeticion>

[Sanduzelai]

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

Las facturas enviadas SinSG (capítulo 1.2) son co un formato diferente y no llevan encadenamiento.
Te adjunto un fichero enviado de esta forma:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<lrpjfessgamp:LROEPJ240FacturasEmitidasSinSGAltaModifPeticion xmlns:lrpjfessgamp="https://www.batuz.eus/fitxategiak/batuz/LROE/esquemas/LROE_PJ_240_1_2_FacturasEmitidas_SinSG_AltaModifPeticion_V1_0_1.xsd">
  <Cabecera>
    <Modelo>240</Modelo>
    <Capitulo>1</Capitulo>
    <Subcapitulo>1.2</Subcapitulo>
    <Operacion>A00</Operacion>
    <Version>1.0</Version>
    <Ejercicio>2023</Ejercicio>
    <ObligadoTributario>
      <NIF>S0950331I</NIF>
      <ApellidosNombreRazonSocial>Empresa T3</ApellidosNombreRazonSocial>
    </ObligadoTributario>
  </Cabecera>
  <FacturasEmitidas>
    <FacturaEmitida>
      <Destinatarios>
        <IDDestinatario>
          <NIF>S7292711D</NIF>
          <ApellidosNombreRazonSocial>CASA JUAN</ApellidosNombreRazonSocial>
          <CodigoPostal>08009</CodigoPostal>
        </IDDestinatario>
      </Destinatarios>
      <VariosDestinatarios>N</VariosDestinatarios>
      <EmitidaPorTercerosODestinatario>N</EmitidaPorTercerosODestinatario>
      <CabeceraFactura>
        <SerieFactura></SerieFactura>
        <NumFactura>1</NumFactura>
        <FechaExpedicionFactura>28-06-2023</FechaExpedicionFactura>
        <FacturaSimplificada>N</FacturaSimplificada>
        <FacturaEmitidaSustitucionSimplificada>N</FacturaEmitidaSustitucionSimplificada>
      </CabeceraFactura>
      <DatosFactura>
        <DescripcionFactura>art 0</DescripcionFactura>
        <ImporteTotalFactura>3630.00</ImporteTotalFactura>
        <Claves>
          <IDClave>
            <ClaveRegimenIvaOpTrascendencia>01</ClaveRegimenIvaOpTrascendencia>
          </IDClave>
        </Claves>
      </DatosFactura>
      <TipoDesglose>
        <DesgloseFactura>
          <Sujeta>
            <NoExenta>
              <DetalleNoExenta>
                <TipoNoExenta>S1</TipoNoExenta>
                <DesgloseIVA>
                  <DetalleIVA>
                    <BaseImponible>3000.00</BaseImponible>
                    <TipoImpositivo>21.00</TipoImpositivo>
                    <CuotaImpuesto>630.00</CuotaImpuesto>
                    <TipoRecargoEquivalencia>0.00</TipoRecargoEquivalencia>
                    <CuotaRecargoEquivalencia>0.00</CuotaRecargoEquivalencia>
                    <OperacionEnRecargoDeEquivalenciaORegimenSimplificado>N</OperacionEnRecargoDeEquivalenciaORegimenSimplificado>
                  </DetalleIVA>
                </DesgloseIVA>
              </DetalleNoExenta>
            </NoExenta>
          </Sujeta>
        </DesgloseFactura>
      </TipoDesglose>
    </FacturaEmitida>
  </FacturasEmitidas>
</lrpjfessgamp:LROEPJ240FacturasEmitidasSinSGAltaModifPeticion>

Genial! Gracias por la ayuda

[edejuan]

Buenos días,


Para la creación del LROE 140 (Bizkaia), como habéis enfocado el tema de la recuperación del epígrafe ?, sobre todo por si tiene más de uno.


- Un campo en el registro de la serie de facturación ? y que facture escogiendo la serie según el epígrafe que necesite asociar a esa factura.
- En la pantalla de facturación, que pueda elegir a que epígrafe se asocia la factura ?


Gracias.

[xamminf]

Empezado por MaeseKvothe

Anulación es para cuando se ha emitido la factura por error. Es decir, nunca ha llegado a ser una factura válida.

Yo lo veo de otra forma:
Si haces una factura y resulta que recien hecha, Y SIN ENVIAR AUN, te das cuenta que está mal porque metiste un articulo de más, lo que haces es anularla así al cliente sólo le llegará una factura y no dos (factura más rectificativa), porque realmente queda muy mal que al cliente le lleguen dos facturas porque las tendrá que mecanizar y subir al SII, cuando él simplemente pidió una mercancía que debería dar lugar a un unico documento

https://www.gipuzkoa.eus/es/web/ogas...ema-ticketbai-


Ya mi duda, y que expuse en hilos anteriores es saber cómo tratar las anuladas en el programa. Entiendo que habria que afectar a todos los query porque se deberian excluir y ademas posibilitar con parametros consultus donde SI poder incluirlas. Hay quien propuso otras formas

[Sanduzelai]

Hola,
un cliente me ha comentado que está en regimen por recargo de equivalencia en lugar de regimen general que es el que tengo desarrollado.
He visto la documentación y veo que tengo que cambiar algunos tags y añadir otros para este caso.
No me queda claro como hay que calcular el tag CuotaRecargoDeEquivalencia.
En este ejemplo de factura, ¿como habría que hacer?

Código PHP:

<DetallesFactura>
        <IDDetalleFactura>
          <DescripcionDetalle>Pipas Facundo</DescripcionDetalle>
          <Cantidad>1</Cantidad>
          <ImporteUnitario>0.63636364</ImporteUnitario>
          <ImporteTotal>0.70</ImporteTotal>
        </IDDetalleFactura>
      </DetallesFactura>
      <ImporteTotalFactura>0.70</ImporteTotalFactura>
      <Claves>
        <IDClave>
          <ClaveRegimenIvaOpTrascendencia>51</ClaveRegimenIvaOpTrascendencia>
        </IDClave>
      </Claves>
    </DatosFactura>
    <TipoDesglose>
      <DesgloseFactura>
        <Sujeta>
          <NoExenta>
            <DetalleNoExenta>
              <TipoNoExenta>S1</TipoNoExenta>
              <DesgloseIVA>
                <DetalleIVA>
                  <BaseImponible>0.64</BaseImponible>
                  <TipoImpositivo>10</TipoImpositivo>
                  <CuotaImpuesto>0.06</CuotaImpuesto>
                 <TipoRecargoEquivalencia>1.4</TipoRecargoEquivalencia>
                 <CuotaRecargoEquivalencia>?</CuotaRecargoEquivalencia>
                  <OperacionEnRecargoDeEquivalenciaORegimenSimplificado>S</OperacionEnRecargoDeEquivalenciaORegimenSimplificado>
                </DetalleIVA>
              </DesgloseIVA>
            </DetalleNoExenta>
          </NoExenta>
        </Sujeta>
      </DesgloseFactura>
    </TipoDesglose> 


Entiendo que TipoRecargoEquivalencia será 1.4 por lo que he visto en la web de la agencia tributaria española (pero tampoco estoy seguro que sean los mismos % para las forales)

Artículos al tipo general del 21%: recargo del 5,2%
Artículos al tipo reducido del 10%: recargo del 1,4%
Artículos al tipo superreducido del 4%: recargo del 0,5%

Gracias!

[Sistel]

Empezado por Sanduzelai

Entiendo que TipoRecargoEquivalencia será 1.4 por lo que he visto en la web de la agencia tributaria española (pero tampoco estoy seguro que sean los mismos % para las forales)
Artículos al tipo general del 21%: recargo del 5,2%
Artículos al tipo reducido del 10%: recargo del 1,4%
Artículos al tipo superreducido del 4%: recargo del 0,5%

Hola,

Sí, los tipos de IVA y de recargo de equivalencia son los mismos en todas las administraciones tributarias de España, incluídas las forales.
Te falta un tipo de IVA con su recargo de equivalencia:
Aceites de oliva y de semillas y pastas alimenticias: 5% de IVA con recargo de equivalencia del 0,62%

Saludos

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

Empezado por Sanduzelai

Hola,
un cliente me ha comentado que está en regimen por recargo de equivalencia en lugar de regimen general que es el que tengo desarrollado.
He visto la documentación y veo que tengo que cambiar algunos tags y añadir otros para este caso.
No me queda claro como hay que calcular el tag CuotaRecargoDeEquivalencia.
En este ejemplo de factura, ¿como habría que hacer?


...

Gracias!

En mi caso, si genero esa factura (con diferencia de decimales) me da lo siguiente; Puedes compararlo con el tuyo, pero tiene buena pinta. Te falta rellenar la cuota de recargo.

Código PHP:

<DetallesFactura>
    <IDDetalleFactura>
        <DescripcionDetalle>pipas facundo</DescripcionDetalle>
        <Cantidad>1.00000000</Cantidad>
        <ImporteUnitario>0.63636300</ImporteUnitario>
        <Descuento>-0.00363700</Descuento>
        <ImporteTotal>0.71296000</ImporteTotal>
    </IDDetalleFactura>
</DetallesFactura>
<ImporteTotalFactura>0.71</ImporteTotalFactura>
<Claves>
    <IDClave>
        <ClaveRegimenIvaOpTrascendencia>01</ClaveRegimenIvaOpTrascendencia>
    </IDClave>
</Claves>
</DatosFactura>
<TipoDesglose>
    <DesgloseFactura>
        <Sujeta>
            <NoExenta>
                <DetalleNoExenta>
                    <TipoNoExenta>S1</TipoNoExenta>
                    <DesgloseIVA>
                        <DetalleIVA>
                            <BaseImponible>0.64</BaseImponible>
                            <TipoImpositivo>10.00</TipoImpositivo>
                            <CuotaImpuesto>0.06</CuotaImpuesto>
                            <TipoRecargoEquivalencia>1.40</TipoRecargoEquivalencia>
                            <CuotaRecargoEquivalencia>0.01</CuotaRecargoEquivalencia>
                            <OperacionEnRecargoDeEquivalenciaORegimenSimplificado>N</OperacionEnRecargoDeEquivalenciaORegimenSimplificado>
                        </DetalleIVA>
                    </DesgloseIVA>
                </DetalleNoExenta>
            </NoExenta>
        </Sujeta>
    </DesgloseFactura>
</TipoDesglose> 


[elcharlie]

Buenos días tod@s,
tengo que un problemón, que con suerte, quizás alguien sepa solucionarlo o por donde van los tiros.
Desde siempre, desde que empezamos con el SII, en el xml de envío, en vez de enviar todos los registros en un solo xml, generábamos un xml por cada uno, para que nos fuera mas fácil tratarlos. No es una manera mala de hacer, es diferente...
Cuando empezamos con el TicketBAI y el Batuz, lo afrontamos de la misma manera, un registro, un xml, y un envio. Hasta aquí la introducción, todo funciona correctamente y sin problemas enviamos y recibimos.
El problema nos viene con la Diputación de Gipuzkoa. Desde hace un tiempo, vemos que si enviamos a la vez muchos registros (con 20 seguidos ya vale), nos cortan la conexión. Hay que esperar unos minutos y volver a enviar, es como si tuvieran un limite de conexiones por tiempo. Nos hemos puesto en contacto con los informáticos de la diputa, y nos han dicho que ellos no bloquean nada, pero a nosotros nos pasa. Solución, enviamos de 10 en 10 esperando unos minutos entre envíos, y así funciona, pero es una chapuza, y me gustaría solucionarlo y poder enviar todo a la vez.
¿A alguien mas le está pasando esto?, ya os digo que en las demás diputaciones 0 problemas, es solo con la de Gipuzkoa, y no podemos modificarlos todo de nuevo para enviarlo en solo xml, seria empezar de nuevo.
¿Alguien sabe algo?
Perdón por el tostón... y gracias de antemano.

[keys]

Empezado por elcharlie

Buenos días tod@s,
tengo que un problemón, que con suerte, quizás alguien sepa solucionarlo o por donde van los tiros.
Desde siempre, desde que empezamos con el SII, en el xml de envío, en vez de enviar todos los registros en un solo xml, generábamos un xml por cada uno, para que nos fuera mas fácil tratarlos. No es una manera mala de hacer, es diferente...
Cuando empezamos con el TicketBAI y el Batuz, lo afrontamos de la misma manera, un registro, un xml, y un envio. Hasta aquí la introducción, todo funciona correctamente y sin problemas enviamos y recibimos.
El problema nos viene con la Diputación de Gipuzkoa. Desde hace un tiempo, vemos que si enviamos a la vez muchos registros (con 20 seguidos ya vale), nos cortan la conexión. Hay que esperar unos minutos y volver a enviar, es como si tuvieran un limite de conexiones por tiempo. Nos hemos puesto en contacto con los informáticos de la diputa, y nos han dicho que ellos no bloquean nada, pero a nosotros nos pasa. Solución, enviamos de 10 en 10 esperando unos minutos entre envíos, y así funciona, pero es una chapuza, y me gustaría solucionarlo y poder enviar todo a la vez.
¿A alguien mas le está pasando esto?, ya os digo que en las demás diputaciones 0 problemas, es solo con la de Gipuzkoa, y no podemos modificarlos todo de nuevo para enviarlo en solo xml, seria empezar de nuevo.
¿Alguien sabe algo?
Perdón por el tostón... y gracias de antemano.

Hola a todos. Decirte que a nosotros nos pasa lo mismo, estamos enviando muchas facturas seguidas y de repente nos devuelve un error de conexión (Unas veces cada 20 facturas, otras cada 10, otras nunca, aleatorio). Nos lleva pasando desde que entraron los comercios a TicketBAI de Gipuzkoa, es decir, cuando entro el grueso de contribuyentes. En su momento hablamos con hacienda y nos dijeron lo mismo que a ti. Bueno también nos dijeron que enviáramos las facturas por la noche, los cachondos de ellos. En el entorno de pruebas hemos hecho miles de pruebas y no pasa.

Como tu dices 0 problemas en las otras dos diputaciones y en Gipuzkoa tampoco hasta que paso lo que he dicho.

La solución no es enviar todas a la vez, ya que en Gipuzkoa solo se puede de una en una. Solo es Bizkaia la que lo permite. Nosotros la solución que hicimos cuando detectamos ese error fue, le damos 30 segundos al programa de descanso, y la volvemos intentar enviar, así un número de intentos que hasta ahora le hemos puesto 6 intentos, y parece que hemos solucionado el problema, aunque hay veces que ni con esas.

Estoy convencido que es un problema de hacienda, y ahora al ver que a alguien más le pasa