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

ANEXO I:
ESTRUCTURA Y VALIDACIONES DEL FICHERO DE ALTA TICKETBAI.

II. CLAVES Y VALORES PERMITIDOS EN CAMPOS DE TIPO LISTA.

ANEXO II:
ESTRUCTURA Y VALIDACIONES DEL FICHERO DE ANULACIÓN TICKETBAI.

II. CLAVES Y VALORES PERMITIDOS EN CAMPOS DE TIPO LISTA.

ANEXO III
ESPECIFICACIONES DE LA FIRMA ELECTRÓNICA DE LOS FICHEROS TICKETBAI

1. Objeto.

Este anexo establece las especificaciones de la firma electrónica de los ficheros TicketBAI (en adelante, especificaciones de firma), a que se refiere el artículo 5 de esta orden foral.

Las especificaciones de la firma electrónica se identificarán con un identificador único que será: https://www.gipuzkoa.eus/ticketbai/sinadura.

Esta identificación se deberá incluir obligatoriamente en la firma electrónica de los ficheros TicketBAI, empleando el campo correspondiente identificativo para determinar el marco general de especificaciones y la versión con las condiciones generales y específicas de aplicación para su validación.

2. Alcance.

2.1. Actores involucrados.

Los actores involucrados en el proceso de creación y validación de la firma electrónica son:

• - Firmante: persona física o jurídica o entidad sin personalidad jurídica que posee un dispositivo de creación de firma y que firma un fichero TicketBAI.
• - Verificador o verificadora: entidad, ya sea persona física o jurídica, que valida o verifica una firma electrónica apoyándose en las condiciones exigidas por unas especificaciones de firma concreta.
• - Prestador o prestadora de servicios de confianza: la persona física o jurídica que expide certificados electrónicos o presta otros servicios en relación con la firma electrónica.
• - Emisor o emisora de las especificaciones de firma: entidad que se encarga de generar y gestionar este documento, por el cual se deben regir el o la firmante y el verificador o la verificadora en los procesos de generación y validación de firma electrónica.

2.2. Formato admitido para la firma electrónica.

El formato admitido para la firma electrónica de los ficheros TicketBAI es el FormatoXAdES (XML AdvancedElectronicSignatures), según las especificaciones técnicas ETSI EN 319 132-1 V1.1.1, ETSI TS 103 171 V2.1.1 y ETSI TS 101 903 V1.4.2. Para versiones posteriores del estándar se analizarán los cambios en la sintaxis y se aprobará la adaptación del perfil a la nueva versión del estándar a través de la modificación del presente anexo.

A lo largo de estas especificaciones de firma se utilizarán los prefijos ds: y xades: para hacer referencia a elementos definidos en los estándares XMLDSig y XAdES, respectivamente.

Dentro de las distintas clases del formato XAdES se deberá adecuar para la generación de, al menos, la clase básica, añadiendo información sobre las especificaciones de firma, clase EPES.

2.3. Creación de la firma electrónica.

Es conveniente realizar la implementación de la creación de la firma electrónica utilizando librerías criptográficas o productos existentes.

No es requerido que la firma incluya Sellado de Tiempo o TimeStamping proporcionados por servicios de TSA en el momento de firma.

2.4. Verificación de la firma electrónica.

El verificador o la verificadora puede utilizar cualquier método estandarizado para verificar la firma creada según el presente anexo. Las condiciones mínimas que deberán cumplirse para validar la firma serán las siguientes:

• 1. Garantía de validez de la integridad de la firma.
• 2. Validez de los certificados en el momento en que se realizó la firma.
• 3. Certificado firmante expedido bajo una Declaración de Prácticas de Certificación específica, disponible en un repositorio público.
• 4. El emisor o la emisora del certificado firmante deberá estar en la lista de Prestadores de Servicios de Confianza Cualificados (QTSP). Esta lista se encuentra disponible en https://webgate.ec.europa.eu/tl-browser/#/.

2.5. Gestión de las especificaciones para la firma.

El mantenimiento, actualización, publicación y divulgación de las especificaciones de firma corresponderá a la Diputación Foral de Gipuzkoa.

Las actualizaciones de estas especificaciones se publicarán en el Boletín Oficial de Gipuzkoa y en el siguiente enlace: https://www.gipuzkoa.eus/ticketbai/sinadura.

3. Política de validación de la firma electrónica.

En este apartado se especifican las condiciones que se deberán considerar por parte del o de la firmante, en el proceso de generación de la firma electrónica, y por parte del verificador o de la verificadora, en el proceso de validación de la firma electrónica.

