La firma con cualquier política de firma (BIZ, GIP, ARA) es válida para las tres provincias
El hash te lo dan ellos (aparece en su web de política de firma)


Suerte

El proceso es el mismo en Alava que en Gipuzkoa, lo unico que cambia es la politica de firma y los servidores a los que envías. El hash esta en la documentacion de Alava.

Código Delphi [-]
     'https://ticketbai.araba.eus/tbai/sinadura/';
     '88E82F917EFFC8720345188FCBF2D84345149FB415F3FD750F50456ECF3232E4';
     'https://ticketbai.araba.eus/tbai/sinadura/';

Gracias Compañero. Me ha sido de gran ayuda. Pongo como quedaria en delphi para enviar por las SecureBlackBox.

Código Delphi [-]
      //EnvioGipuzkoa2 es el componente TsbxHTTPClient


      //Asigno el certificado
      EnvioGipuzkoa2.ClientChain.Clear;

   
      for z := 0 to CertificateStorage.Certificates.Count - 1 do
      begin
        cert := CertificateStorage.Certificates[z];
        if Pos(AnsiUpperCase(Firma), AnsiUpperCase(Cert.Subject) ) <> 0 then //Buscar el certificado que esta seleccionado         
          begin
            EnvioGipuzkoa2.ClientChain.Add(cert);          
            Break;
          end;
      end;

      EnvioGipuzkoa2.TLSSettings.AutoValidateCertificates :=   True;
      EnvioGipuzkoa2.TLSSettings.Versions := csbTLS12;

      EnvioGipuzkoa2.RequestParameters.ContentType := 'application/xml;charset=UTF-8';
        
      EnvioGipuzkoa2.RequestParameters.AcceptCharset := 'UTF-8';
      EnvioGipuzkoa2.RequestParameters.Accept := '*/*';
      EnvioGipuzkoa2.RequestParameters.HTTPVersion := TsbxHTTPClientReqParamsHTTPVersions.chvHTTP11;
      EnvioGipuzkoa2.TLSSettings.RenegotiationAttackPreventionMode := TsbxHTTPClientTLSRenegotiationAttackPreventionModes.crapmAuto;


      EnvioGipuzkoa2.SocketSettings.DNSTotalTimeout := 0;
      EnvioGipuzkoa2.SocketSettings.Timeout := 90000; //60000;
      
      EnvioGipuzkoa2.PostStream(DevolverServidorGipuzkoa(anula),RequestBody);

     //guardamos el fichero de resultado
     stream := TBytesStream.Create(EnvioGipuzkoa2.OutputBytes);
     try
         stream.SaveToFile(Fichero);
     finally
         stream.Free;
     end;

Ese es el HASH que te dan ellos (como tú bien dices en la documentación).
Cada tributación tiene el suyo (para PRE y para PRO). Y ya se ha cambiado alguna vez.
En nuestro caso y en previsión de futuros cambios está guardado en un campo de la B.D.

Hash politica de firma
 

Muchas gracias a todos por la aclaración! :)

Buenos días,

Estoy leyendo estos últimos mensajes mencionando esto, y me estoy quedando un poco a cuadros.

Primero, no tengo recuerdo de haber aplicado en ningún sitio lo de la política de firma.

He buscado en el código, y en efecto veo que en el "firmador.php" está el hash "dTtPpv4fWTcejeVx7+91ILruFX3HysbngBlllJm4i/E=".

Antes de pasarme a esta librería, estuve usando Chilkat 9.5 para PHP, que funcionaba, y no tengo recuerdo de haber puesto ningún string... excepto que haya sido algo que hice muy a los inicios, hace meses, y ya ni me acuerde.

En cualquier caso, llevamos en producción enviando facturas desde el 24 de octubre, y no he cambiado nada en el firmador. Es decir, que estoy usando el mismo hash de "política de firma" que estaba usando en el entorno de desarrollo.

De hecho lo único que hice el día que pasamos al entorno de producción fue poner el número de licencia correcto, así como todo el tema de HuellaTBAI, pero poco más...

¿Me tengo que preocupar?

En el primer mensaje tenemos las políticas de firma.
https://www.clubdelphi.com/foros/sho...97&postcount=1

Creo que deben estar actualizadas (si no es así comentadlo).

