Facturación compatible Verifactu

[gusman126]

En 23/9/2025 a las 12:51 PM, ps_developer dijo:

Hola, sobre el módulo de digitalDot entonces entiendo que es necesario importar en el módulo el certificado p12 + clave privada de la empresa.

Comentais que el certificado se guarda con contraseña pero realmente da igual porque la contraseña el módulo tendrá que guardarla en la base de datos o algún sitio para poder trabajar de forma autónoma, por lo que si hay una intrusión en el servidor podrían acceder tanto al certificado + clave privada como a la contraseña que el módulo habrá guardado en algún sitio.

Lo ideal sería un módulo que trabaje con un HSM externo, un servicio de firma externo en la nube como Camerfirma, Camerfirma tiene este servicio en modo suscripción pero es muy barato por lo que miré, son unos 20 Euros cada dos ó tres años. Si alguien se animase a desarrollar un módulo de este tipo sería ideal. Sobre esta opción me queda duda de si aparte de para la firma de las facturas, el certificado p12 es necesario también para la autenticación de cliente en modo M-TLS a la hora de enviar las facturas, no he mirado si también es necesario para esto porque en este caso el HSM no sería suficiente.

Saludos

Yo por ejemplo tengo un modulo para verificar los CIF en la AEAT y es necesario el certificado p12 subido a la carpeta del modulo
LA CONTRASEÑA se guarda en la base de datos encriptada . obviamente una vez se guarda los datos se podrian sacar, pero no es facil.
Es lo mas seguro que he podido encontrar, otra manera es pagando a terceros y otro gasto mensual de tantos que hay

[qs]

1 minute ago, gusman126 said:

Yo por ejemplo tengo un modulo para verificar los CIF en la AEAT y es necesario el certificado p12 subido a la carpeta del modulo
LA CONTRASEÑA se guarda en la base de datos encriptada . obviamente una vez se guarda los datos se podrian sacar, pero no es facil.
Es lo mas seguro que he podido encontrar, otra manera es pagando a terceros y otro gasto mensual de tantos que hay

Hola, pues con el de verifactu es lo mismo, se sube el p12 + contraseña y indicas que cif o dni quieres para emitir las facturas y listo.

[gusman126]

hace 3 minutos, qs dijo:

Hola, pues con el de verifactu es lo mismo, se sube el p12 + contraseña y indicas que cif o dni quieres para emitir las facturas y listo.

El sistema de enviar datos si.
El sistema de facturación de prestashop no cumple todo lo que pide legalmente, es tan abierto que puede ser modificadas las facturas, tener diferentes numeraciones, puedes hacer todo lo que quieras , por lo tanto un modulo en prestashop ... no lo aconsejo. 
Yo aconsejo una API de envio de facturas externo o un ERP.
Luego hay problemas miran que las facturas estan con prestashop y seguro que cae multa., con los ERP y API puedes hacer lo que quieras en prestashop, lo que manda son los datos de esos sistemas externos. 
Sobre todo con la mierda de calculo de prestashop con centimos e impuestos y las "facturas rectificadas" que se deben hacer si o si bien y enviar bien a AEAT

 

[qs]

1 minute ago, gusman126 said:

El sistema de enviar datos si.
El sistema de facturación de prestashop no cumple todo lo que pide legalmente, es tan abierto que puede ser modificadas las facturas, tener diferentes numeraciones, puedes hacer todo lo que quieras , por lo tanto un modulo en prestashop ... no lo aconsejo. 
Yo aconsejo una API de envio de facturas externo o un ERP.
Luego hay problemas miran que las facturas estan con prestashop y seguro que cae multa., con los ERP y API puedes hacer lo que quieras en prestashop, lo que manda son los datos de esos sistemas externos. 
Sobre todo con la mierda de calculo de prestashop con centimos e impuestos y las "facturas rectificadas" que se deben hacer si o si bien y enviar bien a AEAT

 

Si prestashop si deja hacer eso, pero los que han probado el modulo, lo veran, la pestana de verifactu de los xml facturas sale enviada o no enviada, si la envias ya no se pude modificar aun que modifques algo de prestashop, y si la quieres anular se tiene que reactificar desde el mismo menu. Y editable no es.

