Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[[newtron]]

Bueno... cualquiera que lo solicite puede entrar en el SII y quitarse de enmedio el rollo verifactu pero ganarás por un lado y perderás por otro por lo que no sé si merece la pena. Para mi (dependiendo también de la empresa) es más complicado el SII que el verifactu porque, como han apuntado, verifactu no entra en la naturaleza de la factura. En el SII dependiendo de la empresa se puede complicar la cosa bastante cuando entras en los distintos tipos de factura: intracomunitarias, exportación, inversión del sujeto pasivo, compras y gastos (que no existen en verifactu), etc. etc. Aparte de que las declaraciones de IVA pasan a ser mensuales que dependiendo de la empresa puede venir mejor o peor por lo que cada empresa es un mundo.


Saludos.

[ermendalenda]

Gracias
Más o menos se imaginaba respecto a si quieres SIi pues ala, pero si emites toquets ya tienes que mandar sii, compras y ventas. Es diferente, tienes sus ventajas e inconvenientes.
Lo de que no haya que encadenar, pues estupendo, mucho mejor para todos. Si no van a faltar inspectores e informáticos.

[keys]

Hola a todos.

Otra cosa que dijeron es que el código QR es para todas las facturas, ya sean Verifactu o no tienen que llevar el código QR. A no ser que hagas el SII.

Esta claro que si tu empresa esta en el SII te libras de todo esto. Pero eso puede ser una solución para el cliente, pero no para los que hacemos programas de facturación, ya que para que el programa sea competitivo tendrá que estar adaptado por lo menos a VERIFACTU.

Además el que una empresa haga el SII no es tan sencillo, ya que si haces el SII pasas al REDEME y por lo tanto tienes que hacer el IVA mensual y no Trimestral, registrar las compras, ciertas operaciones intracomunitarias, etc...

Una cosa que yo creo que intentaron decir es que se opte por VERIFACTU, ya que sino a parte de tener el registro de eventos, es casi imposible garantizar que no se puedan producir cambios en los registros de facturación. En el caso nuestro se trata de un programa comercial que se instala en el ordenador del cliente y por lo tanto puede entrar en cualquier momento y ponerse a borrar o restaurar ficheros, ¿y como controla eso tu programa?. Por no hablar de que puedan acceder a los ficheros y cambiar registros.

Yo creo que vamos optar por el camino de sólo VERIFACTU, ya que así es mas sencillo y la responsabilidad del programa es menor, y para los que hemos desarrollado TicketBAI no es tanto cambio. No se como no han hecho como en las forales, TODO EL MUNDO A TICKETBAI y punto.

[Sistel]

Hola,

También aclararon que si se usa la opción Verifactu (opción que recomendaron encarecidamente), para el envío de las facturas se podrá emplear no sólo el certificado digital del obligado tributario sino también el de un tercero.
En este caso, el tercero deberá ser Colaborador Social y tener un documento por el que el obligado tributario le autoriza.
El modelo es éste

Saludos

[Sistel]

Y aclararon que si se opta por utilizar Verifactu ya no hay obligación de firma de la factura ni de llevar el registro de eventos.
Por supuesto, sí se obliga en Verifactu a que la factura lleve un hash.

[ramherfer]

Una pregunta a ver si alguien me puede aclarar una duda que tengo desde hace tiempo.
¿Se deben generar los xml de cada factura por separado?
¿Luego de generados se genera el soap para enviar?
Gracias anticipadas.

[ermendalenda]

Empezado por ramherfer

Una pregunta a ver si alguien me puede aclarar una duda que tengo desde hace tiempo.
¿Se deben generar los xml de cada factura por separado?
¿Luego de generados se genera el soap para enviar?
Gracias anticipadas.

En el supuesto de acogerte a envio inmediato: Comp no tienes que conservarlo puedes hacerlo como quieras, pero debes tener en cuenta que te pueden contestar en el resp del soap al enviar que el próximo envío el número de xmls por ejemplo sea 10 registros encapsulados en el mismo soap o 300segunfos de espera. Entonces lo recomendable es que generes el xml por un lado y encapsules en el soap al enviar.

[ermendalenda]

Gracias a todos los por la información
me han comentado varias cosas sobre los que van a hacer Veri*Factu(Envio):
*La Huella y el encadenamiento es necesaria, alguien ha comentado que para verifactu no lo es, pero debe estar equivocado, me han enseñado el esquema.
*La huella SHA256 en Hexadecimal y MAYÚSCULAS
*Se deben subsanar los errores (de los registros que te devuelvan con error) y volver a remitir los registros subsanados(Ya diran como, supongo que como incidencia....)

[sglorka]

Hola a todos, os pongo las ideas que he sacado del seminario de ayer por si pueden ser de interés para alguno. Espero no haber cometido ningún error.

1.- Recomiendan el uso del sistema VeriFactu como opción segura para ofrecer al cliente. La opción del requerimiento tiene implicaciones que son de difícil cumplimiento y te cargan con una responsabilidad, la conservación, que es complicada de asegurar para una instalación desatendida.

2.- La imposibilidad de remitir temporalmente los registros de facturación por problemas técnicos puntuales la entienden y se abren a que utilicemos el campo Incidencia (S) de la cabecera del mensaje para notificar dicha situación. Incluso hablaron de casos en los que sólo hay Internet a ciertas horas del día y que eso es plausible.

