DECLARACIÓN RESPONSABLE DEL SISTEMA INFORMÁTICO DE FACTURACIÓN

1.a) Nombre del sistema informático a que se refiere la declaración responsable

elpizzero

1.b) Código identificador del sistema informático a que se refiere el apartado 1.a)

EP

1.c) Identificador completo de la versión concreta del sistema informático a que se refiere la declaración responsable

2026.10.54

1.d) Componentes, hardware y software, de que consta el sistema informático a que se refiere la declaración responsable, junto con una breve descripción de lo que hace dicho sistema informático y de sus principales funcionalidades

elpizzero es un sistema de facturación en modalidad SaaS: toda la lógica de facturación se ejecuta en un servidor del productor, que es donde se generan, encadenan y conservan los registros de facturación. Los usuarios acceden por navegador o con las aplicaciones de elpizzero para Android (incluidos los terminales Sunmi y Citaq) y para Windows (TPV, pantalla de cocina y recepción de pedidos), que abren esas mismas pantallas desde el servidor y se limitan a funciones del propio aparato, como la impresión de tickets; no generan, modifican ni conservan registros de facturación.

Consta de:

• Servidor de aplicación (PHP 8.3 sobre Linux, base de datos MariaDB) que concentra toda la lógica de facturación y es donde se generan y conservan los registros de facturación.
• Interfaz web de gestión para el obligado tributario: carta, pedidos, libro de facturas, registros de evento, datos fiscales y configuración de impuestos.
• Terminal de punto de venta (TPV) sobre navegador, utilizable en dispositivos Android de hostelería. No genera registros por su cuenta: los solicita al servidor, que es quien los crea, encadena y conserva.
• Pantalla de cocina (KDS), aplicación de recepción de pedidos y página pública de carta y pedidos, que no generan registros por su cuenta: cuando cierran una venta, el registro lo genera el servidor.

Funcionalidades relativas a la facturación: expedición de facturas simplificadas y completas, numeración correlativa por serie, cálculo y desglose de impuestos, generación del registro de facturación con huella encadenada, generación de registros de evento, libro de facturas expedidas con exportación, facturas de anticipo (señales de encargos y fianzas de reservas) y sus rectificativas, y remisión a la AEAT en modalidad VERI*FACTU cuando el obligado la activa.

El sistema permite gestionar de forma independiente la facturación de varios obligados tributarios, cumpliendo separadamente con la normativa del apartado 1.k) para cada uno, como si se tratara de sistemas informáticos de facturación distintos, cada uno con su propio número de instalación. Cuando un mismo obligado tributario tiene varios establecimientos unidos en el sistema, generan sus registros en una única cadena de registros de facturación, la de ese obligado tributario, y cada establecimiento numera sus facturas con su propia serie.

El sistema identifica dónde tributa cada obligado tributario. A quienes tienen su domicilio fiscal en los Territorios Históricos del País Vasco o en la Comunidad Foral de Navarra, a los que no se aplica el Reglamento, el sistema no les genera registros de facturación VERI*FACTU. En el País Vasco no permite expedir facturas hasta que el obligado tributario disponga de TicketBAI conforme a su normativa foral. En Canarias, Ceuta y Melilla, el registro de facturación identifica el impuesto que se aplica (IGIC o IPSI) y las facturas lo nombran como tal.

1.e) Indicación de si el sistema informático a que se refiere la declaración responsable se ha producido de tal manera que, a los efectos de cumplir con el Reglamento, solo pueda funcionar exclusivamente como «VERI*FACTU»

N – No. Soporta las dos modalidades y la elige cada obligado tributario; los obligados tributarios con varios establecimientos en una misma cadena utilizan por ahora la modalidad no VERI*FACTU. Desde la versión 2026.10.52, la modalidad VERI*FACTU (alta, renuncia o anulación de la renuncia) solo cambia por una acción expresa del obligado tributario en la pantalla de configuración, que muestra marcada la modalidad que el obligado ha elegido, incluida la renuncia ya comunicada. Guardar otros datos (NIF, entorno) no altera la modalidad ni las fechas de inicio o fin del periodo. La credencial de remisión solo se exige al entrar en VERI*FACTU (Orden HAC/1177/2024, art. 17).