3.1. Periodo de validez.

Estas especificaciones de firma son válidas desde su publicación hasta la publicación de una nueva versión actualizada, pudiéndose facilitar un periodo de tiempo transitorio, en el cual convivan las dos versiones, que permita adecuar las diferentes plataformas de los actores involucrados a las especificaciones de la nueva versión. Este periodo de tiempo transitorio deberá indicarse en la nueva versión, pasado el cual sólo será válida la versión actualizada.

3.2. Reglas comunes.

Las reglas comunes para los actores involucrados en la firma electrónica, firmante y verificador o verificadora, son un campo obligatorio que debe aparecer en todas las especificaciones de firma. Estas reglas permiten establecer responsabilidades respecto a la firma electrónica sobre la persona o entidad que crea la firma y la persona o entidad que verifica, definiendo los requisitos mínimos que deben presentarse, debiendo estar firmados, si son requisitos para el o la firmante, o no firmados, si son requisitos para el verificador o la verificadora.

3.3. Reglas del firmante.

El o la firmante se hará responsable de que el fichero TicketBAI a firmar no incluye contenido dinámico que pudiese modificar el resultado de la firma durante el tiempo. Si el fichero TicketBAI a firmar no ha sido creado por el o la firmante, esta persona deberá asegurarse de que no existe contenido dinámico dentro del fichero TicketBAI (como pueden ser macros).

Formato XAdES: se admitirán exclusivamente las firmas XAdESenveloped. No se admitirá XAdESenveloping, ni XAdESdettached.

El o la firmante deberá proporcionar, como mínimo, la información contenida en las siguientes etiquetas dentro del campo SignedProperties (campo que contiene una serie de propiedades conjuntamente firmadas a la hora de la generación de la firma XMLDsig), las cuales son de carácter obligatorio:

• - SigningTime: especifica el momento en que el o la firmante realizó el proceso de firma.
• - SigningCertificatev2 o SigningCertificate: contiene referencias a los certificados y algoritmos de seguridad utilizados en cada certificado. Este elemento deberá ser firmado con objeto de evitar la posibilidad de sustitución del certificado.
• - SignaturePolicyIdentifier: identifica las especificaciones de firma sobre las que se basa el proceso de generación de la firma electrónica, y debe incluir los siguientes contenidos en los elementos en que se subdivide:
  • a) Referencia explícita al presente documento de especificaciones de firma, en el elemento xades: SigPolicyld. Para ello, aparecerá el OID que identifique la versión concreta de las especificaciones de firma o la URL de su localización.
  • b) La huella digital del documento de especificaciones de firma correspondiente y el algoritmo utilizado, en el elemento <xades: SigPolicyHash>, de manera que el verificador o la verificadora pueda comprobar, calculando a su vez este valor, que la firma está generada según las mismas especificaciones de firma que se utilizarán para su validación.

  Las etiquetas restantes que pueden agregarse en el campo SignedProperties serán consideradas de carácter opcional:

  • - SignatureProductionPlacev2 o SignatureProductionPlace: define el lugar geográfico donde se ha realizado la firma del documento.
  • - SignerRolev2 o SignerRole: define el rol de la persona en la firma electrónica. En el caso de su utilización, deberá contener uno de los siguientes valores en el campo ClaimedRoles:
    • a) «Supplier» o «emisor»: cuando la firma la realiza el emisor o la emisora.
    • b) «Customer» o «receptor»: cuando la firma la realiza el receptor o la receptora.
    • d) (sic) «Thirdparty» o «tercero»: cuando la firma la realiza una persona o entidad distinta al emisor o la emisora o al receptor o la receptora.
  • - CommitmentTypeIndication: define la acción del o de la firmante sobre el documento firmado (lo aprueba, lo informa, lo recibe, lo certifica).
  • - AllDataObjectsTimeStamp: contiene un sello de tiempo, calculado antes de la generación de la firma, sobre todos los elementos contenidos en ds: Reference.
  • - IndividualDataObjectsTimeStamp: contiene un sello de tiempo, calculado antes de la generación de la firma, sobre algunos de los elementos contenidos en ds: Reference.

La etiqueta CounterSignature, refrendo de la firma electrónica y que se puede incluir en el campo UnsignedProperties, será considerada de carácter opcional. Las siguientes firmas, ya sean serie o paralelo, se añadirán según indica el estándar XAdES, según el documento EN 319 102-1.

3.4. Reglas del verificador o de la verificadora.

