Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[[newtron]]

Empezado por Neftali [Germán.Estévez]

Os comento cosas que ya se hablaron en TicketBAI y que hablan por aquí por mi empresa la gente que sabe (juristas). Resumiendo mucho.



Simplificando, las multas al desarrollador la idea es que lleguen si el programa facilita de alguna manera que el cliente pueda hacer cosas ilegales.
Digamos que cualquiera con conocimientos puede hacer cosas ilegales con un programa de facturación, pero la obligación del software es no permitirlas o facilitarlas.
Si se demuestra que el software de alguna forma está pensado para hacerlas en cuando el desarrollador puede tener problemas.



Yo creo que no puedes hacer eso.
Si el cliente no se actualiza la versión en un problema suyo, tú no puedes obligarlo y no es tampoco tu responsabilidad si él no quiere hacerlo.

Lo que si nos explicaron es que a partir del día en que se ponga en marcha la ley, la empresa no debe actualizar, ni comercializar ni realizar actividades (lucrativas) con versiones que no soporten la ley (versiones antiguas), no tiene porqué hacer que dejen de funcionar.
Es decir, si la versión SIF es la 5.4, a partir del día que se apruebe la ley, la empresa no puede hacer nada con versiones anteriores (que suponga beneficio). Es decir, un cliente se puede quedar con la versión 5.3 (que no genera QR, ni envía a la AEAT,...) y seguir trabajando. Es su responsabilidad y su problema si le pillan. Lo que es responsabilidad de la empresa es, si se realiza cualquier actividad sobre esas verisones anteriores (soporte, ayuda, mantenimiento, actualizaciones,...)

Es lo más razonable.

[CarlosArjonomia]

Yo creo que no puedes hacer eso.
Si el cliente no se actualiza la versión en un problema suyo, tú no puedes obligarlo y no es tampoco tu responsabilidad si él no quiere hacerlo.

Me refiero a cuando el cliente ya ha actualizado a VeriFactu. Imagina, el cliente actualiza para adaptar el programa a verifactu y una vez pasado el año de actualización y soporte decide dejar de pagar y no actualizar. El programa debe de dejar de emitir facturas ya que no ha sido actualizado y tu puedes estar enviando información incorrecta o no verificada con tu acreditación como proveedor del SIF.

[bmfranky]

Empezado por CarlosArjonomia

Me refiero a cuando el cliente ya ha actualizado a VeriFactu. Imagina, el cliente actualiza para adaptar el programa a verifactu y una vez pasado el año de actualización y soporte decide dejar de pagar y no actualizar. El programa debe de dejar de emitir facturas ya que no ha sido actualizado y tu puedes estar enviando información incorrecta o no verificada con tu acreditación como proveedor del SIF.

Hola, en mi umilde opinion, creo que no es asi, tu legalmente no creo que puedas dejar no funcional un programa que has vendido,pero si no cumple el 100% de las modificaciones de la normativa, por no actualizarlo, no es responsabilidad del creador, sino del cliente final por no actualizarlo, o tendriamos que ser responsables de cualquier cliente que continue facturando con un programa no verifactu en absoluto?

Otra cosa es que un programa que tu vendes/actualizas no cumpla las normativas exigibles, ahi si podriamos tener un problema.

Recuerda que tu acreditas que tu programa "Pepe Factus 2000" , version x.y.z cumplia verifactu version a.b en la fecha en que lo instalaste / actualizaste por ultima vez, no despues.

[Jesusggc]

En relación al servicio caido de esta mañana y posterior remision de Registros una vez solucionado el problema.

En estos casos recibirán este mensaje de error:

<EstadoRegistro>AceptadoConErrores</EstadoRegistro>
<CodigoErrorRegistro>2004</CodigoErrorRegistro>
<DescripcionErrorRegistro>El valor del campo FechaHoraHusoGenRegistro debe ser la fecha actual del sistema de la AEAT, admitiéndose un margen de error de: 120 segundos.</DescripcionErrorRegistro>

He puesto consulta a verifactu, y contestan lo siguiente:

