1. xaVerifactu con Xailer

xaVerifactu con Xailer se apoya en dos librerías propias de OZ Software, que son:

• \lib\libxaVerifactuXailerPruebas.a
• \lib\libxaVerifactuXailerProduccion.a

Será indispensable que en sus proyectos de Xailer incluya además la librería de Xailer Sqlite y de Harbur HbZebra

2. xaVerifactu sin Xailer

xaVerifactu sin Xailer se apoya igualmente en dos librerías propias de OZ Software, que son:

• libxaVerifactuPruebas.a
• libxaVerifactuProduccion.a

Su uso es idéntico a las de Xailer, pero lógicamente no requieren de su uso conjunto. El tamaño de la librería sin Xailer es más grande debido a que incluye la librería completa de SQlite. Las librerías sin Xailer son de 64 bits.

La versión de 'pruebas' debe utilizarse únicamente para realizar pruebas de funcionamiento de la librería. Utiliza el entorno de pruebas de la AEAT y por lo tanto no existe ningún riesgo en su uso ya que los registros de facturación que se suban a la AEAT no tienen ningún efecto fiscal.

La versión de producción es una versión personalizada por cada cliente que adquiere la librería xaVerifactu ya que cada registro de facturación que se sube a la nube de AEAT incorpora información de la empresa que ha desarrollado el SIF (sistema informático de facturación). Por lo tanto, no es una buena idea compartir la librería entre varios desarrolladores.

En ambos casos es necesario incluir las librerías de CURL que son:

• \lib\curl\libhbcurl.a
• \lib\curl\libcurl.a

El ejecutable creado con Harbour (con o sin Xailer) debe ir acompañado de la DLL 'libcurl.dll' que se encuentra en el directorio \lib\curl. Es muy importante que utilice está versión de CURL y no otra ya que xaVerifactu comprueba que está usando esa versión.

Es necesario incluir igualmente un fichero de cabecera de nombre xaVF.ch.

La AEAT es muy tajante indicando que el servidor de pruebas no debe de utilizarse para hacer versiones DEMO del software SIF. Su uso debe de estar limitado a que el SIF se adapte correctamente al sistema Verifactu.

3. Introducción a xaVerifactu

A partir del 01/01/2026 prácticamente todas las empresas (se excluyen las que estén en el SII) deberán 'subir' a la nube de la AEAT todas las facturas que realicen de forma casi instantánea (60 segundos). Para los autónomos la fecha inicial de esta obligación será a partir del 01/07/2026.

Pudiera parecer que el cometido que tiene que realizar nuestro software es simplemente subir cada factura, en el formato que se exija, y poco más. Pero no es así, la Hacienda pública exige un mayor control de la facturación de nuestros clientes:

• Nos exige a encadenar cada factura con la anterior, utilizando un sistema de huellas
• Nos exige a incluir un código QR en cada factura para que el cliente pueda comprobar que la factura ha sido realmente subida a la nube de la AEAT
• Nos exige mantener un registro de facturación inalterable (sólo permite altas)
• Nos exige que las comunicaciones con la AEAT se realicen con certificado digital y no más de una comunicación por cada 60 segundos
• Nos exige controlar completamente cualquier problema que pueda surgir en las comunicaciones
• Nos hace responsables (a cualquier programador que haya intervenido en el software) del correcto funcionamiento del software

Debido a la complejidad de todos los requerimientos han surgido empresas que nos simplifican de forma importante el trabajo, ya que mandando las facturas a la nube de dichas empresa, ellos se encargan del resto. Pero desgraciadamente no es barato y cada uno de nuestros clientes que utilice nuestra facturación deberá contratar dichos servicios.

Han surgido igualmente empresas de informática que ofrecen su propio API/SDK para cumplir con las obligaciones de Verifactu, pero a diferencia de nuestra solución, sólo resuelven la gestión del envío de la información a la AEAT y la obtención del código QR. No incluyen la gestión del registro, ni tampoco la gestión de las contingencias que pueden surgir en las comunicaciones.

xaVerifactun tiene en cuenta todas las exigencias de la AEAT, simplificando al máximo su uso por parte del programador. El registro de facturación es gestionado completamente por la librería y actualmente se soportan los formatos DBF y SQLite. Se incluyen mecanismos para hacer un SQL-DUMP del registro al motor SQL que se requiera.