El formato básico de firma electrónica avanzada no incluye ninguna información de validación más allá del certificado firmante. Los atributos que podrá utilizar el verificador o la verificadora para comprobar que se cumplen los requisitos de las especificaciones de firma según la cual esta se ha generado, son los siguientes:

• - Signing Time: sólo se utilizará en la verificación de las firmas electrónicas como indicación para comprobar el estado de los certificados en la fecha señalada, ya que únicamente se pueden asegurar las referencias temporales mediante un sello de tiempo (especialmente en el caso de firmas en dispositivos cliente).
• - SigningCertificatev2 o SigningCertificate: se utilizará para comprobar y verificar el estado del certificado (y, en su caso, la cadena de certificación) en la fecha de la generación de la firma, en el caso de que el certificado no haya caducado y se pueda acceder a los datos de verificación (CRL, OCSP) o bien en el caso de que el PSC ofrezca un servicio de validación histórico del estado del certificado.
• - SignaturePolicyIdentifier: se deberá comprobar, que las especificaciones de firma que se han utilizado para la generación de la firma se corresponden con la que se debe utilizar para un servicio en cuestión.

Existe un periodo de tiempo de espera, conocido como periodo de precaución o periodo de gracia, para comprobar el estado de revocación de un certificado. El verificador o la verificadora puede esperar este tiempo para validar la firma o realizarla en el mismo momento y revalidarla después. Esto se debe a que puede existir una pequeña demora desde que el o la firmante inicia la revocación de un certificado hasta que la información del estado de revocación del certificado se distribuye a los puntos de información correspondientes. Se recomienda que este periodo, desde el momento en que se realiza la firma sea, como mínimo, el tiempo máximo permitido para el refresco completo de las CRLs o el tiempo máximo de actualización del estado del certificado en el servicio OCSP. Estos tiempos podrán ser variables según el Prestador de Servicios de Certificación.

3.5. Reglas de uso de algoritmos.

Se podrán utilizar cualquiera de los algoritmos basados en RSA admitidos en ETSI TS 119 312 V1.3.1. Como mínimo se exige:

• - Tamaño de la clave será estrictamente superior a 1024.
• - SHA256 o versiones superiores.

4. Requisitos derivados de la arquitectura del software TicketBAI.

4.1. Certificados admitidos.

El software TicketBAI deberá utilizar alguno de los siguientes certificados para la firma electrónica de los ficheros TicketBAI:

• - Certificado de dispositivo, el cual proporciona una identidad única para cada dispositivo de facturación, estando instalado y vinculado al dispositivo desde el que se emiten facturas o justificantes.
• - Certificado de persona física o de representante de entidad, los cuales permiten acreditar la identidad de la persona física o jurídica respectivamente.
• - Sello de empresa, el cual constituye un certificado técnico que puede ser utilizado por un software TicketBAI de forma desasistida, o por un grupo de personas pertenecientes a un departamento o grupo de trabajo. Es un certificado que puede compararse en el mundo físico al uso habitual en el día a día de una empresa de un sello de caucho.
• - Certificado de autónomo o autónoma: certificado no cualificado, emitido para personas físicas que desarrollen una actividad económica de acuerdo con lo previsto en la Norma Foral del Impuesto sobre la Renta de las Personas Físicas, y para cuya emisión, se exigirá la acreditación por la persona física de esta circunstancia.

4.2. Restricciones de la firma en función de la arquitectura.

4.2.1. Arquitecturas con firma en cliente.

Se considera arquitectura con firma en cliente, cuando el software TicketBAI que realiza la firma se encuentra ubicado en el propio dispositivo de facturación desde que se accede al mismo. Por ejemplo, una aplicación de escritorio.

Si se accede de forma remota a otro dispositivo para firmar, se considera arquitectura con firma en servidor.

No existen restricciones en los certificados para este tipo de arquitectura. Se podrá firmar con: certificado de dispositivo, certificado de persona física, certificado de representante de entidad, sello de empresa o certificado de autónomo o autónoma.

4.2.2. Arquitecturas con firma en servidor.

Se considera arquitectura con firma en servidor, cuando el software TicketBAI que realiza la firma se encuentra ubicado en un dispositivo distinto al dispositivo de facturación desde el que se accede al mismo. Por tanto, el dispositivo de facturación cliente accede de forma remota a otro dispositivo para realizar la firma.

De forma complementaria, si la emisión de facturas o justificantes se realiza en procesos desasistidos (batch) se considera «arquitectura con firma en servidor».

