Demo con código Verifactu.dll para (delphi 7)
 

He actualizado la demo para enviar y procesar registros

Enviar registros desde Excel
Prmite obtener el codigo QR
Validar la respuesta
Validar el QR

https://github.com/seccion31/verifactu-delphi-demo

Saludos !

Gracias por en código.
He "fijado" el hilo al inicio del foro.
Actualizo el mensaje#2 con la recopilación de códigos y subo también el ejemplo al FTP del club (v2).

Gracias a DEMO DE ENVIOS
 

Gran aporte realizado por Seccion_31, y gran idea de Germán de crear un tema especifico para estos aportes, justamente había estado estudiando el anterior aporte de Seccion_31 durante el fin de semana, y ahora me encuentro con estas mejoras, vamos a seguir estudiando, es más ameno leer tu codigo fuente que los manuales de la agencia tributaria, he leido también por ahí el tema de los tiempos de envios, o sea, en un bar que hay momentos que se generan tickets cada dos por tres y desde varios puestos, me pregunto se podrían seleccionar todos las ventas en un tiempo, digamos una hora, y enviarlos todos juntos, tal y como se puede hacer en la propuesta de Seccion_31, es una idea, se van generando las huellas de todos los registros y una vez cada hora por ejemplo, se hace una búsqueda de todas las ventas y venga hacia la agencia tributaria, el problema lo tenemos en los códigos QR, que no tenemos las respuestas.

Saludos. Y Gracias a todos por vuestros aportes.

Hay que hacer los envíos según se van generando los documentos si no quieres tener problemas, eso creo que ya lo tenemos claro.


saludos.

Al igual, que una pregunta nueva requiere un hilo nuevo, lo normal es que si vamos a hacer referencia a un hilo ya creado, continuemos con ese hilo.
Junto este con el original de [Seccion_31] sobre su aporte.

Error en la demo
 

Buenos días.

Estoy probando el programa en windows pero me da siempre un error. Al importar el excel de ejemplo y cuando hago cualquier acción me dice 'Field Total not found'.

Me pasa con cualquier excel que importe.

Adjunto imagen.

Has encontrado la solución?. Llevo dos días con el mismo problema.

Escríbele un privado a [seccion_31] explicándole el problema. Tal vez no ha visto el mensaje.

Error
 

Buenos días compañeros!!! Saben si ya han solucionado el problema del programa demo? A mí me da el mismo error que al compañero.

Saludos,

Después de 4 días peleándome con el, lo he solucionado instalando la version 10.1 berlin. Ahí no da problema ninguno.
Pero ahora me he dado cuenta de que si eliminas el fichero ...\Win32\Debug\facturas.xml, con delphi 11, ya tampoco te da error.

Si es borrar el fichero facturas.xml que viene con la demo y el problema creo recordar queda resuelto compañero.

Buenos días. Estoy probando el ejecutable y si la empesa que envía es un NIF (de un autónomo) por ejemplo se produce un error y la AEAT no admite los registros. Si es un CIF de empresa los registros son admitidos obteniendo la respuesta y siendo correcto el cotejamiento y obtención del QR.
Alguien sabria decirme por que ocurre esto.
Por otro lado no veo ningún ejemplo para la comunicación de facturas sustitutivas/rectificativas ¿puede el sistema hacer el envío de este tipo de facturas?
Estoy estudiando el código para tratar de entenderlo y aplicarlo a mi aplicación.
Otra duda que me surge es si la WSDL URL del endpoint es de pruebas, ya que he realizado algún envío con éxito y no me gustaría que no fuera de pruebas y como tienen poco sentido levantar las orejas de la AEAT.

Hola, buenos dias, de momento , los unicos endpoint disponibles , son los de pruebas, y ni siquiera estan disponibles todos, pueto que ahun faltan los endpoint de requerimiento.
En segundo lugar para poder saber que le falla, necesitamos saber, los datos que envia y la respuesta completa del servidor de la aeat, para poder orientarle al respecto.

Me autorespondo a parte de mis preguntas pidiendo disculpas. Era una tontería y que al hacer la pregunta me di cuenta ¡joroba!. Al poner el nombre y apellidos en el Obligado Tributario (OT) en lugar de apellidos y nombre puse nombre y apellidos. Nada más cambiarlo me acepto las facturas.

