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

[seccion_31]

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)

Buenos días:

En un sistema informático de facturación (SIF) que actúa en la modalidad VERI*FACTU, como el que cita, la integridad, inalterabilidad, conservación, accesibilidad y legibilidad se dan por garantizadas en cuanto se remite correctamente el registro de facturación (RF) a la AEAT. Por lo tanto, después ya "no importaría" que esos RF pudieran ser manipulados por otras aplicaciones y no habría obligación de hacer nada más (incluso podrían dejar de conservarse en el SIF, si así se desea). De hecho, los SIF VERI*FACTU no tienen obligación de detectar este tipo de anomalías.

Saludos !

: )

[bmfranky]

Empezado por seccion_31

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

[seccion_31]

version 4.3

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

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

version 4.3
----------------------------------------------------------------------------------------------------------------------------
valida el VIES, ademas del NIF. Para validar el VIES no es necesario un certificado.
Al añadir factura se comprueba que haya desgloses (de exenta o iva) en altas. Debe de haber al menos un desglose, aunque sea a cero.

version 4.2
----------------------------------------------------------------------------------------------------------------------------
corregidos encadenamientos, con facturas reenviadas y nuevas
corregidos tiempo 2 de minutos con facturas reeenviadas para marcar incidencia automaticamente al igualar o superar ese tiempo de reenvio.

version 4.1
----------------------------------------------------------------------------------------------------------------------------
se suprime soloRegistroAceptadas: boolean y pasan a guardarse todos los registros de facturacion, aceptados o no aceptados o incluso de envios fallidos.

a cambio se facilita el nombre del xml ya que si el sistema genera otro registro de facturacion existente por numserie, añadira _1 , _2 etc... al nombre del archivo para conservar todos los registros en la carpeta de ese numserie.

En el resultado (fallido o no) se envia el nombre (solo el nombre del archivo) dentro de la ruta programada en pathXML_RegistroFacturacion en TVeriFactu
en la variable: filenameXMLRegistro del resultado. Esto nos facilita archivar y encontrar el xml generado para una factura concreta.

En el evento del resultado (fallido o no) podremos acceder al nombre del archivo COMPLETO del xml con su ruta a traves del STATUS de cada factura remitida.Tambien recibiremos el XML via parametro.

AHORA:
cuando el envio no puede ser realizado, por fallos tecnicos de la AEAT o internet, etc... se devuelve "un resultado informativo" de la sesion fallida, donde se podran recoger las huellas y el error ocurrido:

resultado.errorDes

envioOk sera false
AceptadasOK :=0;
AceptadasError :=0;
ConErrores :=0;

cada factura del array de resultado contendra al menos los siguiente datos para indicar el error de transmision

facturas[n].ErrorCodigo:=-1;
facturas[n].error:=true;
facturas[n].aceptadoConErrores:=false;

ademas de las huellas y otros datos.

En resultado:

envioOK sera true cuando se haya podido enviar, por tanto los datos que regresen seran de la AEAT

envioOk sera false:

Cuando el envio NO puede ser realizado se guardan los registros de facturacion, exactamente de la misma forma que si hubieran sido aceptados, pero con algunos cambios como hemos visto arriba.

Todos los eventos tienen lugar con normalidad.

El evento que genera las huelllas a medida de calculo, no sabe si la transmision sera posible, por tanto genera las huellas sin mas
El evento que genera los registros de facturacion, ya conoce si el evento es (fallido o no) y se envia envioOK ademas del indice de la factura, el registro de facturacion (XML) y otros parametros.

El evento resultado ya conoce si ha sido fallido. el Componente TVerifactu devuelve false y resultado.envioOK devuelve false.
Las diferencias a cuanto a que encontraremos en el resultado devuelto dependen de si ha sido fallido o no.



version 4.0
----------------------------------------------------------------------------------------------------------------------------
Volvemos a las 10 sesiones

Vista la nueva informacion sobre encadenamientos hay que cambiar la forma en que se envian.

