Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[antoine0]

Empezado por ermendalenda

El periodo de imputación lo he visto en el esquema xsd pero no en el ejemplo.
Lo tengo marcado para quitarlo o dejarlo
Viene solo en la definición de complextipe name.

Está como único nodo del tipo RegistroSf; qué por lo visto, no sirve de nada... hasta ahora.
Supongo que servirá en la ¿futura expansión? de la interfaz con funciones de consultación (que de momento son demasiado pedir); hay un par de otros tipos que parecen ser del mismo índole.

[ermendalenda]

Ojo con el nivel de corrección, y diréis, anda quien se va a dar cuenta?, pues cualquiera
Se ve a simple vista en el qr
Os subo una imagen que lo explica
https://www.google.com/search?client...i0PYF5ryKYjhLM

[ermendalenda]

Aconsejo que en los pdfs pongáis el enlace al pinchar, es un valor.añadido para los clientes que lo reciban por correo

[ermendalenda]

No sabemos como van a construir el código qr, pero si metes algún signo en la serie o cif que no valga para web, por ej3mplo factura 3/33 el qr no va a hacer bien su función a no ser que escribas la cadena para generar el qr wn formato hexadecimal con el %20 antes de cada hexa

[[newtron]]

Me estoy estresando...

[ermendalenda]

Empezado por newtron

Me estoy estresando...

Todo se hace. Hay tiempo

[nincillo]

Empezado por newtron

Me estoy estresando...

Ya somos dos por lo menos...

[ermendalenda]

Estas cosas que he puesto son fáciles de hacer. Ya se explicaran si hace falta.
Hay una cosa que me preocupa, los que usamos curl (EN API O EN CURL
EXE). Al par3cer tiene fexha de caducidad el certificado para usarlo, más concretamente en 2028, no he encontrado la renovación y al ser una herramienta gratuita no tengo ni idea de que harán, a ver si alguien me puede dar luz sobre este asunto.
Si usáis curl, probad a usarlo cambiando la fecha de vuestra máquina a 2029.

[edari]

Empezado por nincillo

Ya somos dos por lo menos...

Yo el tercero


El registro de transacciones me supera y todas las garantías que hay que dar de inalterabilidad, tres cuartos de lo mismo.

Por no hablar de las multas.

[Maska10]

Una duda chorra (o no),

En el fichero de estructura de los ficheros, para, por ejemplo, el fichero de alta hay 3 formatos en 3 pestañas:

- Alta.VERIFACTU
- Alta.Requerimiento
- Alta.C-E

Entiendo que el primero es el formato que debemos usar si nuestro software está conectado a VERIFCATU.

Entiendo, por lógica, que el segundo es el formato que debemos usar si nuestro software NO está conectado a VERIFACTU.

Como podréis adivinar .. ¿para que carajos es el tercero? ¿que significa C-E? ¿está puesto en algun lado y soy tan tonto que no lo veo?

[djatila]

Hola Maska10, no estoy muy seguro, pero puede estar relacionado con la alta de facturas en el sistema de Contabilidad Electrónica.

[Maska10]

Empezado por djatila

Hola Maska10, no estoy muy seguro, pero puede estar relacionado con la alta de facturas en el sistema de Contabilidad Electrónica.

O igual es el fichero individual de cada factura Con Envio .. yo que se

[Usuario0550]

Empezado por Maska10

Una duda chorra (o no),

En el fichero de estructura de los ficheros, para, por ejemplo, el fichero de alta hay 3 formatos en 3 pestañas:

- Alta.VERIFACTU
- Alta.Requerimiento
- Alta.C-E

Entiendo que el primero es el formato que debemos usar si nuestro software está conectado a VERIFCATU.

Entiendo, por lógica, que el segundo es el formato que debemos usar si nuestro software NO está conectado a VERIFACTU.

Como podréis adivinar .. ¿para que carajos es el tercero? ¿que significa C-E? ¿está puesto en algun lado y soy tan tonto que no lo veo?

Esto es lo que me respondieron a mí:

Desde el punto de vista de remisión de información, existirán dos servicios web, uno para el alta y remisión inmediata, detallado en el Diseño de registro DR Alta.Verifactu, y otro para la remisión por requerimiento, detallado en el Diseño de registro DR Alta.Requerimiento (que son las "hojas" del DR sobre las que no tienen dudas).
Adicionalmente, y como elementos propios del SIF, existirá el Registro de Eventos, obligatoriamente en los sistemas no Veri*factu. Este Registro de Eventos es necesario para para que se consideren cumplidas las condiciones establecidas en el artículo 8.3 del Reglamento aprobado por el Real Decreto 1007/2023. Lo que se describe en el DR Evento.v.0.3 es la información estructurada que debe contener. Un ejemplo de acciones a registrar en el DR de Eventos puede ser: Instalación o puesta en marcha inicial del sistema informático, Detección de anomalías en la integridad, inalterabilidad y trazabilidad de registros de eventos, Exportación de registros de facturación generados en un periodo, entre otros. Este registro de Eventos, por el momento, se menciona en el artículo 8.3 de Disposición 24840 del BOE núm. 291 de 2023

