1
DISPOSICIONES GENERALES DEL TERRITORIO HISTÓRICO DE GIPUZKOA

DIPUTACIÓN FORAL DE GIPUZKOA

DEPARTAMENTO DE HACIENDA Y FINANZAS

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.

Con la aprobación de la Norma Foral 3/2020, de 6 de noviembre, por la que se establece la obligación de utilizar herramientas tecnológicas para evitar el fraude fiscal, mediante la modificación de la Norma Foral del Impuesto sobre Sociedades, la Norma Foral del Impuesto sobre la Renta de no Residentes y la Norma Foral del Impuesto sobre la Renta de las Personas Físicas, se determina la obligatoriedad del uso de medidas tecnológicas avanzadas por parte de los contribuyentes a través de nuevos instrumentos tecnológicos en los sistemas de facturación, lo que permitirá el control de la tributación de las personas físicas que desarrollan actividades económicas y de las personas jurídicas, con independencia de su tamaño o volumen.

A lo largo del articulado de la citada Norma Foral se remiten diversas cuestiones a un posterior desarrollo reglamentario de su contenido, tarea que se lleva a cabo mediante la aprobación del Decreto Foral 32/2020, de 22 de diciembre, por el que se aprueba el Reglamento por el que se desarrolla la obligación TicketBAI.

En cuanto al mencionado reglamento, en el mismo se establece que las especificaciones técnicas y funcionales que deberá cumplir el software TicketBAI se aprobarán por orden foral del diputado o de la diputada del Departamento de Hacienda y Finanzas.

En base a lo expuesto, la presente orden foral regula, en su sección primera, las características y especificaciones técnicas y funcionales del software TicketBAI, cuyo contenido se establece en cinco anexos adjuntos a la misma, a saber: los anexos I y II especifican la estructura y validaciones del fichero de alta y de anulación TicketBAI, respectivamente; el anexo III incluye las especificaciones de la firma electrónica de los ficheros TicketBAI; el anexo IV establece las especificaciones técnicas y funcionales y los requisitos del envío de los ficheros TicketBAI; y, por último, el anexo V determina las especificaciones del código identificativo y del código QR incluidos en las facturas o justificantes de las entregas de bienes o de las prestaciones de servicios.   

La sección segunda establece el contenido y la forma de presentación de la declaración de alta en el Registro TicketBAI, que se realizará a través de la sede electrónica de la Diputación Foral de Gipuzkoa, mediante la cumplimentación del formulario que se ponga a su disposición a estos efectos.

Por otro lado, la disposición adicional única establece la obligación de relacionarse con la Administración tributaria por medios electrónicos en todos los trámites y comunicaciones relacionados con el cumplimiento de la obligación TicketBAI.

Finalmente, se establece la entrada en vigor de la orden foral el día siguiente al de su publicación en el Boletín Oficial de Gipuzkoa, con efectos a partir del 1 de enero de 2022, sin perjuicio de que resulte de aplicación para quienes opten por cumplir la obligación TicketBAI voluntariamente a partir del 1 de enero de 2021.

En cumplimiento del desarrollo regulador previsto en el Reglamento por el que se desarrolla la obligación TicketBAI, procede aprobar las especificaciones técnicas y funcionales que desarrollan la obligación TicketBAI.

En su virtud,

dispongo

Artículo 1.  Objeto.

El objeto de la presente orden foral es determinar las características y especificaciones técnicas y funcionales que deben de cumplir el software y los ficheros TicketBAI a los que se refiere el Reglamento por el que se desarrolla la obligación TicketBAI, aprobado por el Decreto foral 32/2020, de 22 de diciembre.

Asimismo, a través de esta orden foral se establece el contenido y forma de presentación de la declaración de alta en el Registro de Software TicketBAI a que se refiere el capítulo VI del citado reglamento.

Artículo 2.  Definiciones.

1.    Los términos empleados en esta orden foral se entenderán conforme a las definiciones contenidas en el artículo 3 del Reglamento por el que se desarrolla la obligación TicketBAI, aprobado por el Decreto Foral 32/2020, de 22 de diciembre.

2.    Además, a efectos de esta orden foral se entenderá por:

a)    Certificado de firma: Documento electrónico expedido por una Autoridad de Certificación que verifica la identidad del firmante del fichero TicketBAI.

b)    Certificado de envío: Documento electrónico expedido por una Autoridad de Certificación que verifica la identidad del remitente del fichero TicketBAI.

Sección Primera.  ‑Especificaciones técnicas y funcionales del Software TicketBAI

Artículo 3.  Fichero de alta TicketBAI.

El fichero de alta TicketBAI incluirá la información a que se refiere el artículo 11 del Reglamento por el que se desarrolla la obligación TicketBAI, aprobado por el Decreto Foral 32/2020, de 22 de diciembre, atendiendo a la estructura, contenido y características del fichero de alta TicketBAI que se especifican en el anexo I a la presente orden foral, y al formato y diseño que consten en la sede electrónica de la Diputación Foral de Gipuzkoa.

La codificación para utilizar deberá ser UTF-8.

Artículo 4.  Fichero de anulación TicketBAI.

Para los casos en los que sea necesario anular una factura o justificante, se generará un fichero de anulación TicketBAI que incluirá la información a que se refiere el artículo 12 del Reglamento por el que se desarrolla la obligación TicketBAI, aprobado por el Decreto Foral 32/2020, de 22 de diciembre, atendiendo a la estructura, contenido y características del fichero de anulación TicketBAI que se recogen en el anexo II a la presente orden foral, y al formato y diseño que consten en la sede electrónica de la Diputación Foral de Gipuzkoa.

