Primeros clientes que no quieren saber nada

[novatico]

Empezado por sglorka

A partir de ahora si actualizas un programa no adaptado para un cliente Verifactu la actualización sólo puede ser de partes del programa que no sean el SIF (mecanización de datos de entrada y generación de Facturas), todo lo demás se puede seguir actualizando hasta final de año o hasta que le toque

Siempre y cuando el programa sea modular, puedes actualizar módulos que no afecten al RRSIF pero si es "monobloque", es decir un "exe" completo, entonces no.

[sglorka]

Empezado por novatico

Siempre y cuando el programa sea modular, puedes actualizar módulos que no afecten al RRSIF pero si es "monobloque", es decir un "exe" completo, entonces no.

Yo no lo veo así.
El programa puede estar formado por clases y módulos que luego tu decides si lo compilas como un sólo bloque o distribuyes un bloque general (exe) y sus librearías como dll de apoyo. Si una de esas dll hiciera referencia a alguna parte del SIF pero también estuviera involucrada en otros menesteres que no tuvieran que ver con el SIF y fuera objeto de actualización, entiendo que la podría actualizar sin problemas. No creo que te vayan a pedir el código fuente para verificarlo. Ellos lo que no quieren es que actúes de manera preventiva o correctiva sobre la parte del programa que genera facturas (SIF) salvo que sea para cumplir con RRSIF porque por ley, a partir del 29 de julio, todo SIF debe cumplir la norma y estaría fuera de la misma, la corrección, la actualización o la prevención de las funcionalidades de un SIF no adaptado.

[novatico]

Empezado por sglorka

Yo no lo veo así.
El programa puede estar formado por clases y módulos que luego tu decides si lo compilas como un sólo bloque o distribuyes un bloque general (exe) y sus librearías como dll de apoyo. Si una de esas dll hiciera referencia a alguna parte del SIF pero también estuviera involucrada en otros menesteres que no tuvieran que ver con el SIF y fuera objeto de actualización, entiendo que la podría actualizar sin problemas. No creo que te vayan a pedir el código fuente para verificarlo. Ellos lo que no quieren es que actúes de manera preventiva o correctiva sobre la parte del programa que genera facturas (SIF) salvo que sea para cumplir con RRSIF porque por ley, a partir del 29 de julio, todo SIF debe cumplir la norma y estaría fuera de la misma, la corrección, la actualización o la prevención de las funcionalidades de un SIF no adaptado.

Creo que estamos diciendo lo mismo, por supuesto si sólo actualizo un librería externa que uso para diferentes procesos, no estoy obligado, pero si esa misma librería está incluida en el mismo "exe" que el proceso de facturación, ese "exe" tendrá fecha posterior al 29/07/2025, con lo que ya estaría obligado, salvo que estemos hablando de "cambiar" la fecha real del exe, en cuyo caso, no tengo nada más que comentar.

[emailesc]

A mi esta discusión me parece el típico "no me puedo creer lo que ven mis ojos". Lo que dicen está muy claro, pero como es una barbaridad supina, no queremos aceptarlo. Quieren meter esto como sea y a martillazos y para ello están haciendo un chantaje brutal a los desarrolladores pequeños... porque los grandes se lo van a saltar a la torera por dos razones: por que no pueden cumplirlo, y porque no es lo que dice el BOE. Ya me explicarás a mí como los grandes programas de facturación y contabilidad en SaaS hacen una actualización y obligan a decenas o cientos de miles de clientes a sacarse de la noche a la mañana un certificado, meterlo y empezar a subir datos como si nada. ¿Van a estar 6 meses o 1 año (en el caso de los autónomos) si hacer actualizaciones?. No lo creo. O, lo comento en otro foro, si Microsoft hace una actualización en teoría no puedes utilizarlo para hacer facturas: de la noche a la mañana cientos de miles de personas, autónomos en su mayoría, serían "perseguibles" y Microsoft tendría una responsabilidad. Ni de coña van a hacer eso. Todo lo más cogerán un par de empresas pequeñas que hayan hecho alguna actualización y las escabecharán para que sirvan de ejemplo. Y los pequeños no tenemos recursos para pleitear con Hacienda.

