Donde has visto esto?

En mi opinión no podemos dejar de generar registros (hacer nuevas facturas) aunque haya un error, un usuario no puede dejar de vender.
Yo pienso que cuando el usuario vea que ha habido un error en una factura, cuando pueda lo arreglará de la forma que el programa se lo permita y se volverá a enviar.

Gracias

Tiene más sentido, así pensaba yo hace unos días, pero me había reorientar a raíz de los últimos post.
Lo lógico es reencadebar todo, ya que si tenemos que pasar un programa para revisar el encadenamiento vanos a tener fallos.
Esto es un problema GORDO para los No verufactusncomo les pidan los registros de hace 1 ó 2 años.

No tienes que parar nada, como algún compañero en un post anterior ha dicho, las facturas no llevan el encadenamiento en el qr. Solo se encadena en los XML. Se arreglan cuando se pueda, teniendo en cuenta que cuanto más esperes más registros tienes que volver a mandar

:confused:


Yo diría que solo tienes que volver a mandar el que se tiene que arreglar... los demás ya están bien. No?

Bueno, algunos entendemos que hay que reencadenar el registro subsanado don el mismo que debería estar anteriormente, con lo cual habría que r3acer todos los encadenamientos de los generados posteriormente.
Yo voy a trabajar en esa línea hasta que alguien haga la consulta y lo detallen claramente.

??
 

Hola, pues no se que deciros, ahora si que estoy hecho un lio, porque si enviamos por ejemplo la facturas 13 y la encadenomos mal , generando una huella por ejmplo hhhh(aunque deveria ser "AAA") , la siguiente factura, la encadenamos con la huella anterior hhhh, que es incorrecta, pero es la semilla que usamos para generar el encadenamiento, entonces nos dara OK, porque generamos con esa semilla, por eso os decia si alguien havia hecho la prueba de encadenar mal a drede , saltando un registro en el mismo envio, para ver como se comportaba.

Perdona , igual me lo he fumado yo, como mi idea es que si hay un error , subsanar antes de seguir...

Hola, simplemente haces un alta por subsanacion , con todos los datos de la factura anulada, segun la operativa, obtienes.

Lo acabo de leer en el documento de validaciones.

Tienes toda la razon sglorka, la consulta la hice yo y es asi como tu dices, es decir hay que coger la huella inmedianteme anterior al ultimo registro.

Pregunta a al AEAT

Contestacion:

Buenos días:

En el caso planteado, tenga en cuenta que para solucionar el error del registro 2 (siempre y cuando no corresponda la emisión de una factura rectificativa) deberá generar un nuevo registro de facturación de tipo "ALTA POR RECHAZO" con el error corregido. El encadenamiento siempre será en orden cronológico, por lo que este nuevo registro (siguiendo la serie, sería el registro 6) irá encadenado con el registro 5.

Efectivamente se producirá un salto en la cadena entre el registro 1 y 3 pero es algo que desde la AEAT ya se tendrá en cuenta por lo que no debe subsanar los registros posteriores con nuevas huellas.

bueno pues tras leer la respuesta que te dio Hacienda, veo que lleváis razón, no consideran que nº de factura sea igual que registro, y por lo tanto si subo las facturas A1 a A5, y luego modifico la A2, esta irá encadenada con A5, y luego cuando suba A6 irá encadenada con la subsanación de A2.
Personalmente me parece un lío, pero bueno, habrá que adaptarse a lo que digan.
gracias por las respuestas

Entonces, lo que hay que hacer es guardar el encadenamiento en una tabla y cada vez que hacemos un envio, rectificacion o lo que sea , siempre usar los datos de la ultima entrada de la tabla, sea la que sea , podria ser abono de una factura del año pasado, da lo mismo , el ecadenamiento sera sobre los ultimos datos introducidos.

Sustitutiva Cliente Erroneo.
 

Hola siguiendo con mi ritmo, ahora me toca las sutitutivas por cliente erroneo, la operativa seria.
Siendo A mis facturas B los registros enviados a la aeat teniendo en cuanta que la factura ya se ha emitido, enviado con su respectivo rsgistro mi factura Fac001.
1-> emito una factura F1 Fac002, con las cantidades en negativo , genero mi factura A, que imprimo por si se la he enviado al cliente anterior.
Genero un registro de Anulacion Bn4 con los datos de la factura Fac001, encadenado con el registro anterior sea cual sea (por claridad n3)

2-> emito una factura F1 Fac003 con los datos ya correctos para enviar al cliente correcto.
Genero un registro de alta, Bn5 con los datos de la factura Fac003, encadenado con Bn4.