La codificación para utilizar deberá ser UTF-8.

Artículo 5.  Firma electrónica de los ficheros TicketBAI.

Los ficheros de alta y de anulación TicketBAI deberán firmarse electrónicamente, atendiendo a las especificaciones de la firma electrónica que se recogen en el anexo III a la presente orden foral.

Artículo 6.  Envío de los ficheros TicketBAI.

Los ficheros de alta y de anulación TicketBAI deberán enviarse a la Administración tributaria, de acuerdo con las especificaciones técnicas y funcionales, y requisitos del envío que se recogen como anexo IV a la presente orden foral.

Artículo 7.  Código TicketBAI y código QR.

Las facturas o justificantes de las entregas de bienes o de las prestaciones de servicios generadas por los softwares TicketBAI incluirán un código TicketBAI y un código QR generados de acuerdo a las especificaciones técnicas y funcionales establecidas en el anexo V de la presente orden foral.

Artículo 8.  Funcionalidad de verificación presencial del software TicketBAI.

El software TicketBAI deberá disponer de una funcionalidad de verificación presencial, en virtud de la cual deberá mostrar la siguiente información en una única pantalla del dispositivo de facturación:

a)    Número de identificación fiscal y apellidos y nombre o razón social o denominación de la persona o entidad desarrolladora del software TicketBAI utilizado desde el dispositivo.

b)    Nombre del software TicketBAI utilizado desde el dispositivo.

c)    Versión del software TicketBAI utilizado desde el dispositivo.

Con carácter opcional, se podrá mostrar igualmente el número de serie del dispositivo desde el cual se muestra la anterior información.

Artículo 9.  Requisitos adicionales del software TicketBAI considerado como aplicación de escritorio.

1.    En relación con el software TicketBAI que tenga la consideración de aplicación de escritorio de acuerdo con lo establecido en el artículo 3 del Reglamento por el que se desarrolla la obligación TicketBAI, aprobado por Decreto Foral 32/2020, de 22 de diciembre, deberán cumplirse los siguientes requisitos adicionales:

a)    Firma electrónica del software TicketBAI.

b)    Conservación de las distintas versiones del software TicketBAI.

2.    Los requisitos adicionales a que se refiere el apartado anterior no se exigirán al software TicketBAI que tenga la consideración de aplicación con arquitectura distribuida de acuerdo con lo establecido en el artículo 3 del Reglamento por el que se desarrolla la obligación TicketBAI, aprobado por el Decreto Foral 32/2020, de diciembre de2020.

3.    El requisito adicional de firma electrónica en relación con el software TicketBAI que tenga la consideración de aplicación de escritorio, al que se refiere la letra a) del apartado 1 anterior, supondrá que:

a)    El archivo instalable en virtud del cual se realiza la distribución del software TicketBAI deberá firmarse electrónicamente por la persona o entidad desarrolladora mediante un certificado electrónico de firma de código emitido por una entidad certificadora reconocida. El certificado deberá mostrar información que garantice la identidad del autor o autora y asegurar la integridad del software.

b)    La instalación de un software TicketBAI que tenga la consideración de aplicación de escritorio deberá solicitar la conformidad del usuario o de la usuaria.

c)    El archivo informático ejecutable del software TicketBAI mediante el cual se arranca dicho software deberá firmarse electrónicamente por la persona o entidad desarrolladora mediante un certificado electrónico de firma de código emitido por una entidad certificadora reconocida.

4.    El requisito adicional de conservación de las distintas versiones del software TicketBAI que tengan la consideración de aplicación de escritorio, al que se refiere la letra b) del apartado 1 anterior, supondrá que la persona o entidad desarrolladora deberá conservar todas las versiones del software TicketBAI distribuidos a sus usuarios y usuarias.

5.    Tanto el software TicketBAI que tenga la consideración de aplicación de escritorio como el que tenga la consideración de aplicación con arquitectura distribuida deberá identificar sus diferentes versiones mediante un código, que vendrá informado en los ficheros de alta y de anulación de operación con software TicketBAI que se generen mediante la utilización de dichos softwares en el campo «versión del software».

Sección segunda.  ‑Declaración de alta en el Registro de Software TicketBAI

Artículo 10.  Declaración de alta en el Registro de Software TicketBAI.

1.    La declaración de alta deberá presentarse a través de la sede electrónica de la Diputación Foral de Gipuzkoa, mediante la cumplimentación del formulario que se ponga a su disposición a estos efectos, que deberá contener, como mínimo, la siguiente información:

a)    Número de identificación fiscal y nombre y apellidos, razón o denominación social completa de la persona o entidad desarrolladora del software TicketBAI.

b)    Nombre del software TicketBAI.

c)    Descripción o información relevante sobre el software TicketBAI.

d)    En su caso, URL de la página web de la persona o entidad desarrolladora.

e)    Indicación de si el software está preparado para trabajar en euskera.

f)    Indicación de si el software TicketBAI va a ser de uso exclusivo para la persona o entidad desarrolladora solicitante y las personas físicas o entidades vinculadas a la misma.

En ese caso, podrá señalar que no desea que el software TicketBAI se incluya en la lista de softwares TicketBAI que se hará pública en la página web de la Diputación Foral de Gipuzkoa.

