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., - Boletín Oficial de Gipuzkoa, de 24-12-2020

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 softwareTicketBAIy la declaración de alta en el Registro de SoftwareTicketBAI.

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ónTicketBAI.

En cuanto al mencionado reglamento, en el mismo se establece que las especificaciones técnicas y funcionales que deberá cumplir el softwareTicketBAI 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 softwareTicketBAI, 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ónTicketBAI, respectivamente; el anexo III incluye las especificaciones de la firma electrónica de los ficherosTicketBAI; el anexo IV establece las especificaciones técnicas y funcionales y los requisitos del envío de los ficherosTicketBAI; 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 RegistroTicketBAI, 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ónTicketBAI.

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ónTicketBAIvoluntariamente a partir del 1 de enero de 2021.

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

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 ficherosTicketBAIa los que se refiere el Reglamento por el que se desarrolla la obligaciónTicketBAI, 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 SoftwareTicketBAI 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ónTicketBAI, 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 ficheroTicketBAI.

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

Sección Primera. Especificaciones técnicas y funcionales del SoftwareTicketBAI

Artículo 3. Fichero de altaTicketBAI.

El fichero de altaTicketBAIincluirá la información a que se refiere el artículo 11 del Reglamento por el que se desarrolla la obligaciónTicketBAI, aprobado por el Decreto Foral 32/2020, de 22 de diciembre, atendiendo a la estructura, contenido y características del fichero de altaTicketBAIque 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ónTicketBAI.

Para los casos en los que sea necesario anular una factura o justificante, se generará un fichero de anulaciónTicketBAIque incluirá la información a que se refiere el artículo 12 del Reglamento por el que se desarrolla la obligaciónTicketBAI, aprobado por el Decreto Foral 32/2020, de 22 de diciembre, atendiendo a la estructura, contenido y características del fichero de anulaciónTicketBAI 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 ficherosTicketBAI.

Los ficheros de alta y de anulaciónTicketBAIdeberá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 ficherosTicketBAI.

Los ficheros de alta y de anulaciónTicketBAIdeberá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ódigoTicketBAIy código QR.

Las facturas o justificantes de las entregas de bienes o de las prestaciones de servicios generadas por los softwaresTicketBAIincluirán un códigoTicketBAIy 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 softwareTicketBAI.

El softwareTicketBAIdeberá 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 softwareTicketBAIutilizado desde el dispositivo.

b)Nombre del softwareTicketBAIutilizado desde el dispositivo.

c)Versión del softwareTicketBAIutilizado 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 softwareTicketBAI considerado como aplicación de escritorio.

1.En relación con el softwareTicketBAI 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ónTicketBAI, aprobado por Decreto Foral 32/2020, de 22 de diciembre, deberán cumplirse los siguientes requisitos adicionales:

a)Firma electrónica del softwareTicketBAI.

b)Conservación de las distintas versiones del softwareTicketBAI.

2.Los requisitos adicionales a que se refiere el apartado anterior no se exigirán al softwareTicketBAIque 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ónTicketBAI, aprobado por el Decreto Foral 32/2020, de diciembre de2020.

3.El requisito adicional de firma electrónica en relación con el softwareTicketBAIque 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 softwareTicketBAIdeberá 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 softwareTicketBAI 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 softwareTicketBAI 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 softwareTicketBAIque 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 softwareTicketBAIdistribuidos a sus usuarios y usuarias.

5.Tanto el softwareTicketBAIque 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 softwareTicketBAIque 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 SoftwareTicketBAI

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

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

b)Nombre del softwareTicketBAI.

c)Descripción o información relevante sobre el softwareTicketBAI.

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 softwareTicketBAI 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 softwareTicketBAIse incluya en la lista de softwares TicketBAIque 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 softwareTicketBAI, 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ónTicketBAIy 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 altaTicketBAI.

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

d)Tipos de facturas o justificantes que genera el softwareTicketBAI, 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ódigoTicketBAIy 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ónTicketBAI.

Disposición adicional única.

Los contribuyentes sujetos a la obligaciónTicketBAIdeberá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ónTicketBAI.

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ónTicketBAIse 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 elBoletín Oficialde 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ónTicketBAI.