Se podrá firmar con: certificado de persona física, certificado de representante de entidad, sello de empresa o certificado de autónomo o autónoma.

En este caso, no se permite la firma con certificado de dispositivo.

4.2.3. Arquitecturas con posibilidad de firma en cliente y en servidor.

Las arquitecturas distribuidas podrán elegir entre realizar la firma en cliente o en servidor, siempre respetando las restricciones aplicadas a cada una de ellas.

Por ejemplo, en una aplicación web:

• - La firma en cliente se realizaría en el dispositivo que tiene instalado el navegador desde el que se accede a la aplicación, aplicándose las restricciones de las arquitecturas con firma en cliente.
• - La firma en servidor se realizaría en el servidor remoto al que accede el navegador, aplicándose en este caso las restricciones de las arquitecturas con firma en servidor.

Una arquitectura no podrá realizar firmas en cliente y servidor de forma simultánea. Debe elegir sólo una de las arquitecturas disponibles.

5. Cláusula de reciprocidad.

A título de reciprocidad, se entenderán cumplidas las especificaciones de firma electrónica contenidas en este anexo cuando los contribuyentes cumplan las especificaciones que a estos efectos hayan sido establecidos por la Diputación Foral de Álava o por la Diputación Foral de Bizkaia. (SigningCertificateV2 - ETSI EN 319132, SigningCertificate - ETSI TS 101 903, ETSI TS 103 171.) (SignatureProductionPlaceV2 - ETSI EN 319 132, SignatureProductionPlace - ETSI TS 101 903, ETSI TS 103 171.) (SignerRoleV2 - ETSI EN 319 132, SignerRole - ETSI TS 101 903, ETSI TS 103 171.).

ANEXO IV
ESPECIFICACIONES TÉCNICAS Y FUNCIONALES, Y REQUISITOS DEL ENVÍO DE LOS FICHEROS TICKETBAI

1. Objeto.

Este anexo establece los requisitos técnicos necesarios para que el servicio de recepción de ficheros TicketBAI de la Diputación Foral de Gipuzkoa recepcione los mensajes que contengan los mismos.

Se utilizarán servicios REST para permitir un suministro de la información en tiempo real.

2. Esquema general de funcionamiento.

El envío de los ficheros TicketBAI se realizará por vía telemática, concretamente mediante Servicios REST basados en el intercambio de mensajes XML. Todos los mensajes se responden de forma síncrona.

Una vez recibido el fichero TicketBAI, se realizará automáticamente un proceso de validación, tanto a nivel sintáctico (formato XML y estructura), como de reglas de negocio, y se devolverá una respuesta que será otro XML:

• - Si el fichero TicketBAI no supera alguna de las validaciones, se especificará en la respuesta que la recepción ha sido incorrecta y el error concreto que se ha producido.
• - Si el fichero TicketBAI supera las validaciones, se indicará en la respuesta que la recepción ha sido correcta.

Una vez realizada una recepción correcta, el sistema informático de la Diputación Foral de Gipuzkoa podrá realizar más validaciones sobre la información recibida, de forma asíncrona. En caso de detectarse errores en estas validaciones adicionales se comunicarán al contribuyente por otros medios.

Se definirán dos tipos de mensaje: Uno para el envío de los ficheros de alta TicketBAI y otro para el envío de los ficheros de anulación TicketBAI.

En la respuesta también se informará del Código TicketBAI, la hora de recepción del fichero TicketBAI y un Código Seguro de Verificación. La inexistencia del Código TicketBAI en la respuesta, significa que no ha podido determinarse el Código TicketBAI de la información recibida en el fichero de alta TicketBAI.

2.1. Descripción de estados globales de un mensaje.

2.1.1. Recibido.

Cuando el envío del fichero TicketBAI tenga este resultado indicará que el fichero TicketBAI ha pasado las validaciones mínimas, tanto sintácticas como de negocio, definidas a nivel de recepción. Por tanto, ha sido registrado en el sistema informático de la Diputación Foral de Gipuzkoa.

En el caso de que hayan avisos de validación relacionados con el fichero TicketBAI, se comunicarán en la respuesta del servicio o posteriormente por otro canal. Estos avisos no suponen, a priori, el rechazo del fichero TicketBAI, pero el remitente ha de tenerlos en cuenta para próximos envíos.

2.1.2. Rechazado.

Significa que el fichero TicketBAI no ha pasado alguna de las validaciones mínimas definidas a nivel de recepción y no cumple los requisitos mínimos para darle entrada al sistema.

Puede deberse a varios motivos:

