Funcion generar QR C#
 

Una vez puesto, ahunque nadie me la ha pedido , adjunto mi funcion para generar el QR
Primero que nada instalar el paquete nuget Aqui os dejo la funcion, debuelve el QR en bytes[], para que lo asignemos directamente a la plantilla de impresion.

Siguen sin comprobar encadenamiento
 

He leido un post de que estaban comprobando el encadenamiento.
Yo he hecho 2 pruebas, he enviado encadenando mal y volviendo a enviar como primer registro y me lo ha aceptado todo como correcto

Por cierto Ya me funciona QR de sustitutivas y de rectificativas.
A los QR en pdf les he añadido que si se pulsan vaya al mismo enlace que leyendolo. No sé si eso al final era un requisito, pero no cuesta nada ponerlo.

Tambien he verificado que si envio una factura y despues envio anulacion ya dice que no existe al leer el QR de nuevo, tal y como han puesto en la ultima modificación de respuestas.

Con SII yo podia acceder a la AEAT y comprobar los registros enviados con sus datos.

En VERI*FACTU hay alguna forma de ver en la AEAT las facturas enviadas ???

Estoy teniendo problemas con la HUELLA cuando ya lo tenia funcionando OK

Necesito ver que HUELLA tiene AEAT de los registros ya enviados para ver el ultimo con su huella y poder calcular la HUELLA del nuevo registro

Reparar encadenamiento.
 

Hola, simplemente, cuando te responde el error, te da la HUELLA que ellos calculan correcta, asignala para la siguiente factura y veras como a partir de ahi no te falla.

Hola, ahi esta , que has vuelto a enviar como primer registro, eso es trampa:D:D, si encadenas mal, hasta que encadenes bien *falla. Mejor dicho da aceptado con errores, si das como primer registro, te pone a cero el encadenamiento, por lo menos de momento.

Que va.
Lo he hecho 2 o 3 veces rompiendo encadenamiento y sd lo come todo. Que raro que a unos sí y a otros no.

Ahora toca a analizar todas ests movidas y las posibles combinaciones:
Incidencia, subsanacion, rechazo previo, tiempo de espera próximo envío.

Hay que sentarse con la librería y ver qué se puede automatizar, que puede decidir un usuario y "que cosa"
tienen que llamar a un informático.
De momento veo un gran enredo de tres pares de narices y 2 paquetes de ibuprofeno de 600.
No por saber que hay que enviar en cada situación, si no en evitar confusiones y que además no se quede en el olvido.

No creo que esto llegue a buen puerto, van a tener que simplificar más. La mayoría de los que estamos aquí le estamos dedicando decenas de horas, pero cuando esto les toque a los miles de desarrolladores de programas hechos con mucho esfuerzo para empresas con programas muy específicos y que ha costado muchísimo tiempo y el desarrollador diga que en esto no se mete, va a haber un gran problema, se van a cargar el particular ecosistema de desarrollos y obligarán a las empresas a comprar softwares a multinacionales que no atenderán las demandas de estas empresas como estaban acostumbrados, en cuando a rapidez y de tú a tú y ya sabemos como trabajan los desarrollos de programas distribuidos a media y gran escala.
Me temo que va a haber repercusiones políticas. Al final no sé si merece la pena adelantarse tanto. Peor claro el miedo a que nos pille el toro nos puede a todos.
Es que no es normal de que nos caiga la mochila de todo:
Que si los servidores están cargados tengamos el programa preparado para la ralentizar los envíos al ritmo que vayan imponiendo.
Que la forma de actuar ante una incidencia este tan complicada para los desarrolladores y suaurios para que ellos tengan los datos súper limpitos para analizar lo mínimo posible.
Que sea todo un riesgo, hasta que te quedes sin Internet y la pila del PC re juegue una mala pasada con la fecha/hora del sistema.
Que haya que estar conectado a las comprobaciones de hacienda de correspondencia de nifs/nombres.

Y otros problema lógicos que se me ocurren que puede pasar y te quedas en bragas ante la aeat por que ellos dicen que tú tienes que tenerlo todo atado, hasta lo imposible.
Por ejemplo, les hice una consulta de que existe un margen de tiempo de caché de grabación al disco en el que se puede perder el dato impreso, y que incluso ante una avería se pierda y no he haya dado tiempo a enviarlo ni hacer copia. Y si el cliente se ha llevado su qr nos podemos meter en un lío y contestan que la ley antifraude obliga a blablabla.

