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

[seccion_31]

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 !

[Neftali [Germán.Estévez]]

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

[muli]

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.

[[newtron]]

Empezado por muli

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.

[Neftali [Germán.Estévez]]

Empezado por muli

Gran aporte realizado por Seccion_31,

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.

[jalvar28]

Empezado por seccion_31

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 !

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.

[mqm]

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

[Neftali [Germán.Estévez]]

Empezado por mqm

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.

[gohermo]

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,

[mqm]

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.

[ramherfer]

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

[ramherfer]

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.

[bmfranky]

Empezado por ramherfer

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.

[ramherfer]

Empezado por ramherfer

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

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.

[seccion_31]

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 !

[seccion_31]

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.

[seccion_31]

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 !

[ramherfer]

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.

[seccion_31]

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 !

[ramherfer]

Empezado por seccion_31

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,