[starlet]

Eso es exactamente lo que yo digo con HOLDED y similares.

Ellos ya tiene adaptado su software a Verifactu (no se cansan de publicitarlo), por lo tanto TENDRIAN QUE OBLIGAR A TODOS SUS CLIENTES nuevos y actuales a Verifactu, y NO lo están haciendo.

Por lo tanto, ellos y todo sus clientes (+80.000 según ellos) incumplen la ley.

Y no puede ser que lay ley sea para unos obligada (nosotros los pequeños) y voluntaria para otros GRANDES.

Si es periodo voluntario, pues voluntario, sino es obligatorio.

[sglorka]

Empezado por novatico

Creo que estamos diciendo lo mismo, por supuesto si sólo actualizo un librería externa que uso para diferentes procesos, no estoy obligado, pero si esa misma librería está incluida en el mismo "exe" que el proceso de facturación, ese "exe" tendrá fecha posterior al 29/07/2025, con lo que ya estaría obligado, salvo que estemos hablando de "cambiar" la fecha real del exe, en cuyo caso, no tengo nada más que comentar.

Te refieres entonces a que al actualizar el EXE, si el programa es monolítico, la fecha es posterior al 29/07/2025 y eso puede acarrear dudas ???
Desde mi punto de vista, puedes tener estructurado tu ERP haciendo uso de clases y módulos para dividir la lógica en los tres componentes clásicos, acceso a datos, reglas de negocio e interfaz de usuario y todo ello compilarlo como un Exe. Se me hace difícil pensar que vayan a discernir si el ejecutable es posterior, qué parte has tocado del código que ha generado una recompilación.

[novatico]

Empezado por sglorka

Te refieres entonces a que al actualizar el EXE, si el programa es monolítico, la fecha es posterior al 29/07/2025 y eso puede acarrear dudas ???
Desde mi punto de vista, puedes tener estructurado tu ERP haciendo uso de clases y módulos para dividir la lógica en los tres componentes clásicos, acceso a datos, reglas de negocio e interfaz de usuario y todo ello compilarlo como un Exe. Se me hace difícil pensar que vayan a discernir si el ejecutable es posterior, qué parte has tocado del código que ha generado una recompilación.

Sólo estaba planteando una idea, realmente aunque ya tengo preparado un SIF "Solo Verifactu", listo para ser instalado, aún no se lo he vendido / actualizado a ningún cliente. Pero sí, mi aplicación tiene un único "exe" y luego diferentes, librerías, tablas, formatos de impresión, etc. Viendo la actitud de la AEAT, que ha trasladado la "carga de la prueba" a los desarrolladores, si instalo un exe que tiene fecha 19 de Agosto de 2025, me temo que tendría que ser yo el que demostrara que no he modificado nada que afecte al RRSIF.

[razorxxx]

Entonces, resumiendo señores. Si de repente un cliente que utiliza un SIF VeriFactu se pasa al SII, pero quiere seguir usando el mismo SIF para seguir facturando, y el SII lo llevan desde un programa de contabilidad ¿qué hacemos con este cliente? No veo lógico mantener 2 versiones de un mismo SIF (una adaptada y otra no), para nosotros desarrolladores es un tormento.

¿Acaso valdría poner un apartado donde elegir Modo VeriFactu o Modo SII, y el modo SII no generaría registros ni el código QR en las facturas?

Esta cuestión la planteé al correo de ayuda de verifactu, y me respondieron lo siguiente:

"El obligado tributario es el responsable último de utilizar un SIF adecuado a la normativa que se le aplica. En el caso planteado, al no serle de aplicación VERI*FACTU, deberá dejar de utilizar el SIF adaptado a VERIFACTU y no deberá emitir facturas a través de él, sino a través de otro SIF que esté preparado y adaptado al SII."