2.    La presentación telemática de la declaración de alta podrá ser efectuada por la persona o entidad desarrolladora del software TicketBAI, o bien por un tercero que actúe en su representación, de acuerdo con lo establecido en el artículo 46 de la Norma Foral 2/2005, de 8 de marzo, General Tributaria del Territorio Histórico de Gipuzkoa.

3.    El formulario a que se refiere el apartado 1 anterior, incluirá una declaración responsable que deberá suscribir la persona o entidad desarrolladora, en la que deberá manifestar:

a)    Que el software cuya inscripción se solicita cumple con lo dispuesto en el apartado 1 de los artículos 122 bis y 112 bis, en el reglamento por el que se desarrolla la obligación TicketBAI y con las especificaciones técnicas y funcionales aprobadas en esta orden foral, acompañando una breve memoria descriptiva de los procedimientos técnicos empleados para dicho cumplimiento.

b)    Que se obliga a mantener el cumplimiento de los requisitos y condiciones a los que se refiere la letra a) anterior durante el período de tiempo en que el software esté inscrito en el registro, así como que se compromete a adaptarlo a las modificaciones que pudieran darse en dichos requisitos y condiciones.

4.    A la declaración de alta deberá adjuntarse la memoria descriptiva a la que se refiere la letra a) del apartado anterior, en la que deberán describirse los siguientes extremos:

a)    Tipo de software: aplicación de escritorio y/o aplicación con arquitectura distribuida.

b)    Proceso de encadenamiento de los ficheros de alta TicketBAI.

c)    Proceso de firma de los ficheros de alta y de anulación TicketBAI, indicando, en particular, los tipos de certificados electrónicos que pueden ser utilizados por el software TicketBAI para el proceso de firma.

d)    Tipos de facturas o justificantes que genera el software TicketBAI, indicando, en particular, si el software genera:

Facturas simplificadas y/o completas.

Facturas en soporte papel y/o electrónicas.

e)    Ubicación del código TicketBAI y del código QR de acuerdo con lo dispuesto en el artículo 7 de esta orden foral.

f)    Identificación de la opción del software que permita la verificación presencial en una única pantalla de la información a que se refiere el artículo 8 de esta orden foral.

g)    Sistema de almacenamiento de los ficheros de alta y de anulación TicketBAI.

Disposición adicional única.

Los contribuyentes sujetos a la obligación TicketBAI deberán efectuar los trámites y comunicaciones derivados del cumplimiento de dicha obligación por medios electrónicos, de conformidad con lo dispuesto en esta orden foral, así como en el resto de la normativa reguladora específica de la obligación TicketBAI.

Asimismo, los contribuyentes a que se refiere el párrafo anterior estarán obligados a recibir por medios electrónicos las comunicaciones y notificaciones que, por lo que al cumplimiento de la obligación TicketBAI se refiere, efectúe el Departamento de Hacienda y Finanzas de la Diputación Foral de Gipuzkoa.

Disposición final única.  Entrada en vigor.

La presente orden foral entrará en vigor el día siguiente al de su publicación en el Boletín Oficial de Gipuzkoa y surtirá efectos a partir del 1 de enero de 2022, sin perjuicio de lo dispuesto en la disposición adicional única de la Norma Foral 3/2020 de 6 de noviembre, por la que se establece la obligación de utilizar herramientas tecnológicas para evitar el fraude fiscal, y las disposiciones adicionales primera y segunda del Decreto Foral 32/2020, de 22 de diciembre por el que se aprueba el Reglamento por el que se desarrolla la obligación TicketBAI.

San Sebastián, a 23 de diciembre de 2020.—El diputado foral del Departamento de Hacienda y Finanzas, Jokin Perona Lertxundi.                (7008)

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

I. CAMPOS DE REGISTRO Y ESPECIFICACIONES FUNCIONALES DE LOS MENSAJES DE ALTA.

Leyenda:

Rojo =

Rojo = Campos obligatorios.

Negro =

Negro = Campos Opcionales

 

Campos excluyentes

 

Obligatorio en Gipuzkoa

 

Bloque

Datos/ Agrupación

Datos/ Agrupación

Datos/ Agrupación

Datos/ Agrupación

Datos/ Agrupación

Datos/ Agrupación

Datos/ Agrupación

Datos/ Agrupación

Formato

Descripción

Valores

Posibles

Cabecera

IDVersionTBAI

 

 

 

 

 

 

 

Alfanumérico(5)

Identificación de la versión de la estructura del fichero TicketBAI utilizado.

L0

Sujetos

Emisor

NIF

 

 

 

 

 

 

FormatoNIF(9)

NIF del emisor o de la emisora.

 

ApellidosNombre

RazonSocial

 

 

 

 

 

 

Alfanumérico(120)

Apellidos y nombre o razón social o denominación social completa del emisor o de la emisora.

 

Destinatarios

IDDestinatario

(1 a 100)

NIF

 

 

 

 

 

FormatoNIF(9)

NIF del destinatario o de la destinataria.

 

IDOtro

CodigoPais

 

 

 

 

Alfanumérico(2)

Código del país asociado al destinatario o a la destinataria.

(ISO 3166-1

Alpha-2

codes)

L1

IDType

 

 

 

 

Alfanumérico(2)

Clave para establecer el tipo de identificación en el país de residencia.

L2

ID

 

 

 

 

Alfanumérico(20)

Número de identificación en el país de residencia.

 

