Módulo Verifactu Libre y Gratis

[Fermin]

La discusión la han iniciado ellos y las ilegalidades también. Incluyendo la violación fraglante de la GPL v3. No lo hemos empezado nosotros. Pero no contestaré más porque sabemos quien eres y lo que intentas.

Gracias!

Entiendo que puede haber tensiones sobre este tema, pero mi intención no es atacar a nadie ni generar conflictos innecesarios. Simplemente planteaba dudas legítimas sobre privacidad y cumplimiento normativo que cualquier administrador de sistemas consideraría antes de implementar una solución en producción.

Respecto a las acusaciones:

1. No represento a ninguna empresa ni tengo intereses ocultos. Soy un profesional que evalúa software para sus clientes.

2. Si existen violaciones de la GPL v3 u otras ilegalidades, eso es precisamente relevante para la comunidad y debería abordarse de manera constructiva.

3. Las insinuaciones sobre "saber quién soy y lo que intento" son infundadas y poco profesionales.

Lamento que la conversación haya tomado este tono. Mi objetivo era obtener claridad técnica, no iniciar confrontaciones. Si consideran que hay malentendidos o información incorrecta en mis planteamientos, estaré encantado de corregirla con datos objetivos.

Saludos.

¿Cambiando de tema abri un hilo buscando un módulo para FTP conoceis alguno?

[tecnoxarxa]

El módulo verifactu incumple las reglas del software libre por dos motivos fundamentales:

La licencia GPL v3 NO permite usar código de terceros para crear un producto privativo que restrinja las libertades que otorga la licencia GPL: Copiar, modificar, publicar. El módulo lo hace. Tiene múltiples ficheros de terceros que nada tienen que ver con Easy Soft.

La asociación Dolibarr que regula y dirige el desarrollo del proyecto Dolibarr y Dolistore, NO permite licenciar módulos que no son con licencias GPL v3 o compatibles. Esto son licencias que NO restringen la copia, modificación, publicación. De ahí que ya no esté disponible en Dolistore. A saber a cuantos han engañado...

Además de esas dos causas fundamentales, el módulo que hemos comprado no funciona para una facturación masiva automática. Si se produce un error por algún dato por parte de hacienda, se retroceden todas las facturas, incluidas las ya subidas a Verifactu. Imposibilitando crearlas de nuevo en Dolibarr dado que ahora el error es que ya existe en Verifactu. Ese hecho fue el detonante para que mirasemos el código y vieramos todas estas anomalias de suma importancia. Además, de que se manda información sensible sin consentimiento del usuario. Para colmo, pretende vender que es necesaria la compra del otro módulo antifraude, cuando no existe ninguna dependencia ya que no es necesario porque los bloqueos anti fraude los realiza activando un módulo ya existente en Dolibarr. Vendiendo de forma engañosa los dos módulos. Solo hemos encontrado un IF condicional que si al activar Verifactu no detecta el módulo antifraude, se niega a ser activado.

Hemos solicitado la devolución de la factura por email sin obtener respuesta. Ninguna. Ni siquiera negativa. ¿Tendremos que defender nuestros derechos de otra forma?

Por cierto nuestro módulo, con la parte que pretenden hacer privativa explícitamente, escrita desde cero, para evitar problemas, no tiene ese error y funciona perfectamente. En caso de fallo, las facturas ya subidas a Verifactu, no se retroceden.

[tecnoxarxa]

Debo decir que finalmente se ha resuelto todo de forma cordial tras haber contactado nuestro asesor legal con la empresa. Habiendo procedido a la devolución del dinero. Por nuestra parte, el tema está zanjado.

ahh y siempre que se cumpla con las normas que rigen el software libre, tendrán nuestro apoyo.

Gracias y Feliz Navidad

[jrbnm]

