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

[delphiGar]

Empezado por seccion_31

efectivamente, ya esta funcionando. gracias !!

tengo que comprobar los encadenamientos, pero ya esta. Cuando actualice el componente, ya se podra hacer asi.

slds !

Me gustaria facilitar estos encadenamientos en el componente, pero todavia no tengo claro si es muy seguro y factible.

Deberias crearte una tabla o algun tipo de fichero donde guardar los datos de ultimo registro generado, en cuanto a los campos IDEMISOR, NUMSERIEFACTURA, FECHAEXPEDICION Y HUELLAANTERIOR, y de esta forma siempre que generes el registro nuevo obtienes los datos de este y al mismo tiempo guardas los del Nuevo en esta misma tabla o fichero, puedes tener en la tabla o fichero un solo registro con estos datos, si inicialmente no hay ninguno, no existe registro anterior, y por lo tanto el registro anterior sera igual a Primerregistro=S e insertas los nuevos, si por el contrario existe el registro coges esos datos y editas para poner los nuevos.

[seccion_31]

ahora me doy cuenta que no necesito el registro anterior en el array de facturas

solo necesitaria el registro inicial como huella anterior del primer registro del array (o ninguno si es primer envio) del paquete de envio.

el array va ordenado cronologicamente (por orden de llegada) y el registro anterior, esta simplemente en j-1

al termino se guarda la ultima, que sera la inicial del siguiente paquete de envio. Y listo. Teniendo en cuenta su estado por subsanacion y rechazoprevio.

[seccion_31]

la DLL ya esta modificada

No se cuantos estais utilizando el componente pero este fin de semana publicare la version 2.

Ya no hara falta el registro anterior, y habra que incluir el registroInicial con el primer encadenamiento del envio.

agradecer a los usuarios que me informaron del funcionamiento del encadenamiento, con ese conocimiento aportado he modificado el componente.

Ya detallare mas los cambios una vez se publique.

slds !

[Pedro9999]

Empezado por seccion_31

la DLL ya esta modificada

No se cuantos estais utilizando el componente pero este fin de semana publicare la version 2.

Ya no hara falta el registro anterior, y habra que incluir el registroInicial con el primer encadenamiento del envio.

agradecer a los usuarios que me informaron del funcionamiento del encadenamiento, con ese conocimiento aportado he modificado el componente.

Ya detallare mas los cambios una vez se publique.

slds !

Felicidades por tu gran aporte!!!

[starlet]

Otro más que aterriza por aquí.

Me he enterado tarde de este proyecto que puede ser un "salva vidas" literal para mucha gente, entre los que me incluyo.

Cuanto tiempo me habría ahorrado si me hubiese enterado antes..

Mil gracias a seccion_31!!!!

Estoy analizando todo. Pero al intentar la demo, no hace nada, compila sin errores, pero no muestra formulario. Se cierra automáticamente.

Estoy haciendo algo mal?. Evidentemente se me escapa algo, pq al resto de la gente le funciona.

Versión Delphi 10.1 y 11.3

Gracias,

[mqm]

Empezado por starlet

Otro más que aterriza por aquí.

Me he enterado tarde de este proyecto que puede ser un "salva vidas" literal para mucha gente, entre los que me incluyo.

Cuanto tiempo me habría ahorrado si me hubiese enterado antes..

Mil gracias a seccion_31!!!!

Estoy analizando todo. Pero al intentar la demo, no hace nada, compila sin errores, pero no muestra formulario. Se cierra automáticamente.

Estoy haciendo algo mal?. Evidentemente se me escapa algo, pq al resto de la gente le funciona.

Versión Delphi 10.1 y 11.3

Gracias,

El formulario principal tiene visible = false
Ponlo a true

[seccion_31]

Empezado por mqm

El formulario principal tiene visible = false
Ponlo a true

gracias

que horror, se debio quedar a false en algun momento y como en D7 se abre sin problema ni cuenta me di.

gracias por todos los apoyos, y gracias a los que habeis contribuido, porque hemos pasado por varias fases:

al principio era un servidor de mensajes, que luego gracias a darkdudae y su aviso, paso a ser DLL, que parece mas profesional
a los usuarios del foro que han contribuido para aislar el xml del registro y poder archivarlo, cosa que no tenia ni idea
y finalmente el tema de comprender el encadenamiento que estaba muy equivocado.

