Hola lo único es que los puntos 2 y 3 están invertidos primero se halla la huella y luego se envia:D

bueno... a ver

la huella no puede ser calculada hasta finalizar la factura, o casi. Lo normal seria esperar a tenerla finalizada. (digo lo normal).

Aquí haces tu factura, y la envías inmediatamente, en el momento del envío, mientras compone el objeto SOAP el registro de Facturacion (x cada factura, antes de su envío), hay un evento que te indica la huella calculada, ahí ya se puede archivar, pero además cuando finalice, o no el envío, completo o no completo, con fallos o sin ellos, puedes todavía recoger las huellas: hablamos de 1 segundo como mucho entre un proceso u otro.

Se podría considerar como una parte del proceso de Facturacion la generación de las huellas, antes de su envío, que ocurre automáticamente al finalizar la factura. (en mi caso).

Evidentemente las huellas se calculan antes, o se recogen vía evento, o al finalizar el envío.

No creo que haya problemas ahí.

Tambien:

Se podría simular un envío, obtener las huellas y archivarlas ¿y después? enviarlas. no le veo sentido.

Estando en verifactu el envio debe ser inmediato. Creo que cumplimos.

Hola, en el momento que imprimes/guardas la factura la huella ya la has de tener, no puedes calcularla despues, puesto que los datos han de ser los mismos que van en el QR, por eso decia de calcular la huella antes.


Yo por mi parte , calculo la huella en el mismo evento de preimpresion de la factura, al mismo tiempo que genero el QR, asi me aseguro que todos los datos concuerden, al finalizar la impresion, justo despues de realizar el envio , si hay error de envio** , lo muestro y almaceno , en mi caso como una proforma, porque me resulta mas facil despues reeenviarla , al no tener implementado el servicio de envio separado.


Como no he impreso, guardado la factura, la genero de 0 creando todos los campos.

*A ver , lo de el error de envio , lo saco de la consulta a la aeat, para ver si el servicio esta activo, lo hago antes de preimprimir ni nada la factura, es que creo que no me he explicado correctamente.

*Este sistema solo lo uso si no se ha podido realizar el envio porque no hay conexion, en caso de error de otro tipo, imprimo y guardo todo de forma normal, para poder realizar la Subsanacion 0 reenvio como sea correcto, sea con una rectificativa o lo que sea menester.

Por comentar temas, a ver....

Los datos que van en el QR son diferentes a la huella. La huella contiene algunos mas. NO es recomendable, pero puedes imprimir una factura con su QR sin tener la huella calculada. Yo no lo haria, pero se puede.

El servicio activo no te garantiza al 100% que se vaya a ejecutar el alta, pero esta bien. (El resto de procesos que haces ya depende de cada uno, hasta ahi)

Ya me he explicado, para aclarar un poco mas, para los que usan el componente:

1) Haces la factura
2) Aqui podrias calcular tu QR sin problemas
3) Añades la factura al componente
4) Se ordena el envio
5) (durante la preparacion del envio se genera la huella y se envia por evento, para guardarla en cada factura)
6) Se envia a la AEAT
7) (y aqui tambien se pueden recoger las huella/s generadas, para guardarlas en la factura)
8) Imprimes


Quizas incluya una funcion "libre de envio" que devuelva la huella en cualquier momento.

Personalmente En mi caso, siempre envio antes de imprimir. La factura se queda enviada, o pendiente. La pendiente, se reenviara cuando sea técnicamente posible: ahora con las huellas actuales y anteriores guardadas, no hay problema alguno. Envias y ya. Se marcara incidencia si el tiempo supera en 2 minutos el establecido en la huella.

Y Validar el NIF antes de empezar mejor
Y Validar si esta activa la AEAT mejor

Saludos !

aun asi, y no os molesteis mucho todavia hay un caso sobre encadenamientos, no dudas del componente:



a ver si alguien tiene paciencia:


facturas