San Sebastián, a 23 de diciembre de 2020.-El diputado foral del Departamento de Hacienda y Finanzas,JokinPeronaLertxundi. (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 ficheroTicketBAI 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).
		FechaExpedicionFactura								FormatoFecha(10)	Fecha de expedición de la factura.	(dd-mm-aaaa)
		HoraExpedicionFactura								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		IDFacturaRectificada 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.
					FechaExpedicion 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.
									TipoRecargoEquivalencia	Decimal(3,2)	Porcentaje asociado en función del tipo de IVA.
									CuotaRecargoEquivalencia	Decimal(12,2)	Cuota resultante de aplicar a la base imponible el tipo de recargo de equivalencia.
									OperacionEnRecargoDeEquivalencia ORegimenSimplificado	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	DesgloseTipoOpera-cion (Cuando contra- parte es nonacio-nal)	PrestacionSer 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.
									TipoRecargoEquivalencia	Decimal(3,2)	Porcentaje asociado en función del tipo de IVA.
									CuotaRecargoEquivalencia	Decimal(12,2)	Cuota resultante de aplicar a la base imponible el tipo de recargo de equivalencia.
									OperacionEnRecargoDeEquivalenciaORegimen 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.
									TipoRecargoEquivalencia	Decimal(3,2)	Porcentaje asociado en función del tipo de IVA.
									CuotaRecargoEquivalencia	Decimal(12,2)	Cuota resultante de aplicar a la base imponible el tipo de recargo de equivalencia.
									OperacionEnRecargoDeEquivalenciaORegimen 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	EncadenamientoFacturaAnterior	SerieFacturaAnterior								Alfanumérico(20)	Serie que identifica a la factura anterior.
		NumFacturaAnterior								Alfanumérico(20)	Número de factura que identifica a la factura anterior.
		FechaExpedicionFacturaAnterior								FormatoFecha(10)	Fecha de expedición de la factura anterior.	(dd-mm-aaaa)
		SignatureValueFirmaFactura Anterior								Alfanumérico(100)	Primeros cien caracteres del campoSignatureValuedel ficheroTicketBAIde 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 SoftwareTicketBAI.
		PersonaOEntidadDesarrolladora		NIF						FormatoNIF(9)	NIF de la persona o entidad desarrolladora. Dato asociado a la inscripción en el Registro de SoftwareTicketBAI.
				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 SoftwareTicketBAI.	(ISO 3166-1 alpha-2codes) 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 SoftwareTicketBAI.	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 SoftwareTicketBAI.
		Nombre								Alfanumérico(120)	Nombre del softwareTicketBAI. Dato asociado a la inscripción en el Registro de SoftwareTicketBAI.
		Version								Alfanumérico(20)	Identificación de la versión del SoftwareTicketBAIutilizado.
	NumSerieDispositivo									Alfanumérico(30)	Número de serie del dispositivo de facturación utilizado.