Ya, pasan cosas muy raras ya os comentaba que es como si hubieran servidores con varias versiones del programa que usen para atender a las peticiones, porque contetan de formas demasiodo diferentes.

Puedes poner como haces el enlace de donde de como haces sl la peticion del soap. A ver si es qu3 estoy poniendo algo diferente.

Duda rechazo previo
 

A ver si me explico,
Si enviamos un registro y después una subsanacion sin rechazo previo y esta última nos la rechaza, se supone que su queremos volver a mandar la subsanacion es sin rechazo previo, no?
O sea, los rechazos de las subsanaciones no hay que tenerlos en cuenta al intentar reenviarlo correctamente pero nosotros si tenemos que tener en cuenta que nos lo ha rechazado

Como se corrige anulación?
 

Enviamos una factura, anulamos por error otra y la enviamos, y además pertenece a otro periodo impositivo la que hemos anulado por error.
Supongo que hay que volver a emitir una nueva de la que hemos anulado ¿con la fecha de la anterior?, aparte del lío de hablar con el cliente que lo mismo está en SII y ya se la ha declarado.
Ahora el cliente tiene que anular esa factura del SII (y que lo haga)
Vaya lio no?
PROHIBIDO EQUIVOCARSE.

Alta por Rechazo de subsanacion
 

Hola, en el documento de validaciones pone esto:

Ok gracias
Anotado

De momento no. Pero en una respuesta hace unos días, dijeron que están estudiando poner en marcha para Veri*factu un portal similar a lo que hay para el SII, con servicio de consultas.

buenas, yo acabo de hacer unas pruebas y si que me comprueba el encadenamiento:

-subo la factura A12 (encadena con la A11), respuesta OK.
-subo la factura A13 (me invento el encadenamiento, pongo que encadena con la B1234 que ni siquiera existe, me invento los valores del nodo Encadenamiento.RegistroAnterior), respuesta Aceptada con errores, error en la huella.
-subo la factura A13 como subsanación, poniendo bien los valores de Encadenamiento (Encadena con A12, relleno bien IdEmisorFactura,NumSerieFactura,FechaExpedicionFactura y Huella) , respuesta OK.
-subo la factura A14 (encadena con la A13, con la huella de la subsanación de la A13), respuesta OK.

En esa situación me encuentro yo, tengo ocho programas de facturación super SUPER a medida, cada uno para un solo cliente, estoy entre que me pille el toro y dejar el negocio, porque esto de negocio ya tenía poco antes, pero ahora me parece que será una ruina total. Lastima que ya tampoco me dejan prejubilarme.....

Buenos días a todos,

Estoy usuando el programa de ejemplo para probar de hacer envíos y, al recibir la respuesta, no soy capaz de convertirla correctamente a un objeto del tipo RespuestaBaseType. EL problema lo tengo al acceder a las líneas de respuesta. Con Length(RespuestaBaseType.RespuestaLinea) me devuelve 0, como si fuese un array vacío pero el xml recibido si que tiene líneas.

Para ver la respuesta que recibo uso el código de pablog2k:

Código Delphi [-]
  ss:=TFileStream.Create(ruta+'\respuesta.xml', fmCreate);
  SOAPResponse.Position := 0;
  ss.CopyFrom(SOAPResponse,SOAPResponse.Size);
  ss.Free;
  SOAPResponse.Position := 0;

Estoy recibiendo el siguiente xml:

Hay alguien mas que se haya encontrado con esto o que sepa como solucionarlo?

Muchas gracias!

duda
 

Hola buenas

Estoy recreando la aplicacion de verifactu que esta colgada en este foro pero en python y ahora estoy con la parte de enviar el certificado y un xml de prueba que genero a partir de un excel. El problema que tengo es que a la hora de enviar la facturas me sale este error

HTTPSConnectionPool(host='prewww1.aeat.es', port=443): Max retries exceeded with url: /wlpl/TIKE-CONT/ws/SistemaFacturacion/VerifactuSOAP (Caused by SSLError(SSLError(524297, '[SSL] PEM lib (_ssl.c:3895)')))

La cosa es que no se si puede ser porque al estar usando un certificado que genere yo con openssl y un xml pero sin las caracteristicas de verifactu me esta dando el error porque el server no acepta eso o es porque tengo que usar una URL diferente para pruebas.

Muchas gracias

Estoy teniendo problemas con el calculo de la huella. He chequeado los datos que vienen en las instrucciones, con ejemplo y resultrado de datos incluido y todo correcto, pero no consigo coincidir con hacienda en el momento de calcular, me da :