sesion 1:
Factura 4 fallida en el envio por fallo de internet encadena con 3



sesion 2: <- aqui ya funciona internet, nos ponemos a facturar

Factura 5 encadena con 4
Factura 6 encadena con 5
Factura 4 encadena con 3 <- reenvío la 4 cuando vemos que ya funciona internet, (hemos enviado 2 delante)

Factura 7 encadena con ?

Cuando se crea la factura 7, su registro de facturación tiene que estar encadenado con el último registro de facturación creado (del mismo obligado tributario y mismo SIF).
Probablemente será el registro de facturación de alta de la factura 6, pero podría no serlo, podría ser una eventual subsanación de la factura 1 por ejemplo.

El encadenamiento no tiene nada que ver con el envío.
Al crear una factura debes crear el registro de facturación de alta y guardar en algún sitio (una tabla por ejemplo) los datos del último registro de facturación creado.
Cuando se crea otro registro de facturación (ya sea de alta de una nueva factura, de anulación, de subsanación) se encadena con el último registro de facturación creado.

El envío de registros de facturación no afecta al encadenamiento. Los registros de facturación creados y no enviados, se van enviando cuando toque, siguiendo el control de flujo que indica la ley

error el la fecha y hora del xml de envío
 

Buenas tardes compañeros estoy haciendo las pruebas con el proyecto del compañero sección31, y me encuentro con este error al realizar el envío de pruebas => CSV: A-8ZC67LVDU6WUPC. TimeStamp: 16:47:49 09/04/2025. He comprobado la fecha del ordenador y está correcta 17:47:50 al parecer no recoge la nueva hora.
Me podeis echar una manita.
Gracias

Hola, como bien dice @rci, lo que has de guardar son los registros ya encadenados, independientemente de si se enviaron o no, has de crear unas tablas, ya sea con el XML complero del registro de facturacion completo, creo que desde c# lo mas facil, o todos los datos para recrearlo al enviar, pero ya completado.


Deves hacer 2 cosas en ese supuesto, inmediatamente enviar lo pendiente , en este caso el registro de factura 4 que ya esta correctamente encadenado, indicando en la cabecera e el fallo en el envio, y esperar los x, segundos para empezar a enviar los registros encolados despues.


Aunque puedes esperar a enviar cuando tengas mas registros , no te lo recomiendo.

Hola, por favor habre un hilo nuevo, y postea el xml, del envio ,para poder verificar donde esta el error, simplemente modifique sus datos, en este casoi necesitamos ver el nodo FechaHoraUsoGenRegistro...

Efectivamente,

Si, eso entraria en la logica del programa. Colocar los pendientes primero. (el componente no tiene base de datos) (la demo hace uso de una base de datos basica demostrativa, no entra en esta complicacion).

Aun asi, me asegurare que si en un paquete de envio hay varios pendientes, siempre se coloque la huella anterior correcta. Lo cual minoraria el problema, porque el envio seria correcto.

Basicamente ya esta echo. Me falta probarlo bien.

gracias a todos !

a ver si alguien puede ayudarle, nunca habia tenido problemas con la hora.

Slds !

Una solucion patatera que se me ocurre es , al fallar el envio, generar en un directorio temporal, los registros pendientes de envio, con su xml completo, al comprobar que ya hay conexion, verificar si el directorio tiene contenido, y entonces automaticamente, antes de permitir empezar a factura, cargar todas las facturas pendientes en orden, y al cargar/enviar la ultima establecer esos datos como los correctos para el encadenamiento.

Si, ya le he comentado que postee el xml del envio, para verificar, seguramente el uso horario no sea el correcto...

gracias ! bueno, pero fuera del uso del componente.

personalmente, en mi aplicación antes de facturar sacare la lista de lo pendiente, para que envíe.

Saludos !

gracias por atender lo de la hora


En mi caso, este es mi timestamp:

2025-04-03T20:06:59+02:00