Signature											Ver 'Especificaciones de la firma electrónica de los ficherosTicketBAI' 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 emitidaportercerooterceraopordestinatarioodestinataria.

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 ficherosTicketBAI(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 ficherosTicketBAI, 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 ficheroTicketBAI.

-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 ficherosTicketBAI es elFormatoXAdES(XMLAdvancedElectronicSignatures), 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 prefijosds: yxades: para hacer referencia a elementos definidos en los estándaresXMLDSigyXAdES, respectivamente.

Dentro de las distintas clases del formatoXAdESse 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 oTimeStamping 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 Oficialde 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 paraelo 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 ficheroTicketBAIa firmar no incluye contenido dinámico que pudiese modificar el resultado de la firma durante el tiempo. Si el ficheroTicketBAIa firmar no ha sido creado por el o la firmante, esta persona deberá asegurarse de que no existe contenido dinámico dentro del ficheroTicketBAI (como pueden ser macros).

FormatoXAdES: se admitirán exclusivamente las firmasXAdESenveloped. No se admitiráXAdESenveloping, niXAdESdettached.

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

-SigningTime: especifica el momento en que el o la firmante realizó el proceso de firma.

-SigningCertificatev2 oSigningCertificate: 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 elementoxades: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, 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 campoSignedProperties serán consideradas de carácter opcional:

-SignatureProductionPlacev2 oSignatureProductionPlace: define el lugar geográfico donde se ha realizado la firma del documento.

-SignerRolev2 oSignerRole: 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 campoClaimedRoles:

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 ends: Reference.

-IndividualDataObjectsTimeStamp: contiene un sello de tiempo, calculado antes de la generación de la firma, sobre algunos de los elementos contenidos ends: Reference.

La etiquetaCounterSignature, refrendo de la firma electrónica y que se puede incluir en el campoUnsignedProperties, será considerada de carácter opcional. Las siguientes firmas, ya sean serie o paralelo, se añadirán según indica el estándarXAdES, 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:

-SigningTime: 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 oSigningCertificate: 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 lasCRLs 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 softwareTicketBAI.

4.1.Certificados admitidos.

El softwareTicketBAIdeberá utilizar alguno de los siguientes certificados para la firma electrónica de los ficherosTicketBAI:

-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 softwareTicketBAIde 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 softwareTicketBAI 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 softwareTicketBAI 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 deBizkaia. (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 ficherosTicketBAIde la Diputación Foral de Gipuzkoa recepcionelos 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 ficherosTicketBAIse 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 ficheroTicketBAI, 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 ficheroTicketBAIno 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 ficheroTicketBAIsupera 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 altaTicketBAIy otro para el envío de los ficheros de anulaciónTicketBAI.

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

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

2.1.1. Recibido.

Cuando el envío del ficheroTicketBAItenga este resultado indicará que el ficheroTicketBAIha 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 ficheroTicketBAI, se comunicarán en la respuesta del servicio o posteriormente por otro canal. Estos avisos no suponen, a priori, el rechazo del ficheroTicketBAI, pero el remitente ha de tenerlos en cuenta para próximos envíos.

2.1.2. Rechazado.

Significa que el ficheroTicketBAIno 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 ficheroTicketBAIrecibido en la presentación no es conforme a la definida (no cumple las validaciones estructurales), o bien, existen errores sintácticos en el ficheroTicketBAI.La respuesta indicaque ha habido error de validación de la estructura.

-No cumple ciertas validaciones mínimas en el contenido del ficheroTicketBAI. Por ejemplo, en el caso de envío de un fichero de altaTicketBAI:

-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ódigoTicketBAI.

2.2. Tratamiento de los ficherosTicketBAIrechazados.

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

Se deberán reenviar los ficherosTicketBAIuna vez corregidos los errores.

2.3. Tratamiento de los ficherosTicketBAIrecibidos.

Los ficherosTicketBAI 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 softwaresTicketBAI 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 ficheroTicketBAI 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 ficherosTicketBAIcon motivo del cumplimiento de la obligaciónTicketBAI.

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 ficheroTicketBAI, de alta o anulación, objeto del envío.

3.2. Estándares utilizados.

Los servicios webRESTful son servicios diseñados para exponerAPIso 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 serviciosRESFful.

La estructura de los ficherosTicketBAIse 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 elnamespace 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 altaTicketBAI.

Este servicio permite dar entrada a un fichero de altaTicketBAIen 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:RestService.

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 altaTicketBAI, en el formato y estructura descritas en el anexo I de la presente orden foral.

Este documento contiene un PDF, para descargarlo pulse AQUI

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

Certificado: Los softwaresTicketBAIque 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:RestService.

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

Este documento contiene un PDF, para descargarlo pulse AQUI

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:

TBAI-00000006Y-251019-btFpwP8dcLGAF-237

01-03-2020 12:31: 34

00

Recibido

Jasota

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

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:

TBAI-00000006Y-251019-btFpwP8dcLGAF-237

01-03-2020 12:31: 34

01

Rechazado

Baztertua

002/Codigo>

El mensaje no cumple el esquema XSD

MezuakezduXSDaren egiturabetetzen

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 altaTicketBAI se ha recibido correctamente.
01	Rechazado	El fichero de altaTicketBAI 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 altaTicketBAIno cumple el esquema XSD.
003	El fichero de altaTicketBAIno incluye líneas de detalle.
004	Falta dato obligatorio o el dato es erróneo [dato].
005	Fichero de altaTicketBAIya 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 softwareTicketBAI.
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ónTicketBAI.

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

4.2.1.Medio de envío.

Entorno: Internet.

Protocolo: HTTPS 1.1 (TLS 1.1 o superior).

Modo de envío: POST.

Mensajes:RestService.

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ónTicketBAIestá definido en el anexo II de la presente orden foral.

Este documento contiene un PDF, para descargarlo pulse AQUI

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

Certificado: Los softwaresTicketBAIque 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 ficherosTicketBAI.

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

4.2.2.Respuesta.

Entorno: Internet.

Protocolo: HTTPS.

Mensajes:RestService.

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

Este documento contiene un PDF, para descargarlo pulse AQUI

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:

TBAI-00000006Y-251019-btFpwP8dcLGAF-237

01-03-2020 12:30: 11

00

Recibido

Jasota

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

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:

01-03-2020 12:25: 52

01

Rechazado

Baztertua

001

Certificado remitente incorrecto (revocado o no homologado)

Bidaltzailearenziurtagiriaokerra(errebokatuaedoez-homologatua)

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ónTicketBAIno 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ónTicketBAIno está disponible. Repita la operación más tarde.
007	Certificado remitente no válido para emisor factura.
017	El tamaño del mensajeno 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 softwareTicketBAI.
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
&	&
	>

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 softwareTicketBAIdeberán incluir un códigoTicketBAIy un código QR generados de acuerdo con las siguientes especificaciones:

-CódigoTicketBAIo 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 sistemaTicketBAI. 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ódigoTicketBAI.

El códigoTicketBAIidentifica a la factura o justificante generado mediante la utilización del softwareTicketBAIy asegura la relación con su correspondiente fichero de altaTicketBAI.

El códigoTicketBAItiene una longitud fija de 39 caracteres.

El tipo y el tamaño de la fuente del códigoTicketBAIdeberá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ódigoTicketBAIes el siguiente:

- 4 caracteres de texto fijo en mayúscula: TBAI.

- 1 carácter «-» como separador.Guiónmedio.

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

- 1 carácter «-» como separador.Guiónmedio.

- 6 caracteres de la fecha de expedición de la factura o justificante.

Debe corresponder con la fecha incluida en el fichero de altaTicketBAI en el campo denominado «FechaExpedicionFactura», en formato DDMMAA, sin separadores internos. Cada uno de lossubcampos 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ónmedio.

- 13 primeros caracteres de la firma del fichero de altaTicketBAI, es decir, los 13 primeros caracteres del campoSignatureValue del fichero de altaTicketBAIasociado a la factura o justificante.

- 1 carácter «-» como separador.Guiónmedio.

- 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 softwareTicketBAIy 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ódigoTicketBAI.

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ódigoTicketBAI:

TBAI-NNNNNNNNN-DDMMAA-FFFFFFFFFFFFF-CRC

Se incluye a continuación un ejemplo concreto del códigoTicketBAI, 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ódigoTicketBAI, el código QR identifica a la factura o justificante generado mediante la utilización del softwareTicketBAIy asegura su relación con su correspondiente fichero de altaTicketBAI.

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 softwareTicketBAIes 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ónTicketBAI.

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 softwareTicketBAI 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» (URLencoding) 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 altaTicketBAI (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 altaTicketBAI(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 altaTicketBAI(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 softwareTicketBAI. 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ámetrocr ni su símbolo asociado '&' utilizado para añadirlo al resto de los parámetros (querystring). 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 softwareTicketBAI 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:

Este documento contiene un PDF, para descargarlo pulse AQUI

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ódigoTicketBAIy 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. ElcodigoTicketBAIse 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ódigoTicketBAI se incluirá en una única línea y debajo el código QR.

En el caso de que el códigoTicketBAIno 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ódigoTicketBAIy 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.

Este documento contiene un PDF, para descargarlo pulse AQUI

Orientación vertical:

Este documento contiene un PDF, para descargarlo pulse AQUI

4.Algoritmo CRC de comprobación.

Este documento contiene un PDF, para descargarlo pulse AQUI