ApellidosNombreRazonSocial

 

 

 

 

 

Alfanumérico(120)

Apellidos y nombre o razón social o denominación social completa del destinatario o de la destinataria.

 

CodigoPostal

 

 

 

 

 

Alfanumérico(20)

Código postal del destinatario o de la destinataria.

 

Direccion

 

 

 

 

 

Alfanumérico(250)

Dirección postal del destinatario o de la destinataria.

 

Varios
Destinatarios

 

 

 

 

 

 

 

Alfanumérico(1)

Identificador que especifica si la factura tiene varios destinatarios o varias destinatarias. Si no se informa este campo se entenderá que tiene valor «N».

L3

Emitida
PorTerceros
ODestinatario

 

 

 

 

 

 

 

 

 

Alfanumérico(1)

Identificador que especifica si la factura ha sido emitida por un tercero o por el destinatario o la destinataria. Si no se informa este campo se entenderá que tiene valor «N».

L4

Factura

Cabecera
Factura

SerieFactura

 

 

 

 

 

 

Alfanumérico(20)

Serie que identifica a la factura. Se recomienda:

Utilizar el siguiente juego de caracteres:

0123456789ABCDEFGHJKLMNPQRSTUVXYZ.

Evitar las letras I, Ñ, O y W, para mejorar la legibilidad.

No emplear letras minúsculas.

Utilizar un único carácter para el empleo del espacio en blanco.

Ajustar el texto a la izquierda, sin que comience con espacios en blanco.

No utilizar acentos.

Puede utilizarse el guion medio “-“.

 

NumFactura

 

 

 

 

 

 

Alfanumérico(20)

Número de factura que identifica a la factura. Se recomienda:

El número de factura debería contener únicamente caracteres numéricos.

No debe comenzar con espacios en blanco (por lo tanto, texto ajustado a la izquierda).

 

FechaExpedicion Factura

 

 

 

 

 

 

FormatoFecha(10)

Fecha de expedición de la factura.

(dd-mm-aaaa)

HoraExpedicion Factura

 

 

 

 

 

 

FormatoHora(8)

Hora de expedición de la factura.

(hh:mm:ss)

FacturaSimplificada

 

 

 

 

 

 

Alfanumérico(1)

Identificador que especifica si se trata de una factura simplificada o una factura completa. Si no se informa este campo se entenderá que tiene valor «N», entendiéndose que se trata de una factura completa.

L5

FacturaEmitida
Sustitucion
Simplificada

 

 

 

 

 

 

Alfanumérico(1)

Identificador que especifica si se trata de una factura emitida en sustitución de una factura simplificada. Si no se informa este campo se entenderá que tiene valor «N».

L6

FacturaRectificativa

Codigo

 

 

 

 

 

Alfanumérico(2)

Código que identifica el tipo de factura rectificativa.

L7

Tipo

 

 

 

 

 

Alfanumérico(1)

Identifica si el tipo de factura rectificativa es por sustitución o por diferencias.

L8

ImporteRectificacionSustitutiva

BaseRectificada

 

 

 

 

Decimal(12,2)

Base imponible de la factura sustituida.

 

Cuota
Rectificada

 

 

 

 

Decimal(12,2)

Cuota repercutida de la factura sustituida.

 

CuotaRecargo
Rectificada

 

 

 

 

Decimal(12,2)

Cuota del recargo de equivalencia de la factura sustituida.

 

Facturas
Rectificadas
Sustituidas

IDFactura Rectificada Sustituida

(1 a 100)

SerieFactura

 

 

 

 

Alfanumérico(20)

Número de serie que identifica a la factura rectificada o sustituida.

 

NumFactura

 

 

 

 

Alfanumérico(20)

Número de factura, que identifica a la factura rectificada o sustituida.

 

Fecha Expedicion Factura

 

 

 

 

FormatoFecha(10)

Fecha de expedición de la factura rectificada o sustituida.

(dd-mm-aaaa)

Factura

DatosFactura

FechaOperacion

 

 

 

 

 

 

FormatoFecha(10)

Fecha en la que se ha realizado la operación siempre que sea diferente a la fecha de expedición.

(dd-mm-aaaa)

DescripcionFactura

 

 

 

 

 

 

Alfanumérico(250)

Descripción general de las operaciones.

 

DetallesFactura

IDDetalleFactura

(1 a 1000)

Descripcion
Detalle

 

 

 

 

Alfanumérico(250)

Descripción del detalle de la línea de factura.

 

Cantidad

 

 

 

 

Decimal(12,2)

Cantidad de la línea de factura.

 

ImporteUnitario

 

 

 

 

Decimal(12,8)

Importe unitario SIN IVA de la línea de factura.

 

Descuento

 

 

 

 

Decimal(12,2)

Porcentaje de descuento de la línea de factura.

 

ImporteTotal

 

 

 

 

Decimal(12,2)

Importe total CON IVA de la línea de factura.

 

ImporteTotalFactura

 

 

 

 

 

 

Decimal(12,2)

Importe total de la factura.

 

Retencion
Soportada

 

 

 

 

 

 

Decimal(12,2)

Retención soportada.

 

BaseImponibleA
Coste

 

 

 

 

 

 

Decimal(12,2)

Base imponible a coste (para grupos de IVA – nivel avanzado).

 

Claves

IDClave

(1 a 3)

ClaveRegimen
IVAOperacion
Transcendencia

 

 

 

 

Alfanumérico(2)

