Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[bmfranky]

Empezado por sglorka

Este punto al que te refieres
"Si se ha expedido una factura a nombre de un destinatario existente pero diferente de aquél para el que se realizó la correspondiente operación, deberá expedirse una factura rectificativa en la que constando el mismo destinatario se consignen con signo negativo las magnitudes de la misma." ...
puede ser incorrecto, ya que sólo tendrán consideración de rectificativas ( apartado 6 del artículo 15) la facturas que se expidan por alguna de las causas previstas en los apartados 1 y 2 del artículo 15 del reglamento de facturación (Real Decreto 1619/2012). En ningún caso, errar en el destinatario de la operación ( no en algún dato descriptivo del mismo) de forma que no era la persona a la que iba dirigida la factura, se contempla en dichos apartados. Para estos casos, existe la factura de abono (factura normal en negativo).

Yo barajaría dos opciones
1.- Anular la factura mediante un registro de anulación y emitir una nueva factura al cliente correcto
2.- Emitir una factura de abono en negativo al cliente incorrecto y otra factura normal con el cliente correcto

Yo elegiría la primera ,ya que de esta forma, el cliente que erramos no se entera de nada. Si eliges la segunda, debes enviar las dos facturas ( Factura errónea y Abono ) al cliente para que las declare como recibidas y se puedean conciliar ante un hipotético cruce de hacienda

Gracias por la sujerencia, el planteamiento es porque me ha pasado que al enviar la factura al cliente, ha cambiado la empresa, o uno que tuve que queria que le facturara a una empresa o otra segun le venia bien,la cuestion es poder anularla y tener un registro fisico, la factura rectificativa en este caso , por si al ceporro se le ocurre presentar las 2.

Entonces si anulo directamente la factura ,no he de darle nada al cliente?
Otra cosa, la factura erronea , tampoco la tengo que pasar a la gestoria?, que genero para que la gestora la elimine, porque en la aeat, el registrovale, pero para la gestoria que hago una factura en negativo?

[bmfranky]

Pues con este es el 3 sitio donde consulto y dice lo mismo.

Un contribuyente ha expedido una factura y posteriormente ha detectado un error en el destinatario de dicha factura y desea conocer si tiene obligación de emitir factura rectificativa.
Pues bien, sólo existe obligación de expedir una factura rectificativa en los supuestos expresamente contemplados en el art. 15 del RD 1619/2012 (Obligaciones de facturación). En particular, y en lo que se refiere al caso que nos ocupa, entre las causas que motivan la expedición obligatoria de una factura rectificativa se comprende la consignación de un nuevo destinatario de la factura cuando se incurrió en un error. Así, es causa de rectificación de las facturas la consignación errónea de cualquier dato o requisito obligatorio que se consigne en las mismas, como pudiera ser el caso de los datos de identificación del destinatario. Por tanto, en caso de que se haya consignado de manera incorrecta la identificación del destinatario de la factura, el contribuyente deberá expedir una factura rectificativa que deberá constar en serie específica de factura.
Dicho esto, la existencia de causas tasadas, que motivan la obligación de expedir una factura rectificativa, no impide que voluntariamente se puedan rectificar las facturas previamente expedidas, cuando se trate de una causa justificada y siempre que dicha práctica permita garantizar la correspondiente comprobación por parte de la Administración tributaria, si bien, en estos casos de modificación voluntaria de una factura previamente expedida no se estará ante la expedición de una factura rectificativa, en los términos y con los requisitos contenidos en el art. 15 del RD 1619/2012 (Obligaciones de facturación), pues de acuerdo con el apdo. 6 del mencionado precepto, sólo las facturas que deban ser objeto de rectificación obligatoria por las causas previstas en los apdos. 1 y 2 del mencionado art. 15, son las que tienen la consideración de facturas rectificativas.
Por tanto, en el supuesto de que no concurran las causas de rectificación obligatoria de una factura, contenidas en los apdos. 1 y 2 del art. 15 del mencionado RD 1619/2012 (Obligaciones de facturación), como podía suceder en casos en los que se expida una factura erróneamente por una operación que nunca llegó a realizarse, y procede su anulación, se está ante un supuesto de sustitución de aquélla factura por otra que la anula, que en ningún caso tendrá el carácter de factura rectificativa.