Y este es el codigo que lo genera:

Para dejarlo mas funcional, porque no añades en la base de datos donde guardas la configuracion, los datos del ultimo registro generado, asi siempre puedes cojer de alli los datos para generar el siguiente, sin preocuparte de si se envio o no, esa parte la puede atender el programa fuera del la DLL, la dl unicamente dedicarse a generar los registro y encadenarlos.

Como le indicas la zona horaria, el C#, le he de indicar , "DateTimeKind.Local", para que la establezca correctamente, sino siempre pone +1, aunque cambie la hora.

ni idea, funcional tal cual.

hola !

necesito un voluntario para probar la 4.0, porque esto ya necesita pruebas algo mas complicadas.

El que quiera participar seriamente en las pruebas que me envíe un privado con su mail.

gracias !

ya tenemos dos voluntarios.

En cuanto este validada la publicamos.

Espero que esta version sea la ultima.

Saludos !

dudas
 

No entiendo en esta dll, lo del servidor B10 o algo así era. Para que sirve, donde está este servidor, si el servidor se cae o no funciona, como lo levanto para continuar con los envios ...


no se, alguien puede explicar algo al respecto ??

El componente empezo como un aplicacion servidora (aplicacion que recibia mensajes y enviaba las facturas)

Desde hace mucho tiempo se convirtio a una DLL.

Bajate la ultima version, mira la ayuda.txt, ejecuta la excelente demo que lleva y ahi tienes toda la informacion.

slds

Machacando el componente
 

Me he puesto el fin de semana a machacar el componente enviado sucesivamente paquetes de facturas.
Estoy trabajando con el Certificado de Prueba emitido por la aeat : 99999910G PRUEBAS CERTIFICADO .

- Si mando facturas de una en una.... guardando el tiempo especificado no hay problema.
- Si mando paquetes de factura 5-15 , cada dos por tres lar rechaza: "Error Al Enviar(ESOAPHTTPException)-Se requiere un certificado para completar la
autenticación de cliente"
- Si intento mandar más de 100 me las rechaza del tirón con el mismo error anterior.

Ya no se si es el componte, el certificado, o algún fallo mío.
He compilado toda la demo en delphi 10.1 y lo he adaptado para que trabaje sobre una base de datos MYSQL.

Otro tema.
Por un fallo mío ... me acepta con errores un factura: Error 2006- El campo CuotaTotal tiene un valor incorrecto para el valor de los campos CuotaRepercutida y CuotaRecargoEquivalencia suministrados.
Intento enviarla la subsanación y me devuelve: Error 3000 - Registro de facturación duplicado.
¿Como tengo que indicar la subsanación con el componente?

Una pregunta:


El IRPF no va en verifactu, pero si pasas una factura con el total afectado por el IRPF verifactu la acepta con errores. (ya que no cuadra sumando bases)



He leido en el foro, que se debe colocar el total de factura como base imponible + iva y obviar el tema del irpf. de tal forma que el total de factura NO sera el real.



¿es correcto?


Saludos !

Revisa estas FAQs:

https://sede.agenciatributaria.gob.e...00dc381e0aRCRD

https: // sede.agenciatributaria.gob.es/Sede/iva/sistemas-informaticos-facturacion-verifactu/preguntas-frecuentes/registros-facturacion-alta.html?faqId=10da024ac9572910VgnVCM100000dc381e0aRCRD


Creo que puedes hacerlo como dices o incluyendo la retención (opcionalmente) de la forma que explica.


Edito:
Mirando nuestro código veo que lo hacemos así:
En una factura con Retención IRPF, para informar el ImporteTotal de la factura sumamos el importe de la retención, para indicar el importe total con iva de la factura antes de la retención. También al generar el QR.

gracias por la respuesta, pero no soy muy bueno interpretando esas faq de la aeat. Tampoco me aclaro como lo haces, con el ejemplo que has puesto.