Clave que identifica el tipo de régimen del IVA o una operación con transcendencia tributaria.

L9

TipoDesglose

DesgloseFactura (cuando la contraparte es un “nacional” o no existe contraparte)

Sujeta

Exenta

DetalleExenta(1 a 7, una agrupación de datos por causa de exención)

CausaExencion

 

 

Alfanumérico(2)

Causa de la exención.

L10

BaseImponible

 

 

Decimal(12,2)

Base imponible exenta en euros correspondiente a la causa de exención.

 

NoExenta

DetalleNoExenta (1 a 2)

TipoNoExenta

 

 

Alfanumérico(2)

Tipo de operación sujeta y no exenta.

L11

DesgloseIVA

DetalleIVA (1 a 6, una agrupación de datos por tipo)

BaseImponible

Decimal(12,2)

Base imponible no exenta. Sobre la base imponible se aplica el tipo impositivo.

 

TipoImpositivo

Decimal(3,2)

Porcentaje aplicado sobre la base imponible para calcular la cuota.

 

CuotaImpuesto

Decimal(12,2)

Cuota repercutida. Será la cuota resultante de aplicar a la base imponible el tipo impositivo.

 

TipoRecargo Equivalencia

Decimal(3,2)

Porcentaje asociado en función del tipo de IVA.

 

CuotaRecargo Equivalencia

Decimal(12,2)

Cuota resultante de aplicar a la base imponible el tipo de recargo de equivalencia.

 

OperacionEn RecargoDe Equivalencia ORegimen Simplificado

Alfanumérico(1)

Identificador que especifica si se trata de una factura expedida por un contribuyente en régimen simplificado o en régimen de recargo de equivalencia. Si no se informa este campo se entenderá que tiene valor «N».

L12

NoSujeta

DetalleNoSujeta (1 a 2)

Causa

 

 

 

Alfanumérico(2)

Causa de la no sujeción.

L13

Importe

 

 

 

Decimal(12,2)

Importe en euros correspondiente a la operación no sujeta.

 

 

Factura

TipoDesglose

Desglo seTipo Opera-cion (Cuando contra- parte es no nacio-nal)

Presta cionSer vicios

Sujeta

Exenta

DetalleExenta (1 a 7, una agrupación de datos por causa de exención)

CausaExencion

 

 

Alfanumérico(2)

Causa de la exención.

L10

BaseImponible

 

 

Decimal(12,2)

Base imponible exenta en euros correspondiente a la causa de exención.

 

NoExenta

DetalleNoExenta (1 a 2)

TipoNoExenta

 

 

Alfanumérico(2)

Tipo de operación sujeta y no exenta.

L11

DesgloseIVA

DetalleIVA

(1 a 6, una agrupación de datos por tipo)

BaseImponible

Decimal(12,2)

Base imponible no exenta. Sobre la base imponible se aplica el tipo impositivo.

 

TipoImpositivo

Decimal(3,2)

Porcentaje aplicado sobre la base imponible para calcular la cuota.

 

CuotaImpuesto

Decimal(12,2)

Cuota repercutida. Será la cuota resultante de aplicar a la base imponible el tipo impositivo.

 

TipoRecargo Equivalencia

Decimal(3,2)

Porcentaje asociado en función del tipo de IVA.

 

CuotaRecargo Equivalencia

Decimal(12,2)

Cuota resultante de aplicar a la base imponible el tipo de recargo de equivalencia.

 

OperacionEn RecargoDe EquivalenciaO Regimen Simplificado

Alfanumérico(1)

Identificador que especifica si se trata de una factura expedida por un contribuyente en régimen simplificado o en régimen de recargo de equivalencia. Si no se informa este campo se entenderá que tiene valor «N».

L12

NoSujeta

DetalleNoSujeta (1 a 2)

Causa

 

 

 

Alfanumérico(2)

Causa de la no sujeción.

L13

Importe

 

 

 

Decimal(12,2)

Importe en euros correspondiente a la operación no sujeta.

 

Entrega

Sujeta

Exenta

DetalleExenta

(1 a 7, una agrupación de datos por causa de exención)

CausaExencion

 

 

Alfanumérico(2)

Causa de la exención.

L10

BaseImponible

 

 

Decimal(12,2)

Base imponible exenta en euros correspondiente a la causa de exención.

 

NoExenta

DetalleNoExenta (1 a 2)

TipoNoExenta

 

 

Alfanumérico(2)

Tipo de operación sujeta y no exenta.

L11

DesgloseIVA

DetalleIVA (1 a 6, una agrupación de datos por tipo)

BaseImponible

Decimal(12,2)

Base imponible no exenta. Sobre la base imponible se aplica el tipo impositivo.

 

TipoImpositivo

Decimal(3,2)

Porcentaje aplicado sobre la base imponible para calcular la cuota.

 

CuotaImpuesto

Decimal(12,2)

Cuota repercutida. Será la cuota resultante de aplicar a la base imponible el tipo impositivo.

 

TipoRecargo Equivalencia

Decimal(3,2)

Porcentaje asociado en función del tipo de IVA.

 

CuotaRecargo Equivalencia

Decimal(12,2)

Cuota resultante de aplicar a la base imponible el tipo de recargo de equivalencia.

 

OperacionEn RecargoDe EquivalenciaO Regimen Simplificado

Alfanumérico(1)

Identificador que especifica si se trata de una factura expedida por un contribuyente en régimen simplificado o en régimen de recargo de equivalencia. Si no se informa este campo se entenderá que tiene valor «N».

 

