Verifactu

Hola,

Sí, hay interés, es un tema que nos empieza a llegar de los comerciantes españoles.

Por nuestra parte no está previsto integrarlo en el núcleo de HikaShop a corto plazo, y la razón no es técnica sino legal : el reglamento no obliga solamente al comerciante, obliga también al productor del software, que debe emitir una declaración responsable certificando que su programa cumple los requisitos de integridad e inalterabilidad. Un sistema informático de facturación tiene que ser no modificable por el usuario, y HikaShop es una extensión PHP que el comerciante instala en su propio servidor y que puede modificar libremente con overrides y plugins. Convertir eso en un SIF certificado no es un desarrollo, es un compromiso permanente.

Por eso, si desarrollas un plugin, la arquitectura que te recomendamos es la de puente y no la de SIF completo : HikaShop envía los datos de la factura a un proveedor VeriFactu ya certificado (hay varias APIs en el mercado en España), y ese proveedor genera el registro encadenado, lo firma, lo remite a la AEAT y te devuelve la huella, el CSV y el QR para imprimir en la factura. Así el certificado del comerciante no vive en el servidor de la tienda y la declaración responsable la mantiene el proveedor, no tú. La otra vía, generar tú mismo el registro de alta, la cadena de huellas, la firma XAdES y el registro de eventos, es mucho más trabajo y te deja con la responsabilidad encima.

En HikaShop tienes lo necesario para engancharlo :

- El evento onAfterInvoiceCreate se dispara justo cuando HikaShop asigna el número de factura a un pedido, con el pedido completo como parámetro. Es el punto natural para generar el registro de alta.
- El plugin Attach invoice genera el PDF de la factura con TCPDF, que sabe dibujar códigos QR de forma nativa, así que ahí es donde se añade el QR y la mención VERI*FACTU.

Dos puntos que conviene aclarar antes de empezar, porque cambian el alcance :

- Muchas tiendas no necesitan que HikaShop sea el SIF. Si la factura la emite su programa de contabilidad a partir de un export de pedidos, el SIF es ese programa, y HikaShop solo le alimenta los datos. Los obligados al SII están directamente fuera del ámbito de VeriFactu.
- Si eliges la modalidad VeriFactu, con remisión inmediata a la AEAT, los registros no necesitan firma electrónica, es la remisión la que da la garantía. La modalidad sin remisión sí exige firma y conservación local, y es bastante más pesada de implementar. Para una tienda online la primera es casi siempre la buena opción.

Sobre las herramientas, existe la librería josemmo/Verifactu-PHP, en MIT, que cubre la generación de los registros y el envío a la AEAT. Curiosamente es del mismo autor que josemmo/einvoicing, la librería que ya usamos en nuestro plugin Attach invoice para el formato UBL. Pide PHP 8.2 como mínimo, así que habría que ponerle un control de versión en el plugin.

Si desarrollas el plugin, dínoslo, lo podemos referenciar en nuestra web para que los comerciantes españoles lo encuentren.

Hola,

Enhorabuena, y gracias por compartirlo con la comunidad. En el mensaje no aparece ningún enlace ni fichero adjunto : ¿dónde pueden descargarlo los comerciantes? Con la URL lo referenciamos desde nuestra web para que los comerciantes españoles lo encuentren.

Dos sugerencias, porque los dos puntos que más van a frenar la adopción son el acceso SSH y la configuración manual :

1. El acceso SSH. Muchos alojamientos compartidos no lo ofrecen, o lo ofrecen sin permisos suficientes, y eso deja fuera a buena parte de las tiendas. Si los comandos son para instalar dependencias con composer, la solución habitual es incluir ya la carpeta vendor dentro del ZIP del plugin : es lo que hacemos nosotros en el plugin "HikaShop - generate PDF invoice", que se instala sin tocar la línea de comandos. Y si son tareas periódicas, Joomla tiene su propio sistema de tareas programadas con lanzador web, que evita depender del cron del servidor.

2. Los campos personalizados. En lugar de pedirlos en el manual, el plugin puede crearlos él mismo en su instalación, con la clase de campos de HikaShop. Así se evitan los errores de nombre de columna, que son difíciles de diagnosticar después. Y si necesita tablas propias, HikaShop dispara el evento onHikashopBeforeCheckDB durante la comprobación de la base de datos : ahí puede declarar sus tablas y sus columnas, y HikaShop las crea y las mantiene al día en cada actualización, igual que hacen varios de nuestros plugins.