• - La estructura del fichero TicketBAI recibido en la presentación no es conforme a la definida (no cumple las validaciones estructurales), o bien, existen errores sintácticos en el fichero TicketBAI. La respuesta indica que ha habido error de validación de la estructura.
• - No cumple ciertas validaciones mínimas en el contenido del fichero TicketBAI. Por ejemplo, en el caso de envío de un fichero de alta TicketBAI:
  • - Se ha usado un certificado no homologado o revocado.
  • - No contiene información de líneas de detalle.
  • - No contiene la información necesaria para el cálculo del Código TicketBAI.

2.2. Tratamiento de los ficheros TicketBAI rechazados.

Los ficheros TicketBAI rechazados no serán registrados en el sistema informático de la Diputación Foral de Gipuzkoa.

Se deberán reenviar los ficheros TicketBAI una vez corregidos los errores.

2.3. Tratamiento de los ficheros TicketBAI recibidos.

Los ficheros TicketBAI han sido registrados en el sistema informático de la Diputación Foral de Gipuzkoa y pasan a los siguientes procesos de validación detallada del contenido.

En caso de detectarse errores, estos se comunicarán al contribuyente. Se deberán corregir los problemas detectados en futuros envíos.

3. Estándares y requisitos.

3.1. Introducción.

El contenido del mensaje es un fichero XML. Un fichero XML debe cumplir las reglas descritas en las diferentes estructuras y que proporcionan normas respecto a formatos, obligatoriedad, etc. pero, en cualquier caso, la coherencia de los datos debe garantizarse en origen por quienes intervengan en la preparación y presentación de los datos.

Cada estructura está organizada en grupos de datos que contienen elementos de datos. Estos se han agrupado de modo que constituyen bloques lógicos, manteniendo una coherencia con el ámbito de cada estructura.

Los softwares TicketBAI que envían información a los servicios REST deberán autenticarse con un certificado electrónico en la parte cliente. Por tanto, el uso de los servicios requiere tener instalado un certificado electrónico reconocido admitido por la Diputación Foral de Gipuzkoa en el dispositivo de facturación desde el que se produzca el envío de la información. Dicho certificado podrá ser de persona física, de representante de entidad, de dispositivo, de sello electrónico o de autónomo o autónoma.

Un fichero TicketBAI de un contribuyente puede ser enviado con su propio certificado o por cualquiera de las siguientes opciones:

• - Certificado de su representante legal o tributario debidamente autorizado.
• - Certificado de su colaborador social.
• - Certificado de dispositivo.

En el caso de certificado de dispositivo, posteriormente a la realización de los envíos, el contribuyente tendrá que confirmar la autorización para que este dispositivo envíe mensajes en su nombre. Para esta confirmación se habilitará un servicio al efecto en la sede electrónica.

En el caso de colaborador social, deberá cumplir con lo previsto en la Orden Foral 523/2002, de 23 de diciembre de 2020 por la que se aprueban los términos de la colaboración social en el envío de los ficheros TicketBAI con motivo del cumplimiento de la obligación TicketBAI.

El NIF del emisor de la factura ha de ser el del contribuyente y estar dado de alta en la base de datos de contribuyentes de la Hacienda Foral de Gipuzkoa.

El certificado que se utilice para el envío puede ser diferente del certificado que se haya utilizado en la firma electrónica del fichero TicketBAI, de alta o anulación, objeto del envío.

3.2. Estándares utilizados.

Los servicios web RESTful son servicios diseñados para exponer APIs o interfaces de programación en la web. El objetivo es proporcionar mejor rendimiento, escalabilidad y flexibilidad que los tradicionales servicios web permitiendo a los clientes acceder a los datos y recursos mediante URL predecibles. Ésta es la manera mediante la cual se van a comunicar los sistemas de información (el del ciudadano/empresa y el de la Hacienda Foral). Se utilizarán los estándares de facto para el desarrollo de servicios RESFful.

La estructura de los ficheros TicketBAI se basa en esquemas XML utilizando la recomendación W3C de 28-Octubre de 2004 en http://www.w3.org/TR/xmlschema-0 y referenciada por el namespace http://www.w3.org/2001/XMLSchema.

Cada servicio tendrá definido un mensaje de entrada y su respuesta de salida por su respectivo esquema XSD.

4. Definición de los servicios.

4.1. Servicio de recepción de ficheros de alta TicketBAI.

Este servicio permite dar entrada a un fichero de alta TicketBAI en el sistema de la Diputación Foral de Gipuzkoa.

4.1.1. Medio de envío.