[[email protected]]

Estoy leyendo el QR de una factura que previamente ya se ha enviado y aceptado como REGISTRO CORRCTO.

Porque al consultar el QR me dice que NO EXISTE DICHA FACTURA

????

[jlsilver]

Hola:

Estoy integrando facturas en la AEAT por veri*factu mediante las clases generadas por la importación del WSDL en delphi,
me encuentro con las siguientes incidencias/problemas que quisiera saber si alguien más le sucede:

1.Cuando envío más de 8 facturas en un bloque me devuelve el siguiente error, esto no sucede si los bloques son de 8 o menos facturas:

Se requiere un certificado para completar la autenticación de cliente - :htt p://prewww1.aeat.es/wlpl/TIKE-CONT/ws/SistemaFacturacion/VerifactuSOAP - SOAPAction:""

2.Envio una factura simplificada (SIN NIF) y me la acepta sin problema, a continuación intento enviar otra factura y me devuelve
el siguiente error:

Incorrecto - 1123 - Error en el bloque de Encadenamiento.. El formato del NIF es incorrecto.. NIF:. - 60

3.Genero las facturas mediante QuickReport, en una factura con varias páginas, y el cálculo de totales lo realizo a la vez que se genera la factura.
¿Como puedo generar el QR en la cabecera de la factura (se necesita el total de la factura entre otros datos)
si el total lo conozco al finalizar la última página?

¿Se tendría que calcular primero el importe de todas las facturas y luego imprimir?

[ermendalenda]

Empezado por bmfranky

Pues con este es el 3 sitio donde consulto y dice lo mismo.

Hola, ten en cuenta que en 2012 no estaba previsto verifactu y el registro de anulación, si estas hablando de un supuesto de que la factura no se ha entregadompuedes hacer el registro de anulación directamente y volver a emitir la correcta ya que no se ha realizado una operación al cliente que se ha emitido.
Es fácil de saber cuál es la opción a elegir en cada cada si tienes en cuenta un par de cosas:
1-la factura emitida no se ha entregado a ningún cliente o al cliente que se le ha entregado no tiene que ver con los datos que nos dijo : ANULACION y remisión nieva factura correctamente.
2-la factura se ha entregado al cliente con algún error o el cliente ha decidido cambiar los datos RECTIFICATIVA POR SUSTITUTUCION

Pero si tienes el programa preparado para facturas rectificativas por sustitución, no dudes en usar siempre esa opción para las modifiaciones del cliente

[bmfranky]

Empezado por jlsilver

Hola:

Estoy integrando facturas en la AEAT por veri*factu mediante las clases generadas por la importación del WSDL en delphi,
me encuentro con las siguientes incidencias/problemas que quisiera saber si alguien más le sucede:

1.Cuando envío más de 8 facturas en un bloque me devuelve el siguiente error, esto no sucede si los bloques son de 8 o menos facturas:

Se requiere un certificado para completar la autenticación de cliente - :htt p://prewww1.aeat.es/wlpl/TIKE-CONT/ws/SistemaFacturacion/VerifactuSOAP - SOAPAction:""

2.Envio una factura simplificada (SIN NIF) y me la acepta sin problema, a continuación intento enviar otra factura y me devuelve
el siguiente error:

Incorrecto - 1123 - Error en el bloque de Encadenamiento.. El formato del NIF es incorrecto.. NIF:. - 60

3.Genero las facturas mediante QuickReport, en una factura con varias páginas, y el cálculo de totales lo realizo a la vez que se genera la factura.
¿Como puedo generar el QR en la cabecera de la factura (se necesita el total de la factura entre otros datos)
si el total lo conozco al finalizar la última página?

