[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.