Por último, también existirá como elemento propio del SIF, un DR Alta.C-E, que se denomina, Diseño de Registro de Alta Conservación y Exportación, o también su análogo para la anulación, que indica cómo se debe conservar los datos en el SIF y también, en su caso, cómo se debe exportar. Ambos son la base u origen de la información de los registros de facturación y comparten un contenido muy similar con los que se utilizarán para la remisión, ya sea inmediata o por requerimiento, pero su ámbito es el propio SIF.

Esperamos haberle aclarado su duda, no obstante, cuando se publique la OM se ofrecerá información más detallada sobre estas cuestiones (y muchas otras).

[Maska10]

Empezado por Usuario0550

Esto es lo que me respondieron a mí:

Desde el punto de vista de remisión de información, existirán dos servicios web, uno para el alta y remisión inmediata, detallado en el Diseño de registro DR Alta.Verifactu, y otro para la remisión por requerimiento, detallado en el Diseño de registro DR Alta.Requerimiento (que son las "hojas" del DR sobre las que no tienen dudas).
Adicionalmente, y como elementos propios del SIF, existirá el Registro de Eventos, obligatoriamente en los sistemas no Veri*factu. Este Registro de Eventos es necesario para para que se consideren cumplidas las condiciones establecidas en el artículo 8.3 del Reglamento aprobado por el Real Decreto 1007/2023. Lo que se describe en el DR Evento.v.0.3 es la información estructurada que debe contener. Un ejemplo de acciones a registrar en el DR de Eventos puede ser: Instalación o puesta en marcha inicial del sistema informático, Detección de anomalías en la integridad, inalterabilidad y trazabilidad de registros de eventos, Exportación de registros de facturación generados en un periodo, entre otros. Este registro de Eventos, por el momento, se menciona en el artículo 8.3 de Disposición 24840 del BOE núm. 291 de 2023

Por último, también existirá como elemento propio del SIF, un DR Alta.C-E, que se denomina, Diseño de Registro de Alta Conservación y Exportación, o también su análogo para la anulación, que indica cómo se debe conservar los datos en el SIF y también, en su caso, cómo se debe exportar. Ambos son la base u origen de la información de los registros de facturación y comparten un contenido muy similar con los que se utilizarán para la remisión, ya sea inmediata o por requerimiento, pero su ámbito es el propio SIF.

Esperamos haberle aclarado su duda, no obstante, cuando se publique la OM se ofrecerá información más detallada sobre estas cuestiones (y muchas otras).

Correcto, es lo que pensaba mas o menos, ahora solo falta ver como hacen para que los ficheros xml sean válidos y solo haya un elemento de nivel superior.

[djatila]

Empezado por Usuario0550

Esto es lo que me respondieron a mí:

Desde el punto de vista de remisión de información, existirán dos servicios web, uno para el alta y remisión inmediata, detallado en el Diseño de registro DR Alta.Verifactu, y otro para la remisión por requerimiento, detallado en el Diseño de registro DR Alta.Requerimiento (que son las "hojas" del DR sobre las que no tienen dudas).
Adicionalmente, y como elementos propios del SIF, existirá el Registro de Eventos, obligatoriamente en los sistemas no Veri*factu. Este Registro de Eventos es necesario para para que se consideren cumplidas las condiciones establecidas en el artículo 8.3 del Reglamento aprobado por el Real Decreto 1007/2023. Lo que se describe en el DR Evento.v.0.3 es la información estructurada que debe contener. Un ejemplo de acciones a registrar en el DR de Eventos puede ser: Instalación o puesta en marcha inicial del sistema informático, Detección de anomalías en la integridad, inalterabilidad y trazabilidad de registros de eventos, Exportación de registros de facturación generados en un periodo, entre otros. Este registro de Eventos, por el momento, se menciona en el artículo 8.3 de Disposición 24840 del BOE núm. 291 de 2023

Por último, también existirá como elemento propio del SIF, un DR Alta.C-E, que se denomina, Diseño de Registro de Alta Conservación y Exportación, o también su análogo para la anulación, que indica cómo se debe conservar los datos en el SIF y también, en su caso, cómo se debe exportar. Ambos son la base u origen de la información de los registros de facturación y comparten un contenido muy similar con los que se utilizarán para la remisión, ya sea inmediata o por requerimiento, pero su ámbito es el propio SIF.