¿Se tendría que calcular primero el importe de todas las facturas y luego imprimir?

Hola, le recomiendo que realice los calculos antes de la impresion, preferiblemente mientras ser introducen los datos de la factura o que genere el Qreport y antes de visualizarlo asigne los datos del qr.
Tambien puede asignar en qreport que se origine la primera hoja al final del reporte.

Puede publicar la parte del codigo en la que asigna los datos de encadenamiento que genera este error?

2.Envio una factura simplificada (SIN NIF) y me la acepta sin problema, a continuación intento enviar otra factura y me devuelve
el siguiente error:

Incorrecto - 1123 - Error en el bloque de Encadenamiento.. El formato del NIF es incorrecto.. NIF:. - 60

Porque para el encadenamiento siguiente no implica el nif anterior.

[bmfranky]

Empezado por ermendalenda

Hola, ten en cuenta que en 2012 no estaba previsto verifactu y el registro de anulación, si estas hablando de un supuesto de que la factura no se ha entregadompuedes hacer el registro de anulación directamente y volver a emitir la correcta ya que no se ha realizado una operación al cliente que se ha emitido.
Es fácil de saber cuál es la opción a elegir en cada cada si tienes en cuenta un par de cosas:
1-la factura emitida no se ha entregado a ningún cliente o al cliente que se le ha entregado no tiene que ver con los datos que nos dijo : ANULACION y remisión nieva factura correctamente.
2-la factura se ha entregado al cliente con algún error o el cliente ha decidido cambiar los datos RECTIFICATIVA POR SUSTITUTUCION

Pero si tienes el programa preparado para facturas rectificativas por sustitución, no dudes en usar siempre esa opción para las modifiaciones del cliente

Hola, gracias por su respuesta, pero lo que no me queda claro es , que pasa con la factura anulada Fac1-00012, porque si no se la llevo a la gestoria, me llama la atencion porque me falta, o la reimprimo con un texto cruzado que indique anulada y se lallevo asi, porque aunque este anulada, no podria reutilizar ese numero de factura, verdad?

[ermendalenda]

Empezado por bmfranky

Hola, gracias por su respuesta, pero lo que no me queda claro es , que pasa con la factura anulada Fac1-00012, porque si no se la llevo a la gestoria, me llama la atencion porque me falta, o la reimprimo con un texto cruzado que indique anulada y se lallevo asi, porque aunque este anulada, no podria reutilizar ese numero de factura, verdad?

Sí, se la puedes dejar al gestor como anulada.
Si hacen un requerimiento que lo tenga todo.

[bmfranky]

Empezado por ermendalenda

Sí, se la puedes dejar al gestor como anulada.
Si hacen un requerimiento que lo tenga todo.

Gracias , eso es lo que me faltava, simplemente , anulo la primera, reimprimo la factura como anulada y doy de alta la nueva, mañana me pongo a ello, Muchas gracias, de verdad.

[sglorka]

Empezado por bmfranky

Pues con este es el 3 sitio donde consulto y dice lo mismo.

La consulta vinculante a la que haces referencia es la (DGT, de 26-10-2022, V2245/2022) hace referencia a una operación que sí se realizó y por tanto, como hay un error en el destinatario, procedes a rectificarla emitiendo rectificativa en negativo y nueva factura con los nuevos datos del destinatario, aunque fuera otro distinto del inicial.
Cuando haces una factura y te equivocas de destinatario, teniendo todos sus datos correctos, la operación nunca llegó a realizarse con dicho destinanatario, por tanto, queda fuera de los casos de rectificación y como te indica en dicha consulta, una operación que nunca llegó a realizarse se debe anular con una factura de abono

[ermendalenda]

Hola, podeis por favor cambiar la huella anterior (SOLO EL HASH), y enviar el siguiente (pero que incluya la huella anterior falsa),
No entiendo que todos estais diciendo que ya controlan el registro anterior, pero yo cambio la huella del anterior (despues de enviarla) y al enviar el siguiente con la huella anterior cambiada me da correcto.