siento ver este hilo

como con la anterior publicacion nadie hizo mucho caso no he vuelto a aparecer por el foro hasta hoy.

voy a ver lo que comentais

saludos !

simplemente hay que borrar este XML:

Facturas.xml

que esta en win32\debug

el programa lo creara correctamente con el campo 'total' que le falta.

saludos

Pero ahora da otro error de respuesta de la AEAT que no se si es por culpa de mis datos de ejemplo.

Eliminando el win32\debug\facturas.xml

y colocando los datos de emision, etc... en la ultima pestaña funciona perfecto para lo que se propone en la demo.

(ya he eliminado el archivo de github)

desde hace 1 semana estoy portando el ejemplo para mi implementación real y ha sido sencillo adaptarlo.

Saludos !

Pues mi opinión personal, es simplemente que esta demo es oro.
Yo estoy dudando si adaptar la aplicación o dejarla. Mi pensamiento es que es una responsabilidad enorme para un desarrollador y que ante cualquier fallo, problema, llamese como uno quiera puede costar la torta un pan. Es una gran duda que tengo.
Tambien tengo muy claro, que si intento adaptar mi maldita aplicación por supuesto que la basaré en esta gran demo.
La verdad, no se si me atreveré o no.
Personalmente seccion_31 te doy las gracias por este gran aporte, tanto si doy el paso, como si no lo doy. No se si seré capaz de integrarlo con mi aplicación.

gracias por tus palabras ramherfer !

me alegra saber que es de utilidad.

voy a comentar algo propio: (que cada caso de implementacion es distinto)

A mi el tema del verifactu me pilla un poco de refilon, ya he implementado una version muy limitada del mismo, funcional.

Facturas F1 F2 - R4 R5 positivo - negativo (x diferencias) y listo. NO tengo usuarios que vayan a exigir mucho mas.

Lo que me causa mucha inquietud, es que no haya un portal donde verificar que la informacion que estas enviando coincide con la que tienes en tu gestion (como tiene el SII). La verificacion atraves del codigo QR me parece muy endeble. NO dice nada.

Tampoco entiendo ese interes en hacer la factura y enviarla en "directo", pienso que puedes entrar a facturar, hacerte tus 15 o 20 facturas (1 hora de trabajo) (tipo cliente que tengo), acceder al programa y enviarlas todas o enviar 1 a 1 en manual, sin mas. (otro tema pueden ser los tickets).

Asi mismo, seguimos esperando ese programa de la AEAT para quienes "facturen poco", quizas permita una importacion de registros de alguna manera.

Para finalizar, me gustaria desarrollar un componente no visual que mediante eventos solicite los datos genere el XML, aislandolo de la parte que todos tenemos diferente que es la base de datos, que es un poco lo que plantea la demo. Pero para cubrir mas casos necesitaria ayuda. En realidad TODOS aqui estamos repitiendo una y otra vez el mismo trabajo.


Saludos !

Y tanto que es de utilidad, yo si lo implemento será basandome en tu codigo de principio a fin.

Yo llevo mucho tiempo con el tema de verifactu, pero en su día consideré que si era todo borradores para que empezar y cambiar una y otra vez lo hecho (gran error) ahora me pilla con muy poca posibilidad de que pueda cumplir los tiempos.

Referente a tu inquietud, cuando se den cuenta de lo endeble que es la comprobación ya se encargaran de darle una vuelta de tuerca y complicarnos más la vida.

El interés de enviar una factura o grupo de facturas directamente nada más confeccionarlas, entiendo que es no dejar espacios de tiempo para hacer una ñapa y engañarlos. Pero ya te digo que de una u otra forma siempre hay alguien que encuentra el modo. Pero bueno si hay que enviarlas se envian y uno descansa de responsabilidades.
Yo mi tipo de cliente me ocurre lo mismo que a ti, son talleres de automoción, imprentas y algún recambista de automoción. Suelen hacer muy pocas facturas al día y alguno hace la facturación del mes y con el tipo de facturas que has indicado, poco mas. Y ese interés que tienen en todo es que muchas empresas de desarrollo como la mia, si no desaparecen será un milagro divino, despues de 35 años de trabajo honrrado, entregando a los clientes una herramienta sencilla y al mismo tiempo potente, sin ningún ánimo de que con ella se engañe a hacienda, todo lo contrario.

