Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[pararegistrarme]

Estoy trabajando con los códigos QR y comparando los ejemplos que pone la AEAT con los que obtengo con distintos componentes Delphi(DelphiZXingQRCodeEx y otros). Sólo he conseguido obtener exactamente el mismo con FastReport. Todos los demás componentes que he probado muestran códigos gráficamente distintos aunque su lectura es correcta.
¿Sabéis de algún componente que cree el código tal y como nos piden?





Gracias de antemano y buenas vacaciones a todos... también a los que estamos trabajando.

[xamminf]

Muy buenas a todos,

Pensando en el flujo (y reflujo)
¿ Como lo hariais vosotros ?
Se imprime la factura y va a la cola. Cuando llegue el tiempo de espera se manda junto con las pendientes.
¿ Pero qué hacer si hay algun error que requiere enviar de nuevo el alta ? ¿ Se haria a traves de otro proceso que tambien generaria cola de envio ?

A ver si alguien lo tiene mas claro que yo

Gracias

[ermendalenda]

Empezado por xamminf

Muy buenas a todos,

Pensando en el flujo (y reflujo)
¿ Como lo hariais vosotros ?
Se imprime la factura y va a la cola. Cuando llegue el tiempo de espera se manda junto con las pendientes.
¿ Pero qué hacer si hay algun error que requiere enviar de nuevo el alta ? ¿ Se haria a traves de otro proceso que tambien generaria cola de envio ?

A ver si alguien lo tiene mas claro que yo

Gracias

Aún no han indicado el.procedimiento de reenvío, solos me ocurren una lógica según va avanzando el proyecto y es que si un registro es rechazado tendras que mandar la corrección (según el tipo de error) encadenada con el último generado NO con en anterior al registro rechazado, puesto que se rompería el encadenamiento.
De todas formas habrá que esperar a ver los detalles, pueden optar por otras opciones: reenvío con uncadenamiebto eapecial, sin encadenar o incluso enviar para tratarlos a otro servicio RESP. A ver que nos cuentan en los detalles técnicos. De momento yo he desarrollado todo según la opción que he puesto como más lógica ya que al tener que volver a generar el registro hay que seguir la secuencia
Otra cosa es que tengas incidencia en el emvio y no sea un rechazo por un registro erróneo.

[ermendalenda]

Empezado por xamminf

Muy buenas a todos,

Pensando en el flujo (y reflujo)
¿ Como lo hariais vosotros ?
Se imprime la factura y va a la cola. Cuando llegue el tiempo de espera se manda junto con las pendientes.
¿ Pero qué hacer si hay algun error que requiere enviar de nuevo el alta ? ¿ Se haria a traves de otro proceso que tambien generaria cola de envio ?

A ver si alguien lo tiene mas claro que yo

Gracias

También ten ecuenta que han metido una variable que es el la referencia del rechazo, la cual tendrás que hacer alusión a esa referencia en algun nodoen el envio del registro que reenvías, quizás con eso no necesite encadenamiento, y con lo que están tardando me espero bastantes modificaciones, si te das cuenta , en los webinars nos cuentan que las motivaciones son para mejorar y facilitar, pero solo facilitan para ellos, para que tengan más automatizados los controles de errores, a nosotros nos van complicando, está todo por ver

[sglorka]

Empezado por xamminf

Muy buenas a todos,

Pensando en el flujo (y reflujo)
¿ Como lo hariais vosotros ?
Se imprime la factura y va a la cola. Cuando llegue el tiempo de espera se manda junto con las pendientes.
¿ Pero qué hacer si hay algun error que requiere enviar de nuevo el alta ? ¿ Se haria a traves de otro proceso que tambien generaria cola de envio ?

A ver si alguien lo tiene mas claro que yo

Gracias

No deberías crear otra cola para estos casos, la cola debe ser única ya que todos los registros, sin excepción, tienen que estar encadenados siguiendo su fecha de generación.

En el documento de Validaciones y Errores tienes la respuesta

"4.4 Subsanación de errores
Solo podrá llevarse a cabo una subsanación cuando no se trate de una causa que exija la emisión de una factura rectificativa (u otro mecanismo contemplado en el Reglamento de Facturación).

Este mecanismo se empleará para subsanar datos en cualquiera de los siguientes casos:

- Errores admisibles (registro de facturación aceptado –con errores admisibles– por la AEAT), salvo las excepciones previstas en el apartado que explica el tratamiento de los errores admisibles.
- Errores no admisibles (registro de facturación rechazado por la AEAT).
- Dato incorrecto detectado posteriormente por el obligado a expedir factura (registro de facturación remitido y aceptado sin errores por la AEAT).

