Buenas tardes y felices fiestas,
Dudas después de leer todo el hilo:
1. Módulo 'invoicexmlexport' de doymer.com: me ha parecido entender que este módulo lo único que hace es exportar las facturas a XML con la posibilidad de ser firmadas electrónicamente conforme a Facturae, pero no hace nada más de lo exigido por la Ley Antifraude y Verifactu. ¿Es correcto o estoy equivocado?
2. Módulo 'Ley Antifraude' de sgestion.net: ¿qué es la 'Hoja Responsable'? ¿es algo requerido por la AEAT? ¿implica la certificación de Dolibarr en materia de Ley Antifraude en caso de inspección fiscal? ¿si tienes la 'Hoja Responsable' en regla evitas todas las multas que parece que nos van a amenazar en breve?
3. Parece que otras opciones para manejar esto son API Multisoftware Verifactu de binovo.es y DoliFactu.es de 2byte, Notebuk y otros desarrolladores: ¿alguien conoce alguna más?
Aparte, la pregunta del millón: si Dolibarr no incluye el soporte a esto como módulo propio GNU/GPL v3+ instalable en su versión por defecto, su versión oficial, GNU/GPL v3+, la que te puedes descargar e instalar libremente sin pasar por caja, será inservible en España, ¿no? Para que te sirva Dolibarr en España, habrá que contratar un módulo no incluido en la versión oficial de Dolibarr o usar algo ajeno a Dolibarr como la API Verifactu u otra cosa similar. ¿Es correcto?
Gracias por la atención y que disfrutéis de la cena.
Abrazos,
Manuel
LEY ANTIFRAUDE Y CERTIFICADO PARA DOLIBARR
Buenas, te puedo responder a varias cosas...
Es obligatorio por ley una hoja responsable del integrador/programador/desarrollador donde se indique que cumple la normativa. Con el modulo se facilita dicha hoja responsable, en esa hoja sale version de doli , versión de modulo con su hash y los datos fiscales del cliente.
Nosotros certificamos que el programa tal como es en esa version y con ese modulo cumple la normativa, si después el usuario toca y modifica se pierde esa hija responsable
Sobre el punto 3, la opcion de la api no es un modulo para dolibarr, tendrias q desarrollarlo o alguien. Es una api intermedia como muchas otras, creo q lo de 2byte va por ese camino, pero no lo se seguro.
Cuando acabemos lo nuestro, sera directo sobre hacienda no con apis de terceros.
Te sería inservible SOLO si lo usas para facturar a autonomos y empresas.
Un saludo.
Es obligatorio por ley una hoja responsable del integrador/programador/desarrollador donde se indique que cumple la normativa. Con el modulo se facilita dicha hoja responsable, en esa hoja sale version de doli , versión de modulo con su hash y los datos fiscales del cliente.
Nosotros certificamos que el programa tal como es en esa version y con ese modulo cumple la normativa, si después el usuario toca y modifica se pierde esa hija responsable
Sobre el punto 3, la opcion de la api no es un modulo para dolibarr, tendrias q desarrollarlo o alguien. Es una api intermedia como muchas otras, creo q lo de 2byte va por ese camino, pero no lo se seguro.
Cuando acabemos lo nuestro, sera directo sobre hacienda no con apis de terceros.
Te sería inservible SOLO si lo usas para facturar a autonomos y empresas.
Un saludo.
Muchísimas gracias por tu respuesta.
Lo de la hoja responsable me parece esencial para la tranquilidad de distribuidores y usuarios finales, que las multas previstas son para echarse a temblar...
Entiendo que lo de tocar y modificar se refiere únicamente a lo relacionado con el módulo antifraude (que cualquier otra cosa se podrá seguir tocando y modificando).
Y confirmo que la API de binovo requiere que alguien desarrolle algo con Rest, además de tener unos precios de licencias bastante elevados (les pregunté por correo).
Abrazos
Lo de la hoja responsable me parece esencial para la tranquilidad de distribuidores y usuarios finales, que las multas previstas son para echarse a temblar...
Entiendo que lo de tocar y modificar se refiere únicamente a lo relacionado con el módulo antifraude (que cualquier otra cosa se podrá seguir tocando y modificando).
Y confirmo que la API de binovo requiere que alguien desarrolle algo con Rest, además de tener unos precios de licencias bastante elevados (les pregunté por correo).
Abrazos
Buenas.spanish escribió: ↑Mar, 24/12/2024, 19:20 Buenas tardes y felices fiestas,
Dudas después de leer todo el hilo:
1. Módulo 'invoicexmlexport' de doymer.com: me ha parecido entender que este módulo lo único que hace es exportar las facturas a XML con la posibilidad de ser firmadas electrónicamente conforme a Facturae, pero no hace nada más de lo exigido por la Ley Antifraude y Verifactu. ¿Es correcto o estoy equivocado?
.....
Abrazos,
Manuel
Te puedo responder directamente ya que somos los que estamos desarrollando el módulo que has indicado en el punto 1.
El módulo está en desarrollo (V 0.3) por lo que las funciones finales están todavía por concretar y los posibles errores por localizar, pero ya hace varias cosas. Como acabo de comentar en el hilo en el que se anuncia el modulo (viewtopic.php?f=12&t=14272) hemos sido capaces de bloquear las acciones de modificación y eliminación de facturas que han sido exportadas y que se insertan y controlan mediante un BlockChain. Estos cambios se están realizando en una rama separada de la principal en el desarrollo. La rama principal solo es, como bien dices, Facturae que es lo que casi todos los programas actuales hacen: te generan los ficheros XML o XSIG (no todos permiten que los puedas firmar) y te los dejan para que los envíes a mano a FACe. En principio ese era el objetivo del modulo, entre otras cosas, porque los detalles de Veri*Factu no estaban muy claros.
Sin embargo, debido a que se acerca el plazo definitivo, se comenzó el desarrollo en una rama adicional de la parte de Veri*Factu, entendiendo por eso la generación, e inserción, del código QR en las facturas y el envío de las mismas a los servidores de pruebas o de producción correspondientes. Para no alterar la rama principal, que unos pocos están probando, es en esta rama donde se ha añadido el código que evita que las facturas sean modificadas. Si hay necesidad podemos pasarlo a la principal para que otros lo prueben.
Esta rama, por el momento es capaz de generar los QR e insertarlos en las facturas, tanto si se emiten mediante fusión ODT como si se emiten usando las plantillas crabe o sponge. Pero todavía no se realiza el envío, entre otras cosas, porque no tenemos claro como hay que hacerlo. Para enviar a FACe directamente hay que registrarse primero con un certificado que identifique al remitente. No sabemos si hay que hacer lo mismo para Veri*Factu.
En principio, hasta que no se aclaren esos detalles la rama QR no se integrara en la principal. El modulo esta en pleno desarrollo y las características que se desarrollan están basadas, principalmente, en nuestras necesidades dado que no hay mucha gente ahí afuera que haya mostrado interés por colaborar en su desarrollo.
Si esto cambia aquí estamos para ofrecerlo y trabajar para mejorarlo con la idea de que cumpla con la ley porque los primeros interesados somos nosotros que usamos Dolibarr para gestionar nuestras facturas.
Buenas Florenci.Solatec escribió: ↑Dom, 22/12/2024, 19:24 Hola buenas tardes,
He instalado el módulo en mi Dolibarr de test y activado las opciones para mi usuario. Veo las opciones que comentas, pero cuando voy a la opción masiva para exportar la factura a XML me aparece un error que dice:
Alguna condición para la generación de las facturas no se cumple. Faltan datos del registro del emisor.
Entiendo que me falta configurar alguna cosa, pero no lo encuentro.
Muchas gracias por el módulo y la ayuda.
Florenci
Disculpa pero este foro no me avisa de las nuevas entradas.
Se ha encontrado que la versión del modulo que bajaste, en la fecha que indicas, tiene un problema en ciertos casos con la validación de los datos requeridos para poder generar luego los ficheros. Eso está reparado en a partir de la versión 0.3.
Ahora ya está disponible la 0.4 (https://drive.google.com/file/d/1Pbh5xS ... sp=sharing) que incluye el bloqueo de los botones de modificación y borrado de las facturas si han sido exportadas.
Espero que esto te sea de ayuda.
Hola merril,
estoy tratando de probar la última versión del módulo que has pasado en mi Dolibarr y si no incluyo el archivo pfx del certificado me devuelve este error al tratar de generar el xml de una factura:
"Alguna condición para la generación de las facturas no se cumple. Falta el fichero para la firma"
Si subo el archivo .pfx del certificado e indico la contraseña, al tratar de generar el xml me devuelve primero un error muy raro:
"Error al obtener los detalles del error"
Y al aceptar:
"Ocurrió un error:Cannot read properties of undefined (reading 'read')"
No sé si es un problema del módulo o del fichero PFX del certificado. Espero que me puedas ayudar.
Gracias.
estoy tratando de probar la última versión del módulo que has pasado en mi Dolibarr y si no incluyo el archivo pfx del certificado me devuelve este error al tratar de generar el xml de una factura:
"Alguna condición para la generación de las facturas no se cumple. Falta el fichero para la firma"
Si subo el archivo .pfx del certificado e indico la contraseña, al tratar de generar el xml me devuelve primero un error muy raro:
"Error al obtener los detalles del error"
Y al aceptar:
"Ocurrió un error:Cannot read properties of undefined (reading 'read')"
No sé si es un problema del módulo o del fichero PFX del certificado. Espero que me puedas ayudar.
Gracias.
He comprobado el modulo en la ultima versión de Dolibarr 20.0.2 y no funciona. La versión 0.4 para ser exacto. El error es el siguiente "Error al obtener los detalles del error".
Si le indico que es sin contraseña el certificado, me la sigue pidiendo y sigue dando el mismo error. No me genera el documento.
Si deshabilito la opción de certificado sigue preguntando la contraseña. No me acaba de funcionar. Si podeis ayudarme os lo agradeceria.
Si le indico que es sin contraseña el certificado, me la sigue pidiendo y sigue dando el mismo error. No me genera el documento.
Si deshabilito la opción de certificado sigue preguntando la contraseña. No me acaba de funcionar. Si podeis ayudarme os lo agradeceria.
merill escribió: ↑Mié, 15/01/2025, 03:38Buenas.spanish escribió: ↑Mar, 24/12/2024, 19:20 Buenas tardes y felices fiestas,
Dudas después de leer todo el hilo:
1. Módulo 'invoicexmlexport' de doymer.com: me ha parecido entender que este módulo lo único que hace es exportar las facturas a XML con la posibilidad de ser firmadas electrónicamente conforme a Facturae, pero no hace nada más de lo exigido por la Ley Antifraude y Verifactu. ¿Es correcto o estoy equivocado?
.....
Abrazos,
Manuel
Te puedo responder directamente ya que somos los que estamos desarrollando el módulo que has indicado en el punto 1.
El módulo está en desarrollo (V 0.3) por lo que las funciones finales están todavía por concretar y los posibles errores por localizar, pero ya hace varias cosas. Como acabo de comentar en el hilo en el que se anuncia el modulo (https://www.dolibarr.es/foro/viewtopic.php?f=12&t=14272) hemos sido capaces de bloquear las acciones de modificación y eliminación de facturas que han sido exportadas y que se insertan y controlan mediante un BlockChain. Estos cambios se están realizando en una rama separada de la principal en el desarrollo. La rama principal solo es, como bien dices, Facturae que es lo que casi todos los programas actuales hacen: te generan los ficheros XML o XSIG (no todos permiten que los puedas firmar) y te los dejan para que los envíes a mano a FACe. En principio ese era el objetivo del modulo, entre otras cosas, porque los detalles de Veri*Factu no estaban muy claros.
Sin embargo, debido a que se acerca el plazo definitivo, se comenzó el desarrollo en una rama adicional de la parte de Veri*Factu, entendiendo por eso la generación, e inserción, del código QR en las facturas y el envío de las mismas a los servidores de pruebas o de producción correspondientes. Para no alterar la rama principal, que unos pocos están probando, es en esta rama donde se ha añadido el código que evita que las facturas sean modificadas. Si hay necesidad podemos pasarlo a la principal para que otros lo prueben.
Esta rama, por el momento es capaz de generar los QR e insertarlos en las facturas, tanto si se emiten mediante fusión ODT como si se emiten usando las plantillas crabe o sponge. Pero todavía no se realiza el envío, entre otras cosas, porque no tenemos claro como hay que hacerlo. Para enviar a FACe directamente hay que registrarse primero con un certificado que identifique al remitente. No sabemos si hay que hacer lo mismo para Veri*Factu.
En principio, hasta que no se aclaren esos detalles la rama QR no se integrara en la principal. El modulo esta en pleno desarrollo y las características que se desarrollan están basadas, principalmente, en nuestras necesidades dado que no hay mucha gente ahí afuera que haya mostrado interés por colaborar en su desarrollo.
Si esto cambia aquí estamos para ofrecerlo y trabajar para mejorarlo con la idea de que cumpla con la ley porque los primeros interesados somos nosotros que usamos Dolibarr para gestionar nuestras facturas.
Esto y otros muchos vendedores de humo, no tienen certificado del desarrollador. Te lo tienes que certificar tú mismo.
Si eres desarrollador y no certificas, el que lo use paga 50.000 €.
Si desarrollas para tí mismo, te certificas a tí miso y pagas 200.000 €. O bien tienes la multa asegurada de 50.000 €
Si certificas para otros: 150.000 € por usuario.
Es decir que si vienes preguntando como pyme:
Definitivamente no hay NINGÚN DESARROLLADOR de módulo dolibarr verifactu o RSIF que CERTIFIQUE QUE CUMPLE CON LA LEY, Y SI LO USAS COMO PYME, 50.000 € DE MULTA.
Buenas noches;
Lo que comentas me genera bastantes dudas, sobre todo por el uso que haces del término “certificado del desarrollador”.
En el marco del RD 1007/2023 y la Orden HAC/1177/2024, lo que está regulado para los sistemas informáticos de facturación es la Declaración Responsable del productor/comercializador del software, no un sistema de “certificación” externa del desarrollador por parte de la AEAT o de un organismo homologador específico.
Las sanciones que mencionas (150.000 € para desarrolladores por software y año, 50.000 € para usuarios por ejercicio, y 1.000 € adicionales cuando falte un certificado exigible) derivan del art. 201 bis de la LGT y de su desarrollo, pero ese “certificado” al que se refiere la ley es una figura genérica aplicable solo cuando reglamentariamente se establezca un procedimiento de certificación formal concreto.
A día de hoy, para los SIF/VeriFactu regulados por el RD 1007/2023, lo que se exige de forma expresa es:
1 - Que el software cumpla los requisitos técnicos (integridad, hash, QR, XML RSIF, etc.).
2 - Que el productor/comercializador firme una Declaración Responsable asumiendo su responsabilidad sobre ese software.
No conozco –y agradecería mucho que lo indicaras si existe– ningún procedimiento oficial de “certificación de desarrollador” específico para módulos de Dolibarr o SIF en general publicado por la AEAT, más allá de la Declaración Responsable que todos tenemos que emitir bajo nuestra propia responsabilidad desarrollador, integrador, usuario...
¿Podrías concretar a qué “certificado del desarrollador” te refieres exactamente y, si lo hay, enlazar el BOE u orden ministerial donde se regula ese proceso de certificación concreta para este caso? Porque, tal y como está hoy la normativa, hablar de que “no hay ningún desarrollador que certifique que cumple con la ley” puede inducir a pensar que existe un sello o certificado externo obligatorio, y lo que realmente hay es la DR del software firmada por el productor/comercializador.
Un saludo.
Lo que comentas me genera bastantes dudas, sobre todo por el uso que haces del término “certificado del desarrollador”.
En el marco del RD 1007/2023 y la Orden HAC/1177/2024, lo que está regulado para los sistemas informáticos de facturación es la Declaración Responsable del productor/comercializador del software, no un sistema de “certificación” externa del desarrollador por parte de la AEAT o de un organismo homologador específico.
Las sanciones que mencionas (150.000 € para desarrolladores por software y año, 50.000 € para usuarios por ejercicio, y 1.000 € adicionales cuando falte un certificado exigible) derivan del art. 201 bis de la LGT y de su desarrollo, pero ese “certificado” al que se refiere la ley es una figura genérica aplicable solo cuando reglamentariamente se establezca un procedimiento de certificación formal concreto.
A día de hoy, para los SIF/VeriFactu regulados por el RD 1007/2023, lo que se exige de forma expresa es:
1 - Que el software cumpla los requisitos técnicos (integridad, hash, QR, XML RSIF, etc.).
2 - Que el productor/comercializador firme una Declaración Responsable asumiendo su responsabilidad sobre ese software.
No conozco –y agradecería mucho que lo indicaras si existe– ningún procedimiento oficial de “certificación de desarrollador” específico para módulos de Dolibarr o SIF en general publicado por la AEAT, más allá de la Declaración Responsable que todos tenemos que emitir bajo nuestra propia responsabilidad desarrollador, integrador, usuario...
¿Podrías concretar a qué “certificado del desarrollador” te refieres exactamente y, si lo hay, enlazar el BOE u orden ministerial donde se regula ese proceso de certificación concreta para este caso? Porque, tal y como está hoy la normativa, hablar de que “no hay ningún desarrollador que certifique que cumple con la ley” puede inducir a pensar que existe un sello o certificado externo obligatorio, y lo que realmente hay es la DR del software firmada por el productor/comercializador.
Un saludo.