Sobre el esperado tema, ya te anticipo que esa aplicación de la AEAT lo que no llevará será ninguna importación ya que considero que va contra el principio VERIFACTU.

Ese componente que comentas, eso sería la leche. Yo por ejemplo estoy utilizando Delphi 7 y me las voy a ver y desear para poder codificar en el todos los procesos, teniendo que acudir a codigo externo en Delphi 10 para que pueda hacer todo lo que va a hacer y con ese componente me facilitaría migraciones posteriores a Delphi 10 de toda mi aplicación, cosa que tiempo material ahora no tengo.

Ya construí una dll que permitia generar el maldito codigo de encadenamiento en sha256 y pienso lo mismo que tu, miles de programadores haciendo el mismo trabajo y para el mismo fin, en lugar de entre todos facilitarnos la solución con componentes y dll's e implementarla luego en nuestras aplicaciones. Somo todos tan listos que acabamos siendo burros de carga. En fin, entiendo que cada uno mire por su propio beneficio y su aplicación, pero esto hubiese sido sencillo, sencillo de hacer, pero si una comunidad como esta no ha sido capaz de organizarlo así, es que no somos tan inteligentes.
Si decides empezar y yo te puedo ayudar, nos organizamos y nos ponemos manos a la obra. mis conocimientos en este tipo de procesos es muy limitado (mi gran problema) pero seguro que en algo te podría ayudar ante la problemática.

Gracias de nuevo por tu aporte, no me cansaré de dartelas y estoy convencido que muchos igual que yo, pero al ser humano parece ser que le cuesta mucho agradecer y hacerlo público.

Un saludo,

Interesante el proyecto, muchas gracias por este aporte seccion_31

La parte que falta sería el tema de qué hacer con cada respuesta de la AEAT como códigos de error...

procesar los codigos de error,

bueno, eso esta mas o menos en el codigo, en la funcion que procesa el envio.

anuncio que tengo previsto hacer otra demo (quizas la ultima), espero poder llegar al final, porque creo que ese codigo lo voy a usar. (sino tendre que tirar un monton de codigo)

se podra enviar facturas desde delphi 7, mediante un componente no visual, le das los datos de la factura, y recibes la respuesta.

soportara facturas, tickets, alta, rectificacion por diferencia, anulacion, exportacion...

En principio podras hacer una factura con D7 y enviarla a la AET sin mas.

Saludos

Buenas noticias, no sería más sencillo encapsularlo en una clase ?

Una pregunta ¿por qué usas capicom ? no es más sencillo cargar desde un fichero el certificado:

Código Delphi [-]
procedure TMain.HTTPRIO1HTTPWebNode1BeforePost(const HTTPReqResp: THTTPReqResp;
  Client: THTTPClient);
var
   CertStream: TMemoryStream;
begin
     CertStream := TMemoryStream.Create;
     CertStream.LoadFromFile('file.pfx');
     HTTPReqResp.ClientCertificate.Stream := CertStream;
     HTTPReqResp.ClientCertificate.Password := 'password';

end;

¿Sinceramente?

porque no tengo mucha idea, y se hacerlo asi. XD

ahora mismo esta echo asi.

¿que ventajas tiene un metodo sobre otro?

xD, pues como ventajas, a simple vista, que no hay necesidad de instalar el certificado,
se puede cargar directamente desde un fichero o stream, y simplifica el código reduciendo dependencias

uummmm...

voy a ver que hago finalmente, de momento publico este componente asi y luego se puede incoporar.

gracias por el extracto de codigo.

El que se pueda enviar una factura desde D7 para mi no es sencillo. la unidad de la AEAT no compila, y el httprio tampoco funciona.

Interaccionar con una DLL en berlin tampoco he podido porque el httprio da un error de proteccion al enviar.

He descartado el DDE

Al final he usado mensajes definidos por el usuario para comunicar con una aplicacion (D10) que se queda residente y va recibiendo las facturas, ordenes de envio y comunica el resultado.
Los datos se transmiten en dos direcciones atraves de funciones "filemapping".