Entorno: Internet.

Protocolo: HTTPS 1.1 (TLS 1.1 o superior).

Modo de envío: POST.

Mensajes: Rest Service.

Codificación: UTF-8. La entrada es un XML que se debe adecuar a la especificación del siguiente esquema de entrada XSD.

Se trata del fichero de alta TicketBAI, en el formato y estructura descritas en el anexo I de la presente orden foral.

Cabeceras http requeridas: Content-Type: application/xml;charset=UTF-8.

Certificado: Los softwares TicketBAI que envían información a los servicios REST deberán autenticarse con un certificado electrónico en la parte cliente. Por tanto, el uso de los servicios requiere tener instalado un certificado electrónico reconocido admitido por la Diputación Foral de Gipuzkoa en el dispositivo de facturación desde el que se produzca el envío de la información. Dicho certificado podrá ser de persona física, de representante de entidad, de dispositivo, de sello electrónico de entidad o de autónomo o autónoma.

Dirección del servicio: https://tbai-z.egoitza.gipuzkoa.eus/sarrerak/alta.

4.1.2. Respuesta.

Entorno: Internet.

Protocolo: HTTPS.

Mensajes: Rest Service.

Codificación: UTF-8. La salida es un XML con codificación UTF-8. El xml se debe adecuar a la especificación del siguiente esquema de salida XSD:

Firma: el mensaje de respuesta no va firmado.

A continuación, a modo de ejemplo, se muestra una respuesta XML resultante de la aplicación de dicho esquema en caso de éxito:

El Código Seguro de Verificación deja constancia de la presentación en la sede electrónica de la Diputación Foral de Gipuzkoa.

A continuación, a modo de ejemplo, se muestra una respuesta XML resultante de la aplicación de dicho esquema en caso de errores de validación:

4.1.3. Códigos de resultado.

El código global de estado recogido en el elemento estado de la respuesta tiene las siguientes posibilidades:

En el caso de rechazado o aceptado incorrecto, puede indicarse una lista de errores en la respuesta, de acuerdo a esta codificación.

4.2. Servicio de recepción de ficheros de anulación TicketBAI.

Este servicio permite dar entrada a un fichero de anulación TicketBAI.

4.2.1. Medio de envío.

Entorno: Internet.

Protocolo: HTTPS 1.1 (TLS 1.1 o superior).

Modo de envío: POST.

Mensajes: Rest Service.

Codificación: UTF-8. La entrada es un XML que se debe adecuar a la especificación del siguiente esquema de entrada XSD.

La estructura y el formato del fichero de anulación TicketBAI está definido en el anexo II de la presente orden foral.

Cabeceras http requeridas: Content-Type: application/xml;charset=UTF-8.

Certificado: Los softwares TicketBAI que envían información a los servicios web deberán autenticarse con certificado electrónico en la parte cliente. El uso de los servicios requiere tener instalado un certificado electrónico reconocido admitido por la Diputación Foral de Gipuzkoa, en el dispositivo de facturación desde el que se produzca el envío de los ficheros TicketBAI.

Dirección del servicio: https://tbai-z.egoitza.gipuzkoa.eus/sarrerak/baja.

4.2.2. Respuesta.

Entorno: Internet.

Protocolo: HTTPS.

Mensajes: Rest Service.

Codificación: UTF-8. La salida es un XML con codificación UTF-8. El xml se debe adecuar a la especificación del siguiente esquema de salida XSD:

Firma: el mensaje de respuesta no va firmado.

A continuación, a modo de ejemplo, se muestra una respuesta XML resultante de la aplicación de dicho esquema en caso de éxito:

El Código Seguro de Verificación deja constancia de la presentación en la sede electrónica de la Diputación Foral de Gipuzkoa.

A continuación, a modo de ejemplo, se muestra una respuesta XML resultante de la aplicación de dicho esquema en caso de errores de validación:

4.2.3. Códigos de resultado.

El código global de estado recogido en el elemento estado de la respuesta tiene las siguientes posibilidades:

En el caso de recepción incorrecta, puede indicarse una lista de errores en la respuesta, de acuerdo a esta codificación.

5. Otras consideraciones.

5.1. Errores en el procesado de peticiones.

En caso de errores al procesar la petición HTTP, serán comunicadas tal como se describen en el protocolo HTTP estándar.

A modo de resumen como respuesta a una petición se pueden producir los siguientes casos:

5.2. Aclaración sobre escapado de caracteres especiales.