El cálculo de la huella suministrada es incorrecta.

Datos de entrada cálculo huella:

IDEmisorFactura=33461360V&NumSerieFactura=107-2024-13783&FechaExpedicionFactura=21-10-2024&TipoFactura=F1&CuotaTotal=10.07&ImporteTotal=58.15&Huella=7F89287D674954888681E C947D1019EDD8C8D81248CD510AD768E668B526171C&FechaHoraHusoGenRegistro=2024-10-23T10:24:27+02:00

Huella calculada: 9800FA2F5E2B24ED9F0EE98C8174C78B8E97B1294D5F58E90E506E27B31133B4


Alguien podria calcularla con los datos entrada calculo huella que muestro mas arriba.

Gracias

El encadenamiento siempre tiene que ser con el registro generado anteriormente en orden cronológico para el mismo SIF. La tercera operación que has hecho, -subo la factura A13 como subsanación, poniendo bien los valores de Encadenamiento (Encadena con A12, relleno bien IdEmisorFactura,NumSerieFactura,FechaExpedicionFactura y Huella) , respuesta OK.

no debería ser correcta ya que no estás encadenando con el registro anterior de factura A13 que sí fue aceptado, aunque con errores. Para subsanar una huella no puedes saltarte la cadena cronológica aunque parezca que en realidad no estás subsanando nada. Esto ya lo he consultado con el correo de Verifactu. Si te responde Ok en porque ellos internamente habrán decidido eso pero saben perfectamente que el encadenamiento está mal

no acabo de entender lo que dices:
subo la A12 encadena con A11, ok
subo A13 encadena con B21324(inventada), Aceptada con errores (arregla la huella me dicen)
subo A13 corregida que encadena con A12 (huella ok ) contesta OK
subo A14 encadena A13, contesta OK
el orden cronológico lo he seguido.
precisamente lo que he arreglado es el encadenamiento de la A13 que apuntaba a una inventada y le e dicho que apunte a la A12 que cronológicamente es la anterior

Para formar la huella en la tercera operación, ¿ Qué huella anterior estás tomando, la de el registro de alta inicial de A13 o la de A12 ?
Sólo puedes coger la del alta inicial de A13

Veo que muchos metéis este dato&
En vez de solo &
Una cosa es quepara generar un xml generes los caracteres en unicode pero para calcular la huella?Mmm
No sé lo mismo tb está bien, pero yo calculo con wl ampersan (&) a pelo y no me da problemas

yo me guardo en base de datos de cada registro enviado, el valor del campo Huella (el SHA256 calculado de 64 caracteres), entonces cuando hago el siguiente registro, relleno los datos de encadenamiento asi:

Código Delphi [-]
  ARegistroFactura[0].RegistroAlta.Encadenamiento.RegistroAnterior := SistemaFacturacion.EncadenamientoFacturaAnteriorType.Create;
  ARegistroFactura[0].RegistroAlta.Encadenamiento.RegistroAnterior.IdEmisorFactura := 'B97486070';
  ARegistroFactura[0].RegistroAlta.Encadenamiento.RegistroAnterior.NumSerieFactura := 'A12';
  ARegistroFactura[0].RegistroAlta.Encadenamiento.RegistroAnterior.FechaExpedicionFactura := '23-10-2024';
  ARegistroFactura[0].RegistroAlta.Encadenamiento.RegistroAnterior.Huella := 'EA1128619C488A282B3B544EBFEB2FE0BDDAC52C12CA7BD75019EDE49AAE6ED5';

En mi caso , cuando subo la primera vez el A13, pongo los datos de encadenamiento de A12 bien , pero el numserieFactura lo pongo mal a propósito. Genero la huella de A13 y subo el registro.
Hacienda me contesta que está mal, que lo arregle.
Vuelvo a subir A13, como subsanacion, ahora rellenando bien RegistroAnterior.NumSerieFactura , genero la huella y la guardo. Envío y Hacienda contesta OK.
Genero la A14, con la huella buena de la A13, la subo y OK
creo que los pasos que he seguido son los normales a la hora de arreglar un error de encadenamiento (subes una factura, te dice aceptada pero arregla el encadenamiento, lo arreglas, guardas huella bien hecha, subes a hacienda, responde OK)

¿ De qué registro estás cogiendo la huella anterior para generar la huella de A13 cuándo la subes como subsanación ?

Creo que ya he visto donde tienes el error.
sigues metiendo retorno de carro enmedio de la huella
entre 81E
y C94