El uso de la librería es realmente sencillo. Por ejemplo:

LOCAL oVerifactu, oFac 
  oVerifactu := TxaVerifactu():New( cNIF )
  oVerifactu:SistemaPersistencia( vfSQLITE )
  oFac := oVerifactu:NuevaFacturaAlta( "A-0001" )
  WITH OBJECT oFac
   :dFecExpedicion := Date()
   :NuevoDestinatario( ... )
   :NuevoDesglose( ... )
   :cTipoFactura := "F1"
   IF :Validar() .AND. :Registrar()
     	// Imprimir factura (trabajo del SIF, no de xaVerifactu)
   ENDIF  
  END WITH

Observe como se instancia el objeto TxaVeriFactu indicando el NIF emisor. Este parámetro es obligatorio ya que la librería mantienen un sistema completo de persistencia por cada NIF que se utilice. Crea los directorios y tablas si no existen de forma automática.

En el momento en que se llama al método Registrar(), la factura pasa al registro, pasa a ser inalterable y se puede imprimir a partir de ese momento, incluso aunque no haya subido aún a la nube de la AEAT. Todo la gestión de encadenamiento de facturas es realizada por la librería. Nuestra librería permite realizar este proceso en dos tiempos: uno de creación de la factura, que llamaremos pre-factura, que guarda en tablas los datos de la misma al invocar el método Validar() siempre que no haya errores importantes. Y otro proceso en el cual se registra la pre-factura y se convierte en factura ya registrada. En el ejemplo se ha realizado en un único paso, pero entendemos que la existencia de pre-facturas es muy útil ya que en cierta forma sustituye al sistema clásico de 'cierre de facturación'.

El proceso de envío a la AEAT de todas las facturas en registro pendientes de envío se realiza con el método EnvioDirecto() de la clase TxaVeriFactu. Y por supuesto, la librería xaVerifactu controla perfectamente la información devuelta por la AEAT y actualiza todos los registros de facturación involucrados con la información devuelta.

La AEAT es especialmente meticulosa en la información que se le envía y rechaza las facturas en cuanto observa el mínimo error o incongruencia. El método Validar() de la clase TFactura comprueba de forma exhaustiva la factura para que pase sin problemas los filtros que realiza la AEAT.

La AEAT sólo permite realizar un envío cada 60 segundos y es por dicho motivo por el cual el envío se ha de hacer desde la clase TxaVeriFactu y no desde TFactura. Este método envía a la AEAT todas las facturas pendientes de envío. Si intenta utilizar el méotdo EnvioDirecto() antes de que hayan transcurrido los 60 segundos que exige la AEAT le notificará que no es posible, indicándole los segundos que faltan.

Y este es el funcionamiento básico de la librería. Hemos intentado simplificar su uso al máximo, sin perder flexibilidad, y realizando la gestión completa del registro y envío.

4. Jerarquía de clases de xaVerifactu

La librería consta de únicamente tres clases exportadas para realizar todo el trabajo, que son:

• TxaVerifactu: Esta es la clase base responsable de todos los procesos que puede realizar xaVerifactu. Su constructor 'New' requiere únicamente como parámetro el NIF emisor de la facturación. Ese parámetro es absolutamente necesario y posteriormente inalterable por ser de sólo lectura. Puede instanciar a la vez todos objetos de TxaVerifactu que necesite.
• TVfFacturaAlta: Esta es la clase responsable de gestionar todas las facturas ordinarias. Su instanciación debe de realizarse a través del método NuevaFacturaAlta de la clase TxaVerifactu
• TVfFacturaAnul: Esta es la clase responsable de gestionar todas las facturas de anulaciones. Su instanciación debe de realizarse a través del método NuevaFacturaAnul de la clase TxaVerifactu

5. La persistencia de xaVerifactu

Para simplificar de forma drástica todo el trabajo que realizar el desarrollador del SIF, xaVerifactu gestiona de forma completa toda la persistencia de las operaciones que exige la AEAT. Para ello, puede utilizar dos tipos de motores: archivos DBF o SQLite. Es decisión del programador decidir que sistema desea utilizar, pero lógicamente, una vez seleccionado uno de ellos, no deberá cambiar bajo ninguna circunstancia de sistema ya que provocaría un desfase en su registro de facturación que la AEAT podría penalizar.