L12

NoSujeta

DetalleNoSujeta (1 a 2)

Causa

 

 

 

Alfanumérico(2)

Causa de la no sujeción.

L13

Importe

 

 

 

Decimal(12,2)

Importe en euros correspondiente a la operación no sujeta.

 

HuellaTBAI

Encadenamiento FacturaAnterior

SerieFactura Anterior

 

 

 

 

 

 

Alfanumérico(20)

Serie que identifica a la factura anterior.

 

NumFactura Anterior

 

 

 

 

 

 

Alfanumérico(20)

Número de factura que identifica a la factura anterior.

 

FechaExpedicion FacturaAnterior

 

 

 

 

 

 

FormatoFecha(10)

Fecha de expedición de la factura anterior.

(dd-mm-aaaa)

SignatureValue FirmaFactura Anterior

 

 

 

 

 

 

Alfanumérico(100)

Primeros cien caracteres del campo SignatureValue del fichero TicketBAI de la factura anterior.

 

Software

TicketBAI

LicenciaTBAI
(Número de Alta Inscripción)

 

 

 

 

 

 

Alfanumérico(20)

Número de alta-inscripción asignado por la Administración tributaria en el Registro de Software TicketBAI.

 

PersonaOEntidad Desarrolladora

NIF

 

 

 

 

 

FormatoNIF(9)

NIF de la persona o entidad desarrolladora.

Dato asociado a la inscripción en el Registro de Software TicketBAI.

 

IDOtro

CodigoPais

 

 

 

 

Alfanumérico(2)

Código del país asociado a la persona o entidad desarrolladora.

Dato asociado a la inscripción en el Registro de Software TicketBAI.

(ISO 3166-1 alpha-2 codes)

L1

IDType

 

 

 

 

Alfanumérico(2)

Clave para establecer el tipo de identificación en el país de residencia.

Dato asociado a la inscripción en el Registro de Software TicketBAI.

L2

ID

 

 

 

 

Alfanumérico(20)

Número de identificación en el país de residencia.

Dato asociado a la inscripción en el Registro de Software TicketBAI.

 

Nombre

 

 

 

 

 

 

Alfanumérico(120)

Nombre del software TicketBAI.

Dato asociado a la inscripción en el Registro de Software TicketBAI.

 

Version

 

 

 

 

 

 

Alfanumérico(20)

Identificación de la versión del Software TicketBAI utilizado.

 

NumSerie Dispositivo

 

 

 

 

 

 

 

Alfanumérico(30)

Número de serie del dispositivo de facturación utilizado.

 

Signature

 

 

 

 

 

 

 

 

 

Ver “Especificaciones de la firma electrónica de los ficheros TicketBAI” en el anexo III.

 


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

 

L0 → IDVersionTicketBai.

Valores

Descripción

1.2

Versión actual del esquema utilizado.

 

L1 → Código de país.

Se informará según la relación de códigos de países y territorios vigente.

 

L2 → Tipos de identificación en el país de residencia.

Valores

Descripción

02

NIF-IVA.

03

Pasaporte.

04

Documento oficial de identificación expedido por el país o territorio de residencia.

05

Certificado de residencia.

06

Otro documento probatorio.

 

L3 → Varios destinatarios o destinatarias.

Valores

Descripción

S

Sí.

N

No.

 

L4 → Factura emitida por tercero o tercera o por destinatario o destinataria.

Valores

Descripción

N

Factura emitida por el propio emisor o emisora.

T

Factura emitida por tercero o tercera.

D

Factura emitida por el destinatario o la destinataria de la operación.

 

L5 → Factura simplificada.

Valores

Descripción

S

Sí.

N

No.

 

L6 → Factura emitida en sustitución de factura simplificada.

Valores

Descripción

S

Sí.

N

No.

 

L7 → Código de factura rectificativa.

Valores

Descripción

R1

Factura rectificativa: error fundado en derecho y Art. 80 Uno, Dos y Seis de la Ley del IVA.

R2

Factura rectificativa: artículo 80 Tres de la Ley del IVA.

R3

Factura rectificativa: artículo 80 Cuatro de la Ley del IVA.

R4

Factura rectificativa: Resto.

R5

Factura rectificativa en facturas simplificadas.

 

L8 → Tipo de factura rectificativa.

Valores

Descripción

S

Factura rectificativa por sustitución.

I

Factura rectificativa por diferencias.

 

L9 → Clave de régimen especial de IVA y operaciones con trascendencia tributaria.

Valores

Descripción

01

Operación de régimen general y cualquier otro supuesto que no esté recogido en los siguientes valores.

02

Exportación.

03

Operaciones a las que se aplique el régimen especial de bienes usados, objetos de arte, antigüedades y objetos de colección.

04

Régimen especial del oro de inversión.

05

Régimen especial de las agencias de viajes.

06

Régimen especial grupo de entidades en IVA (Nivel Avanzado).

07

Régimen especial del criterio de caja.

08

Operaciones sujetas al IPSI/IGIC (Impuesto sobre la Producción, los Servicios y la Importación  / Impuesto General Indirecto Canario).

09

Facturación de las prestaciones de servicios de agencias de viaje que actúan como mediadoras en nombre y por cuenta ajena (disposición adicional 3ª del Reglamento de Facturación).

10