La huella que has puesto es la correcta si quitas el retorno de carro y los caracteres especiales para unicode
9800FA2F5E2B24ED9F0EE98C8174C78B8E97B1294D5F58E90E506E27B31133B4

de A12, que es la que subí cronológicamente antes de la A13.
Relleno el encadenamiento de la A13 con los datos de la A12 (numserie,fecha,huella) , que fueron los datos que puse mal y me dijeron que los arreglara, y sobre ese registro, genero la huella y la guardo en el registro de A13, para cuando haga la A14

La Huella anterior que debes coger para formar el registro de subsanación de A13 es la huella del registro de A13 que te aceptaron con errores

creo que no es correcto lo que me comentas, ya que la huella anterior según su documentación es lo siguiente:
Primeros 64 caracteres de la huella o «hash» del registro de facturación anterior (sea de alta o de anulación) generado en este sistema informático.
en mi opinión, si yo subo la factura A12, luego la A13, y me la aceptan con errores, si voy a subsanar A13, el registro de facturación anterior es A12, no A13 que subí previamente pero me dio errores (me parecería mucho más lioso). De hecho hasta que no subes como subsanación el HASH o huella de A12, no te da como correcta la A13.

Yo diría que tiene razón sglorka pero a ver si alguien mas puede opinar.

Te estás respondiendo tú mismo

Primeros 64 caracteres de la huella o «hash» del registro de facturación anterior (sea de alta o de anulación) generado en este sistema informático

bueno, creo que tenemos conceptos distintos de lo que es 'factura anterior'.
Para mi la factura anterior a A13 es A12, aunque estés subsanando la A13, de hecho todo el encadenamiento (en mi opinión) está hecho para que las facturas 'físicamente' vayan 'encadenadas' unas con otras, no para que la A13 encadene con la A12, la A13 subsanada encadene con la A13 sin subsanar, la A13 subsanada dos veces encadene con la A13 subsanada una vez....
Al final conforme vayan refinando las respuestas de OK y no OK saldremos de dudas , porque según parece ahora 'traga' con casi todo

Mi recomendación es que hagas la consulta a Verifactu.

Subsanacion encadenado.
 

Hola, creo que estais mezclando saraos,en el caso de subsanacion del encadenamiento, solo tenemos que tener en cuenta los datos de encadenamiento de esa factura/registro no los posteriores, tened en cuenta que tenemos que reenviar todo el registro igual, menos la cadena has y poner que es subsanacion/correccion, nada mas.
tened en cuenta que para los encadenamientos sucesivos, ellos tienen en cuenta, no la huella que nosotros enviamos, sino la que ellos calculan.

pues mira llevas razón , voy a plantear la duda y con lo que contesten lo informo aquí

A continuación mi opinión basada en una consulta a hacienda:

No es lo mismo un "registro de facturación" que una "factura".
Un registro de facturación se refiere al XML que se genera. Esto es lo que es inalterable y lo que se tiene que encadenar.
Puede haber mas de un registro de facturación para cada factura.
Al crear la factura generas un registro de facturación y lo envías, puede contestar aceptada con errores, lo corriges y generas un nuevo registro de facturación (sobre la misma factura) y lo envías, encadenado con el anterior "registro de facturación", no con la anterior factura.

Espero que alguien más de su opinión y lo aclaramos.

Esto admite 2 lógicas en este caso así que hay que ver que dicen para que sigamos la misma lógica:
Lógica 1(para mi es la más coherente): estoy enviando un registro de subsanacion de la factura A13, la cual la estoy recomponiebdo en mi sistemay recalculando las huellas, si la lógica nuestra es borrar el registro y hacerlo de nuevo perdemos la huella que generamos en su momento si no la henos guardado aparte. Yo por ejemplo no guardo aparte la huella ultimma si no junto al registro generado, y si el último registro enviado coincide con el que tengo que volver a enviar, en esta lógica non puedes encadenarlo a si mismo, hay que encadenarlo al A12.
La lógica 2 es que se guarde 2 veces el registro último y se encadena al a13 que estaba mal.

Hola, la cuestion es que estamos subsanado la huella, y segun esto.
Creo que tenemos que componer la huella enviada, teniendo en cuenta los datos del registro a subsanar, osea la huella anterior al registro subsanado, teniendo en cuenta que nos indican que no debemos continuar generando registros hasta subsanar los anteriores...

Una cosa , alguien ha probado a enviar varios registros , fallando la cadena al principio, si las da todas como erroneas o solo la primera?