Y dos preguntas por curiosidad técnica :

- ¿Qué modalidad implementa, VERI*FACTU con remisión inmediata a la AEAT, o el modo sin remisión con firma XAdES y conservación local?
- ¿Qué versión mínima de PHP requiere? Es útil indicarlo en la página de descarga, sobre todo si usa una librería que pide PHP 8.2.

Hola,

Hemos estudiado tu plugin a fondo y le hemos dedicado tiempo, porque nos parece la pieza que le falta a las tiendas españolas y porque la arquitectura que has elegido es la correcta: apoyarte en una librería ya existente para la firma, la huella encadenada y el diálogo SOAP con la AEAT, en vez de reinventarlo.

Para poder trabajar sobre él sin pisarte nada, lo hemos puesto en un repositorio público de GitHub:

github.com/hikashop-nicolas/hikashop-verifactu

El primer commit es tu versión 0.30.32 tal cual, sin tocar, así que todo lo que viene después se lee como una diferencia contra tu código. La licencia GPLv2 y tu autoría están indicadas en el README y en la descripción del repositorio. Es tu plugin: coge de aquí lo que te sirva, ignora lo que no, y si prefieres llevarlo tú en tu propio repositorio, encantados de enviar los cambios allí.

Cada corrección va en su propio commit, con el porqué explicado en el mensaje:

1. Instalación en MySQL, no solo en MariaDB
github.com/hikashop-nicolas/hikashop-verifactu/commit/bb3c42eb7
El SQL de instalación creaba las dos columnas del pedido con ADD COLUMN IF NOT EXISTS. Eso es una extensión de MariaDB: MySQL responde error 1064, el instalador de Joomla se para ahí y los campos personalizados que van después no llegan a crearse. Ahora las crea un script de instalación que comprueba antes en INFORMATION_SCHEMA, y funciona en los dos.

2. Funcionar sin el plugin de compatibilidad de Joomla
github.com/hikashop-nicolas/hikashop-verifactu/commit/fd6ba79c0
El plugin usaba JPlugin, JFactory y JLog, así que en Joomla 5 y 6 solo cargaba mientras estuviera activo "Comportamiento - Compatibilidad con versiones anteriores", que viene desactivado en una instalación nueva. Un plugin fiscal que deja de enviar facturas el día que alguien desactiva ese plugin es un riesgo que no compensa. Todas esas clases están sustituidas por sus equivalentes con espacio de nombres.

3. El registro ya no queda accesible desde la web
github.com/hikashop-nicolas/hikashop-verifactu/commit/0fa434e36
Cada operación se añadía a debug.log dentro de la carpeta del plugin, con números de pedido, números de factura y NIF. Esa carpeta la sirve el servidor web, así que el archivo se podía descargar sabiendo la dirección. Ahora se escribe en el registro de Joomla, en su carpeta de logs y con extensión .php, que Joomla protege.

4. No declarar un desglose inventado
github.com/hikashop-nicolas/hikashop-verifactu/commit/a1f48a3ca
Cuando el pedido no traía un desglose de impuestos utilizable, se construía una línea al 21 % con la base igual al total y cuota cero, y se enviaba. Una declaración equivocada es peor que una tardía: queda registrada y hay que rectificarla. Ahora ese caso devuelve un error y se anota en el log, y la factura no se envía hasta que se arreglen los impuestos del pedido.

5. La base imponible cuadra con el total de la factura
github.com/hikashop-nicolas/hikashop-verifactu/commit/7b54b1157
Este es el que más nos ha llamado la atención, y solo se ve con gastos de envío o de pago con impuesto. HikaShop guarda esos gastos con el impuesto ya incluido y además vuelve a sumar la cuota al calcular el campo amount de order_tax_info, así que la base que salía de ahí venía inflada justo en el doble del impuesto de esos gastos.

Lo hemos medido con un pedido real, creado con el propio recálculo de HikaShop: producto 100 + cargo 20 + envío 12,10 + pago 6,05, todo al 21 %.

HikaShop guarda: amount = 141,30   tax_amount = 28,35   total = 163,35
Se declaraba:    base   = 141,30 + cuota 28,35 = 169,65  frente a 163,35
Ahora:           base   = 135,00 + cuota 28,35 = 163,35  igual al total

Hola,

Reproducido, y la causa no está en HikaShop sino en el manifiesto del plugin:

<media folder="media" destination="com_hikashop">
    <folder>plugins</folder>
</media>