Buenas tardes tecnoxarxa. Me gustaría instalar el modulo en una instancia de dolibarr para probarlo pero tengo algunas dudas antes de ponerlo en producción. Lo voy a usar para mi, soy usuario, no programador, y además nuevo en dolibarr y me ha sorprendido gratamente. Provengo de otras aplicaciones, anteriormente gratuitas, que están aprovechando estos cambios para meter el método de suscripción o pago a sus usuarios que quieran tener verifactu. He leído la información e instrucciones de github pero mis dudas iniciales sobre el modulo son:
1. En el modo test estarían todas las funcionalidades del modo producción?
2. Una vez instalado el certificado para firma, en el modo test, ¿que hace la acción de envio de la factura a verifactu? Una simulación del envio? Que diferencia habría entre hacer el envio en modo test o en modo producción?
3. Al menos yo estoy un poco confuso con el tema del registro inviolable, etc... y todos estos aspectos legales, y las cantidades astronómicas de las sanciones que amenazan con ponerte me deja un poco inquieto. Entonces una vez puesto en producción esto tiene algún efecto sobre dolibarr? Es decir, ya no se puede desactivar el modulo (aunque todavía no es obligatorio)? Solo se podrán hacer facturas verifactu desde ese momento o es reversible? Lo digo porque en alguna otra aplicación que he probado solo funcionaba la facturación si verifactu estaba activo y registrado.
4. Si se desactiva en el futuro cuando ya sea obligatorio (si es que es posible desactivarlo una vez activado) aunque sea de forma accidental por una actualización de dolibarr por ejemplo, eso tendría implicaciones sobre el cumplimiento de normativa (validez de la declaración responsable o algún otro aspecto) o simplemente hay que estar atento de que todas las facturas se generen con el modulo activo para garantizar la cadena de códigos? La cadena de códigos se continuaría al reactivarlo?
5. Hay que ser especialmente cuidadoso con algo durante su uso para no tener problemas?
Gracias

[jonniher]

Creo quebpara obtener una respuesta verdadera deberías escríbeles a los verdaderos autores del módulo, no a los del "copy paste", no creo que tengan la menor idea de lo que les estás preguntando.

Buenas tardes tecnoxarxa. Me gustaría instalar el modulo en una instancia de dolibarr para probarlo pero tengo algunas dudas antes de ponerlo en producción. Lo voy a usar para mi, soy usuario, no programador, y además nuevo en dolibarr y me ha sorprendido gratamente. Provengo de otras aplicaciones, anteriormente gratuitas, que están aprovechando estos cambios para meter el método de suscripción o pago a sus usuarios que quieran tener verifactu. He leído la información e instrucciones de github pero mis dudas iniciales sobre el modulo son:
1. En el modo test estarían todas las funcionalidades del modo producción?
2. Una vez instalado el certificado para firma, en el modo test, ¿que hace la acción de envio de la factura a verifactu? Una simulación del envio? Que diferencia habría entre hacer el envio en modo test o en modo producción?
3. Al menos yo estoy un poco confuso con el tema del registro inviolable, etc... y todos estos aspectos legales, y las cantidades astronómicas de las sanciones que amenazan con ponerte me deja un poco inquieto. Entonces una vez puesto en producción esto tiene algún efecto sobre dolibarr? Es decir, ya no se puede desactivar el modulo (aunque todavía no es obligatorio)? Solo se podrán hacer facturas verifactu desde ese momento o es reversible? Lo digo porque en alguna otra aplicación que he probado solo funcionaba la facturación si verifactu estaba activo y registrado.
4. Si se desactiva en el futuro cuando ya sea obligatorio (si es que es posible desactivarlo una vez activado) aunque sea de forma accidental por una actualización de dolibarr por ejemplo, eso tendría implicaciones sobre el cumplimiento de normativa (validez de la declaración responsable o algún otro aspecto) o simplemente hay que estar atento de que todas las facturas se generen con el modulo activo para garantizar la cadena de códigos? La cadena de códigos se continuaría al reactivarlo?
5. Hay que ser especialmente cuidadoso con algo durante su uso para no tener problemas?
Gracias

[jesusmej]

Me sale el siguiente error al instalarlo en un hospedaje externo Hostinger***
He seguido todas las instrucciones y me da l siguiente error:

[Ruben Gomez]

Buenas tardes a todos,

En primer lugar, quiero agradecer y alabar enormemente el gran trabajo de **tecnoxarxa** por compartir su código con toda la comunidad. Yo me encontraba desarrollando un módulo VeriFactu propio, pero no tan completo, mil gracias, he tenido que realizar unos ajustes y el módulo funciona de maravilla, ofreciendo mucha información y con un diseño impecable y muy profesional. ¡Un gran aporte para Dolibarr!

Quería documentar una problemática con la que me topé al instalarlo en un servidor de **Hosting Compartido**. Por motivos de seguridad, muchos proveedores de hosting bloquean por completo la función `exec()` de PHP. Al intentar generar y validar las facturas en este entorno, el sistema fallaba arrojando el siguiente error crítico:

> *Certificate error: The exec function is not enabled on your server. Please contact your administrator.*
> *El envío a VeriFactu falló para la factura F-XXXXXX. La factura permanece como borrador - corrija los problemas e inténtelo de nuevo.*

Esto sucede porque originalmente el módulo delega la preparación y extracción del certificado digital a comandos externos del sistema operativo usando OpenSSL vía línea de comandos.

Para solucionar esto y hacer el módulo **100% compatible con cualquier hosting compartido**, he modificado el código para realizar todo el proceso utilizando las funciones criptográficas nativas de PHP (`openssl_*`).