[bmfranky]

Empezado por sglorka

La consulta vinculante a la que haces referencia es la (DGT, de 26-10-2022, V2245/2022) hace referencia a una operación que sí se realizó y por tanto, como hay un error en el destinatario, procedes a rectificarla emitiendo rectificativa en negativo y nueva factura con los nuevos datos del destinatario, aunque fuera otro distinto del inicial.
Cuando haces una factura y te equivocas de destinatario, teniendo todos sus datos correctos, la operación nunca llegó a realizarse con dicho destinanatario, por tanto, queda fuera de los casos de rectificación y como te indica en dicha consulta, una operación que nunca llegó a realizarse se debe anular con una factura de abono

Hola, gracias por la respuesta, entonces por simplificar.
Si la factura la realizo despues de por ejemplo haber reparado el coche, rectificativa, en negativo.
Pero si es por ejemplo antes de entregar un material que me han pedido, factura de abono, verdad.

[CarlosArjonomia]

Empezado por ermendalenda

Hola, podeis por favor cambiar la huella anterior (SOLO EL HASH), y enviar el siguiente (pero que incluya la huella anterior falsa),
No entiendo que todos estais diciendo que ya controlan el registro anterior, pero yo cambio la huella del anterior (despues de enviarla) y al enviar el siguiente con la huella anterior cambiada me da correcto.

Solo controlan que la huella cumpla la regla de negocio, que sea UNA huella válida. No que sea LA huella válida.

Es normal, ya que esto nos facilita mucho el desarrollo. Imagina no poder pasar a la siguiente fase porque te atascas en el encadenamiento de las huellas. Más adelante activarán el control entiendo.

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

Empezado por [email protected]

Estoy leyendo el QR de una factura que previamente ya se ha enviado y aceptado como REGISTRO CORRCTO.
Porque al consultar el QR me dice que NO EXISTE DICHA FACTURA????

La respuesta más lógica es que estés calculando mal el QR (la URL a consultar).
Deberías dar más datos de cómo lo calculas y a partir de qué datos. Sin eso es imposible ayudarte más.

[ermendalenda]

Empezado por CarlosArjonomia

Solo controlan que la huella cumpla la regla de negocio, que sea UNA huella válida. No que sea LA huella válida.

Es normal, ya que esto nos facilita mucho el desarrollo. Imagina no poder pasar a la siguiente fase porque te atascas en el encadenamiento de las huellas. Más adelante activarán el control entiendo.

No se Puede comprobar el hash de la huella anterior si no se comprueba con los datos del hash anterior.
Los hashses no tienen dígito de control ni letra de control ni nada en su contenido ni nada parecido para poder verificar si es correcto, la única forma de verificarlo es compararlo con el correcto,
Y peor aun, modifico un solo carácter del hash en el último registro enviado(despues de enviar) y en el siguiente registro (nodo registro anterior) incluyo el hash malo.
Y Dan como aceptado
Entonces mi duda es, esa prueba la habéis hecho?

[CarlosArjonomia]

Empezado por ermendalenda

No se Puede comprobar el hash de la huella anterior si no se comprueba con los datos del hash anterior.
Los hashses no tienen dígito de control ni letra de control ni nada en su contenido ni nada parecido para poder verificar si es correcto, la única forma de verificarlo es compararlo con el correcto,
Y peor aun, modifico un solo carácter del hash en el último registro enviado(despues de enviar) y en el siguiente registro (nodo registro anterior) incluyo el hash malo.
Y Dan como aceptado
Entonces mi duda es, esa prueba la habéis hecho?

Prueba enviando "xxx" y te dará como parcialmente aceptado con error el el cálculo del HASH.

Error:La longitud de huella del registro anterior no cumple con las especificaciones.

[sglorka]