Esto seria lo correcto o en vez de la factura F1 Fac002, seria una Rectificativa R1?


Perdonad la obbiedad pero soy muy ceporro con las cosas que no he hecho nunca hasta que las comprendo.

Pues esto es una buena noticia dentro de todo este lío.
Gracias.

Creo que hay un pequeño lio de varias cosas aquí.
Empezando por el título, aquí nohay sustitutivas, aquí estas intentando hacer una rectificativa por sustitucion de una factura f1.
Las sustitutivas (f3) son emitidas para sustituir las de tipo f2.
Para las facturas por sustitución no hay que hacer anulaciones, algún compañerote lo podrá explicar mejor, ya que las rectificativas que yo tengo son por diferencias no hago de sustitución
El caso que has planteando estas aplicando una doble negativa, al anular y emitir un abono y se te quedaría todo a 0, como si no hubieras emitido nada.
Además las facturas rectificativas por sustitución también tienen 2 formas de hacerlas y dependiendo de lo que quieras hacer o mejor se adapte a tu software, es mejor qur lo veas claro.es un punto un poco lioso en el reglamento

Estoy contigo sobre lo que es lo correcto: si el SIF ha generado A13malo, debe encadenar la siguiente (A13bueno) con este mismo A13malo, no con A12.
Y estoy seguro que esta secuencia (A13bueno encadenada con A13malo y marcada subsanación) será aceptada por AEAT.

Ahora bien, puede haber caso de operatividad que permiten secuencias como:

• se genera A12 limpiamente
• se empieza a generar un A13, hay un problema, el sistema se raya, envía un A13malo y al mismo tiempo se cae (incluso puede llegar a no recuperar la respuesta al envío de A13malo)
• se recupera el sistema, en la base la cadena tiene entonces A12 como última (el SIF no sabe nada de A13)
• se envía la siguiente, A13bueno, encadenada con A12
• este envío está descartado por AEAT ya que "A13" ya existe en el sistema de AEAT (aunque ¡no existe en el SIF!)
• se reenvía A13bueno como subsanación (sin cambiar nada)

Visto desde la AEAT, la secuencia será efectivamente la que lo que ha probado @pablog2K. Y creo que es admisible (aunque se necesitan dos incidentes, que se raye y que se caiga).

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

Si de ha enviado seguramente puedas consultarla cuando hagan la web, debes generar la factura a13 de nuevo y enviarla como subsanacion, si r3cibes la r3spuesta que ya está en el sistema tienes que recibir esa notificación y saber que tienes que hacer.
El problema es que hayas emitido la factura con su qr y no haya dado tiempo a enviarla antes de la avería y es un escenario posible y un potencial problema aquí no cabe subsanacion.

Muchas gracias compañero voy a ver si lo consigo poner en marcha. Es el plan "C" que tengo pensado si no lo consigo con el Delphi 2007 ni con el 2022.

Forma de cambiar destinatario de una factura
 

Hola, segun esto, me cotesto a mi mismo
La operativa correcta es emitir una factura rectificativa "R1" , con todas las cantidades en negativo, a nombre del anterior destinatario Con numero de serie diferente ,asignado a las rectificativas, que es la que imprimo como prueba de la anulacion, creando un registro de sustitucion y a la vez, creo una factura ordinaria "F1", consignando los datos del destinatario correcto,que es la que imprimo y le doy al destinatario, creando un nuevo registro de alta, encadeno y envio los 2 registros.

1-> Emito una factura R1 FacR001, con las cantidades en negativo , genero mi factura A serie Rectificativa, que imprimo para el cliente anterior generando un registro de Rectificacion Bn4 con los datos de la factura Fac001, encadenado con el registro anterior sea cual sea (por claridad Bn3)

2-> Emito una factura F1 Fac002 con los datos ya correctos con serie de facturas normales ,para enviar al cliente correcto generando un registro de alta, Bn5 con los datos de la factura Fac002, encadenado con Bn4.



Gracias de todas formas por tu interes @ermendalenda^\||/

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?

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

Consultar factura por el codigo QR
 

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

????

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, 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, 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?
Porque para el encadenamiento siguiente no implica el nif anterior.

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.

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.

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

Huella Anterior
 

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.

Por acabar de entenderlo.
 

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.

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.

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.

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.

Es un buen resumen

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



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.

Hola buenos dias

Preguntaba como funciona el encadenamiento de facturas puedo enviarlas todas por esta URL?:prewww1.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

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.

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.