Buenas tardes:
Este es un error de los denominados admisibles (ver documento de validaciones, apartado "4.3 Tratamiento de los errores admisibles ") y debido a ello se admitirá el registro. Este error en concreto, se excepciona de la necesidad de ser subsanado por lo que necesitarían realizar ninguna subsanación posteriormente.
Otra cuestión a tener en cuenta, es que está previsto que los sistemas informáticos de facturación, tengan indisponibilidades como cortes de luz, falta de conexión, fallos en el sistema , etc. y se pueda superar el tiempo establecido...En esos casos deben activar el campo "Incidencia" (ver diseño de registro, hoja "1)DR Remisión Alta-Anul.VF-Req.") para que no les aparezca dicho error

[jguarda]

Había alguien, que había subido un código fuente para enviar facturas al sistema VERIFACTU, hay alguna actualización al respecto para probar de nuevo??

[unomasmas]

Empezado por Jesusggc

...He puesto consulta a verifactu, y contestan lo siguiente:
Otra cuestión a tener en cuenta, es que está previsto que los sistemas informáticos de facturación, tengan indisponibilidades como cortes de luz, falta de conexión, fallos en el sistema , etc. y se pueda superar el tiempo establecido...En esos casos deben activar el campo "Incidencia" (ver diseño de registro, hoja "1)DR Remisión Alta-Anul.VF-Req.") para que no les aparezca dicho error

Me preocupa esto. ¿Habéis pensado cómo implementar la posibilidad de señalar el campo "Incidencia"? Se supone que el proceso debe ser lo más automatizado posible, por lo que no veo una buena solución la intervención humana; principalmente porque el usuario típico no se va a parar a pensar en procedimientos extraordinarios...

[novatico]

Empezado por unomasmas

Me preocupa esto. ¿Habéis pensado cómo implementar la posibilidad de señalar el campo "Incidencia"? Se supone que el proceso debe ser lo más automatizado posible, por lo que no veo una buena solución la intervención humana; principalmente porque el usuario típico no se va a parar a pensar en procedimientos extraordinarios...

En mi caso, siempre incluyo la "Incidencia=N" en el proceso normal, aunque no se obligatoria. Esto me permitirá sustituirla por "Incidencia=S" en el caso de tener que reenviarlo de forma automatizada, ya que, como ese dato no forma parte ni del cálculo del HASH ni del QR, no hay problema en modificarlo.

[bmfranky]

Empezado por novatico

En mi caso, siempre incluyo la "Incidencia=N" en el proceso normal, aunque no se obligatoria. Esto me permitirá sustituirla por "Incidencia=S" en el caso de tener que reenviarlo de forma automatizada, ya que, como ese dato no forma parte ni del cálculo del HASH ni del QR, no hay problema en modificarlo.

Si, es lo logico, yo uso un bool para consultar el estado en la regeneracion envio.

 
//en la parte del load del form incluyo indencia = false;


voluntaria.Incidencia = ServicioVerifactu.IncidenciaType.N;
                if(incidencia)
                {
                    voluntaria.Incidencia = ServicioVerifactu.IncidenciaType.S;
                }

Al intentar el envio establezco el valor en true;

                try
                {
                    retorno = client.RegFactuSistemaFacturacion(facAPresentar);
                }
                catch
                {
                    incidencia = true;
                    consolaError cE = new consolaError();
                    cE.Text = "Ha habido un error en la conexion con el servicio web de hacienda, por favor verifique el estado de su conexion a internet, en 60\"  vuelva a intentar el envio, si tampoco tiene exito, se archivara esta factura como proforma y se le indicara el numero de la misma , para que vuelva a proceder al envio de la misma mas tarde";
                    cE.Cuentaatras = 60;
                    cE.Errores = false;
                    cE.volverAVer.Visible = false;
                    cE.ShowDialog();
}

[unomasmas]

Empezado por novatico

En mi caso, siempre incluyo la "Incidencia=N" en el proceso normal, aunque no se obligatoria. Esto me permitirá sustituirla por "Incidencia=S" en el caso de tener que reenviarlo de forma automatizada, ya que, como ese dato no forma parte ni del cálculo del HASH ni del QR, no hay problema en modificarlo.

Empezado por bmfranky

Si, es lo logico, yo uso un bool para consultar el estado en la regeneracion envio.

 
//en la parte del load del form incluyo indencia = false;


