Club Delphi  
    FTP   CCD     Buscar   Trucos   Trabajo   Foros

Retroceder   Foros Club Delphi > Proyecto SIF/Veri*Factu/Ley Antifraude > Envío de registros y sus respuestas
Registrarse FAQ Miembros Calendario Guía de estilo Temas de Hoy

 
 
Herramientas Buscar en Tema Desplegado
  #2  
Antiguo 06-11-2024
CarlosR CarlosR is offline
Miembro
 
Registrado: sep 2015
Posts: 135
Poder: 10
CarlosR Va por buen camino
Resumen general

Aquí os dejo un resumen general que al menos a mí me sirve como guia.

Espero que si hay algún asunto que no "cuaje" me lo hagais saber.
Con respecto a la PREFACTURA creo que ya lo he expuesto varios artículos mas abajo.


***********************************
Veri*factu vs dual veri*factu
Breve resumen (S.E.u.O.)
***********************************

1. Consideraciones iniciales.

a) Se excluyen al menos de momento de la obligación de usar veri*factu las empresas acogidas al SII.
b) Si el sistema informático "puede usarse" en alguna instalación como NO VERIFACTU entonces ha de
cumplir las normas NO VERIFACTU inclusive en las instalaciones que se acojan a VERI*FACTU. Es estos
programas se les denomina modelos duales.
c) Si el sistema informático está limitado a VERI*FACTU y en ningún caso podría ser usado con las normas
de NO VERIFACTU entonces se le conoce como SOLO VERI*FACTU.
d) Si el sistema informático alberga varias empresas (formen grupo empresarial o no) y al menos una
de ellas es NO VERIFACTU entonces el sistema ha de considerarse como capaz de cumplir NO VERIFACTU y
debe cumplir las normas de NO VERIFACTU. Es decir, deberá garantizar el productor la NO alterabilidad
de la información de todas las empresas y usar un certificado para cada factura expedida.
Aunque alguna de las empresas se acoja a veri*factu.
e) Cuando se expide una factura por error y no se ha cobrado, ésta se puede corregir enviando un registro de
anulación. O bien si es una factura de un trabajo que se pensaba hacer y no se termina de realizar.
No se trta de una rectificativa sino una factura que nunca debió existir. P.e. error al expedirla a un
cliente incorrecto. ¿ Cómo procesar ? Después de haberla declarado en el SIF se expedirá un
registro de factura anulada también en el SIF. Los dos se comunicarán a la AEAT.
Se creará otra factura con los mismos contenidos y cantidades negativas en una serie específica para
facturas anuladas. Las facturas de esta serie no se registran en el SIF. En cambio las dos se
llevarán al registro de iva contable con lo que no habrá descuadres ni en el modelo 300/330 ni en el 347
en cambio se verá en el registro de facturas emitidas y en los extractos del cliente. Tampoco habrá descuadres
de existencias en almacén.
f) El sistema informático o DISPOSITIVO debe tener instalado un CERTIFICADO DIGITAL. O bien se usará en
los modelos VERI*FACTU para comunicar a la AEAT los envíos o bien si se trata de un modelo NO VERI*FACTU
se usará para certificar cada documento expedido y posteriormente poder suministrar a la AEAT los requerimientos.
g) Obligación y entrada en vigor. El 29 de Julio de 2025 cualquier sistema informático que se venda debe
cumplir las obligaciones veri*factu y no veri*factu. El 1 de enero de 2026 todos los clientes deberán
tener adaptado su sistema para cumplir dichas normas.
h) El diseño del código QR que se imprimirá en cada documento expedido está definido en un PDF con nombre
DetalleEspecificacTecnCodigoQRfactura_BORRADOR.pdf con fecha 02/10/2024
i) Hay unas FAQ de la propia AEAT que se pueden aglutinar en un único PDF. Eta es la dirección
https://sede.agenciatributaria.gob.e...00dc381e0aRCRD

2. Sistema VERI*FACTU.

Normas generales.