Diria que está bien lo que dijiste
Será total de la factura el real sin tener en cuenta la retención del IRPF

En nuestro caso el campo que tenemos de total de factura es cuando ya les has aplicado la retención (se le ha restado el importe de la retención) por lo tanto, para conseguir el valor para informar en el registro de facturación, cogemos ese total y le sumamos el importe de la retención, para obtener el total de la factura sin tener en cuenta esa retención.
Pero cada uno lo tendrá montado a su manera.

Hay que diferenciar con el tema del IRPF, lo que se cobra por la factura y el importe real de la misma:

Una factura normal SIN IRPF coincide el Importe Real con el que se va a cobrar:

Base Imponible + cuota iva = Importe Real, es el que se declara en verifactu

En el caso de una factura normal CON IRPF no coinicden los importes de cobro y el importe real:

Base Imponible + cuota iva - IRPF ( porcentaje aplicado IRPF * Base Imponible ) = Total a cobrar

Base Imponible + cuota iva = Importe real y a declarar en Verifactu.

Nota: El que no pagemos el IRPF o no lo cobremos de una factura es por que, o bien lo ingresamos en hacienda o nos lo deducimos, en ese orden.

gracias a ambos por las respuestas !

En cuanto probemos un poco mas la 4.2 la semana que viene, la publicare, y creo qua estas alturas ya no añadiremos mas funcionalidades mas.

Slds !

ayuda
 

existe alguna forma de validar que el certificado con el que enviamos las facturas es correcto, es decir, está en vigor y todo eso

ayuda
 

Otra cosa, hay alguna manera de validar los NIFs extranjeros y comunitarios antes de dar de alta algún cliente en el sistema de gestión, hacerlo a traves de esta librería. ?

en la demo tienes un ejemplo para validar el nif con la aeat.

en la version 4.3 ademas se añade la validacion del vies para paises de la ue.

Saludos !

en teoria que recuerde, los certificados que se obtienen de almacen, solo se muestran los vigentes.

el usado desde un archivo pfx o p12, ese no se valida antes de usarlo.

saludos

El lunes se publicara la version 4.3, que incorpora bastantes cosas nuevas, y espero cerrar ya el ciclo de novedades, e ir arreglando posibles fallos.

saludos !

esto no es parte del componente, pero por si no lo sabiais, respuesta de la AEAT:

(sobre integridad, inalterabilidad de los datos en sistemas verifactu)

Saludos !

: )

Pus, mira , de un plumazo desaparece la la mitad de cosas a implementar...

version 4.3

(ya enviada para su publicacion en el ftp del foro)

Leed atentamente ayuda.txt y cualquier duda, la posteais:

Excelente el trabajo que están haciendo con esta DLL.

Yo en mi trabajo he propuesto usar esta DLL con Delphi, pero de momento están explorando otra solución.

Quieren hacer un REST webservice donde la aplicación Delphi envia la factura y certificado mediante JSON, y el webservice ya se encargue del resto generando huella, XML, envio a la administracion y devolviendo la respuesta.
Todo esto lo quieren implementar en Phyton que según me han dicho esta muy documentado y hay muchos recursos ya creados.

Veo 2 enfoques diferentes, pero la ventaja que me comentan es que el servicioweb se puede invocar desde varios programas, y la adaptación de los programas mas antiguos puede ser mas rápida.

Yo soy mas de Delphi de toda la vida, y vuestra DLL me gusta mas. Por lo que me surgen dudas.

¿De verdad veis que es una ventaja usar un webservice? ¿Podríamos integrar esta DLL en un webservice en delphi?

A ver que opinais.

Sin salir de delphi, colocas unas cuantas lineas de codigo, envias la factura, recoges la respuesta y la procesas. Sin mas. Ya esta. FIN.

No encuentro la nueva versión en el ftp.

Sólo me salen versiones antiguas.

Podéis compartir el enlace de la nueva versión?.

Muchas gracias