Comparto detalladamente los **dos cambios exactos** que se deben realizar por si alguien más se encuentra en esta situación y quiere aplicarlo de forma segura:

---

### Cambio 1: Desactivar la restricción del chequeo de `exec`

Dado que ya no vamos a necesitar la ejecución de comandos del sistema, el primer paso es localizar el bloque que bloquea el módulo si `exec` no está disponible y eliminarlo o comentarlo.

**Código a modificar:**

```php
// BUSCAR Y COMENTAR O ELIMINAR ESTE BLOQUE:
// Verify exec function is enabled
if (!function_exists('exec')) {
$GLOBALS['verifactu_cert_error'] = "The exec function is not enabled on your server. Please contact your administrator.";
return false;
}

```

---

### Cambio 2: Reemplazar la función `prepareLocalCertificate` por extracción nativa PHP

El segundo cambio radica en la función encargada de procesar el archivo `.p12` o `.pfx` para generar el contenedor `.pem` combinado. Sustituimos las llamadas externas por el uso nativo de `openssl_pkcs12_read` y `openssl_pkey_export`.

**Código completo de la nueva función sustituta:**

```php
function prepareLocalCertificate(
string $certificateFile,
string $outputPath,
string $certificatePassword,
bool $encryptKey = false,
?string $privateKeyPassword = null,
string $winOpensslPath = '' // Se mantiene por compatibilidad de argumentos, pero ya no se usa
): string {

$certName = pathinfo($certificateFile, PATHINFO_FILENAME);
$outputPath = rtrim($outputPath, DIRECTORY_SEPARATOR) . DIRECTORY_SEPARATOR . $certName;
$bundleFile = $outputPath . ($encryptKey ? '_bundle_protegido.pem' : '_bundle.pem');

if (file_exists($bundleFile)) {
return $bundleFile;
}

// 1. Leer el archivo PFX nativamente sin llamadas de sistema
$pkcs12 = file_get_contents($certificateFile);
if ($pkcs12 === false) {
die("Error: No se pudo leer el archivo del certificado.");
}

// 2. Extraer certificados en memoria usando PHP nativo
$certs = [];
if (!openssl_pkcs12_read($pkcs12, $certs, $certificatePassword)) {
die("Error extrayendo el certificado. Comprueba la contraseña.");
}

$certOutContent = $certs['cert'];
$keyOutContent = $certs['pkey'];

// 3. Si se requiere cifrar la clave privada, lo hacemos de forma nativa
if ($encryptKey) {
$passOut = $privateKeyPassword ?? $certificatePassword;
$pkeyResource = openssl_pkey_get_private($keyOutContent);
if ($pkeyResource) {
openssl_pkey_export($pkeyResource, $keyOutContent, $passOut);
}
}

// 4. Combinar y guardar directamente en un solo .pem
file_put_contents($bundleFile, $certOutContent . "\n" . $keyOutContent);

return $bundleFile;
}

```

---

### Conclusión y Resultados

Tras realizar estas dos modificaciones y hacer las comprobaciones pertinentes, el envío a la sede electrónica de la AEAT funciona perfectamente, de manera fluida y sin requerir permisos elevados en el servidor.

Espero que a los que usáis hostings compartidos os sirva esta adaptación y ojalá se pueda integrar de manera definitiva en las próximas versiones del script para hacerlo aún más universal si cabe.

¡De nuevo, mi enhorabuena al creador por la base de este gran módulo!


Saludos.

[Fermin]

Me sale el siguiente error al instalarlo en un hospedaje externo Hostinger***
He seguido todas las instrucciones y me da l siguiente error:

Yo, a raíz de todo el revuelo que hubo, también lo probé porque lo necesitábamos. Sin embargo, finalmente preferí pagar a los autores originales. Cabe decir que envié varias consultas al correo de la versión liberada y no obtuve respuesta. En un tema tan delicado como Verifactu, necesito sentirme respaldado. Además, a mí también me dio varios problemas, por lo que acabé desistiendo.

[jonniher]

Me sale el siguiente error al instalarlo en un hospedaje externo Hostinger***
He seguido todas las instrucciones y me da l siguiente error:

Yo, a raíz de todo el revuelo que hubo, también lo probé porque lo necesitábamos. Sin embargo, finalmente preferí pagar a los autores originales. Cabe decir que envié varias consultas al correo de la versión liberada y no obtuve respuesta. En un tema tan delicado como Verifactu, necesito sentirme respaldado. Además, a mí también me dio varios problemas, por lo que acabé desistiendo.

Exacto es que de nada sirve liberarlo si no sabes que y como se hace, el "listillo" lo que hizo fue pasarlo por Claude y se creyó un DEV de verdad.

[Ruben Gomez]

Buenas tardes a todos,

