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>

Hola,

Sobre subir la versión a GitHub: sí, podemos subirla nosotros al repositorio. Antes de hacerlo te comentamos los puntos que hemos visto en la revisión, porque varios cambian lo que acaba registrado en la AEAT y preferimos que la versión que quede publicada ya los lleve resueltos. Dinos qué te parece cada uno, y con lo que decidas la subimos.

Subir la versión a nuestro GitHub es justo lo que no podemos hacer, y es el mismo punto de los mensajes anteriores. Si tú dejas de distribuir y el único sitio donde se descarga el instalable es nuestro repositorio, el distribuidor pasamos a ser nosotros, que es el papel que dijimos desde el principio que HikaShop no puede asumir. Abrir una cuenta en GitHub es gratis y son dos minutos: si creas el repositorio, te enviamos allí nuestros cambios y tú publicas las versiones. Y si prefieres no usar GitHub, vale cualquier alojamiento tuyo, Drive como hasta ahora o tu propia web; nosotros mantenemos el nuestro solo como repositorio de código, con tu autoría.

Numeración propia. Viene activada por defecto, así que una tienda que actualice cambia de numeración sin enterarse; nos parece más prudente que el valor por defecto sea No y que cada comerciante la active a conciencia. La semilla solo reconoce el formato {aa}{prefijo}-{dígitos}, así que en una tienda cuyo formato de factura de HikaShop sea otro la serie arranca en 0001 en vez de continuar. Y con el prefijo F1 vacío tu serie tiene exactamente la misma forma que la nativa de HikaShop: las facturas que HikaShop numera pero que no llegan al estado disparador conservan el número nativo y ese contador sigue avanzando por su cuenta, con lo que las dos series pueden acabar emitiendo el mismo número. Poner también un prefijo propio a F1, o disparar exactamente en el estado en el que HikaShop numera, lo evita. Un último detalle: el año sale de la fecha del envío, no de la de la factura, así que una factura del 31 de diciembre enviada el 1 de enero recibe el prefijo del año nuevo mientras su FechaExpedicion sigue en el anterior.

Destinatario extranjero. Tu cambio vuelve a fijar IDType 02 para todo el extranjero. 02 es NIF-IVA y la AEAT lo contrasta contra VIES: PT503890278 pasa, pero 503890278 a secas, que es como lo escribe medio mundo, y cualquier cliente de fuera de la UE se rechazan, que es el 1103 que viste. Lo tenemos resuelto sin perder tu caso: 02 solo cuando el identificador lleva el prefijo de su país (EL en el caso de Grecia), 04 en los demás, y CodigoPais siempre informado. Te lo pasamos para que lo incorpores.

Desglose vacío. De acuerdo en las dos cosas: el 21 % inventado estaba mal, y cortar antes de registrar dejaba el pedido sin rastro ni QR. Pero declarar N2, no sujeta por reglas de localización, en cualquier pedido sin desglose también declara como no sujeta una venta española cuyos impuestos simplemente estén mal configurados, y eso queda registrado en la AEAT igual de bien. Nosotros lo limitaríamos al destinatario fuera de España, y para un pedido español sin desglose seguiríamos devolviendo error, pero guardando ya la fila del registro local como haces ahora.

Validador de NIF. Vaciar el NIF cuando no valida tiene un efecto que quizá no buscabas: en el plugin VeriFactu la familia se decide según haya o no NIF de cliente, así que un cliente español que se equivoca en una letra pasa de F1 a F2 y su factura sale a la AEAT como simplificada, con los límites de importe que eso implica, sin que nadie se entere. Es mejor rechazar el valor y que el cliente lo corrija, o guardarlo tal cual y marcar el pedido para revisión, que borrarlo en silencio. Dos detalles menores: el plugin escribe directamente en $_POST, que Joomla ya ha leído en su propio objeto Input, así que ese borrado puede no llegar donde esperas; y el mensaje de error está fijo en español dentro del JavaScript, sin archivo de idioma.