Cobros por cuenta de terceros de honorarios profesionales o de derechos derivados de la propiedad industrial, de autor u otros por cuenta de sus socios, socias, asociados, asociadas, colegiados o colegiadas efectuados por sociedades, asociaciones, colegios profesionales u otras entidades que realicen estas funciones de cobro.

11

Operaciones de arrendamiento de local de negocio sujetas a retención.

12

Operaciones de arrendamiento de local de negocio no sujetas a retención.

13

Operaciones de arrendamiento de local de negocio sujetas y no sujetas a retención.

14

Factura con IVA pendiente de devengo en certificaciones de obra cuyo destinatario sea una Administración Pública.

15

Factura con IVA pendiente de devengo en operaciones de tracto sucesivo.

51

Operaciones en recargo de equivalencia.

52

Operaciones en régimen simplificado.

53

Operaciones realizadas por personas o entidades que no tengan la consideración de empresarios, empresarias o profesionales a efectos del IVA.

 

L10 → Causa de exención de operaciones sujetas y exentas.

Valores

Descripción

E1

Exenta por el artículo 20 de la Ley del IVA.

E2

Exenta por el artículo 21 de la Ley del IVA.

E3

Exenta por el artículo 22 de la Ley del IVA.

E4

Exenta por el artículo 23 y 24 de la Ley del IVA.

E5

Exenta por el artículo 25 de la Ley del IVA.

E6

Exenta por otra causa.

 

L11 → Tipo no exenta.

Valores

Descripción

S1

Sin inversión del sujeto pasivo.

S2

Con inversión del sujeto pasivo.

 


 

 

L12 → Operación en recargo de equivalencia o régimen simplificado.

Valores

Descripción

S

Si.

N

No.

 

L13 → Causa de no sujeción.

Valores

Descripción

OT

No sujeto por el artículo 7 de la Ley del IVA. Otros supuestos de no sujeción.

RL

No sujeto por reglas de localización.

 

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

I. CAMPOS DE REGISTRO Y ESPECIFICACIONES FUNCIONALES DE LOS MENSAJES DE ANULACIÓN.

Leyenda:

Rojo =

Rojo = Campos obligatorios.

Negro =

Negro = Campos Opcionales

 

Campos excluyentes

 

Obligatorio en Gipuzkoa

 

Bloque

Datos/ Agrupación

Datos/ Agrupación

Datos/ Agrupación

Datos/ Agrupación

Datos/ Agrupación

Datos/ Agrupación

Datos/ Agrupación

Datos/ Agrupación

Formato

Descripción

Valores

Posibles

Cabecera

IDVersionTBAI

 

 

 

 

 

 

 

Alfanumérico(5)

Identificación de la versión de la estructura del fichero TicketBAI utilizado.

L0

IDFactura

Emisor

NIF

 

 

 

 

 

 

FormatoNIF(9)

NIF del emisor o de la emisora.

 

ApellidosNombreRazonSocial

 

 

 

 

 

 

Alfanumérico(120)

Apellidos y nombre o razón social o denominación social completa del emisor o de la emisora.

 

CabeceraFactura

SerieFactura

 

 

 

 

 

 

Alfanumérico(20)

Serie que identifica la factura anulada.

 

 

NumFactura

 

 

 

 

 

 

Alfanumérico(20)

Número de factura que identifica la factura anulada.

 

 

FechaExpedicionFactura

 

 

 

 

 

 

FormatoFecha(10)

Fecha de expedición de la factura anulada.

(dd-mm-aaaa)

HuellaTBAI

Software
TicketBAI

LicenciaTBAI
(Número de alta-inscripción)

 

 

 

 

 

 

Alfanumérico(20)

Número de alta-inscripción asignado por la Administración tributaria en el Registro de Software TicketBAI.

 

PersonaOEntidadDesarrolladora

NIF

 

 

 

 

 

FormatoNIF(9)

NIF de la persona o entidad desarrolladora.

Dato asociado a la inscripción en el Registro de Software TicketBAI.

 

IDOtro

CodigoPais

 

 

 

 

Alfanumérico(2)

Código del país asociado a la persona o entidad desarrolladora.

Dato asociado a la inscripción en el Registro de Software TicketBAI.

(ISO 3166-1 alpha-2 codes)

L1

IDType

 

 

 

 

Alfanumérico(2)

Clave para establecer el tipo de identificación en el país de residencia.

Dato asociado a la inscripción en el Registro de Software TicketBAI.

L2

ID

 

 

 

 

Alfanumérico(20)

Número de identificación en el país de residencia.

Dato asociado a la inscripción en el Registro de Software TicketBAI.

 

Nombre

 

 

 

 

 

 

Alfanumérico(120)

Nombre del software TicketBAI.

Dato asociado a la inscripción en el Registro de Software TicketBAI.

 

Version

 

 

 

 

 

 

Alfanumérico(20)

Identificación de la versión del Software TicketBAI utilizado.

 

NumSerieDispositivo

 

 

 

 

 

 

 

Alfanumérico(30)

Número de serie del dispositivo de facturación utilizado.

 

Signature

 

 

 

 

 

 

 

 

 

Ver “Especificaciones de la firma electrónica de los ficheros TicketBAI” en el anexo III.

 

 


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

 

L0 → IDVersionTicketBai.

Valores

Descripción

1.2

Versión actual del esquema utilizado.

 

L1 → Código de país.

Se informará según la relación de códigos de países y territorios vigente.

 

L2 → Tipos de identificación en el país de residencia.

Valores

Descripción

02

NIF-IVA.

