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

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

[CarlosMz]

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

[seccion_31]

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

[CarlosMz]

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;

[seccion_31]

¿Sinceramente?

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

ahora mismo esta echo asi.

¿que ventajas tiene un metodo sobre otro?

[NANAUJ1970]

Tengo unas dudas con las librerias.
Estaba usando hasta ahora D6 y acabo de instalar D7 y cuando quiero usar librerias tipo:

System.SysUtils, System.Classes, Soap.Rio, Xml.XMLIntf, Soap.SOAPHTTPClient, Soap.SOAPHTTPTrans etc

me dice que no encuentra el .dcu....

Alguien pude ayudarme por favor diciendome donde se encuentran y como instalarlas

Gracias de antemano

[NANAUJ1970]

Tengo unas dudas con las librerias.
Estaba usando hasta ahora D6 y acabo de instalar D7 y cuando quiero usar librerias tipo:

System.SysUtils, System.Classes, Soap.Rio, Xml.XMLIntf, Soap.SOAPHTTPClient, Soap.SOAPHTTPTrans etc

me dice que no encuentra el .dcu....

Alguien pude ayudarme por favor diciendome donde se encuentran y como instalarlas

Gracias de antemano

[NANAUJ1970]

Tengo unas dudas con las librerias.
Estaba usando hasta ahora D6 y acabo de instalar D7 y cuando quiero usar librerias tipo:

System.SysUtils, System.Classes, Soap.Rio, Xml.XMLIntf, Soap.SOAPHTTPClient, Soap.SOAPHTTPTrans etc

me dice que no encuentra el .dcu....

Alguien pude ayudarme por favor diciendome donde se encuentran y como instalarlas

Gracias de antemano

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

Se ha subido al FTP la versión 2.1 de la DLL.
https://terawiki.clubdelphi.com/Otro...%20Delphi%207/

[seccion_31]

La versión 3.0 incorporara:

Las 1.000 facturas de envío, con descripción de operación completa a 500 dígitos

Un evento para recibir consultas con mas de +1.000 facturas, hasta las 10.000 que puede enviar la AEAT en la primera pagina.

Además de mantener también las primeras 1.000 consultadas como en la actualidad en el array.

Demo mejorada, para mostrar el funcionamiento de los eventos.

Eso si, se restringe en la consulta la descripción de operación a 255 dígitos.

Saludos !

[Galahad]

Hola, buenas tardes.
Estoy intentando compilar el proyecto verifactuformd7 en delphi 12.1 y crea un ejecutable, pero no válido,, aparece el error:

'No se encuentra el punto de entrada del procedimiento setbackgroundcolor en la biblioteca de vinculos dinamicos verifactuformd7.exe'

es compatible el proyecto con delphi 12.1 ¿?