Repsando encadenamienos con Anulación intercalada
 

Buenas, me ha surgido una "pequeña duda", si os apetece revisar la encrucijada, como pasatiempos y para revisar si estoy haciéndolo bien, aunque es una cosa que ya vimos:
1. Emito Una factura (Factura Num.1)
Primer registro ="S"
Huella = "AMASKJDFJKA345KL34LKY3UHR34UIRU34U3427884283498982349......"
2. Emito otra (Factura Num.2)
Huella="7823HEHI23HI823EYH2DHD238EH2DH2O3D82D83HD3D23DHDH293D....."
Huella Anterior = "AMASKJDFJKA345KL34LKY3UHR34UIRU34U3427884283498982349......"
3. Emito Anulacion de la segunda
Huella Anterior="7823HEHI23HI823EYH2DHD238EH2DH2O3D82D83HD3D23DHDH293D....."
Huella="GD2783E72379EDH2D2398E239EH923H38ED8923E283......"
4. Emito otra factura (Factura Num.3)
Huella Anterior="GD2783E72379EDH2D2398E239EH923H38ED8923E283......"
Huella= "AEBFHRIE8238R23HJH2823482H3EH32E........."




Consulto en verifactu, da igual por web o por websoap, devuelven lo mismo, registros devueltos:
Factura Num.1
Numserie Factura anterior=vacio (logico es la primera del SIF)
Huella Anterior=Vacio (lógico por que es el primero de ese SIF)
Huella = "AMASKJDFJKA345KL34LKY3UHR34UIRU34U3427884283498982349......"
Registro Anulado:
Factura anulada=2
Numserie Factura anterior=2
Huella Anterior = "7823HEHI23HI823EYH2DHD238EH2DH2O3D82D83HD3D23DHDH293D.....( o sea la huella de la factura anulada que ya no puedo ver en su servidor)
Huella="GD2783E72379EDH2D2398E239EH923H38ED8923E283......"
Factura N.3.
Factura anterior=2
Huella Anterior="GD2783E72379EDH2D2398E239EH923H38ED8923E283......"
Huella= "AEBFHRIE8238R23HJH2823482H3EH32E........."



En resumén, stengo que tener en cuenta que el registro que falta tenia la huella =huella anterior de la anulacion), pero se complica aún más si la anulación se emite varios registros despues, o incluso dias despues.
Por lo cual, verificar el encadenamiento con los datos que nos dan, y cuando detectamos un salto, implica un algoritmo de busquedas bastante complejo.
¿Se me escapa algo que facilite esta verificacion?

en la demo del componente he incorporado un seguimiento de huellas. Que no toca ese caso:

solicito el periodo, en la demo el año completo

ordeno por generacion de registro

me coloco al final y empiezo a comprobar, subiendo hasta el inicio.


no he tocado el caso de bajas, pero como dices fallara en la comprobación, porque la anulada ya no te la devuelve. (si la devolviera con alguna marca, problema solucionado). No se tampoco si habra mas problemas. esto ha sido un poco rapido de examinar.

Llegado al registro de baja, te guardas ese numero.

Cuando tengas un error de huella, compruebas si la factura anterior del registro fallido, pertenece a una factura de baja de las que has guardado, compruebas la huella archivada en tu BD para esa anulada, y sigues.

Saludos !

No se si entendi bien tu consulta.

Con el apoyo de tu BD con tus facturas anuladas puedes solucionar el problema.

Quizas esta solucion la incopore en la siguiente version, porque en la BD de la demo contiene la anulada. Lastima no haber visto antes este posteo.

: )

Buenos dias !

He colocado un codigo en la demo, con la descripcion anterior y funciona.

Caso probado:

w240020
w240021
w240022
w240023
w240022 (Baja)


Los que esteis interesados en verlo, estará en la demo 5.9 del componente TVeriFactu. No es muy complicado, solo requiere guardar la huella de tus facturas anuladas en una bd. (que entiendo que ya lo haceis).

Otra posibilidad seria colocar la huella de la que vas a anular en refExterna al enviar la Baja, con ello no tendrias que mirar ninguna BD, simplemente consultarías la huella en la refExterna de la baja.
Eso si refExterna sigue siendo de 70 digitos. ¿si fue acortada a 60 digitos?, como creo que lei, con guardar los ultimos 60, te garantizarias igualmente una comprobacion muy fiable.

Saludos !

Lo que ocurre es que he delegado las verificaciones al asesor fiscak, le he hecho un programa de comprobaciones, libro de iva...todo leido de verifactu y SII, y le he puesto lso encadenamientos y queria hacerle un botón de verificacion, pero creo que voy a abortar esto último.