Explicaremos como se hacia, y despues como se hara desde la 4.0

Version 3 y anteriores:
Cuando se envia un registro SIEMPRE se calculaba una nueva huella:

Si la factura es nueva, no hay problema, huella nueva
Si se vuelve a enviar por error de datos de facturacion, un nif equivocado o algo asi, no hay problema, huella nueva
Si se vuelve a enviar por un error tecnico, fallo de internet, del equipo, (sin respuesta de la AEAT) etc... y el registro en principio es valido. HAY PROBLEMA, no deberiamos calcular una nueva huella deberiamos enviar la factura con la huella y encadenamiento originales. Y marcar como incidencia. Respetando el encadenamiento de la ultima factura añadida, para las siguientes. (eso ya pertences a la logica del programa).

La version 4 soluciona este problema
Se añaden tres campos en el registro de factura:

numeroSerieAnt[60]
huellaAnterior[64]
huellaFechaAnt[20]

estos tres campos junto a estos ya existentes:

huella[64]
huellaFechaHora[20]

Seran los que nos permitiran reenviar una factura fallida por fallo tecnico.

El Envio de una factura nueva, o factura modificada, huella nueva, por tanto no hay que indicar nada en estos valores

En el Re-Envio de una factura por fallo tecnico, hay que indicar esos valores, ya que tenemos un registro valido.

Por tanto siempre debemos guardar estos datos.

¿Como guardarlos?

Tras el envio y ocurra lo que ocurra, estan disponibles en el registro de factura:

Ejemplo: (sin el evento para recoger huellas) (ha sido escrito sin compilar, de memoria y es una aproximacion propia)

iniciamos sesion, cargamos datos , etc...

veriFactu.clearFactura( factura );
........
........
........ cargamos datos de la factura, cuotas, cif, totales, etc...
........
........ y añadimos:

// si hubo un fallo tecnico en la factura (ver mas abajo) tras el envio llevara marcado esto:
if dbFactura.feldbyName('fallotecnico').text='S' then
begin
factura.huella :=dbFactura.fieldbyName('huella').text; // cargamos la huella y anterior original
factura.huellafecha:=dbFactura.fieldbyName('Huellafecha').text; // debe contener espacio suficiente para la fecha y hora (string(20))

factura.numeroSerieAnt:=dbFactura.fieldbyname('antnumero').text;
factura.huellaFechaAnt:=dbFactura.fieldbyname('antfecha').text;
factura.huellaAnterior:=dbFactura.fieldbyname('anthuella').text;
end;

ok:=Verifactu.envio( resultado ); // enviamos

Verifactu.factura(1, factura); // seleccionamos la 1ª factura (puede ser un envio de 1)

dbFactura.edit; // la guardamos en la bd. (el registro de la bd. ya esta posicionada en ese registro)

dbFactura.fieldbyName('huella').text :=factura.huella; // 64 digitos
dbFactura.fieldbyName('Huellafecha').text:=factura.huellaFechaHora; // este campo deberia ser de 20 digitos. (contendra fecha y hora)

dbFactura.fieldbyname('antnumero').text :=factura.numeroSerieAnt;
dbFactura.fieldbyname('antfecha').text :=factura.huellaFechaAnt; // fecha
dbFactura.fieldbyname('anthuella').text :=factura.huellaAnterior; // 64 digitos

if not resultado.envioOk then // el envio ha sido fallido por causas tecnicas ( ha salido por el try... except )
begin
dbFactura.fieldbyname('fallotecnico').text:='S'; // lo indicamos en la factura

dbIncidencias.insert; // lo anotamos en el libro de incidencias (opcional)
dbIncidencias.fieldbyName('fecha').asdatetime:=time;
dbIncidencias.fieldbyName('hora').text :=timetostr(time);
dbIncidencias.fieldbyName('factura').text :=factura.numSerieFactura;
dbIncidencias.fieldbyName('texto').text :=resultado.error;
dbIncidencias.post;
end
else
dbFactura.fieldbyname('fallotecnico').text:='N'; // limpiamos esto si paso bien