Empezado por bmfranky

Hola, gracias por la respuesta, entonces por simplificar.
Si la factura la realizo despues de por ejemplo haber reparado el coche, rectificativa, en negativo.
Pero si es por ejemplo antes de entregar un material que me han pedido, factura de abono, verdad.

Es un buen resumen

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

Empezado por jlsilver

1.Cuando envío más de 8 facturas en un bloque me devuelve el siguiente error, esto no sucede si los bloques son de 8 o menos facturas:
Se requiere un certificado para completar la autenticación de cliente - :htt p://prewww1.aeat.es/wlpl/TIKE-CONT/ws/SistemaFacturacion/VerifactuSOAP - SOAPAction:""

¿Cómo estás incluyendo el certificado en el envío?
¿Si envías sólo 1 factura no te da ese error?

Empezado por jlsilver

3.Genero las facturas mediante QuickReport, en una factura con varias páginas, y el cálculo de totales lo realizo a la vez que se genera la factura.
¿Como puedo generar el QR en la cabecera de la factura (se necesita el total de la factura entre otros datos)
si el total lo conozco al finalizar la última página?
¿Se tendría que calcular primero el importe de todas las facturas y luego imprimir?

Yo creo que lo ideal es que el total esté calculado y almacenado previamente con los datos de la factura.
¿Si lo generas al imprimir, significa que no lo tienes guardado en tu Base de Datos?
Si es así, podría pasar que 2 impresiones diferentes de una misma factura en diferentes momentos cambiaran el total.

[Becario127]

Hola buenos dias

Preguntaba como funciona el encadenamiento de facturas puedo enviarlas todas por esta URL?rewww1.aeat.es/wlpl/TIKE-CONT/ws/SistemaFacturacion/VerifactuSOAP
Y hay alguna URL para pruebas en vez de tener que usar la URL de produccion?

Muchas gracias

[antoine0]

Empezado por sglorka

Bueno esta situación, en teoría, no podría darse, y no me refiero a que se caiga el sistema, me refiero a esta suposición que haces "se recupera el sistema, en la base la cadena tiene entonces A12 como última (el SIF no sabe nada de A13)". Si en el paso anterior has podido enviar A13 y la ha aceptado la Aeat, es por que la tienes registrada en tu sistema, que luego no te enteres de la respuesta porque el sistema se haya caido no es problema porque volverías a enviar A13 (se supone que tu algoritmo la tiene marcada como no enviada) y te daría registro duplicado en la Aeat y aquí no ha pasado nada.

Disculpa que no he sido lo suficientemente claro. No estoy hablando de un sistema teórico, sino de un sistema que ha caído. Por tanto el sistema después de la recuperación no sabe si se ha enviado el A13malo o ni siquiera que existe este A13malo. Pensar por ejemplo que se ha recuperado desde un backup cogido después de la emisión de A12.

En mi cabeza no cabe que un registro que se envía a la Aeat no esté almacenado en el Sif. El código que se desarrolle para tal cometido, al menos, debe asegurar este punto.

Aquí exactamente está mi punto. En teoría, el sistema debe pasar sucesivamente por todos los estados creación_número_factura - registro_creado_y_encadenado - enviado - recibido_AR, sin salto, siendo cada operación monotónica (procesando los registros en orden estricto). Y estoy de acuerdo contigo que el código debe absolutamente seguir este guion y asegurarlo (sé que hay una duda sobre la existencia del primer guion).
Pero en la práctica pasan cosas inesperadas y los sistemas pueden caer. Y luego arrancan desde un punto de recuperación anterior a la caída.
A veces, en situación perfecta, cada guion en mi esquema anterior siendo un punto de recuperación, se restaura desde el último guion anterior a la caída, y llegamos al esquema que propones.
Pero a veces en una caída, debes recular de uno o varios puntos de recuperación, por circunstancias; y aquí tienes la oportunidad de tener una situación, observada desde el exterior, como la que he dibujado.