fallos, no se si saldran muchos mas, ahora, tampoco se si falta alguna caracteristica clave como las dos ultimas mencionadas arriba.

Un saludo a todos, y me alegro de que este sirviendo para su fin.

[ramherfer]

Hola buenos días.
¿Teneis algún mecanismo para que antes de realizar un envío comprobar si el servicio de la AEAT se encuentra activo o no?.

creo que VeriFactuD7.final( LogFile ) No me está creando el fichero log

Un saludo,

[seccion_31]

Empezado por ramherfer

Hola buenos días.
¿Teneis algún mecanismo para que antes de realizar un envío comprobar si el servicio de la AEAT se encuentra activo o no?.

Un saludo,

Podrías hacer una consulta simple

[seccion_31]

Empezado por ramherfer

Hola buenos días.
¿Teneis algún mecanismo para que antes de realizar un envío comprobar si el servicio de la AEAT se encuentra activo o no?.

creo que VeriFactuD7.final( LogFile ) No me está creando el fichero log

Un saludo,

Con la DLL el log quedo obsoleto

[starlet]

Empezado por mqm

El formulario principal tiene visible = false
Ponlo a true

Lo primero, pedir disculpas, por la repetición de mensajes. Juro que al postear el mensaje me daba error, y no se publicaba, y hoy, aparecen de golpe varias repeticiones del mismo mensaje.

Pido a los moderadores, que sólo dejen uno. Gracias

Respecto a visible = false en el form principal, sí, ya lo había visto y por supuesto lo he puesto a true, pero sigue exactamente igual. Y como digo lo he probado con 2 versiones diferentes de Delphi.

Evidentemente, asumo que es un error de mi equipo, pero no tengo ni idea de qué puede ser, porque desarrollo en este equipo sin ningún problema desde hace varios años.

Reitero mi agradecimiento a seccion_31 y a todos los que habéis contribuido en este proyecto y desde ahora en lo que pueda, intentaré ayudar igualmente.

[seccion_31]

Empezado por starlet

Lo primero, pedir disculpas, por la repetición de mensajes. Juro que al postear el mensaje me daba error, y no se publicaba, y hoy, aparecen de golpe varias repeticiones del mismo mensaje.

Pido a los moderadores, que sólo dejen uno. Gracias

Respecto a visible = false en el form principal, sí, ya lo había visto y por supuesto lo he puesto a true, pero sigue exactamente igual. Y como digo lo he probado con 2 versiones diferentes de Delphi.

Evidentemente, asumo que es un error de mi equipo, pero no tengo ni idea de qué puede ser, porque desarrollo en este equipo sin ningún problema desde hace varios años.

Reitero mi agradecimiento a seccion_31 y a todos los que habéis contribuido en este proyecto y desde ahora en lo que pueda, intentaré ayudar igualmente.

Has instalado el capicom ?

[ramherfer]

Buenos días. Por favor tengo a raíz de los últimos post una pequeña duda y que pensaba que lo tenía claro.

Entonces, si la AEAT me rechaza una factura ya que contiene errores, en la AEAT está claro que no está, pero yo en el registro del SIF ya tengo uno como incorrecto/rechazado por el motivo que sea un registro.

Ahora bien, ¿Rectifico los errores en la factura (importes,nif, motivos exención,etc... -cualquier dato-) o se debe generar una nueva con los errores corregidos?

¿En el registro SIF dejo el registro de error tal cual para siempre generando un nuevo registro como subsanación por rechazo previo e inexistente en la AEAT y que iria encadenado con el registro SIF que provocó el rechazo?

Entiendo que se rectifica la factura y se genera un nuevo registro en el SIF con los datos correctos y encadenado al registro SIF erróneo. ¿Estoy en lo cierto?

¿Si ha sido aceptada con errores el procedimiento sería el mismo tanto en la factura como en el registro SIF?

Un saludo,

[delphiGar]

Empezado por ramherfer

Buenos días. Por favor tengo a raíz de los últimos post una pequeña duda y que pensaba que lo tenía claro.

Entonces, si la AEAT me rechaza una factura ya que contiene errores, en la AEAT está claro que no está, pero yo en el registro del SIF ya tengo uno como incorrecto/rechazado por el motivo que sea un registro.

Ahora bien, ¿Rectifico los errores en la factura (importes,nif, motivos exención,etc... -cualquier dato-) o se debe generar una nueva con los errores corregidos?