dbFactura.post;

Y ahora procesariamos mas cosas....

Con esto ya tendriamos las huellas disponibles, y mas informacion si añadimos un bucle etc... podemos intervenir todas las facturas enviadas


Mas tarde podriamos volver a enviar la factura, y al haber sido marcada como fallotecnico se cargaran las huellas originales y no se generaran nuevas.


Nuevo: evento para recoger huellas

Sin esperar al resultado del envio:

El evento: onRegHue proporciona las huellas a medida que se va calculando el objeto SOAP antes de enviar, factura por factura.
Nos enviara la siguiente informacion:


TRegistroHueEvent = procedure( Sender: TObject; resultadoHuella:THuellaCallBack ) of object;

THuellaCallback=record
nifEmisor :string[9];
numserie :string[60];
FechaFactura :TDatetime;
TipoFactura :string[2]; ( F1 F2 etc... ó "B" si anulacion )
alta_baja :string[1]; (A o B)

Cuotatotal :currency;
ImporteTotal :currency;

Huella :string[64];
huellaFechaHora :string[20]; // guardaremos en un campo timestamp o de 20 digitos fecha y hora

numeroSerieAnt :string[60];
huellaAnterior :string[64];
huellaFechaAnt :string[20];

huellaSinCodificar:TMyString; // solo en altas o bajas ( no en reenvios con huella anterior)

indice :integer;
incidencia :boolean;
end;

Permitiendonos guardar esta informacion antes de su envio. (eso si, tenemos que llamar a la funcion enviar)



----------- enviamos la factura -------------------

Y procesamos resultado.

Y podria volver con algun fallo de nif, etc... pero al reenviar ya lo hariamos con huella nueva.

[ontisoft]

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.

[seccion_31]

Empezado por ontisoft

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.

[starlet]

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

[ramherfer]

Empezado por starlet

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

La versión 4.3 tampoco la veo para descargar.

La última que está es la versión 3 con fecha 08/04/2025 y creo que no es la última.

Un saludo

[rafa1963]

Buenas tardes compañero ramherfer, he estado buscando el el FTP del club la versión 4.3 del proyecto y no consigo localizar ni la 3. Me puede indicar como poder acceder a ellas ????.

Gracias.

[seccion_31]

Empezado por rafa1963

Buenas tardes compañero ramherfer, he estado buscando el el FTP del club la versión 4.3 del proyecto y no consigo localizar ni la 3. Me puede indicar como poder acceder a ellas ????.

Gracias.

la veo publicada aqui

Con fecha 30 de abril.

slds

[rafa1963]

Gracias ya la tengo descargada y funcionando.
Como siempre agradeceros vuestra dedicación y apoyo.

Gracias.

[ramherfer]

Empezado por starlet

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

Yo tampoco la encuentro.

La útima que hay en el ftp es la 3 de fecha 08/04/2025.

Por lo que creo que no es la última.
Un saludo

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

Ya está actualizada la versión 4.3 en el FTP
https://terawiki.clubdelphi.com/Otro...%20Delphi%207/
(perdonad la demora)

[jguso]

Tengo un problema con facturas periódicas de mantenimiento.



Si al aplicar verifactu, las fechas de facturación se suponen que deben de ser las de la fecha actual, entonces como hacemos para la facturación periódica, alguien ha resuelto este tema. ¿ como ?.

[seccion_31]

Empezado por jguso

Tengo un problema con facturas periódicas de mantenimiento.



Si al aplicar verifactu, las fechas de facturación se suponen que deben de ser las de la fecha actual, entonces como hacemos para la facturación periódica, alguien ha resuelto este tema. ¿ como ?.

Explicate mejor porque no entiendo el problema

Una cosa es el periodo facturado y otra la fecha de emisión. Supongo que hasta ahí todos de acuerdo.

Pero como digo no lo entiendo