En caso de que fuera necesario consignar en un valor de un elemento XML, alguno de los siguientes caracteres se escapará con las entidades XML siguientes:

ANEXO V
ESPECIFICACIONES DEL CÓDIGO TICKETBAI Y DEL CÓDIGO QR DE LAS FACTURAS O JUSTIFICANTES GENERADOS POR EL SOFTWARE TICKETBAI

De acuerdo con lo establecido en el artículo 7 de la presente orden foral, las facturas o justificantes de las entregas de bienes o de las prestaciones de servicios generadas por el software TicketBAI deberán incluir un código TicketBAI y un código QR generados de acuerdo con las siguientes especificaciones:

• - Código TicketBAI o código identificativo, que consiste en un código formado por número, letras y otros caracteres que identifica a la factura o justificante dentro del sistema TicketBAI. El tipo y el tamaño de la fuente deberán ser similares al del resto de la factura o justificante, asegurando su legibilidad por parte del destinatario de la factura o justificante.
• - Código QR, que consiste en un código con formato QR de tamaño mayor o igual a 30x30 milímetros y menor o igual a 40x40 milímetros.

1. Especificaciones del código TicketBAI.

El código TicketBAI identifica a la factura o justificante generado mediante la utilización del software TicketBAI y asegura la relación con su correspondiente fichero de alta TicketBAI.

El código TicketBAI tiene una longitud fija de 39 caracteres.

El tipo y el tamaño de la fuente del código TicketBAI deberán ser similares al del resto de la factura o justificante, asegurando su legibilidad por parte de su destinatario o destinataria.

El contenido del código TicketBAI es el siguiente:

• - 4 caracteres de texto fijo en mayúscula: TBAI.
• - 1 carácter «-» como separador. Guión medio.
• - 9 caracteres del NIF de la persona o entidad emisora de la factura o justificante.

  Debe corresponder con el NIF, según su formato oficial, incluido en el fichero TicketBAI.

• - 1 carácter «-» como separador. Guión medio.
• - 6 caracteres de la fecha de expedición de la factura o justificante.

  Debe corresponder con la fecha incluida en el fichero de alta TicketBAI en el campo denominado «FechaExpedicionFactura», en formato DDMMAA, sin separadores internos. Cada uno de los subcampos será rellenado con ceros a la izquierda en caso de ser necesario, de manera que el tamaño de la fecha será siempre 6 números en todos los casos (por ejemplo, 010122 sería uno de enero de 2022).

  El formato DDMMAA se compone de: DD: día de la expedición de la factura o justificante; MM: mes de la expedición de la factura o justificante; y AA: Últimos dos dígitos del año de expedición de la factura o justificante. Por ejemplo, para 2022, AA=22.

• - 1 carácter «-» como separador. Guión medio.
• - 13 primeros caracteres de la firma del fichero de alta TicketBAI, es decir, los 13 primeros caracteres del campo SignatureValue del fichero de alta TicketBAI asociado a la factura o justificante.
• - 1 carácter «-» como separador. Guión medio.
• - 3 caracteres que se corresponden con un código de detección de errores cuyo objetivo es garantizar el contenido correcto del identificativo:

  Este dato debe ser calculado por el software TicketBAI y será el resultado de aplicar el algoritmo CRC-8 a la cadena de caracteres anteriormente definidos, es decir, será el resultado de aplicar dicho algoritmo sobre los 36 caracteres anteriores.

La entrada al algoritmo será el contenido del código identificativo generado hasta ese momento (los 36 primeros caracteres del código identificativo) con una codificación UTF-8.

La salida del algoritmo se escribirá en formato decimal completando, en caso de ser necesario, con ceros a la izquierda los 3 últimos caracteres del código TicketBAI.

En el apartado 4 de este anexo se incluye el algoritmo que se utilizará para la comprobación del CRC por parte de la Administración tributaria. La finalidad de la publicación de este algoritmo es permitir que el software de facturación asegure la obtención de los mismos resultados que obtendrá la Administración tributaria.

Se incluye a continuación la composición genérica del código TicketBAI:

TBAI-NNNNNNNNN-DDMMAA-FFFFFFFFFFFFF-CRC

Se incluye a continuación un ejemplo concreto del código TicketBAI, en el cual el contenido de los campos número de identificación fiscal y firma no es válido y sólo se incluyen para poner de manifiesto el formato exigido:

TBAI-00000006Y-251019-btFpwP8dcLGAF-237.

2. Especificaciones del código QR.

Del mismo modo que el código TicketBAI, el código QR identifica a la factura o justificante generado mediante la utilización del software TicketBAI y asegura su relación con su correspondiente fichero de alta TicketBAI.

