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

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

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

[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

[hago_preguntas]

Empezado por 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:


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

Nos ha pasado con Álava y Guipúzcoa que son las que estamos probando.

Nosotros codificamos los parámetros de la consulta que va en la URL antes de codificar el QR, sin mirar la diputación, que es lo que señala la especificación, pero, como dices, Álava no sigue su especificación, la cual indica que hay que calcular el crc sobre el contenido del QR, y en dicho contenido los parámetros de la consulta de la URL deben estar codificados (URL encondig, que también señalan en su especificación), y por lo tanto la /, el +, los espacios, etc... se sustituyen por sus códigos hexadecimales precedidos del %, para que la URL sea correcta y se pueda navegar a la misma (otra cosa es que muchos navegadores analicen las URLs y las codifiquen y reescriban correctamente antes de hacer la petición).

Lo suyo sería que siguieran sus especificaciones, pero sino lo hacen (deberían de cambiar las especificaciones), tocará calcular sólo la parte del crc de manera distinta en función de la administración que es el parámetro que parece que falla (¡¡¡y eso que es sólo una comunidad con 3 provincias, el día que salte a nivel nacional algo parecido, va a ser un caos!!!).

[hago_preguntas]

Empezado por 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:


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

Ya debería de funcionar como el resto de administraciones, escribimos a Álava para preguntar por la inconsistencia con respecto a las especificaciones, y nos respondieron esto:

Hemos implantado una nueva versión en la cual no deberíais tener problemas para realizar dicha consulta.



¿Lo podéis probar?



Un saludo y disculpen las molestias.

Lo probamos con varias que no funcionaban, y ya funcionan como indica la especificación.

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

[ermendalenda]

Empezado por unomasmas

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

OK. me ha costado varios días crear un php que te devuelva todos los datos del certificado, incluso me devuelve el email de quien lo solicitó( siempre que se haya introducido ese dato al solicitarlo), con lo cual automatiza que envíe un email para advertir de la proximidad de la caducidad a ese Email u a otro. después te paso el php.

[ermendalenda]

Empezado por unomasmas

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

Supongo que ya todos estais teniendo en cuenta donde estais dejando los php, firmador, anulador,,,
Por si acaso, os advierto que seais cuidadosos pueden sacar las claves facilmente, no lo tengais en servidores públicos, lo lógico es que esté en redes privadas.

Aquí os dejo un ejemplo Curl para llamar al php

curl.exe --connect-timeout 1  http://xxxx/Caducidad.php?fichero==[NombreCertificado.xxx]=[Clave]=  --data-binary @[path completo donde esta alojado el certificado..xxx]  -o [path donde quereis los datoscertificado ejemplo c:\certs\datos_certificado.txt]

Respetad todos los signos igual que los uso para separar los campos, ya que no he encontrado otra forma de mandarlos(que seguro que la hay)
Intentad que las claves de certificado no contengan signos "=","+",",",solo letras numeros guiones bajos y medios y cualquier signo que no necesite traducirlo a codigo uri(podeis investigar un poco mas si quereis para mandar mas signos, yo me he plantado aqui)


En el php, no solo compruebo el certificado si no que lo dejo alojado en el servidor y machaco el que hubiera, esto es muy bueno para actualizar certificados.
Aquí teneis el Caducidad.php

Código PHP:

<?php 
$p = file_get_contents('php://input'); // $p stands for params
$datos = $_GET['fichero'];
$varias=explode("=",$datos);
$xml=file_get_contents("php://input");
$Clave=$varias[2];
$dir_cert =($_SERVER['DOCUMENT_ROOT'].'/certs');
if (!file_exists($dir_cert)) {
    mkdir($dir_cert, 0700, true);
}

$dir_cert = $dir_cert.'/'.$varias[1] ;
file_put_contents($dir_cert, $p);

    $fac = new Comprobador();
    $CompruebaF = $fac -> comprobar($dir_cert,$Clave);
    exit;

?>

<?php 
class Comprobador{
    public function comprobar($certificadop12, $clavecertificado)
    {
    if (!$pfx = file_get_contents($certificadop12))
    {
        echo "Error: No se puede leer el fichero del certificado o no existe en la ruta especificada";
       exit;
    }
    if (openssl_pkcs12_read($pfx, $key, $clavecertificado))
    {
    $this->publicKey    = $key["cert"];
    $this->privateKey   = $key["pkey"];
    }
    else
    {
        echo "Error: No se puede leer el almacén de certificados o la clave no es la correcta.";
           exit;
    }
    $Comprueba1                       = $this->insertaComprobacion();
    return $Comprueba1;
    }
    public function insertaComprobacion(){
        $certData   = openssl_x509_parse($this->publicKey);
$validFromd1 = date('d-m-Y H:i:s', $certData['validFrom_time_t']);
                
$validFromd = date('d-m-Y', $certData['validFrom_time_t']);
        $validFromh = date('H:i:s', $certData['validFrom_time_t']);
$validTod1 = date('d-m-Y H:i:s', $certData['validTo_time_t']);
                
$validTod = date('d-m-Y', $certData['validTo_time_t']);
        $validToh = date('H:i:s', $certData['validTo_time_t']);
    
    echo "<FechaDesde>".$validFromd."</FechaDesde>";
    echo "\r\n<HoraDesde>".$validFromh."</HoraDesde>";
    echo "\r\n<FechaHasta>".$validTod."</FechaHasta>";
    echo "\r\n<HoraHasta>".$validToh."</HoraHasta>";
        if (!empty($certData['name'])){
        echo "\r\n<Nombre>".$certData['name']."</Nombre>";
        }
    if (!empty($certData['hash'])){
    
    echo "\r\n<Hash>".$certData ['hash']."</Hash>";
    }
    if (!empty($certData['C'])){
        
        echo "\r\n<Pais>".$certData['C']."</Pais>";
       }
    if (!empty($certData['subject']['ST'])){
        
        echo "\r\n<Estado>".$certData['subject']['ST']."</Estado>"; 
       }
    if (!empty($certData['subject']['L'])){
        
           echo "\r\n<Municipio>".$certData['subject']['L']."</Municipio>";
    }       
    if (!empty($certData['subject']['CN'])){
        
        echo "\r\n<RazonSocial>".$certData['subject']['CN']."</RazonSocial>";
    } 
    if (!empty($certData['extensions']['subjectAltName'])){

        $variosemails=explode(",",$certData['extensions']['subjectAltName']);
          if (!empty($variosemails[0])){
            $vemails=explode(":",$variosemails[0]);
              if (!empty($vemails[1])){
            
                echo "\r\n<Email>".$vemails[1]."</Email>";   
             }                
            else
            {
                 echo "\r\n<EmailSinFormateo>".$vemails."</EmailSinFormateo>";
        
            }
        if (!empty($variosemails[1])){

        echo "\r\n<SubjectEmail1>".$variosemails[1]."</SubjectEmail1>";   
        }
        if (!empty($variosemails[2])){

        echo "\r\n<SubjectEmail2>".$variosemails[2]."</SubjectEmail2>";   
        }

        if (!empty($variosemails[3])){

        echo "\r\n<SubjectEmail3>".$variosemails[3]."</SubjectEmail3>";   
        }
        if (!empty($variosemails[4])){

        echo "\r\n<SubjectEmail4>".$variosemails[4]."</SubjectEmail4>";   
        }
        if (!empty($variosemails[5])){

        echo "\r\n<SubjectEmail5>".$variosemails[5]."</SubjectEmail5>";   
        }
        if (!empty($variosemails[6])){

        echo "\r\n<SubjectEmail6>".$variosemails[6]."</SubjectEmail6>";   
        }
        }
    }       
    if (!empty($certData['extensions']['authorityKeyIdentifier'])){
    
        echo "\r\n<KeyAutorizacion>".$certData['extensions']['authorityKeyIdentifier']."</KeyAutorizacion>"; 
    }      
    if (!empty($certData['issuer']['OU'])){
        echo "\r\n<Emisor>".$certData['issuer']['OU']."</Emisor>"; 
    }       
    echo "\r\n<ClavePublica>". $this->publicKey ."</ClavePublica>"; 

    echo "\r\n<ClavePrivada>".$this->privateKey."</ClavePrivada>"; 


    echo "\r\n";
    echo "\r\n// --- Datos con nombres de campos Originales ---";
    
    echo "\r\n<validFrom_time_t>".$validFromd1."</validFrom_time_t>";
    echo "\r\n<validTo_time_t>".$validTod1."</validTo_time_t>";
    if (isset($certData['subject'])){
        
        foreach ($certData['subject'] as $item=>$value)
            {
                   echo "\r\n<".$item.">". $value."</".$item . ">";
            }
        }
        if (isset($certData['extensions'])){
         foreach ($certData['extensions'] as $item=>$value)
            {
                   echo "\r\n<".$item.">". $value."</".$item . ">";
            }
        }
    $Comprueba='';
    return $Comprueba;
    } 
}
?>

[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

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

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