ya subire capturas del modulo y como funciona, porque creo que mucha gente no sabe como es. Yo tampoco lo tenia claro hace 15 dias, pero una vez lo configuras y lo trasteas es facil de utilizar y todo automatico eso si lo mencionado no deja editar nada una vez enviada .

[ps_developer]

25 minutes ago, gusman126 said:

Yo por ejemplo tengo un modulo para verificar los CIF en la AEAT y es necesario el certificado p12 subido a la carpeta del modulo
LA CONTRASEÑA se guarda en la base de datos encriptada . obviamente una vez se guarda los datos se podrian sacar, pero no es facil.
Es lo mas seguro que he podido encontrar, otra manera es pagando a terceros y otro gasto mensual de tantos que hay

Lo de que "la contraseña se guarda en la base de datos encriptada".... no vale de nada si tienes una intrusión en el servidor. Si se guarda encriptada, la propia clave de encriptación de la contraseña se tiene que guardar en la base de datos también o en un fichero (o estará hardcoded en el código del módulo).... cualquiera de las opciones si tienes una intrusión con acceso al código fuente de tu sitio web prestashop (lo cual da también acceso a la BBDD) te da igual.... van a poder acceder también al certificado y su contraseña...

 

[qs]

1 minute ago, ps_developer said:

Lo de que "la contraseña se guarda en la base de datos encriptada".... no vale de nada si tienes una intrusión en el servidor. Si se guarda encriptada, la propia clave de encriptación de la contraseña se tiene que guardar en la base de datos también o en un fichero (o estará hardcoded en el código del módulo).... cualquiera de las opciones si tienes una intrusión con acceso al código fuente de tu sitio web prestashop (lo cual da también acceso a la BBDD) te da igual.... van a poder acceder también al certificado y su contraseña...

 

Esta guardada solo en una carpeta del servidor .”fichero”

[ps_developer]

2 hours ago, infoal said:

buenos dias @ps_developer

déjame que divida este mensaje en dos partes,

por un lado me interesa muchísimo tu punto de vista por que, para dentro de 1 año, además de verifactu, los prestashops deberan cumplir la ley crea y crece, y eso significa que en teoria deberan enviar las facturas en XML firmados digitalmente con el certificado de la empresa. De momento con verifactu lo hemos solucionado con los certificados de colaborador social de la aeat, pero si no cambia la norma, deberemos encontrar una manera de firmar las facturas de cada empresa con su certificado.

he encontrado una gente que se llaman factupress y que han hecho el plugin de verifactu para wordpress que lo que hacen es subir el PFX en en servidor del cliente, y la contraseña guardarla en un servidor propio totalmente separado, y llaman a un webservice propio que realiza la firma combinando ambas cosas solo cuando lo necesitan. Así evitan parte del riesgo, y evitan la enorme complejidad que tiene cumplir la norma para el almacenamiento de certificados de clientes. Probablemente es la mejor aproximación que he visto.

me interesaria mucho intercambiar conocimientos de este tema, tenemos 1 año para perfeccionarlo.

del tema del verifactu,
tu planteamiento tiene bastante sentido. Des de que la administración pública reemplazó su dependencia de java y de internet explorer y adoptó el lanzamiento de autofirma desde cualquier navegador, sin duda se ha ganado en facilidad, fiabilidad y robustez... y aplicar un enfoque similar para una solución de firma parece tener todo el sentido. 

 

y por otro lado, ya dejo a un lado el tema de verifactu.

desde el principio estoy insistiendo en una idea que varios de los que han escrito en el foro no acaban de ver, y es que en realidad no nos enfrentamos a un problema técnico con el tema de verifactu, si fuera así cualquier enfoque sería perfectamente válido. El problema al que nos enfrentamos es 100% de cumplimiento legal, da igual como lo plantee yo, como lo plantees tu, y cualquier desarrollador de software que pueda leernos. 

y como sé que casi nadie se ha leído con detalle la ley de la que estamos hablando, me permito pegaros un resumen con enlaces al boe generado por el chatgpt de los puntos que nos interesan, son los dos siguientes, os los recumo yo primero y mas abajo os dejo el texto integro.

1 - multa de 50.000 euros fija por cada ejercicio fiscal en el que el propietario de una web haya estado utilizando (en el caso de prestashop) un plugin que no esté "homologado", es decir, que no tenga la correspondiente declaración responsable del desarrollador certificando que cumple