El código QR es un código con formato QR de tamaño mayor o igual a 30x30 milímetros y menor o igual a 40x40 milímetros.

El contribuyente usuario del software TicketBAI es responsable de asegurar la legibilidad de los códigos QR incluidos en las facturas o justificantes que expida en el desarrollo de su actividad económica. Una factura o justificante cuyo QR no sea legible, no se considerará válida desde el punto de vista de los requisitos de la obligación TicketBAI.

El nivel de corrección de errores del código QR será M. La codificación utilizada para la generación del código será UTF-8.

El contraste de colores entre el código QR y el fondo debe ser lo suficientemente alto para asegurar la legibilidad. A este respecto, se recomienda mantener 6 milímetros de espacio en blanco alrededor de los cuatro lados del código QR.

El código QR debe contener una URL válida para acceder a la aplicación web de comprobación de facturas o justificantes expedidos con software TicketBAI con los datos de la factura o justificante incluidos como parámetros. Si la URL o sus parámetros contienen caracteres no válidos, deberán ser «codificados» (URL encoding) de forma correcta siguiendo los usos normales de las arquitecturas web.

El contenido del código QR será el siguiente:

• - URL de acceso a la aplicación web de lectura del código QR, que será: https://tbai.egoitza.gipuzkoa.eus/gr/ (con «/» al final para el cálculo del CRC).
• - Parámetros:

  Clave	Valor	Descripción
  Id	Código identificativo	Sus especificaciones se recogen en el apartado 1 de este anexo.
  s	Serie de la factura o justificante	Serie de la factura o justificante según la normativa de facturación. Debe corresponder con la serie incluida en el fichero de alta TicketBAI (campo “SerieFactura”).
  nf	Número de la factura o justificante	Número de la factura o justificante según la normativa de facturación. Debe corresponder con el número de factura o justificante incluido en el fichero de alta TicketBAI (tag “NumFactura”).
  i	Importe total de la factura o justificante	Importe de la factura o justificante con IVA incluido. Debe corresponder con el importe total incluido en el fichero de alta TicketBAI (tag “ImporteTotalFactura”), tanto el valor como el formato.
  cr	CRC-8. Código de detección de errores con el objetivo de detectar cambios accidentales en el contenido del código QR.	Este dato debe ser calculado por el software TicketBAI. Se incluirá como último parámetro de la URL. Será el resultado de aplicar el algoritmo CRC-8 a la cadena de caracteres del contenido del QR. La entrada al algoritmo será el contenido del QR generado hasta ese momento con una codificación UTF-8. Por tanto, no se incluirá ni el propio parámetro cr ni su símbolo asociado “&” utilizado para añadirlo al resto de los parámetros (query string). La salida del algoritmo se escribirá en formato decimal como nuevo parámetro de la URL. En el apartado 4 de este anexo se incluye el algoritmo que se utilizará para la comprobación del CRC por parte de la Administración tributaria. La finalidad de la publicación de este algoritmo es permitir que el software TicketBAI asegure la obtención de los mismos resultados que obtendrá la Administración tributaria.

Se incluye a continuación un ejemplo del contenido del código QR:

https://tbai.egoitza.gipuzkoa.eus/qr/?id=TBAI-44619360G-261020-EzyQEMtxw37Gm-161&s=TB-2020-F&nf=419&i=1542.75&cr=182.

Se incluye a continuación un ejemplo del código QR:

3. Especificaciones relativas a la ubicación dentro de la factura o justificante del código identificativo y del código QR.

La ubicación dentro de la factura o justificante del código TicketBAI y del código QR dependerá de su orientación:

• - En una orientación vertical, se ubicarán en la parte más inferior de la factura o justificante. El codigo TicketBAI se incluirá en una única línea y debajo el código QR.
• - En una orientación horizontal, se ubicarán en la parte más a la derecha de la factura o justificante. El código TicketBAI se incluirá en una única línea y debajo el código QR.

En el caso de que el código TicketBAI no pueda ser incluido en una única línea, se permitirán varias líneas consecutivas. El último carácter de cada línea, excepto de la última, será el separador «-» (guion medio).

Las siguientes imágenes sólo deben tenerse en cuenta como ejemplos de la ubicación del código TicketBAI y código QR dentro de la factura o justificante. El contenido, el tamaño y las proporciones de estos ejemplos no son válidos.

Orientación horizontal.

Orientación vertical:

4. Algoritmo CRC de comprobación.