Podrías saltarte las bajas en la verificación

Es mejor eso que nada, cumples tú propósito inicial mejor


Saludos!

Una pregunta, ¿cómo hacéis la verificación del encadenamiento, recalculais en cada registro la huella, o guardáis en vuestra base de datos en cada registro la huella generada y la huella anterior o como...?

yo utilizo las huellas recibidas de la AEAT y las comparo

Ordenadas por generacion de registro.

Ahora bien: generacion de registro tiene una resolucion de tiempo de 1 segundo. es decir que si en un segundo has generado varios registros NO te servira porque la AEAT luego lo envia todo "revuelto" en ese segundo de tiempo. (podria hacerlo dentro de ese segundo, ordenadas en su llegada, pero no). (... aqui se podria hacer algo con tiempo de remision pero tampoco lo tengo claro ... )

¿y como es posible generar varios registros en menos de 1 segundo? pues la demo, que importa una excel con varias facturas lo hace.

Asi que para probarlo o simular condiciones reales con tiempos de generacion "normales", hay que importar varias exceles y enviarlas 1 a 1 para dejar algo de tiempo entre ellas y tener un tiempo de generacion de registro correcta.

Eso con un programa no te ocurrira. Pasa con la demo del componente TVerifactu, pero queria explicarlo.

Saludos !

En mi caso es que no estaba haciendo la verificación del encadenamiento tal y como la hacéis vosotros. En mi caso la verificación la hago al crear el registro, vuelvo a recalcular la huella del registro anterior y si me coincide con la que tengo guardada pues palante, y si no pues salta un error de encadenamiento. Pero no me había planteado lo de comparar "mis huellas" con las que tiene hacienda, y al verlo me estaba planteando hacerlo, aunque no se si me aporta algo...

Entiendo que si tú programa no deja cambiar la factura una vez realizada esa huella siempre coincidirá

El ordenar por generación de registro y comprobar las huellas después te permite ver el número de orden de las facturas y apreciar otra vista de tu facturación, de cómo hacienda lo ve.

Saludos!

Poca cosa aporta, sobre todo si está todo bien depurado, es algo temporal, si tienes bases de datos robustas que no vayan a tener problemas de indices o lo tengas controlado bien, el problema son c7ando trabajas con bases de datos mas inconsistentes, las bases de datos de escritorio(bd en ficheros) sin un servidor dedicado mysql, postgreSQL... que aun siwndo más robustas y estabkes necesitan mas recursos, y para tpvs con pocos recursos con software de escritorio pueden ser un martirio en rendimiento.
Si estas con un motor de bd dedicado y manjeas bien lss transacciones, tienes mas estabilidad y es raro que necesites verificar nada, si tienes bd de escritorio, ni manejando lss transacciones te garantizas estabilidad, en este ultimo puede ser mas aconsejable tener una monitorizacion

En nuestro caso son bases de datos de SQL Server 2017, y la verdad no he tenido nunca problemas. Los registros de facturación una vez creados y enviados, al igual que las facturas ya no se tocan, el cliente no puede hacerlo. Creo que por ahora me ahorraré lo de verificar con hacienda, ya que en todo caso tengo todos los registros guardados, incluidas por supuesto las anulaciones, y si acaso ya meteré estas verificaciones más adelante, que tenga más tiempo. Gracias por vuestros comentarios. Saludos !!!

Con esta comprobación te aseguras que tú generación de registro coincide con el encuadramiento de las huellas

Yo lo veo útil.

¿Qué es el encuadramiento de las huellas?

XD

Encadenamiento

Estoy con el movil

Yo tambien eatoy de acuerso, aunque xomo dicea, como ultima parte del proyecto y con el fin de dormir mejor, yo voy a hacer una monitorizacion, chekeo 2 vecws al dia (desde unequpo remoto por aue al ser programas de escritorio si no hay conexion no hay verificacion). Con ello me llega un reporte de si hay rotura de encadenamiento, los poaiblea envios con incidencias y ai algun equipo deberia estar enviando o no(para ello ademas le tendre que meter un calendario (dias horas) de trabajo.
Para los que trabajan todo en nube eno es necesario casi nada de esto.

Nosotros también trabajamos en tpvs en los centros, lo que tengo por ahora es una alerta por correo de cualquier error que les surja de verifactu, nos mande una alerta al servicio técnico, porque por experiencia en Ticketbai la peña no avisa de nada si no se les para la facturación.

Eso es lo que tengo de momento, pero si un tpv deja de enviar por algún motivo distinto a los contenplados, lo mismo tampoco recibes errores. Por eso voy a hacer la monitorizacion externa