2 - multa de hasta 150.000 euros para el desarrollador que suministre sistemas de facturación (como un plugin de prestashop que envie datos a verifactu) que no cumpla la normativa... y lo de cumplir la normativa, pues no es solo lo de la declaración responsable, hace falta mucho estudio de las leyes, son una lista inacabable de requerimientos (cadena de hashes, conservación, seguridad, y mil cosas).

y así está el tema ahora mismos, o sea que no, no hablamos , en absoluto, de un tema técnico, y mira que me sabe mal, por que a mi lo que me gusta es hablar de temas técnicos y no de temas legales, pero es que si alguien entra en este foro, y no está informado de lo que hay, es importante que lo sepa, da igual que imaginemos como se puede o no se puede hacer a nivel técnico, o el desarrollador te firma la declaración responsable, o tienes un problemón:
 

 

Hola @infoal, en la parte técnica, lo del módulo que sí requiere instalar certificado+clave privada pero que se comunica con un API externo para obtener la contraseña parece en principio interesante.... pero si consiguen hacer una intrusión al servidor, la clave de autenticación que sea necesaria para ese API externo tendrá el módulo que guardarla en algún sitio, base de datos o un fichero. De nuevo, sería parecido a guardar la propia contraseña del certificado en en el propio prestashop. Se podría exponer fácilmente el acceso a la clave privada.....

Pero por otro lado, se me ocurre (en la misma línea que mi propuesta de Autofirma) otra implementación en la que sin dependencia de autofirma, guardas el certificado con contraseña en el servidor y cuando se haga el envío te pide la contraseña del certificado el backoffice, la contraseña se pediría cada vez que vayas a hacer un envío, no la guardaría el servidor en ningún sitio. Es un poco menos segura que la propuesta de Autofirma porque tienes que instalar el certificado en el servidor, pero no guardas la clave privada de ninguna forma en el servidor ni ninguna forma de acceder a ella... La solución de Autofirma me parece mejor en cualquier caso.

En la parte legal, está claro que es lo más delicado. No me he leido la ley, pero entiendo que esto en concreto:

"Debe conservar los datos en un formato accesible, legible y recuperable durante el tiempo que establezca la normativa."

Con esto requiere que el módulo haga cosas adicionales para homologar un módulo descargable.

Creo que sería posible con un módulo que aparte de la integración con Verifactu, fuerze un backup de las facturas con redundancia geográfica "prestashop + módulo Verifactu + backup con redundancia geográfica" (por ejemplo en AWS S3). La solución de backup en S3 requiere de nuevo un coste mensual, pero S3 para el volumen de facturas sería una solución superbarata para almacenar varios años de facturas (probablemente menos de 1 Euro al mes).... El módulo, para garantizarse una posible homologación (por quien la desarrolle) podría forzar a dicho backup. El backup de las facturas podría ser la escritura de las facturas PDF en tiempo real en S3 al mismo tiempo que se envían a Verifactu.

Con algo así creo un desarrollador debería ser capaz de homologar un "módulo de pago único"...

 

 

 

[gusman126]

hace 14 minutos, ps_developer dijo:

Lo de que "la contraseña se guarda en la base de datos encriptada".... no vale de nada si tienes una intrusión en el servidor. Si se guarda encriptada, la propia clave de encriptación de la contraseña se tiene que guardar en la base de datos también o en un fichero (o estará hardcoded en el código del módulo).... cualquiera de las opciones si tienes una intrusión con acceso al código fuente de tu sitio web prestashop (lo cual da también acceso a la BBDD) te da igual.... van a poder acceder también al certificado y su contraseña...

 

Lo se, pero es lo mas seguro que puedes hacer sin tener que usar herramientas externas. 
Bueno , siguiendo con lo de Verifactu.
A mis clientes le aconsejo usar un ERP mucho mas seguro que cualquier otra alternativa, mas caro? puede , hay programas gratuitos , baratos y de buen precio 
Como he indicado lo caro es el conector , aunque una inversión de programa + conector entre 600€ y mucho mas, te ahorras problemas, te ahorras cosas raras y sobre todo estas mucho mas legal que solo en prestashop
si un negocio no puedes gastar 600€ el primer año y luego 350 o 300 al año, mira como hacerlo porque debes tener una mierda de beneficios.
Y que conste TODA esta mierda si lo van hacer TODOS perfecto , y es una mierda tener que gastar dinero cuando te obligan hacer algo (aunque estaba la mierda de kit digital y programas, no hay que abrir el melon) 
Pues eso, he venido aqui a aconsejar  USAR ERP o PROGRAMA DE GESTION, 
 