1.f) Indicación de si el sistema informático a que se refiere la declaración responsable permite ser usado por varios obligados tributarios o por un mismo usuario para dar soporte a la facturación de varios obligados tributarios

S – Sí

1.g) Tipos de firma utilizados para firmar los registros de facturación y de evento en el caso de que el sistema informático a que se refiere la declaración responsable no sea utilizado como «VERI*FACTU»

Los registros de facturación de alta y de anulación, y los registros de evento, se firman electrónicamente con firma XAdES Enveloped Signature, clase EPES, conforme al estándar ETSI EN 319 132 / TS 101 903, con estos parámetros:

La firma se genera con la clave privada asociada a un certificado electrónico cualificado de firma electrónica en vigor, emitido por un prestador cualificado de servicios de confianza conforme al Reglamento (UE) n.º 910/2014 e incluido en la lista de confianza de la UE, que debe aportar el obligado tributario.

El sistema firma cada registro inmediatamente después de generarlo y, si en ese momento no es posible, de forma automática poco después, a partir de la fecha que indica el obligado tributario y una vez incorporado su certificado; un certificado caducado no se utiliza para firmar. El certificado puede ser del propio obligado tributario o de un apoderado suyo para este trámite: cuando el obligado tributario no tiene un certificado propio en vigor configurado para firmar, ha otorgado apoderamiento en la sede electrónica de la AEAT al titular del certificado con el que firma la plataforma y, además, le ha autorizado expresamente en el propio sistema, como representante autorizado, a firmar en su nombre sus registros de facturación y de evento (autorización que se conserva de forma inalterable con su texto, fecha y autor, y que puede revocar en cualquier momento), una vez comprobado ese apoderamiento el sistema firma sus registros con dicho certificado a partir del momento en que se comprueba, sin firmar los registros anteriores, y deja de hacerlo cuando vence la fecha de fin del apoderamiento o cuando el obligado tributario revoca la autorización o retira esta opción. En modalidad VERI*FACTU, la remisión a la AEAT se autentica con el certificado del obligado tributario o, en las mismas condiciones, con el del apoderado. El sistema impide expedir facturas cuando el obligado no tiene consignados su nombre y apellidos o razón social y su domicilio fiscal (RD 1619/2012, arts. 6.1.c, 6.1.e y 7.1.d), igual que sin NIF válido; el NIF del obligado se normaliza al guardarlo, y la factura, el registro de facturación y el certificado de firma usan siempre el mismo NIF. Desde el 15 de octubre de 2026, si el obligado no tiene la firma de sus registros verificada (firma por apoderado confirmada, certificado propio en vigor o VERI*FACTU con credencial de envío), el sistema no permite vender por ningún canal: carta web, mesa QR, TPV (también el programa de Windows y las aplicaciones Android), recepción, panel, interfaz de programación e integraciones; tampoco emite facturas de señales ni de fianzas, y la carta pública queda cerrada temporalmente hasta que la firma se verifica. Mientras tanto, el sistema tampoco genera ni firma ningún registro de facturación nuevo de ese obligado, incluidos los de operaciones anteriores que se cierren después (por ejemplo, en el cierre automático del día): quedan pendientes, consta la incidencia y se firman en cuanto la firma está verificada; las facturas rectificativas no se bloquean. Sin un certificado en vigor con el que remitir, propio o de su apoderado, el sistema no permite registrar nuevas ventas en la modalidad VERI*FACTU; una incidencia técnica en la remisión no impide facturar, y los registros se remiten al resolverse (Orden HAC/1177/2024, art. 16). En la modalidad no VERI*FACTU, el sistema no permite registrar nuevas ventas sin un certificado en vigor configurado para firmar, propio o de su apoderado. A los obligados tributarios dados de alta antes del 8 de octubre de 2026 se les concede hasta el 15 de octubre de 2026 para incorporarlo, otorgar el apoderamiento o pasar a la modalidad VERI*FACTU, y durante ese plazo se les advierte en el panel; a los dados de alta desde esa fecha se les exige desde el primer día.