Yo miraría de actualizarlas.
Recuerdo que nosotros estuvimos un tiempo enviando también con una política antigua sin problemas, hasta que un día empezó a quejarse (no recuerdo en qué tributación).
Supongo que aquel día alguien activó esa validación. Que no se esté quejando ahora no quiere decir que cualquier día no empiece a hacerlo.

Zuzendu Gipuzkoa
 

Hola!

Vosotros como habéis planteado el tema del zuzendu subsanar? Me refiero al caso que un fichero ticketBAI se ha rechazado por errores en el XML, "Fichero no cumple el esquema XSD".
Mostráis al usuario el codigo XML del fichero TicketBAI original (sin firmar) para que el mismo lo edite y corrija y se pueda enviar al servicio Zuzendu?:confused:

Porque claro, las posibilidades de errores a corregir pueden ser muchísimas para programar cada caso... y supongo que hará falta la interacción con el usuario para indicar el dato correcto... o no.
No me parece factible que el usuario de nuestro programa corrija a mano el XML con errores :(
Ando un poco perdido en este tema.

Gracias!

Por un lado, el XML que se envía no es sin más el original sin firmar. Aunque mantiene la estructura original, la definición del fichero y el bloque de "Cabecera" cambian.

Por otro lado, si hay un error en el XML, significa que hay un problema en el software que lo ha generado, o bien en la propia factura.

Es decir, corregir un XML a mano y enviarlo puede ser algo factible cuando tienes que enviar YA algo, y no tienes otra cosa preparada.

Lo correcto es corregir el problema que ha motivado un XML erróneo.

Por ejemplo, si le faltan las líneas de detalle, hay que enviarlo a Zuzendu-Subsanar. De nada sirve que abras el XML y las agregues a mano, porque te va a volver a pasar.

O abres la factura desde tu aplicación y agregas las líneas de detalle, y vuelves a enviarla, o bien corriges la programación que ha impedido la generación de unas líneas de detalle que sí existían.

En conclusión, ahora mismo no se me ocurre un motivo o razón justificada para editar un XML a mano.

Por ejemplo, en el sistema que tengo montado si hay un problema con el envío, me guardo el código de error, y además marco esa factura como a rectificar, o enviar a Zuzendu (según el error original), para saber qué hacer con ella. Además, dejo un registro de todos y cada uno de los envíos, con el XML original y el firmado para cada caso, con la respuesta obtenida. Pero cada intento de envío genera un XML y un registro nuevo, es decir, jamás reutilizo un XML ya generado.

No me parece correcto/lógico/seguro/... dar acceso al XML para que se modifique antes de enviar.
¿Podrías cambiar los importes y enviarlo? ¿entonces lo que envías no "cuadraría" con la factura?

No le veo sentido sinceramente y creo que te puede provocar muchos más problemas y errores de los que vas a solucionar.

impresión qr en impresora de tickets
 

Hola a tod@s, estoy liado con lo del ticketbai y necesito imprimir el qr en los tickets d caja. Alquien me puede ayudar con los comandos a enviar a la impresora de ticket???.
Gracias a todos d antemano

NOTA DEL MODERADOR: He movido tu pregunta a este hilo específico de TickeBAI, porque seguramente en este hilo habrá usuarios que se hayan encontrado con ese problema.

Hola, no todas las impresoras permiten imprimir un código QR, por ejemplo, las matriciales.
Por otro lado, según la marca y modelo de la impresora usará unos comandos u otros, epson, zebra, etc.
Tienes manual de la impresora? normalmente ahí suelen venir los códigos, si los admite.
Especifica algo más por favor.
Un saludo.

Bienvenido.
Revisa la Guía de estilo de los foros.
Si das el modelo de impresora será más fácil poder ayudarte.

Tienes razón Irreo, el usuario no puede editar el XML.

El caso es este, todavía no hemos desarrollado zuzendu y se ha rechazado una factura por un cif enviado con un guion, por un bug del programa. Ya hemos corregido el programa para no permitirlo pero claro, tenemos que enviar esa factura de alguna forma.
La idea es que no se rechacen facturas pero siempre puede ocurrir algo..


Vamos a ver como lo hacemos.



Muchas gracias

Tienes razón Neftali. Que el usuario edite el XML no es una opción.

Supongo que tendremos que programar una solución para cada posible error.
Muchas gracias

No creo que sea cuestión de programar una solución para cada posible error :)