[ps_developer]

16 minutes ago, qs said:

Esta guardada solo en una carpeta del servidor .”fichero”

Sí, pues eso, si te hacen una intrusión al servidor lo más probable es que consigan acceso al menos de lectura a cualquier carpeta a la que tenga permisos de lectura Prestashop / PHP, es decir, van a poder acceder a dicho fichero.

Un hacker que entra en tu servidor y consigue cualquier acceso de escritura a cualquier carpeta de tu sitio web, ya sea de Prestashop, Wordpress o lo que sea, lo primero que hace normalmente es subirse un file manager escrito en PHP, que le da acceso total a toda la estructura de directorios en tu servidor a la que tenga acceso PHP / Prestashop.... Si tu módulo Prestashop puede leer ese fichero lo podrá leer también dicho file manager en PHP...

 

[gusman126]

hace 3 minutos, ps_developer dijo:

Hola @infoal, en la parte técnica, lo del módulo que sí requiere instalar certificado+clave privada pero que se comunica con un API externo para obtener la contraseña parece en principio interesante.... pero si consiguen hacer una intrusión al servidor, la clave de autenticación que sea necesaria para ese API externo tendrá el módulo que guardarla en algún sitio, base de datos o un fichero. De nuevo, sería parecido a guardar la propia contraseña del certificado en en el propio prestashop. Se podría exponer fácilmente el acceso a la clave privada.....

Pero por otro lado, se me ocurre (en la misma línea que mi propuesta de Autofirma) otra implementación en la que sin dependencia de autofirma, guardas el certificado con contraseña en el servidor y cuando se haga el envío te pide la contraseña del certificado el backoffice, la contraseña se pediría cada vez que vayas a hacer un envío, no la guardaría el servidor en ningún sitio. Es un poco menos segura que la propuesta de Autofirma porque tienes que instalar el certificado en el servidor, pero no guardas la clave privada de ninguna forma en el servidor ni ninguna forma de acceder a ella... La solución de Autofirma me parece mejor en cualquier caso.

En la parte legal, está claro que es lo más delicado. No me he leido la ley, pero entiendo que esto en concreto:

"Debe conservar los datos en un formato accesible, legible y recuperable durante el tiempo que establezca la normativa."

Con esto requiere que el módulo haga cosas adicionales para homologar un módulo descargable.

Creo que sería posible con un módulo que aparte de la integración con Verifactu, fuerze un backup de las facturas con redundancia geográfica "prestashop + módulo Verifactu + backup con redundancia geográfica" (por ejemplo en AWS S3). La solución de backup en S3 requiere de nuevo un coste mensual, pero S3 para el volumen de facturas sería una solución superbarata para almacenar varios años de facturas (probablemente menos de 1 Euro al mes).... El módulo, para garantizarse una posible homologación (por quien la desarrolle) podría forzar a dicho backup. El backup de las facturas podría ser la escritura de las facturas PDF en tiempo real en S3 al mismo tiempo que se envían a Verifactu.

Con algo así creo un desarrollador debería ser capaz de homologar un "módulo de pago único"...

 

 

 

lo de "homologar el modulo" No se como lo van hacer y no si lo han pensado bien, cualquier problema que tenga el cliente al final llegara al desarrollador.
Yo no hice el modulo por eso, y disculpa @qs pero yo ni loco haria un modulo para prestashop poniendo en riesgo una posible multa o NO, eso debes mirar bien la normativa.
Repito como programador ni loco haria o hare un modulo que certifique que cumple la normativa y la ley  en un sistema abierto como prestashop
Y eso que tengo un modulo de bloqueo de cookies y datalayer y nunca nunca puedo asegurar que se instale un modulo un codigo que genere cookies, porque es imposible controlar algo asi, lo mismo con las facturas .

Suerte @qs y espero que vendas muchos y vaya todo bien, pero sintiendolo no lo voy a aconsejar mis clientes.  
 

[ps_developer]

3 minutes ago, gusman126 said:

Lo se, pero es lo mas seguro que puedes hacer sin tener que usar herramientas externas. 
Bueno , siguiendo con lo de Verifactu.
A mis clientes le aconsejo usar un ERP mucho mas seguro que cualquier otra alternativa, mas caro? puede , hay programas gratuitos , baratos y de buen precio 
Como he indicado lo caro es el conector , aunque una inversión de programa + conector entre 600€ y mucho mas, te ahorras problemas, te ahorras cosas raras y sobre todo estas mucho mas legal que solo en prestashop
si un negocio no puedes gastar 600€ el primer año y luego 350 o 300 al año, mira como hacerlo porque debes tener una mierda de beneficios.
Y que conste TODA esta mierda si lo van hacer TODOS perfecto , y es una mierda tener que gastar dinero cuando te obligan hacer algo (aunque estaba la mierda de kit digital y programas, no hay que abrir el melon) 
Pues eso, he venido aqui a aconsejar  USAR ERP o PROGRAMA DE GESTION, 
 

De seguro ya te digo que lo puedes encriptar 20 veces, que si  las claves de encriptación la guardas en fichero o en tu base de datos del mismo servidor, de seguro no tiene nada....

La única solució 100% segura de momento y que no requiere herramientas externas es Autofirma, yo hago desarrollo de módulos pero para mi web y para mis clientes, no tengo tiempo de ponerme ahora a desarrollar un módulo de este tipo pero la verdad que me estan entrando ganas de ponerme...

Pero como comentaba alguien en el foro, es más complicado por el tema legal, si lo hace alguien lo suyo sería tener en cuenta el resto de requisitos que creo que tambíen se puede proponer una solución que los cubra como módulo único y tal vez que fuerze a utilizar una solución de backup en object storage / S3 por ejemplo que serán un centimos al mes o un euro al mes....

 

 

[gusman126]

hace 3 minutos, ps_developer dijo:

Sí, pues eso, si te hacen una intrusión al servidor lo más probable es que consigan acceso al menos de lectura a cualquier carpeta a la que tenga permisos de lectura Prestashop / PHP, es decir, van a poder acceder a dicho fichero.

Un hacker que entra en tu servidor y consigue cualquier acceso de escritura a cualquier carpeta de tu sitio web, ya sea de Prestashop, Wordpress o lo que sea, lo primero que hace normalmente es subirse un file manager escrito en PHP, que le da acceso total a toda la estructura de directorios en tu servidor a la que tenga acceso PHP / Prestashop.... Si tu módulo Prestashop puede leer ese fichero lo podrá leer también dicho file manager en PHP...

 

Y cualquier sistema puede pasar, herramientas externas, internas,  todos los sistemas tienen agujeros de seguridad o las personas son el agujero.
Hay que intentar bloquear y proteger todo lo posible. 
Luego si hay intrusión no es solo el problema del certificado son todo lo que tienes que hacer y denunciar y publicar y veremos la multa de la AEPD 
Sobre todo en sistemas de prestashop 1.7 y los 1.6 que es increible que aun esten por ahi , una intrusion alguien denuncia y te cae el pelo por tener un sistema sin soporte de seguridad desde hace 10 años? 
bueno esto ya seria otro mensaje en otro sitio del foro

[ps_developer]

4 minutes ago, gusman126 said:

lo de "homologar el modulo" No se como lo van hacer y no si lo han pensado bien, cualquier problema que tenga el cliente al final llegara al desarrollador.
Yo no hice el modulo por eso, y disculpa @qs pero yo ni loco haria un modulo para prestashop poniendo en riesgo una posible multa o NO, eso debes mirar bien la normativa.
Repito como programador ni loco haria o hare un modulo que certifique que cumple la normativa y la ley  en un sistema abierto como prestashop
Y eso que tengo un modulo de bloqueo de cookies y datalayer y nunca nunca puedo asegurar que se instale un modulo un codigo que genere cookies, porque es imposible controlar algo asi, lo mismo con las facturas .

Suerte @qs y espero que vendas muchos y vaya todo bien, pero sintiendolo no lo voy a aconsejar mis clientes.  
 

Entiendo que sí consigues que la administración homologue tu módulo, a partir de ahí te quitas la responsabilidad de la multa. Por supuesto que siempre puede haber algún problema pero entiendo que la multa es por vender un módulo sin homologación (para el desarrollador) o para la tienda por usar un software sin homologar....

 

 

[gusman126]

hace 1 minuto, ps_developer dijo:

Entiendo que sí consigues que la administración homologue tu módulo, a partir de ahí te quitas la responsabilidad de la multa. Por supuesto que siempre puede haber algún problema pero entiendo que la multa es por vender un módulo sin homologación (para el desarrollador) o para la tienda por usar un software sin homologar....

 

 

Pero sabes que es imposible en un sistema tan abierto como prestashop te homologen algo como lo que pide AEAT.

Yo alucine cuando Odoo hizo el modulo para la version comunity , alucine porque la comunity es abierta , menos que prestashop obviamente, pero lo es. 
Lo dicho, suerte a QS y que venda muchos que para eso trabajamos los desarrolladores.

 

[infoal]

17 minutes ago, ps_developer said:

Entiendo que sí consigues que la administración homologue tu módulo, a partir de ahí te quitas la responsabilidad de la multa. Por supuesto que siempre puede haber algún problema pero entiendo que la multa es por vender un módulo sin homologación (para el desarrollador) o para la tienda por usar un software sin homologar....

 

 

hola, no, no funciona así, la administración no tiene medios técnicos para homolagar nada, imaginaros lo que supondria, La "homologación" consiste en una especie de carta firmada por el administrador de la sociedad que ha creado el software, donde "jura", que su software cumple... y más le vale que así sea, por que esa carta no es lo que va a utilizar hacienda para saber a quien multar en caso de problema... a todo esto, creo que ya está claro que el módulo dice que tiene QS, al igual que el de STK, no tienen declaración responsable (espero equivocarme), y si es así, no hay más vueltas que dar, son ilegales, 50.000 euros de multa prr cada año que se usen.

[gusman126]

hace 5 minutos, infoal dijo:

hola, no, no funciona así, la administración no tiene medios técnicos para homolagar nada, imaginaros lo que supondria, La "homologación" consiste en una especie de carta firmada por el administrador de la sociedad que ha creado el software, donde "jura", que su software cumple... y más le vale que así sea, por que esa carta no es lo que va a utilizar hacienda para saber a quien multar en caso de problema... a todo esto, creo que ya está claro que el módulo dice que tiene QS, al igual que el de STK, no tienen declaración responsable (espero equivocarme), y si es así, no hay más vueltas que dar, son ilegales, 50.000 euros de multa prr cada año que se usen.

Tienes razon, AEAT no homologa, es verdad. 

Como dices es quien hace el software, por lo tanto el que lo haga para prestashop, enhorabuena. 
 

[infoal]

33 minutes ago, gusman126 said:

Y cualquier sistema puede pasar, herramientas externas, internas,  todos los sistemas tienen agujeros de seguridad o las personas son el agujero.
Hay que intentar bloquear y proteger todo lo posible. 
Luego si hay intrusión no es solo el problema del certificado son todo lo que tienes que hacer y denunciar y publicar y veremos la multa de la AEPD 
Sobre todo en sistemas de prestashop 1.7 y los 1.6 que es increible que aun esten por ahi , una intrusion alguien denuncia y te cae el pelo por tener un sistema sin soporte de seguridad desde hace 10 años? 
bueno esto ya seria otro mensaje en otro sitio del foro

menudo melón has abierto amigo mio!
¿sabeis esa gente que se instala plugins piratas para ahorrarse 15 euros? pues si les entran por ahí, les roban la base de datos y no informan inmediatamente a la aepd y a los clientes, negligencia y, dice el supremo que hasta 4 años de carcel: https://www.autonomosyemprendedor.es/articulo/empresas/multas-millonarias-autonomos-pymes-que-informen-clientes-ciberataque/20250925162408045670.html

[infoal]

y por eso, precisamente, a parte de conectar con un erp (cosa que obviamente es mas caro pero óptimo), la única solución legal son las apis externas, con su correspondiente declaración responsable, en nuestra web ya les tenemos publicadas

[gusman126]

hace 5 minutos, infoal dijo:

y por eso, precisamente, a parte de conectar con un erp (cosa que obviamente es mas caro pero óptimo), la única solución legal son las apis externas, con su correspondiente declaración responsable, en nuestra web ya les tenemos publicadas

exacto. y como desarrollador, le doy toda la enhorabuena a @qs por hacerlo y espero que venda y no tenga problemas. 
Pero yo no lo voy a aconsejar a mis clientes. 
100% de ERP o programa de gestion