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

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

[[newtron]]

Hola a tod@s.

Como creo que también habrá que darle solución al tema NO VeriFactu (para no quedarme sin clientes) estoy dándole vueltas a la firma del registro que se guarda en la tabla en ese caso. ¿Alguien tiene claro cómo va este tema?

Gracias y un saludo.

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

Empezado por newtron

Hola a tod@s.
Como creo que también habrá que darle solución al tema NO VeriFactu (para no quedarme sin clientes) estoy dándole vueltas a la firma del registro que se guarda en la tabla en ese caso. ¿Alguien tiene claro cómo va este tema?

Yo creo que el firmado será similar al de TBAI.
Aquí al principio de este hilo, alguien ya ha hecho algo de firmado:
https://www.clubdelphi.com/foros/sho...92&postcount=2

Y si te quieres entretener, puedes echarle un vistazo a los código de TBAI. Hay con diferentes componentes y básicamente al final es firmar un XML:
https://www.clubdelphi.com/foros/sho...31&postcount=2

[[newtron]]

Gracias Germán.

He visto el primer post que comentas, según parece es una dll que algún amable forero ha montado para firmar un XML pero estoy un poco despistado con esto. ¿Habrá que firmar y guardar el XML de alguna manera? o lo que se firma es algún campo del registro... no sé.

Echaré un vistazo al hilo de TicketBAI a ver si me aclara algo.

Saludos.

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

Creo que ya se ha discutido, pero diría que firmas un trozo del XML y esa firma se añade en una sección del propio XML.
Opcionalmente una parte de esa firma puede ir al encadenamiento de la siguiente (eso refuerza que una vez encadenadas no se puedan modificar)

(lo digo de memoria...)

[antoine0]

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

Opcionalmente una parte de esa firma puede ir al encadenamiento de la siguiente (eso refuerza que una vez encadenadas no se puedan modificar)

Técnicamente, se puede (aunque no se debe) modificar registros aunque sigan encadenados y firmados cada uno: solo hace falta volver a firmar y encadenar todos los registros empezando por el más antiguo. Y hacer lo mismo con el registro de los eventos (escribiéndolo ya me parece que no está nada legal; pero técnicamente se puede hacer si uno tiene acceso a la clave de firma.)

Lo que permite garantizar que no haya modificaciones sería poner una marca de tiempo (timestamp) al mismo tiempo que se firme.
Evidentemente, en este caso depende de la calidad de la marca de tiempo (si el servidor TSA RFC3161 lo controle el mismo que él que opera el SIF, no sería mucha garantia.)

Otra manera equivalente es depositar alguna huella del último registro (o del último registro de eventos, sería equivalente) en algún notario que le pondrá sello de tiempo.

[jlmoli_67]

Buenas,


Resulta que leyendo esta mañana me encuentro con una noticia de google en la que se expresa la necesidad de que cada sistema de facturacion contenga un certificado expedido por la administracion para poder facturar. Yo no sabia nada de eso y me gustaria saber si alguien ha leido algo al respecto porque es la primera noticia que tengo ya que pensaba que con la declaracion responsable ibamos que nos la pelabamos.



La noticia es:


https://www.autonomosyemprendedor.es...107037982.html


Un saludo y felices vacaciones al que pueda disfrutar o esté disfrutando ya de ellas.

[[newtron]]

Efectivamente, yo había leido esa noticia pero no sé si ese medio tendrá más información que nosotros por lo que lo pongo en cuarentena hasta que no se publique la normativa definitiva.


Saludos.

[antoine0]

Empezado por jlmoli_67

Resulta que leyendo esta mañana me encuentro con una noticia de google en la que se expresa la necesidad de que cada sistema de facturacion contenga un certificado expedido por la administracion para poder facturar. Yo no sabia nada de eso y me gustaria saber si alguien ha leido algo al respecto porque es la primera noticia que tengo ya que pensaba que con la declaracion responsable ibamos que nos la pelabamos.

(he subrayado yo.)
¿Dónde está escrito que hay certificados que deben ser expedido por la administración?

Hasta ahora, en España todo se ha basado en la necesidad de cumplir unas normas, es decir, software responsable. El «certificado» será la declaración responsable, tal como pensabas.

Por ninguna parte está descrito un «proceso de certificación» por parte de la administración; y tampoco por delegación de la administración (que puede ser más lógico o más verosímil). Hasta ahora Hacienda cuenta con inspectores, no con certificadores, y no es el mismo oficio.

[ermendalenda]

Empezado por jlmoli_67

Buenas,


Resulta que leyendo esta mañana me encuentro con una noticia de google en la que se expresa la necesidad de que cada sistema de facturacion contenga un certificado expedido por la administracion para poder facturar. Yo no sabia nada de eso y me gustaria saber si alguien ha leido algo al respecto porque es la primera noticia que tengo ya que pensaba que con la declaracion responsable ibamos que nos la pelabamos.



La noticia es:


https://www.autonomosyemprendedor.es...107037982.html


Un saludo y felices vacaciones al que pueda disfrutar o esté disfrutando ya de ellas.

Los de autonomosyenpresas la lían con este tipo de noticias, ya lo hicieron hace unos meses
Ni caso.
De momento la certificación del programa pasará por la declaración responsable de que cumple con la normativa. No sé si darán algún identificador para que lo incluyas en los xmls. Pero no habrá un certificado digital no nada de eso. Lo que tendrás que tener un botón de acceso rápido para ver la declaración responsable etc.
Otra cosa es que para identificarte en el envio sí que mecesitaras algún tipo de identificación si no se envia por un tercero, y seguramente sea el de empresa o autónomo.

[krilian]

Hola compañeros, una pequeña duda, voy un poco perdido con el tema del envío de la petición, estoy empleando SOAP y no consigo conectarme, sabéis si se tiene que dar de alta a algún servicio , y también si hay un entorno de pruebas? Gracias