En primer lugar, quiero agradecer y alabar enormemente el gran trabajo de **tecnoxarxa** por compartir su código con toda la comunidad. Yo me encontraba desarrollando un módulo VeriFactu propio, pero no tan completo, mil gracias, he tenido que realizar unos ajustes y el módulo funciona de maravilla, ofreciendo mucha información y con un diseño impecable y muy profesional. ¡Un gran aporte para Dolibarr!

Quería documentar una problemática con la que me topé al instalarlo en un servidor de **Hosting Compartido**. Por motivos de seguridad, muchos proveedores de hosting bloquean por completo la función `exec()` de PHP. Al intentar generar y validar las facturas en este entorno, el sistema fallaba arrojando el siguiente error crítico:

> *Certificate error: The exec function is not enabled on your server. Please contact your administrator.*
> *El envío a VeriFactu falló para la factura F-XXXXXX. La factura permanece como borrador - corrija los problemas e inténtelo de nuevo.*

Esto sucede porque originalmente el módulo delega la preparación y extracción del certificado digital a comandos externos del sistema operativo usando OpenSSL vía línea de comandos.

Para solucionar esto y hacer el módulo **100% compatible con cualquier hosting compartido**, he modificado el código para realizar todo el proceso utilizando las funciones criptográficas nativas de PHP (`openssl_*`).

Comparto detalladamente los **dos cambios exactos** que se deben realizar por si alguien más se encuentra en esta situación y quiere aplicarlo de forma segura:

---

### Cambio 1: Desactivar la restricción del chequeo de `exec`

Dado que ya no vamos a necesitar la ejecución de comandos del sistema, el primer paso es localizar el bloque que bloquea el módulo si `exec` no está disponible y eliminarlo o comentarlo.

**Código a modificar:**

```php
// BUSCAR Y COMENTAR O ELIMINAR ESTE BLOQUE:
// Verify exec function is enabled
if (!function_exists('exec')) {
$GLOBALS['verifactu_cert_error'] = "The exec function is not enabled on your server. Please contact your administrator.";
return false;
}

```

---

### Cambio 2: Reemplazar la función `prepareLocalCertificate` por extracción nativa PHP

El segundo cambio radica en la función encargada de procesar el archivo `.p12` o `.pfx` para generar el contenedor `.pem` combinado. Sustituimos las llamadas externas por el uso nativo de `openssl_pkcs12_read` y `openssl_pkey_export`.

**Código completo de la nueva función sustituta:**

```php
function prepareLocalCertificate(
string $certificateFile,
string $outputPath,
string $certificatePassword,
bool $encryptKey = false,
?string $privateKeyPassword = null,
string $winOpensslPath = '' // Se mantiene por compatibilidad de argumentos, pero ya no se usa
): string {

$certName = pathinfo($certificateFile, PATHINFO_FILENAME);
$outputPath = rtrim($outputPath, DIRECTORY_SEPARATOR) . DIRECTORY_SEPARATOR . $certName;
$bundleFile = $outputPath . ($encryptKey ? '_bundle_protegido.pem' : '_bundle.pem');

if (file_exists($bundleFile)) {
return $bundleFile;
}

// 1. Leer el archivo PFX nativamente sin llamadas de sistema
$pkcs12 = file_get_contents($certificateFile);
if ($pkcs12 === false) {
die("Error: No se pudo leer el archivo del certificado.");
}

// 2. Extraer certificados en memoria usando PHP nativo
$certs = [];
if (!openssl_pkcs12_read($pkcs12, $certs, $certificatePassword)) {
die("Error extrayendo el certificado. Comprueba la contraseña.");
}

$certOutContent = $certs['cert'];
$keyOutContent = $certs['pkey'];

// 3. Si se requiere cifrar la clave privada, lo hacemos de forma nativa
if ($encryptKey) {
$passOut = $privateKeyPassword ?? $certificatePassword;
$pkeyResource = openssl_pkey_get_private($keyOutContent);
if ($pkeyResource) {
openssl_pkey_export($pkeyResource, $keyOutContent, $passOut);
}
}

// 4. Combinar y guardar directamente en un solo .pem
file_put_contents($bundleFile, $certOutContent . "\n" . $keyOutContent);

return $bundleFile;
}

```

---

### Conclusión y Resultados

Tras realizar estas dos modificaciones y hacer las comprobaciones pertinentes, el envío a la sede electrónica de la AEAT funciona perfectamente, de manera fluida y sin requerir permisos elevados en el servidor.

Espero que a los que usáis hostings compartidos os sirva esta adaptación y ojalá se pueda integrar de manera definitiva en las próximas versiones del script para hacerlo aún más universal si cabe.

¡De nuevo, mi enhorabuena al creador por la base de este gran módulo!


Saludos.