Esquema de funcionamiento
2.1. Se expide una factura (recapitulativa, rectificativa por modificación o sustitución, contado,
simplificada, canje) o bien se anula una factura. Se añade un registro en una tabla (o varias es elección del diseñador)
contenedora de datos tales como ...
HASH del registro actual
HASH del registro anterior (siempre que no sea registro inicial)
FECHA del documento
FECHA del documento anterior
FACTURA compuesto por serie mas nº de factura
FACTURA anterior
FECHAHORA del registro con formato U.T.C. (El sistema no podrá enviar un documento posterior
con fecha/hora posterior)
... y otras especificaciones del documento que se envía, están en la documentación
de la AEAT.
La tabla debe poder ser consultada en hacia adelante y hacia atrás y poder ser verificable
posteriormente en cualquier momento.
2.2. En el caso de la AUTOFACTURA o facturas de compra emitidas por el destinatario o cliente
la AEAT indica que es obligación de registrar en el SIF la factura del proveedor si éste le ha
indicado por escrito que así debe ser. Quiero imaginar que el certificado usado para comunicarlo a la AEAT es el
del cliente y no el del proveedor, sino sería un desastre. La cabecera del envío en este caso
imagino que es la del proveedor y que deben diferenciarse de las facturas expedidas por nuestra entidad,
comunicándolas por separado, en otro tramo. Al tener que emitir desde distintos titulares habrá
que utilizar los datos fiscales del proveedor como cabecera del declarante.
2.3. Si hay pendientes de envío a la AEAT 1000 registros habrá que enviárselos a la AEAT.
O bien si ha pasado un plazo de 2 horas habrá que enviarle los registros que haya acumulados,
si los hay.
Se genera un evento que identifica el envío a la AEAT.
Los tiempos de espera entre envíos deberán ser superiores al menos a 60 segundos.
Si el envío ha fracasado por causas diversas (falta de conexión a internet, el sistema está parado,
hay un determinado fallo) hay que registrarlo como evento y al enviar de nuevo la información a la
AEAT hay que indicar que hubo intentos previos de envío.
2.4. La AEAT puede responder de tres formas distintas :
2.3.1 Envío aceptado.
2.3.2 Envio aceptado con errores.
2.3.3 Envío rechazado.
En los tres casos se refiere a cada factura enviada no al conjunto del envío.
En cualquier caso los documentos rechazados deben volver a enviarse como alta pero como subsanación.
Se genera un evento en la tabla de eventos para indicar lo sucedido. Registro incidencia.
2.5. En la tabla de facturas o registro SIF hay que crear un nuevo registro con los datos de la factura
que se vuelve a enviar. Esto es para no perder el encadenamiento anterior.
2.6. Eventos
Consultar tabla de eventos definida por la AEAT. (L1E, L2E, L3E, L4E) enla hoja de cálculo
DR-Facturacion-VeriFactu-OM_RD-1007-2023-BORRADOR.xlsx última revisión 02/10/2024

3. Sistema NO VERI*FACTU.

Normas generales.

3.1. Es obligatorio que el productor del software garantice la integridad de los datos y la no alterabilidad
de los mismos así como su conservación durante al menos un plazo de 5 años.
3.2. No hay obligación de transmitir los registros a la AEAT.
3.3. Al igual que en VERI*FACTU el funcionamiento es similar en lo que toca a los registros de la tabla
de SIF. Con la salvedad de que hay que firmar cada registro con un certificado digital.
3.4. Debe existir una tabla de requerimientos de tal forma que cuando la AEAT solicite información
de los registros SIF se le pueda transmitir. Debe quedar registrado en dicha tabla los requerimientos.
4.4. La tabla de eventos también ha de ser firmado cada registro con el certificado digital.
4.5. Es también necesario expedir el código QR en las facturas al igual que en VERI*FACTU aunque esto
no sirva para verificar si la AEAT tiene la factura registrada. Sirve para comunicar que el
emisor ha hecho una factura y cual es su código. Lo veo algo innecesario pero así se expone en
las FAQ de la AEAT.
4.6. Período mínimo de conservación de los registros 5 años. Se pueden exportar los registros a medios
externos pero nunca dejando huecos en el registro sino exportar desde el comienzo hasta la fecha
que se defina. Los registros exportados deben ser legibles y no alterados y guardados por 5 años.

4. Trazabilidad y eventos.

4.1. Todos los registros tendrán la posibilidad de ser exportados para consulta posterior.
4.2. Habrá procedimientos automáticos que se encargan de verificar en el sistema que no se ha roto
la cadena de los registros SIF. Se hará por tramos y fechas. En todo caso se creará un evento
de comienzo de verificación y de final de verificación. Si se encontrase alguna anomalía hay que
indicarla también en el registro de eventos.
4.3. Aunque no se indica nada al respecto sería conveniente tener una herramienta gráfica para poder
verificar el registro sif. Es importante que la salida esté ordenada tal y como se ha enviado a
la AEAT y también en orden inverso.

5. Si la empresa dispone de sistemas separados que produzcan facturas se considerará cada uno como un centro
productor de sif y deberá llevar sus registros por separado.

6. Si no he comprendio mal se reduce a verificar el registro anterior antes de que se inserte el nuevo
registro en la tabla verifactu. Anteriormente eran los 5 anteriores.
Responder Con Cita
 



Normas de Publicación
no Puedes crear nuevos temas
no Puedes responder a temas
no Puedes adjuntar archivos
no Puedes editar tus mensajes

El código vB está habilitado
Las caritas están habilitado
Código [IMG] está habilitado
Código HTML está deshabilitado
Saltar a Foro

Temas Similares
Tema Autor Foro Respuestas Último mensaje
Consulta QR Verifactu JoseLeeTo Envío de registros y sus respuestas 10 09-11-2024 21:49:21
Cumplir VeriFactu xevi General/Noticias 2 04-11-2024 12:12:40
verifactu jguarda Internet 1 03-10-2024 17:48:17
Tabla de Facturas vs Detalles de Facturas magnu9 Conexión con bases de datos 9 27-07-2007 17:27:37
Campos calculados, facturas y detalles de facturas. Letty Conexión con bases de datos 7 07-11-2003 11:19:44


La franja horaria es GMT +2. Ahora son las 00:37:25.


Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi
Copyright 1996-2007 Club Delphi