Para llevar a cabo la subsanación, será necesaria la remisión de un nuevo registro de facturación (con el mismo identificador de factura del registro de facturación que se quiere subsanar) por cada uno de los registros con datos a subsanar, con la combinación de valores de campos que proceda según el caso (ver en el anexo los cuadros de operativas de alta y anulación admisibles)."

Sólo en el caso de que la comunicación no se haya establecido correctamente con la Aeat y no se haya podido enviar el mensaje, deberías volver a reintentar el envío, tal cual estaba, las veces necesarias hasta conseguir respuesta.

[ermendalenda]

Empezado por sglorka

No deberías crear otra cola para estos casos, la cola debe ser única ya que todos los registros, sin excepción, tienen que estar encadenados siguiendo su fecha de generación.

En el documento de Validaciones y Errores tienes la respuesta

"4.4 Subsanación de errores
Solo podrá llevarse a cabo una subsanación cuando no se trate de una causa que exija la emisión de una factura rectificativa (u otro mecanismo contemplado en el Reglamento de Facturación).

Este mecanismo se empleará para subsanar datos en cualquiera de los siguientes casos:

- Errores admisibles (registro de facturación aceptado –con errores admisibles– por la AEAT), salvo las excepciones previstas en el apartado que explica el tratamiento de los errores admisibles.
- Errores no admisibles (registro de facturación rechazado por la AEAT).
- Dato incorrecto detectado posteriormente por el obligado a expedir factura (registro de facturación remitido y aceptado sin errores por la AEAT).

Para llevar a cabo la subsanación, será necesaria la remisión de un nuevo registro de facturación (con el mismo identificador de factura del registro de facturación que se quiere subsanar) por cada uno de los registros con datos a subsanar, con la combinación de valores de campos que proceda según el caso (ver en el anexo los cuadros de operativas de alta y anulación admisibles)."

Sólo en el caso de que la comunicación no se haya establecido correctamente con la Aeat y no se haya podido enviar el mensaje, deberías volver a reintentar el envío, tal cual estaba, las veces necesarias hasta conseguir respuesta.

Es verdad, pero insisto en que es mejor esperar antes de meter mucha historia a las correcciones, en el Sii puedes corregir directamente en la web de la AEAT, así que no me extrañaría que hubiera un servicio equivalente

[ermendalenda]

Creéis factible generar una rectificativa de una factura en un SIF distinto al que se produjo? El XM lo genero bien, pero me quedaria la duda de que comprueben que esa factura no se ha producido en el mismo SIF.
Esto puede ser necesario por que un cliente devuelve mercancía en otro punto distinto de donde la adquirió.

[sglorka]

Empezado por ermendalenda

Creéis factible generar una rectificativa de una factura en un SIF distinto al que se produjo? El XM lo genero bien, pero me quedaria la duda de que comprueben que esa factura no se ha producido en el mismo SIF.
Esto puede ser necesario por que un cliente devuelve mercancía en otro punto distinto de donde la adquirió.

Una consulta relacionada ya la hice en su momento a la Aeat y dejaron claro que, cada obligado tributario puede tener distintos SIFs donde cada uno lleva su propio encadenamiento, al final, ellos ven desde su lado la relación NifObligado-NúmSerieFactura-FechaExpedición como una clave única que se debe mantener independientemente de los SIFs que tenga el obligado. Por ello, se podría rectificar e incluso anular facturas desde un SIF distinto al que las creó.

[ermendalenda]

Empezado por sglorka

Una consulta relacionada ya la hice en su momento a la Aeat y dejaron claro que, cada obligado tributario puede tener distintos SIFs donde cada uno lleva su propio encadenamiento, al final, ellos ven desde su lado la relación NifObligado-NúmSerieFactura-FechaExpedición como una clave única que se debe mantener independientemente de los SIFs que tenga el obligado. Por ello, se podría rectificar e incluso anular facturas desde un SIF distinto al que las creó.

Gracias, lo aplicaré así

[ermendalenda]

Empezado por pararegistrarme

Estoy trabajando con los códigos QR y comparando los ejemplos que pone la AEAT con los que obtengo con distintos componentes Delphi(DelphiZXingQRCodeEx y otros). Sólo he conseguido obtener exactamente el mismo con FastReport. Todos los demás componentes que he probado muestran códigos gráficamente distintos aunque su lectura es correcta.
¿Sabéis de algún componente que cree el código tal y como nos piden?





Gracias de antemano y buenas vacaciones a todos... también a los que estamos trabajando.

Lo único que piden es que el control de errores sea mínimo el tipo M y las medidas. Lo de Gráficamente distinto no sé a qué te refieres pero si es por que has dejado el tipo por defecto de cada componente puede que el control de errores sea distinto y te va a salir un gráfico distinto, mientras no sea tipo L(low) será aceptado.
Por otro lado, según el procesador que tenga el equipo, un tipo de control de errores más alto que el M, necesita más recursos y te puede ralentizar la generación