03

Pasaporte.

04

Documento oficial de identificación expedido por el país o territorio de residencia.

05

Certificado de residencia.

06

Otro documento probatorio.

 

 

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)    «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:

TicketBaiResponse xmlns=»http://uri.etsi.org/01903/v1.3.2#» xmlns: ns2=»http://ticketBai.eus»>

TBAI-00000006Y-251019-btFpwP8dcLGAF-237

<FechaRecepcion>01-03-2020 12:31: 34FechaRecepcion>

00

<Descripcion>RecibidoDescripcion>

<Azalpena>JasotaAzalpena>

TBAI33076dde-180d-4484-88ff-094ba2e93587

TicketBaiResponse>

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:

TicketBaiResponse xmlns=»http://uri.etsi.org/01903/v1.3.2#» xmlns: ns2=»http://ticketBai.eus»>

TBAI-00000006Y-251019-btFpwP8dcLGAF-237

<FechaRecepcion>01-03-2020 12:31: 34FechaRecepcion>

01

<Descripcion>RechazadoDescripcion>

<Azalpena>BaztertuaAzalpena>

<ResultadosValidacion>

<Codigo>002/Codigo>

<Descripcion>El mensaje no cumple el esquema XSDDescripcion>

<Azalpena>Mezuak ez du XSDaren egitura betetzenAzalpena >

ResultadosValidacion>

TicketBaiResponse>

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:

VALOR

DESCRIPCIÓN

SIGNIFICADO

00

Recibido

El fichero de alta TicketBAI se ha recibido correctamente.

01

Rechazado

El fichero de alta TicketBAI contiene errores que impiden su recepción.

 

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

Código

Descripción

Errores que suponen rechazo del mensaje

001

Certificado remitente incorrecto (revocado o no homologado).

002

El fichero de alta TicketBAI no cumple el esquema XSD.

003

El fichero de alta TicketBAI no incluye líneas de detalle.

004

Falta dato obligatorio o el dato es erróneo [dato].

005

Fichero de alta TicketBAI ya registrado en el sistema.

006

El servicio de recepción no está disponible. Repita la operación más tarde.

007

Certificado remitente no válido para emisor factura.

017

El tamaño del mensaje no es válido: ha superado el tamaño permitido.

Avisos

008

Error en verificación de firma.

010

Posible error de encadenamiento.

011

Error validación de negocio [dato].

012

Error en verificación alta-inscripción software TicketBAI.

013

Dispositivo de facturación remitente no registrado.

015

Certificado remitente caducado, debe renovar para próximos envíos.

016

Certificado firmante caducado, debe renovar para próximos envíos.

 

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:

TicketBaiResponse xmlns=»http://uri.etsi.org/01903/v1.3.2#» xmlns: ns2=»http://ticketBai.eus»>

TBAI-00000006Y-251019-btFpwP8dcLGAF-237

<FechaRecepcion>01-03-2020 12:30: 11FechaRecepcion>

00

<Descripcion>RecibidoDescripcion>

<Azalpena>JasotaAzalpena>

TBAI33076dde-180d-4484-88ff-094ba2e93587

TicketBaiResponse>

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:

TicketBaiResponse xmlns=»http://uri.etsi.org/
01903/v1.3.2#» xmlns: ns2=»http://ticketBai.eus»>

<FechaRecepcion>01-03-2020 12:25: 52FechaRecepcion>

01

<Descripcion>RechazadoDescripcion>

<Azalpena>BaztertuaAzalpena>

<ResultadosValidacion>

<Codigo>001Codigo>

<Descripcion>Certificado remitente incorrecto (revocado o no homologado)Descripcion>

<Azalpena>Bidaltzailearen ziurtagiria okerra (errebokatua edo ez-homologatua)Azalpena>

ResultadosValidacion>

TicketBaiResponse>

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:

VALOR

DESCRIPCION

SIGNIFICADO

00

Recibido

El fichero de anulación se ha recibido correctamente.

01

Rechazado

El fichero de anulación no se ha recibido.

 

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

Código

Descripción

Errores que suponen rechazo del mensaje.

001

Certificado remitente incorrecto (revocado o no homologado).

002

El fichero de anulación TicketBAI no cumple el esquema XSD.

004

Falta dato obligatorio o el dato es erróneo [dato].

006

El servicio de recepción de ficheros de anulación TicketBAI no está disponible. Repita la operación más tarde.

007

Certificado remitente no válido para emisor factura.

017

El tamaño del mensaje no es válido: ha superado el tamaño permitido.

018

El fichero de alta que se anula no existe en el sistema.

019

El fichero de alta ya ha sido anulado previamente.

Avisos

008

Error en verificación de firma.

012

Error en verificación alta-inscripción software TicketBAI.

013

Dispositivo de facturación remitente no registrado.

015

Certificado remitente caducado, debe renovar para próximos envíos.

016

Certificado firmante caducado, debe renovar para próximos envíos.

 

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:

Resultado en el lado cliente

Acción

Se recibe una respuesta con el formato XML de respuesta esperado.

Petición procesada. Se debe analizar la respuesta para determinar el resultado de la operación.

Se recibe una respuesta con formato incorrecto, no ajustado al formato.

Error en el proceso de la petición. Se debe repetir la petición.

 

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:

Carácter

Carácter escapado

&

&amp;

&lt;

> 

&gt;

 

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 (tagNumFactura”).

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 (tagImporteTotalFactura”), 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.