La librería crea una carpeta y sus correspondientes archivos por cada NIF utilizado. Es importante, que en entornos de red donde haya más de un usuario , la carpeta base, sea una carpeta compartida a la cual puedan acceder todos los ejecutables que utilicen xaVerifactu. Las tablas creadas por la librería son completamente accesibles sin ninguna limitación. No obstante, muchas de ellas incorporan mecanismos de 'checksum' que nos permiten saber si han sido manipuladas.

xaVerifactu posee un método para realizar SQL-DUMP (Insert múltiple) de todo el registro de facturación para su incorporación a cualquier base datos. Está en nuestra hoja de ruta abordar el desarrollo de sistemas de persistencia adicionales como MariaDB o ActiveX. Si requiriese de dicha funcionalidad, no dude en ponerse en contacto con nosotros para saber el estado de dicho desarrollo.

5. Pre-facturas y registro de facturación

Las tablas que maneja xaVerifactu son las siguientes:

• Tabla de pre-facturas
• Tabla de registro de facturación
• Tabla de eventos
• Tabla de configuración

La tabla de pre-facturas es completamente temporal hasta que la factura sea registrada. En dicho momento sale de la tabla de pre-facturas y se almacena en la tabla de registro de facturación. Por lo tanto, dicha tabla tendrá un número limitado de registros. Incluso en facturaciones muy sencillas que realicen el proceso de validación y registro a la vez, es muy normal que esta tabla esté vacía.

Cuando la factura es registrada pasa a la tabla de registro de facturación. Y además de toda la información de la factura en formato XML, se guardan todos los parámetros que exige la AEAT que son calculados de forma automática. Esta tabla no debe de ser alterada bajo ninguna circunstancia.

La tabla de eventos realiza la persistencia de todas las operaciones importantes realizadas y en el caso de que se haya producido cualquier error, también éste es guardado en esta tabla. Las respuestas de la AEAT en las comunicaciones que establecemos con ella, también son archivadas en esta tabla con toda la información recibida.

Por último, la tabla de configuración guarda información importante de la empresa, el certificado digital e información de la última comunicación con la AEAT.

6. Comunicaciones con la AEAT

Las comunicaciones con la AEAT se realizan a través de Internet utilizando los servidores de pruebas o producción que la AEAT pone a nuestra disposición. Independientemente del servidor que usemos es necesario utilizar un certificado digital válido para el NIF emisor de las facturas que registremos. En el caso de que utilicemos un certificado digital inválido el envío será denegado

Durante el proceso de comunicaciones se envían todos los registros pendientes en un bloque y la AEAT responde con un archivo XML sobre la validez o invalidez de los mismos. xaVerifactu gestiona completamente la respuesta de la AEAT y actualiza cada factura del registro con la respuesta recibida. La clase TxaVerifactu le permite recuperar las facturas del registro y conocer el estado de cada una de ellas.

En el caso de que se produzca algún problema técnico durante el envío, éste es guardado en la tabla de eventos y el próximo envío se indica que incorpora 'incidencia' por haber tenido un problema técnico en el anterior envío. La AEAT exige que transcurran 60 segundos entre envíos. En el caso de que intenté realizar un envío y no hayan pasado los 60 segundos, xaVerifactu le indicará que la comunicación no ha sido posible y le indicará los segundos que faltan.

Es responsabilidad del SIF realizar el envío. Es decir, si no se utiliza el método TxaVerifactu:EnvioDirecto() nunca llegarán a subir las facturas a la AEAT.

7. Utilidades de xaVerifactu

La librería incluye varias utilidades que pueden ser muy útiles para el usuario que son:

• Método para comprobar la caducidad de un certificado digital
• Método para comprobar con un servicio web ofrecido por la AEAT de la validez de un determinado NIF/DNI
• Método para comprobar que la conexión con la AEAT funcionan correctamente
• Método para comprobar la información de facturación que tiene la AEAT sobre la empresa

Es responsabilidad del SIF comprobar la validez del certificado para avisar al cliente final cuando éste vaya a caducar