A ver, las facturas normales en si no tienen mucho misterio (por suerte) ya que es solo remitente, destinatario, y unas líneas de detalle.

Lo importante es tener desarrollada la funcionalidad de Alta con su firma, y por otro la de Zuzendu, que simplemente genera un XML prácticamente igual, pero sin firmar y adjuntando parte de la firma de la factura original.

Por lo demás, "da igual" que errores genere la factura original. ¿CIF incorrecto? Lo corriges, y haces lo que corresponda.... ¿fecha aaaa-mm-dd en lugar de dd-mm-aaaa? Lo mismo.

Con esto quiero decir que lo importante es tener hechos los servicios de envío.

Lógicamente lo que si debes tener documentado en algún sitio es qué tienes que hacer con cada error, porque en unos casos será Zuzendu, y en otros requerirá crear una nueva factura rectificativa.

Por ejemplo, a nosotros nos pasó lo de un CIF con guión, y este fue el error devuelto:

1153 - El NIF del destinatario tiene un formato erróneo

El error "1153" yo lo tengo anotado como "a rectificar". Por lo tanto, la operativa fue corregir el CIF del cliente, y emitir una factura sustitutiva.

Ánimo y suerte.

A estas alturas ya tengo un lío en la cabeza importante y además ahora hace semanas que hemos apartado este tema, pero ¿esas facturas erróneas, una vez corregido el programa, no puedes enviarlas con el libro 240 sin software garante?

UPDATE:
Efectívamente me he echo un lío. 240SinSG sólo es para BATUZ y asumo que tú estás en una de la otras dos tributaciones.
En ese caso y según la documentación:

Artículo 1. Procedimiento para el envío de la información correspondiente
al fichero TicketBAI que ha sido rechazado.
1. La información correspondiente al fichero TicketBAI que ha sido objeto de rechazo
por no cumplir las validaciones mínimas establecidas en la Orden Foral 521/2020, de
23 de diciembre, por la que se regulan las especificaciones técnicas y funcionales del
software TicketBAI y la declaración de alta en el Registro de Software TicketBAI,
deberá ser objeto de subsanación a través del envío del fichero de subsanación, de
acuerdo con los requisitos de los servicios Zuzendu, el procedimiento y las
especificaciones técnicas y funcionales que se regulan como anexo I a la presente
orden foral.
2. El fichero TicketBAI rechazado no podrá sufrir alteración alguna, y deberá
conservarse en su estado original dentro del sistema informático para garantizar la
integridad, conservación, trazabilidad e inviolabilidad del fichero TicketBAI generado
por el software TicketBAI.

Exacto Irreo, creo que haremos esto, desarrollar la parte de generar el xml para zuzendu y la parte del envío y después ver en cada caso como lo gestionamos.
En nuestro caso se ha rechazado una factura en Gipuzkoa, hemos enviado un guion y se ha rechazado, han contestado:

"Fichero no cumple el esquema XSD. Detalle del error: cvc-pattern-valid: Value 'NIFEJEMP-R' is not facet-valid with respect to pattern '(([a-zA-Z]{1}\d{7}[a-zA-Z]{1})(\d{8}[a-zA-Z]{1})([a-zA-Z]{1}\d{8}))' for type 'NIFType'."


Por lo tanto tenemos que utilizar Zuzendu subsanar para volver a enviar la factura sin el guión en el nif y con los apartados nuevos de zuzendu


Gracias

Disculpa Neftali, no habia especificado que es para Gipuzkoa, que tienen Zuzendu y creo que es igual o muy similar que el Zuzendu de Araba. En cambio en Bizkaia no lo tienen pero hay este capítulo de "Sin software garante".

Ahora estamos con el Zuzendu y mas adelante ya entraremos con el Batuz apartado "sin software garante":p

Muchas Gracias

¿Pero ese error lo has obtenido desde el servicio KONTSULTA, o fue lo que te devolvieron al enviar la factura a Alta?

Yo mirando la respuesta XML que tuvimos, tengo esto:

00 - Recibido - ALTA PREP
1153
El NIF del destinatario tiene un formato erróneo

Es decir, el estado es "00", recibido, pero con errores.

Esto fue en Gipuzkoa.