Funcionar, funciona, y enviar una factura es muy simple. En caso de fallo solo haria falta cambiar la aplicacion residente o servidor, que incopora un sistema de log que te va diciendo lo que hace.

mas o menos quedara asi:

voy a intentar hacer que admita un nombre de certificado o nombre de fichero.pfx en el certificado para tener las dos opciones.

Tiene buena pinta, creo que ¿habría que agregarle un control de flujo según los errores recibidos por parte de la AEAT?

buenos dias !

el servidor de mensajes en B10 funciona
el componente en D7 funciona
la demo que envía una excel D7 funciona


Hay un componente en D7 que crea una sesion en el servidor B10
El componente D7 recoge los datos de la facturas y las envia al servidor B10
El componente D7 da orden de envio al servidor B10
El servidor B10 devuelve el resultado del envio al componente D7

Este es un trozo de código del ejemplo de la anterior demo programada en B10, AHORA reprogramada con el nuevo componente para D7

Código en D7 que hace uso del componente:




Hay varios temas preliminares

Faltan mejorar y afinar algunos temas

¿hay alguien interesado en usarlo?

Para publicarlo, necesito alguien que entienda BIEN la composicion de los mensajes de la AEAT segun cada tipo de factura para componerlo con la informacion basica de una factura y se encargue de ello.
El resto de la logica de envio y recepcion como digo ya funciona.

Seria tomar la funcion que hace la carga del objeto de la AEAT e indicarle los datos segun la factura suministrada.

Ahi dejo este mensaje, a ver si alguien se anima.

Yo estoy interesado, aunque tampoco tengo mucha idea en este tipo de procesos.
Toda mi aplicación está programada en D7. Y tengo un problemón de narices. Ya que tiempo material para recodificar todo es imposible.
Ya comenté que en lo que pueda ayudar y echar un cable, intento hacer lo que medigas.
Tambien me gustaría tener más claro la metodología de uso del componente para no tener fallos a la hora de su uso y que todo vaya como la seda.
Sigo sin entender porque no se trabajó en los foros orientado en este sentido. Muchos tendríamos la solución con un poquito de aporte de todos.

Yo podría echar una mano para convertir el código a delphi 12, intentando minimizar dependencias y encapsulando todo el código en una clase para evitar el uso de componentes no "nativos"




Hay varios temas preliminares

Faltan mejorar y afinar algunos temas

¿hay alguien interesado en usarlo?

Para publicarlo, necesito alguien que entienda BIEN la composicion de los mensajes de la AEAT segun cada tipo de factura para componerlo con la informacion basica de una factura y se encargue de ello.
El resto de la logica de envio y recepcion como digo ya funciona.

Seria tomar la funcion que hace la carga del objeto de la AEAT e indicarle los datos segun la factura suministrada.

Ahi dejo este mensaje, a ver si alguien se anima.[/quote]

¿De donde puedo descargar el componente D7 para intentar integrarlo y poder hacer pruebas?
¿cual sería el path para ubicar el servidor B10?
Ya tengo los datos del sistema informático emisor implementados en la ficha de empresa y me faltaría desde donde emito las ordenes de envío y recojo las respuestas, que, imagino sería desde un grid de facturas emitidas gestionando las pendientes de envío.
Soy un mar de dudas para empezar las pruebas

Primero de nada, agradecer a "seccion_31" por la grandísima aportación que ha tenido para con este foro, al brindarnos la posibilidad de usar el código facilitado.
Yo personalmente lo he adaptado para, desde Delphi 10, hace una aplicación en segundo plano que se conecta a la base de datos MYSQL y va enviando la facturas
simplificadas y ordinarias que se van generando en una aplicación en delphi 7.
Estoy intentando desarrollarlo tanto para una application con MYSQL/MariaDB y otra con ficheros DBF de paradox.
De momento consigo enviar con tu código y capturar la respuesta de la AEAT. Ahora estoy esperando a ver como actuar ante las repuestas de la AEAT.
Si en algo puedo ayudar... aquí me tenéis.

Si pudieras enviar algo de codigo de esa aplicación que funciona en segundo plano para poder ver como estableces las conexiones entre el servidor B10 y tu base de datos, estaría genial y me ayudaría posiblemente a entender un poco más. Mi aplicación tambien funciona en Delphi 7 y uso tablas paradox db y voy perdido, no, lo siguiente