1.h) Nombre y apellidos de la persona o razón social de la entidad productora del sistema informático a que se refiere la declaración responsable

Ángel Rives García

1.i) Número de identificación fiscal (NIF) español de la persona o entidad productora del sistema informático a que se refiere la declaración responsable

15415960A

1.j) Dirección postal completa de contacto de la persona o entidad productora del sistema informático a que se refiere la declaración responsable

Calle Redován 3, 03350 Cox (Alicante), España

1.k) Declaración de cumplimiento de la persona o entidad productora del sistema informático a que se refiere la declaración responsable

La persona productora del sistema informático a que se refiere esta declaración responsable hace constar que dicho sistema informático, en la versión indicada en ella, cumple con lo dispuesto en el artículo 29.2.j) de la Ley 58/2003, de 17 de diciembre, General Tributaria, en el Reglamento que establece los requisitos que deben adoptar los sistemas y programas informáticos o electrónicos que soporten los procesos de facturación de empresarios y profesionales, y la estandarización de formatos de los registros de facturación, aprobado por el Real Decreto 1007/2023, de 5 de diciembre, en la Orden HAC/1177/2024, de 17 de octubre, y en la sede electrónica de la Agencia Estatal de Administración Tributaria para todo aquello que complete las especificaciones de dicha orden.

1.l) Fecha y lugar en los que la persona o entidad productora del sistema informático suscribe la declaración responsable del mismo

Fecha: 15 de octubre de 2026
Lugar: Cox (Alicante) – España

Fdo.: Ángel Rives García

Anexo

Conforme al artículo 13 del Reglamento aprobado por el Real Decreto 1007/2023, de 5 de diciembre, y al artículo 15 de la Orden HAC/1177/2024, de 17 de octubre.

2.a) Otras formas de contacto

• Correo electrónico: hola@elpizzero.com
• Teléfono: +34 664 37 36 76

2.b) Direcciones de internet

• Sitio web: https://elpizzero.com
• Histórico de declaraciones responsables: https://elpizzero.com/legal/declaracion-responsable

2.c) Cómo cumple las especificaciones técnicas

Además de lo de obligado cumplimiento (algoritmo de huella SHA-256 según las especificaciones publicadas en la sede electrónica de la AEAT), se hace constar:

• La expedición de la factura y la generación de su registro de facturación se consolidan en una única unidad transaccional del gestor de base de datos.
• El registro de facturación se genera cuando el importe de la venta queda fijado y ya no puede modificarse, de modo que el importe registrado es el definitivo: por defecto, al cerrarse la venta, sea cual sea el medio por el que se cierre (TPV, pantalla de cocina, aplicación de recepción, ficha del pedido, interfaz de programación o cierre automático); en los pedidos para llevar y a domicilio, al entrar el pedido o al quedar listo para su entrega o salir en reparto, según elija el obligado tributario, y en los pedidos para llevar y a domicilio que el cliente realiza por la carta en línea. También se genera antes del cierre si se solicita el documento de la factura del pedido. Los encargos para otro día no se facturan al entrar, sino al cerrarse la venta o al cobrarse. Si en el momento previsto el registro no puede generarse, se intenta de nuevo al cerrarse la venta y, a partir de entonces, de forma automática cada quince minutos; lo que siga sin poder registrarse se avisa al obligado tributario. Una venta de más de 3.000 euros no puede cerrarse desde el TPV, desde la ficha del pedido ni desde la aplicación de recepción sin los datos del destinatario. Desde que se expide, la factura y su importe no se modifican: lo que se añade o se quita después se factura aparte, como se indica a continuación.
• La leyenda «Factura registrada · RD 1007/2023» solo se imprime junto al código QR de un registro de facturación existente. Los textos legales de tickets y facturas dependen del país del obligado tributario y no del idioma del ticket: el sistema no imprime leyendas de cumplimiento de sistemas de otros países, y fuera de España no cita el RD 1619/2012 ni el RD 1007/2023 y rotula el documento como justificante de venta.
• Las facturas expedidas con otro sistema de facturación conforme a su propia normativa (TicketBAI en el País Vasco) no forman parte de la cadena de registros de facturación ni de los registros que se remiten a la AEAT, y el sistema no permite anularlas ni rectificarlas mediante registros de este Reglamento: cada una se anula o rectifica con su propio sistema y, si este no lo permite, la operación se bloquea. Sus facturas y tickets no llevan leyendas ni código QR de este Reglamento.
• Las facturas expedidas por un TPV con chip de seguridad forman parte de la cadena de registros de ese dispositivo, con su propia serie y su propio número de instalación, y no de la del servidor, y se remiten a la AEAT desde el servidor exactamente como las generó el dispositivo, solo mientras el obligado tributario está en la modalidad VERI*FACTU. Su anulación o rectificación (devoluciones) la realiza el servidor mediante registros de su propia cadena que identifican la factura del dispositivo, y no se remite a la AEAT antes que el registro de alta de esa factura. A esas facturas no se les añaden ni se les quitan líneas: se corrigen mediante devolución, con su factura rectificativa. Con conexión, el TPV con chip solo expide la factura de una venta que se cobra en ese mismo dispositivo: al cobrarla, el chip la reclama al servidor con su firma y el servidor le entrega el desglose firmado, que es lo único que el chip puede facturar. Una venta que nadie reclama (por ejemplo, cerrada en otro puesto) o que el chip no puede expedir (por ejemplo, porque lleva propina o señal) la expide el servidor; mientras está reclamada, el servidor no la expide hasta que el chip renuncie a ella con su firma, y el chip no expide nunca dos facturas de la misma venta, de modo que cada venta tiene una sola factura. Si el dispositivo se avería o se pierde, el obligado tributario puede darlo de baja: queda cerrado para siempre, el servidor no le admite ningún registro más y las ventas que tenía reclamadas sin factura las expide el servidor.
• El importe que el TPV muestra mientras se prepara el pedido aplica el mismo precio por tipo de servicio (en el local, para recoger o a domicilio) que el servidor usa al registrar la venta; el importe de la factura y de su registro de facturación lo calcula el servidor; en el TPV con chip de seguridad, el servidor calcula y firma el desglose de cada venta con conexión y el dispositivo expide la factura con ese desglose, y durante una pérdida de conexión el dispositivo lo calcula con la carta de precios y tipos impositivos firmada por el servidor, aplicando las mismas reglas.
• Lo que se añade a un pedido cuya factura ya se ha expedido se factura aparte, en una factura nueva por lo añadido, enlazada al pedido; la factura original no se modifica, no se anula y no se rectifica por ello. Esto se aplica a los pedidos para llevar y a domicilio; en los demás casos (consumo en el local o pedidos ya cerrados) el sistema no admite añadir nada a un pedido ya facturado.
• En los pedidos para llevar y a domicilio, lo que se quita de un pedido cuya factura ya se ha expedido, mientras el pedido no se ha cobrado ni entregado, se corrige mediante una factura rectificativa por diferencias, con importes negativos, expedida automáticamente en la serie de rectificativas, que identifica la factura rectificada y se imprime para su entrega al cliente; la factura original no se modifica ni se anula. Si el pedido ya se ha cobrado o entregado, la corrección se hace mediante devolución, con su factura rectificativa, que nunca supera lo pendiente de rectificar. Un pedido con facturas por lo añadido o rectificativas vigentes no puede cancelarse sin cancelar antes estas, y una factura rectificativa ya aplicada en el cobro no se cancela. Si se cancela sin cobrar un pedido cuya factura ya se había entregado al cliente (impresa o enviada), se expide una factura rectificativa por el total en lugar de un registro de anulación; el registro de anulación queda para las facturas que no consta que se hayan entregado. Desde el panel, el registro de anulación solo se admite para facturas no cobradas que no consta que se hayan entregado.
• Cuando el cliente no se presenta a una reserva y el obligado tributario retiene la fianza cobrada, la factura de anticipo de esa fianza se rectifica por su totalidad, porque la cantidad retenida tiene naturaleza indemnizatoria y no está sujeta al impuesto.
• La numeración de la factura se asigna en el mismo acto que su registro, de manera que una operación anulada antes de expedirse no consume numeración ni deja saltos en la serie.
• Las facturas rectificativas se expiden en una serie específica, distinta de la de las facturas ordinarias y con su propia numeración correlativa.
• Las facturas de pedidos y de señales de importe superior a 3.000 euros se expiden como facturas completas, en una serie propia, y no se expiden sin el nombre o razón social, el NIF y el domicilio del destinatario. Las fianzas de reserva, que se facturan como simplificadas, no superan los 3.000 euros. La devolución de una factura completa se rectifica con una factura rectificativa del tipo de las completas.
• Antes de empezar a facturar, y solo si el obligado tributario no tiene todavía ningún registro de facturación y ya tiene preparada la firma electrónica de sus registros o la modalidad VERI*FACTU, el sistema permite un único periodo de pruebas de siete días como máximo. Durante ese periodo las facturas se expiden y se registran con normalidad, firmadas y encadenadas, pero en una serie específica de pruebas («PRU»), y la factura lleva la mención «FACTURA DE PRUEBAS · SIN VALIDEZ»; solo pueden hacer pedidos las personas usuarias del propio obligado tributario, y no se admiten pagos en línea, señales en línea ni pedidos de otros canales. Al terminar el periodo, a petición del obligado tributario o automáticamente a los siete días, el sistema genera el registro de anulación de todas las facturas de la serie de pruebas y las conserva, junto con sus registros. El periodo no puede repetirse ni reabrirse, y la propia base de datos lo impide.
• El sistema permite al obligado tributario identificar las bebidas alcohólicas y las bebidas refrescantes, zumos y gaseosas con azúcares o edulcorantes añadidos; en las ventas para llevar y a domicilio, que no constituyen servicio de restauración, les aplica el tipo general del IVA, y en el establecimiento, el tipo reducido del servicio de restauración. Los gastos de envío de un pedido con varios tipos impositivos se reparten entre ellos en proporción a su importe.
• Si el obligado tributario lo activa, el sistema añade el precio de los envases de plástico de un solo uso y de las bolsas que solicite el cliente a los pedidos para llevar y a domicilio de la carta en línea y a los del TPV que aún no se han cobrado, en líneas diferenciadas de la factura (Ley 7/2022, art. 55.2; Real Decreto 293/2018, art. 4) y con su propio tipo impositivo: el envase, el del producto que contiene, y la bolsa, el tipo general del IVA. Los descuentos del pedido no se aplican a esas líneas. Esta función solo está disponible con el IVA de la península y Baleares.
• Las facturas de anticipo de las señales de encargos desglosan cada tipo impositivo en la proporción del pedido en el momento de expedirse, y ese desglose se conserva inalterado y es el que usa su rectificativa; las de las fianzas de reserva se expiden al tipo impositivo por defecto del obligado tributario. La factura final descuenta el anticipo.
• Cuando la factura se expide en un día distinto al de la operación, el registro de facturación y la factura en PDF indican la fecha de la operación.
• Una factura expedida no puede modificarse ni cancelarse desde el sistema: solo puede corregirse mediante el correspondiente registro de anulación o factura rectificativa.
• El TPV envía a imprimir la factura, con su número y su código QR, en el momento de su expedición, para su entrega al cliente: al cerrar la venta, al quedar el pedido listo o salir en reparto o, cuando se expide al entrar el pedido, en el primer ticket del pedido. Las facturas de pedidos que no se imprimen en un TPV (las expedidas desde la pantalla de cocina, el reparto o el cierre automático, o los pedidos en línea que no se imprimen al recibirse) se muestran al obligado tributario como pendientes de entregar, con su documento para imprimirlo o enviarlo.
• Con las plantillas de ticket de cliente, los tickets que se imprimen antes de expedirse la factura indican «JUSTIFICANTE DE PEDIDO · NO ES FACTURA» o su traducción al idioma del ticket. Los tickets de cliente que imprime el TPV (justificantes y facturas) se registran en el servidor cuando el TPV tiene conexión, y ese registro se conserva de forma inalterable durante seis ejercicios, sin los datos personales del cliente que no forman parte de la factura.
• La propia base de datos impide borrar las operaciones ya registradas y modificar, una vez generados, la huella, la referencia al registro anterior, el número de orden en la cadena y la fecha y hora de generación de cada registro; en las facturas de pedido, además, su número, fecha de expedición, tipo, importes y líneas. También impide borrar los registros de evento, los registros firmados y las remisiones a la AEAT, y modificar los registros de evento salvo para añadirles su firma, así como cambiar el NIF, el país o el territorio fiscal del obligado tributario cuando ya tiene registros. La razón social y el desglose de impuestos de las facturas de pedido se conservan tal como estaban al generar el registro. Tampoco permite que la numeración de las series retroceda, ni modificar los complementos de las líneas de una factura de pedido expedida. Tampoco permite borrar ni modificar las declaraciones responsables publicadas de cada versión (solo indicar cuál es la vigente), las aceptaciones de las condiciones del servicio ni los datos del certificado con el que se ha firmado como apoderado. Estas protecciones no pueden desactivarse desde el sistema.
• Desde la versión 2026.10.54 el sistema genera registros de facturación de alta de subsanación (Subsanacion = «S»; en la modalidad no VERI*FACTU, sin informar RechazoPrevio) cuando un registro ya generado no refleja los datos de su factura, conforme a las preguntas frecuentes de la AEAT para desarrolladores (apartado 17, caso 2.b) y a la descripción de los servicios web (versión 1.0.3, apartados 9.1.2 y 10.1.2). El registro original se conserva inalterado; el de subsanación lleva la misma identificación de la factura (NIF del emisor, número y fecha de expedición), los importes y el desglose de impuestos de la factura, su propia huella encadenada al registro inmediatamente anterior y firma electrónica, y la base de datos impide modificarlo o borrarlo. La comprobación de integridad de la cadena distingue los registros subsanados.
• El certificado electrónico con el que se firman los registros se conserva cifrado en el servidor y solo se descifra en memoria en el momento de firmar o de remitir; al sustituirlo, el anterior deja de conservar su clave privada. El sistema avisa con antelación de la caducidad de los certificados de firma y de los apoderamientos (al obligado tributario en su panel, a partir de 30 días antes) y avisa al productor a diario de esas fechas y de las anomalías detectadas en la firma o en la cadena de registros.
• Corregir un cobro ya anotado en una venta que todavía no se ha facturado (desmarcarlo como cobrado, reducir su importe o indicar que no se cobró en el local) solo lo puede hacer un usuario con rol de responsable del establecimiento, indicando el motivo, y queda constancia de quién, cuándo, el importe anterior y el nuevo en un registro que la propia base de datos impide modificar o borrar. En una venta ya facturada el importe cobrado no se modifica: se corrige con la devolución y su factura rectificativa. Quitar o modificar líneas, o aplicar descuentos, no puede dejar el importe de un pedido por debajo de lo ya cobrado.
• Sin conexión con el servidor el TPV no se abre: muestra un aviso de que no hay conexión y se abre solo cuando se recupera. Si la conexión se pierde con el TPV ya abierto, no toma pedidos nuevos, no cambia las líneas ni el importe de los que tenga guardados ni anota cobros: avisa de que no hay conexión y no admite la operación hasta que se recupera. Así no se vende al margen del servidor, que es donde se expiden las facturas y se generan sus registros de facturación, salvo en el TPV con chip de seguridad de un obligado tributario en la modalidad VERI*FACTU: si se pierde la conexión con el TPV abierto, el dispositivo expide la factura simplificada de las ventas directas (para llevar o en el local, cobradas en el momento, sin descuentos ni medias raciones) y genera su registro de facturación en el mismo momento, con su código QR, durante un máximo de 4 horas y 50 facturas desde su último contacto verificado con el servidor, medidos con el reloj de funcionamiento del dispositivo (no con su fecha y hora, que el usuario podría cambiar), nunca tras un reinicio sin conexión y nunca con la depuración del dispositivo activada. Al recuperar la conexión, el dispositivo envía los registros al servidor, que los remite a la AEAT indicando la incidencia, y el pedido se crea en el servidor enlazado a su factura; si el importe o el desglose por tipo impositivo del pedido no coincide con el de la factura, o algún dato no cuadra, se deja constancia de la anomalía, se avisa al obligado tributario y el dispositivo deja de poder funcionar sin conexión. Los pedidos que un dispositivo hubiera guardado sin conexión con una versión anterior del sistema se envían al servidor en cuanto la recupera, y la factura y su registro se generan entonces en el servidor, quedando anotado que se hicieron sin conexión; desde el TPV no puede descartarse un pedido con un cobro anotado, y lo que el servidor rechaza queda apartado y anotado.
• Desde que el obligado tributario otorga la autorización de firma o genera su primer registro de facturación, la propia base de datos impide modificar su NIF, su nombre o razón social, su domicilio fiscal, su país y su territorio fiscal, el NIF del emisor de sus registros y la cadena de registros a la que pertenece. En todo momento, rechaza incorporar como certificado propio uno cuyo titular no sea el propio obligado tributario o, en los certificados de representante, la entidad representada; los registros solo se firman con el certificado del propio obligado tributario o con el de su apoderado, en las condiciones indicadas en el apartado sobre la firma.
• La fecha y hora de generación de cada registro se conserva con su huso horario.
• Antes de generar cada registro, el sistema comprueba que el último registro de la cadena es el esperado y deja constancia de cualquier anomalía; las anomalías detectadas se muestran como alarma al obligado tributario en su panel y en el TPV.
• Un obligado tributario sin NIF, o con un NIF que no supera la comprobación de su carácter de control, no puede recibir pedidos en el sistema, porque sin un NIF válido no puede generarse un registro de facturación válido.
• Las facturas de los obligados tributarios a los que se aplica el Reglamento incluyen el código QR con la URL del servicio de cotejo de la AEAT que corresponde a su modalidad, precedido del texto «QR tributario:», tanto en PDF como en los tickets impresos. En papel, el TPV imprime el código QR como imagen; cuando la impresión va por un canal de solo texto que no puede dibujarlo, la factura no se imprime por ese canal y queda pendiente de entregar, para imprimirla en otra impresora o enviarla al cliente por medios electrónicos.
• En la modalidad no VERI*FACTU, el sistema verifica periódicamente y de forma automática la integridad de la cadena de registros de facturación y de la cadena de registros de evento, y deja constancia tanto del lanzamiento del proceso como de la detección de anomalías, si las hubiera.
• Los registros de evento se generan para los supuestos previstos, con los códigos de TipoEventoType del esquema oficial, y se conservan encadenados entre sí.
• El obligado tributario dispone de consulta y exportación de sus registros de facturación y de evento desde su propio panel, también en el formato XML de los registros; en la modalidad no VERI*FACTU, ambas exportaciones quedan registradas como evento.
• En modalidad VERI*FACTU, ante incidencias técnicas la remisión se reintenta con espera creciente (como máximo una hora entre intentos), respetando el tiempo de espera indicado por la AEAT y comunicando la incidencia; los registros rechazados quedan anotados con el motivo del rechazo. La cadena de registros compartida por varios establecimientos de un mismo obligado tributario solo la remite su establecimiento principal, con su configuración, y únicamente se remiten como registros de alta de facturas los generados en la modalidad VERI*FACTU. La anulación de una factura cuyo registro de alta no consta en la AEAT (generado antes de acogerse a VERI*FACTU o fuera de ese periodo, o rechazado) se remite como anulación sin registro previo (SinRegistroPrevio = S), sin alterar la huella de ningún registro; y la renuncia a VERI*FACTU solo surte efecto el 1 de enero si antes del 31 de diciembre se remitió a la AEAT un envío con la fecha de fin (Orden HAC/1177/2024, art. 17.3); si no, el sistema sigue funcionando como VERI*FACTU.