¿En el registro SIF dejo el registro de error tal cual para siempre generando un nuevo registro como subsanación por rechazo previo e inexistente en la AEAT y que iria encadenado con el registro SIF que provocó el rechazo?

Entiendo que se rectifica la factura y se genera un nuevo registro en el SIF con los datos correctos y encadenado al registro SIF erróneo. ¿Estoy en lo cierto?

¿Si ha sido aceptada con errores el procedimiento sería el mismo tanto en la factura como en el registro SIF?

Un saludo,

Si los errores del Registro de Facturacion ( RF ) estan contemplados en el Reglamento de Facturacion debes generar una nueva Factura tipo F1 o F2, Anula esa mediante SinRegistroPrevio=S y RechazoPrevio=N. Si por el contrario no esta en Reglamento de Facturacion haces una subsanacion de esa misma Factura mediante Susbanacion=S y RechaPrevio=X.
El encadenamiento recuerda que se hace con el ultimo registro de factuacion generado. De tal forma que si antes del rechazo habias generado otro se encadena a ese ultimo y no al rechazado.

[gcqZW]

De tal forma que si antes del rechazo habias generado otro se encadena a ese ultimo y no al rechazado.

Despues***

Si los errores del Registro de Facturacion ( RF ) estan contemplados en el Reglamento de Facturacion debes generar una nueva Factura tipo F1 o F2

Seria un Rx no?? Si esta contemplado en el ROF significa que estas obligado a rectificar.

[delphiGar]

Empezado por gcqZW

Despues***

No, al ultimo RF generado por el SIF

Empezado por gcqZW

Seria un Rx no?? Si esta contemplado en el ROF significa que estas obligado a rectificar.

No, por que ha sido Incorrecto. Distinto seria si fuera aceptada o aceptada con errores, en ese caso seria Rx.

[gcqZW]

No, al ultimo RF generado por el SIF

Exacto, según como lo has escrito has puesto que hay que encadenar con el ultimo correcto, si antes del rechazado has generado un RF, el rechazado debió estar encadenado a ese y el nuevo que generes ha de estar encadenado al rechazado.

[delphiGar]

Empezado por gcqZW

Despues***



Seria un Rx no?? Si esta contemplado en el ROF significa que estas obligado a rectificar.

Ponte en el caso de que estas generando nuevas facturas y el RF que se va a enviar y da Incorrecto esta en espera durante los 60sg para enviar, por eso siempre digo el ultimo generado.

[gcqZW]

Si me da que estamos pensando lo mismo solo que hemos interpretado mal las palabras, el dogma es: se encadena al ultimo RF que hayas generado, pensaba que te referías a que se encadena al último RF aceptado que tuvieras. Me ha liado la palabra "antes".

[DarkDudae]

Me da la sensación que hay mucha confusión con el tema de encadenamientos.

Hay que saber diferenciar entre Registro de Facturación y Facturación.
El registro de facturación es el que almacena el encadenamiento y las huellas y es el SIF el que debe encargarse de almacenar este registro de facturación. Este registro de facturación tendrá un registro encadenado por cada una de las operaciones que enviamos a VeriFactu, independientemente de que estas hayan sido aceptadas, aceptadas con error, o rechazadas. El encadenamiento no ha de tener en cuenta la respuesta recibida por VeriFactu (al menos no en lo relativo al encadenamiento y huellas previas), así que todos los registros irán inmediatamente enlazados a su registro anterior sin tener en cuenta su aceptación o no en la AEAT.

Por otro lado, tenemos la facturación.
Hay que saber distinguir los casos en los que una factura no ha llegado bien a VeriFactu o ha llegado pero con errores, o directamente, es errónea.

Si haces una subsanación de un registro NO ACEPTADO (el caso de un NIF incorrecto, por ejemplo)
FLAGS:
Subsanacion = S
RechazoPrevio = X

Si haces una subsanación de un registro Aceptado o Aceptado con Errores:
FLAGS:
Subsanacion = S
RechazoPrevio = N

En este último caso (Verifactu tiene los registros aceptados o aceptados con errores), el registro de facturación tendrá el mismo número de factura a subsanar cuando NO estemos obligados a generar una factura rectificativa. En caso de que sea necesaria una factura rectificativa, sí que llevaría el número de factura nuevo con la serie de rectificativas y la nueva numeración pertinente.