Si te estoy diciendo que los libros del SII los envían desde el programa de Contabilidad y no desde el de facturación, ¿cómo me dices que tiene que usar un SIF adaptado al SII? Aquí me han partido en 2...

[Jarogo08]

Empezado por razorxxx

Entonces, resumiendo señores. Si de repente un cliente que utiliza un SIF VeriFactu se pasa al SII, pero quiere seguir usando el mismo SIF para seguir facturando, y el SII lo llevan desde un programa de contabilidad ¿qué hacemos con este cliente? No veo lógico mantener 2 versiones de un mismo SIF (una adaptada y otra no), para nosotros desarrolladores es un tormento.

¿Acaso valdría poner un apartado donde elegir Modo VeriFactu o Modo SII, y el modo SII no generaría registros ni el código QR en las facturas?

Justo... un SIF adaptado a la ley te debe permitir elegir el modo de trabajo: Verifactu o SII (si tu programa contempla el SII, claro). Y si contempla el "No Verifactu" te debe permitir elegir entre una de las 3 opciones.

Pero si sólo tienes Verifactu o SII y una vez que elijas:

-Si eliges Verifactu se generan y envían los registros de facturación y las facturas llevan QR
-Si eliges SII no se generan ni envían los registros de facturación y las facturas no llevan QR

Sólo tienes un SIF, sólo tienes una versión, está adaptado a la ley, y te permite trabajar de las dos maneras

Así al menos es como lo tenemos nosotros

Y se puede dar el caso, obviamente, que estés en el SII y en un momento dado cambies al Verifactu o al revés (respetando los plazos, claro)

[ermendalenda]

Empezado por razorxxx

Entonces, resumiendo señores. Si de repente un cliente que utiliza un SIF VeriFactu se pasa al SII, pero quiere seguir usando el mismo SIF para seguir facturando, y el SII lo llevan desde un programa de contabilidad ¿qué hacemos con este cliente? No veo lógico mantener 2 versiones de un mismo SIF (una adaptada y otra no), para nosotros desarrolladores es un tormento.

¿Acaso valdría poner un apartado donde elegir Modo VeriFactu o Modo SII, y el modo SII no generaría registros ni el código QR en las facturas?

Esta cuestión la planteé al correo de ayuda de verifactu, y me respondieron lo siguiente:

"El obligado tributario es el responsable último de utilizar un SIF adecuado a la normativa que se le aplica. En el caso planteado, al no serle de aplicación VERI*FACTU, deberá dejar de utilizar el SIF adaptado a VERIFACTU y no deberá emitir facturas a través de él, sino a través de otro SIF que esté preparado y adaptado al SII."

Si te estoy diciendo que los libros del SII los envían desde el programa de Contabilidad y no desde el de facturación, ¿cómo me dices que tiene que usar un SIF adaptado al SII? Aquí me han partido en 2...

Uff, parece que quieren que el SII sea algo, como dicen ellos, sincronizado indefectifkemente con dicho envio, proponles otfo procedimiento a ver si te lo validan:
-tienes que "reinstalar" segun ellos tienes que hacer una instalacion limpia enl a que instales en modo SII, sin posiblidad de cambio de un modo a otro por parte del cliente(nada de botoncitos).
-por otro lado, indica en algun lado de tu software que usa el programa "X" para el envio SII y como lo hace.
-explica como generas los datos que ellos cogen para el SIiI y la trazabilidad del mismo.
-que el cliente te firme un documento de compromiso de que el hace el envio de esa forma con el SII
Una vez lo tengas todo "atado" preguntales de nuevo indicando el procedimiento que sigues.
Suerte y cuentanos que interesa saberlo.
No te pueden decir que no uses programas ee terceros para el envio, si dejan hasta con verifactu.