Simplemente hago uso de los componentes de Devart unidac. Los demás es adaptar el ejemplo a mis tables, es fácil no te lleva mucho tiempo adaptarlos. Simplemente en vez de la rejilla del excell a enviar, tengo dos grid con las facturas simplificadas y las ordinarias, y para "envioFacturas" me he creado una tabla donde en lugar de un excell , voy guardando todos los registros que voy enviando.
Termino de depurar un poco y te paso el proyecto por si te ayuda.
En mi caso para mis aplicaciones, es solo añadir 4 campos a las tablas y crear la tabla de envíos.

Claro que me serviria de ayuda, lo cual agradecdería. Cualquier codigo que vea su planteamiento me serviría y mucho para ir entendiendo.

Hola !

El componente desde Delphi 7 ya envia y devuelve la respuesta. Ya es operativo en la DEMO que importaba de una hoja de calculo, compilada con D7.

En este otro ejemplo de codigo de delphi 7 se procesa la respuesta tras un envio:



En teoria, sube factura, tickets, rectificativas, comunitarias, y exportación. (hasta 1.000 facturas x envio) Pero lamentablemente ahora mismo no se bien como cubrir el resto de casos.

Genera el QR

Ya esta implementado el cotejo contra la AEAT con el nuevo objeto de consulta: tan simple como llamar a una funcion desde DELPHI 7 y se devuelve un array con los resultados:



Lo voy a incoporar en una aplicacion real que espero empiece a ser probada en un entorno real de facturacion al inicio de año enviandolas a pre-produccion, e imprimiendo el codigo QR real sobre la factura, como demo. Pero todo muy real.

Pero claro, me doy cuenta de la responsabilidad que adquiero una vez publicado, esto NO es una demo.

Permite hacer todo el trabajo desde Delphi 7 con el apoyo de la aplicacion servidora, y desde la version 10 en adelante, puede usarse como una unidad, sin mas con un uses.

En unas semanas una vez probado veo que hacer.

Yo sigo implementado tu demo inicial.
Pero.. que hacer en caso de que no tengamos respuesta de la aeat?
Para mi es fácil la implementation. Son pequeña tiendas... facturo envio y en caso de equivocación mando una en negativo. Ni permito borrado ni anulación.
Pero me he encontrado con 2-3 casos en mis pruebas, que la aeat no responde nada ... y posteriormente he visto que las facturas enviadas estaban recogidas.
Con lo fácil que seria una consulta a la aeat, para saber cual es la ultima factura enviada/grabada y aceptada.

Sinceramente..... me estoy planteando dejar todo esto. Hablando claro.... esto es una puñetera mierda que no hay dios que la entienda. Si quieren controlar... les mandamos la caja del día al finalizar la jornada y listo. Tengo algunos clientes de 50 y pico de años que dicen que cierran el negocio.
Amen de las XXX empresas en la web que te ofrecen el kit, y la solución milagrosa para tu software, y muchas ponen que homologadas por hacienda. Quc homologación ni leches..... En manos de que o quienes estamos.

buenos dias

yo siempre he encontrado respuesta de la aeat. es mas: lo normal es archivarla.

Creo y digo creo (porque tengo que comprobarlo) que cuando en una lista de facturas hay una erronea importa hasta ahi, ignorando el resto que va detras.

ahora el tema es mas sencillo, con la consulta que se puede obtener, puedes interrogar con el objeto de consulta y ver que facturas estan subidas, tambien podras consultarlas en un portal como se hace con el SII. Eso da mucha seguridad.

Despues de mi experiencia con el SII: los primeros dias habra millones de registros subidos, cientos de miles con posibles errores y poco a poco ira la cosa a mejor. No es para tanto, creo que hay que confiar mas en nuestras capacidades y en la sensatez. Con el SII pensaba que seria terrible y no ha sido para tanto.

Ahora bien: sigo sin entender porque con el SII para una empresa que factura 20 millones al año, por ejemplo puedas enviar tus facturas de miles de euros en 4 dias habiles y en verifactu una factura de 10 euros deba ser enviada al instante, obligando a mantener una infraestructura, programa, etc... 24/7 en perfecto funcionamiento. Para mi es incomprensible.

Saludos !