3.- Han dejado bien claro que los sistemas VeriFactu están excluidos de la conservación, firma electrónica, accesibilidad y eventos de los registros de facturación. El evento de entrada / salida de Verifactu sólo atañe en el caso de que, NO estando en VeriFactu, (debes tener eventos) quisieras cambiarlo y entrar en Modo Verifactu, entonces deberías generar ambos eventos de salida y entrada. Ya en el nuevo modo, desaparecerían.

El modo Verifactu se resume en, envío automático, consecutivo, encadenamiento de registros y generación de huellas para cada registro de facturación. Ya para factura impresa o electrónica, adición de Qr.
Hablaron sobre el control de flujo (n,t). En principio lo van a cambiar, ya que, el número máximo de envío de registros en un mismo mensaje agrupado ya está limitado, son 1000. Por lo tanto, el parámetro “n” carece de sentido. Sí, van a utilizar el parámetro “t” en segundos.

4.- Aunque han dicho que van a mantener los servicios diferenciados para la remisión de registros a través de VeriFactu y a través de requerimiento, tiene la idea de que, dichos registros, contengan la misma información, por lo que se avecina otro cambio en la estructura del registro de alta y de anulación

5.- Piensan unificar en el mismo mensaje de envío, registros de alta y de anulación.

6.- La huella hash ya no será del nodo registro de facturación sino que se construirá con ciertos campos del xml que ya indicarán. Y lo más importante es que un error en esta huella no será considerado como motivo de rechazo sino como aceptada con errores.

7.- Dejaron entrever, que la idea final es que sólo exista un método de envío de registros de facturación a la aeat, por lo que al final, tenderemos a un híbrido entre el SII y VeriFactu como sistema de envío. Por ello, la idea de adherirse al SII para no cumplir con VeriFactu deberíamos desecharla.

8.- Los certificados electrónicos de terceros serán admisibles para remitir los registros de facturación de un obligado tributario, idéntico al SII.

[pablog2k]

gran resumen, de acuerdo con lo dicho, gracias compañero

[CarlosMz]

Empezado por sglorka

Hola a todos, os pongo las ideas que he sacado del seminario de ayer por si pueden ser de interés para alguno. Espero no haber cometido ningún error.

1.- Recomiendan el uso del sistema VeriFactu como opción segura para ofrecer al cliente. La opción del requerimiento tiene implicaciones que son de difícil cumplimiento y te cargan con una responsabilidad, la conservación, que es complicada de asegurar para una instalación desatendida.

2.- La imposibilidad de remitir temporalmente los registros de facturación por problemas técnicos puntuales la entienden y se abren a que utilicemos el campo Incidencia (S) de la cabecera del mensaje para notificar dicha situación. Incluso hablaron de casos en los que sólo hay Internet a ciertas horas del día y que eso es plausible.

3.- Han dejado bien claro que los sistemas VeriFactu están excluidos de la conservación, firma electrónica, accesibilidad y eventos de los registros de facturación. El evento de entrada / salida de Verifactu sólo atañe en el caso de que, NO estando en VeriFactu, (debes tener eventos) quisieras cambiarlo y entrar en Modo Verifactu, entonces deberías generar ambos eventos de salida y entrada. Ya en el nuevo modo, desaparecerían.

El modo Verifactu se resume en, envío automático, consecutivo, encadenamiento de registros y generación de huellas para cada registro de facturación. Ya para factura impresa o electrónica, adición de Qr.
Hablaron sobre el control de flujo (n,t). En principio lo van a cambiar, ya que, el número máximo de envío de registros en un mismo mensaje agrupado ya está limitado, son 1000. Por lo tanto, el parámetro “n” carece de sentido. Sí, van a utilizar el parámetro “t” en segundos.

4.- Aunque han dicho que van a mantener los servicios diferenciados para la remisión de registros a través de VeriFactu y a través de requerimiento, tiene la idea de que, dichos registros, contengan la misma información, por lo que se avecina otro cambio en la estructura del registro de alta y de anulación

5.- Piensan unificar en el mismo mensaje de envío, registros de alta y de anulación.

6.- La huella hash ya no será del nodo registro de facturación sino que se construirá con ciertos campos del xml que ya indicarán. Y lo más importante es que un error en esta huella no será considerado como motivo de rechazo sino como aceptada con errores.

7.- Dejaron entrever, que la idea final es que sólo exista un método de envío de registros de facturación a la aeat, por lo que al final, tenderemos a un híbrido entre el SII y VeriFactu como sistema de envío. Por ello, la idea de adherirse al SII para no cumplir con VeriFactu deberíamos desecharla.

8.- Los certificados electrónicos de terceros serán admisibles para remitir los registros de facturación de un obligado tributario, idéntico al SII.

Excelente resumen, muchas gracias.

Si el sistema es SOLO verifactu, no se aplica el registro de eventos en ningún caso ? Ni entrada al sistema, salida,... ?

Si el Hash se calculará sobre ciertos campos no tendremos que serializar primero el XML para obtener el nodo, entiendo ?

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

Empezado por Sistel

También aclararon que si se usa la opción Verifactu (opción que recomendaron encarecidamente), para el envío de las facturas se podrá emplear no sólo el certificado digital del obligado tributario sino también el de un tercero.
En este caso, el tercero deberá ser Colaborador Social y tener un documento por el que el obligado tributario le autoriza.
El modelo es éste

Añadido el documento al FTP del club y añadido enlace al mensaje #1 (recopilatorio).