voluntaria.Incidencia = ServicioVerifactu.IncidenciaType.N;
                if(incidencia)
                {
                    voluntaria.Incidencia = ServicioVerifactu.IncidenciaType.S;
                }

Al intentar el envio establezco el valor en true;

                try
                {
                    retorno = client.RegFactuSistemaFacturacion(facAPresentar);
                }
                catch
                {
                    incidencia = true;
                    consolaError cE = new consolaError();
                    cE.Text = "Ha habido un error en la conexion con el servicio web de hacienda, por favor verifique el estado de su conexion a internet, en 60\"  vuelva a intentar el envio, si tampoco tiene exito, se archivara esta factura como proforma y se le indicara el numero de la misma , para que vuelva a proceder al envio de la misma mas tarde";
                    cE.Cuentaatras = 60;
                    cE.Errores = false;
                    cE.volverAVer.Visible = false;
                    cE.ShowDialog();
}

Muchas gracias a ambos :-) Estoy pensando que podría servir incluso en caso de problemas de otro tipo; no sólo de caídas del sistema... (aunque es una idea que habrá que analizar un poco...)

[[email protected]]

Yo tengo montado mis procesos con VERIFICACION por FTP de cada cliente.
Nosotros a cada cliente les damos servicio por suscripcion/uso, si alguno no paga, lo que se hace es que se quita del FTP el acceso de ese cliente y no EJECUTA la aplicacion.
En vista de los hechos que van apareciendo, creo que lo cambiaremos y en lugar de no dejar entrar en la aplicación, lo que se hara es BLOQUEAR alguna de las opciones , ente ellas LA EMISION DE FACTURAS y el mantenimiento de ALBARANES.

Lo comento por si le sirve a alguien

[bmfranky]

Empezado por [email protected]

Yo tengo montado mis procesos con VERIFICACION por FTP de cada cliente.
Nosotros a cada cliente les damos servicio por suscripcion/uso, si alguno no paga, lo que se hace es que se quita del FTP el acceso de ese cliente y no EJECUTA la aplicacion.
En vista de los hechos que van apareciendo, creo que lo cambiaremos y en lugar de no dejar entrar en la aplicación, lo que se hara es BLOQUEAR alguna de las opciones , ente ellas LA EMISION DE FACTURAS y el mantenimiento de ALBARANES.

Lo comento por si le sirve a alguien

Entonces , vosotros no vendeis el programa, alquilais el derecho de uso, como en los videojuegos digitales, o como se deba expresar correctamente.

[[email protected]]

Empezado por bmfranky

Entonces , vosotros no vendeis el programa, alquilais el derecho de uso, como en los videojuegos digitales, o como se deba expresar correctamente.

Exactamente, vendemos derecho de suscripcion/uso, es lo que estan haciendo las grandes marcas, Office365, Reader, etc.

Ahora con la nueva ley, si no se paga la mensualidad, cambiaremos y en lugar de impedir que usen la aplicación, lo que se hara es BLOQUEAR alguna de las opciones, entre ellas la emision de facturas y albaranes

[antoniomarquezc]

Hola.

¿ Ha dejado de funcionar el webservice ?.

No puedo subir facturas de prueba.

[kalimero]

Creo que está caido. A mi tampoco me deja

[CarlosArjonomia]

Empezado por [email protected]

Yo tengo montado mis procesos con VERIFICACION por FTP de cada cliente.
Nosotros a cada cliente les damos servicio por suscripcion/uso, si alguno no paga, lo que se hace es que se quita del FTP el acceso de ese cliente y no EJECUTA la aplicacion.
En vista de los hechos que van apareciendo, creo que lo cambiaremos y en lugar de no dejar entrar en la aplicación, lo que se hara es BLOQUEAR alguna de las opciones , ente ellas LA EMISION DE FACTURAS y el mantenimiento de ALBARANES.

Lo comento por si le sirve a alguien

Exactamente lo mismo hago yo. Creo que las nuevas circunstancias requieren nuevas políticas de uso. A partir de la primera actualización a verifactu, funcionamiento de la aplicación condicionada al pago de soporte y actualizaciones. Explica después a la aeat que tu aplicación ha estado mandando información incorrecta por tus escrúpulos de cara a los derechos de tu cliente.