Autoría. El manifiesto sigue diciendo author y copyright "Custom". Para que podamos subirlo esto sí necesitamos cambiarlo: la GPLv2 mantiene el nombre del autor, y nosotros no podemos publicar como anónimo un código que no hemos escrito. Además, tal como queda ahora, la declaración deja un documento en el que el productor declarado es el comerciante y el software no lo firma nadie. Es tu plugin, ponte como autor.

Lo que no hemos podido comprobar sigue siendo lo mismo que la otra vez: el envío real a la AEAT, porque aquí no tenemos certificado ni entorno de pruebas dado de alta. Todo lo anterior es revisión de código sobre tus dos zips.

Hola Nico,

Te adjunto tu versión 0.32.2 con el cambio del destinatario extranjero ya incorporado, y el diff por separado (en .txt, el foro no admite .diff) para que veas exactamente qué cambia. Solo toca src/VerifactuLibraryBridge.php, el resto del zip es tu versión tal cual.

Lo que hace:
- IDType 02 (NIF-IVA) solo cuando el identificador empieza por el prefijo de su país (PT503890278, o EL para Grecia). Tu caso sigue funcionando igual.
- IDType 04 en los demás casos: número nacional sin prefijo (503890278) y cualquier cliente de fuera de la UE.
- CodigoPais siempre informado.
- Un cliente español que escribe su NIF con el prefijo ES (ES12345678Z) lo pierde antes de ir en NIF.

Como la otra vez, aquí solo lo hemos comprobado contra la validación de la librería, no contra la AEAT. Antes de usarlo en producción convendría enviar en el entorno de pruebas una factura con un NIF portugués sin prefijo y otra con un cliente de fuera de la UE.

Sobre la numeración que explicas en tu mensaje: de acuerdo en que cada tipo de factura necesita su serie correlativa. Los puntos que comentamos en la revisión siguen en pie (activada por defecto, la semilla, el posible choque con la numeración nativa si F1 no tiene prefijo, y el año tomado del envío).

Hola Nico,

Gracias por la nueva versión y por las pruebas contra la AEAT. Hemos revisado la 0.34.16 frente a la 0.32.2. De acuerdo con tu análisis del IDType: la lógica 02/04 es equivalente a la nuestra, y está bien que la numeración propia venga ahora desactivada por defecto y que el desglose vacío ya no se declare como N2 para un cliente español. Antes de subirla al repositorio, estos son los puntos que hemos encontrado, del más grave al menos grave:

1. La actualización desde la 0.32.2 falla. El archivo sql/updates/mysql/0.34.13.sql hace un MODIFY COLUMN de verifactu_sustituye_simplificada, pero en una tienda con la 0.32.2 esa columna todavía no existe: la crea script.php en el postflight, que Joomla ejecuta después de los SQL de actualización. MySQL responde "Unknown column", Joomla interrumpe la actualización y el postflight no llega a ejecutarse, así que tampoco se crean tipo_registro y motivo_anulacion ni se acepta el aviso legal. Al reintentar, vuelve a fallar en el mismo punto. La solución es quitar ese MODIFY del SQL y hacerlo en script.php, solo si la columna existe y todavía es TINYINT. De paso: Joomla activa siempre el modo estricto de MySQL, así que guardar 'Sí' en una columna TINYINT da un error, no se trunca en silencio como dicen los comentarios.

2. Las anulaciones no se guardan en el registro local. En guardarRegistro(), total_factura vale null para una anulación, pero la columna es DECIMAL NOT NULL sin valor por defecto. El INSERT falla y la excepción solo se escribe en el log: la AEAT ha aceptado la anulación, pero la tabla no la tiene, la cadena de huellas se la salta y el siguiente guardado del pedido la vuelve a enviar. Poner 0 en total_factura para las anulaciones, o permitir NULL en la columna, lo resuelve. Pasa algo parecido cuando el aviso legal no está aceptado: la fila se intenta guardar sin fecha, NIF ni total, y el número de factura ya se ha consumido.

3. El prefijo ES del NIF español sigue sin quitarse (lo mencionas tú mismo). La línea es esta, en el bloque del destinatario español:

$recipient->nif = preg_replace('/^ES(?=[0-9A-Z]{9}$)/', '', $nifCliente);