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

[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,