Esperamos haberle aclarado su duda, no obstante, cuando se publique la OM se ofrecerá información más detallada sobre estas cuestiones (y muchas otras).

Gracias por la aclaración, ahora que lo has mencionado leí algo a ese respecto en el primer enlace del post 1025 a partir de la pagina 32

[ermendalenda]

Empezado por Usuario0550

Esto es lo que me respondieron a mí:

Desde el punto de vista de remisión de información, existirán dos servicios web, uno para el alta y remisión inmediata, detallado en el Diseño de registro DR Alta.Verifactu, y otro para la remisión por requerimiento, detallado en el Diseño de registro DR Alta.Requerimiento (que son las "hojas" del DR sobre las que no tienen dudas).
Adicionalmente, y como elementos propios del SIF, existirá el Registro de Eventos, obligatoriamente en los sistemas no Veri*factu. Este Registro de Eventos es necesario para para que se consideren cumplidas las condiciones establecidas en el artículo 8.3 del Reglamento aprobado por el Real Decreto 1007/2023. Lo que se describe en el DR Evento.v.0.3 es la información estructurada que debe contener. Un ejemplo de acciones a registrar en el DR de Eventos puede ser: Instalación o puesta en marcha inicial del sistema informático, Detección de anomalías en la integridad, inalterabilidad y trazabilidad de registros de eventos, Exportación de registros de facturación generados en un periodo, entre otros. Este registro de Eventos, por el momento, se menciona en el artículo 8.3 de Disposición 24840 del BOE núm. 291 de 2023

Por último, también existirá como elemento propio del SIF, un DR Alta.C-E, que se denomina, Diseño de Registro de Alta Conservación y Exportación, o también su análogo para la anulación, que indica cómo se debe conservar los datos en el SIF y también, en su caso, cómo se debe exportar. Ambos son la base u origen de la información de los registros de facturación y comparten un contenido muy similar con los que se utilizarán para la remisión, ya sea inmediata o por requerimiento, pero su ámbito es el propio SIF.

Esperamos haberle aclarado su duda, no obstante, cuando se publique la OM se ofrecerá información más detallada sobre estas cuestiones (y muchas otras).

Gracias por compartir.

Hola estoy un poco espeso, he leido esta respuesta y me he quedado con la misma duda que tenua, a raiz de esta respuesta de la aeat, sabeis si realmente los sistemas SÍ VERIFACTU (O sea que envian directamente) tienen que crear algún evento. el de instalación inicio de envio...? no entiendo muy bien el mensaje

[keno_71]

Empezado por ermendalenda

Gracias por compartir.

Hola estoy un poco espeso, he leido esta respuesta y me he quedado con la misma duda que tenua, a raiz de esta respuesta de la aeat, sabeis si realmente los sistemas SÍ VERIFACTU (O sea que envian directamente) tienen que crear algún evento. el de instalación inicio de envio...? no entiendo muy bien el mensaje

Hola, yo también me he quedado con la misma duda, pensaba que eso era independiente de si se enviaba inmediatamente o por requerimiento. Gracias a todos por toda la información

[ermendalenda]

Al parecer en el pdf, según la OM propuesta), habrá que ponerle el enlace (Escribiendolo completo e integrandole el enlace) debajo o encima del dibujo del QR.

[ermendalenda]

Os adjunto un pdf con aproximación de como quedaría una factura con QR en pdf según los datos que nos dan en la OM.
Las medidas son 35x35 ya que como piden entree 30x30 y 40x40 me quedo justo en el centro para tener margen por si hay alguna putadilla con las medidas de la impresora.

[nuevo1234]

Empezado por ermendalenda

Gracias por compartir.

Hola estoy un poco espeso, he leido esta respuesta y me he quedado con la misma duda que tenua, a raiz de esta respuesta de la aeat, sabeis si realmente los sistemas SÍ VERIFACTU (O sea que envian directamente) tienen que crear algún evento. el de instalación inicio de envio...? no entiendo muy bien el mensaje

Hola,

Lo que yo creo.

El registro de eventos es obligatorio únicamente en el caso de los sistemas no Veri*factu. Los sistemas Veri*factu pueden contar con él, pero es opcional.
Esto se recoge en la Orden Ministerial que está puesta a información pública y se ha publicado el 3 de enero de 2024.

En el pdf "Texto del proyecto" Artículo 3
"…. en tanto actúen como sistemas VERI*FACTU, no les serán de aplicación los artículos 6.b), 6.c), 6.d), 6.e), 6. f), 7.f), 7.h), 7.i), 7.j), 8 y 9 de esta orden."

El artículo 9 es el Registro de eventos.