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

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

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

[seccion_31]

Buenas noches

Ya esta enviada para publicacion la nueva version del componente la 2.0:

version 2.0
----------------------------------------------------------------------------------------------------------------------------
-> ATENCION: aumentar el maxstack size minimo a: $00400000
-> ATENCION: Se recomienda deshabilitar range check

Tras recibir nueva informacion sobre el funcionamiento de los encadenanmientos en foro clubDelphi se ha modificado ampliamente
el funcionamiento del componente: Algunos de estos cambios pueden verse aplicados en la DEMO_D7

https://www.clubdelphi.com/foros/sho...d.php?p=559560

Los encadenamientos de un emisor son sobre el registro anterior generado cronologicamente, independientemente de si existe
o no en verifactu y de su serie. Asi ya no es necesario obtener el numero anterior de factura.

De esta forma eliminamos el parametro factura anterior y creamos la funcion registroInicial( ) para establecer el primer encadenamiento
del envio. (que deberia ser simplemente los datos el ultimo registro enviado, en el envio anterior)

TVeriFactu.addRegistroInicial(numserieFactura, fechaFactura, huella:string):boolean;

Asi tenemos la funcion registroInicial para establecer el encadenamiento cero y el resto de encadenamientos anteriores de los siguientes registros
como es cronologico se obtienen del registro indice del array de facturas - 1.

Si NO hay encadenamiento previo (registro Inicial), llamar a la funcion registroInicial con '' (string vacio) en todos los apartados. (o no llamarla).

---> Las huellas siempre se calculan en el momento del envio, (excepto la del registro inicial), dejar el campo huella de la factura sin valor al añadir la factura
Despues del envio se puede recuperar la factura con la nueva funcion TVerifactu.factura (ver abajo) y ahi estara la huella calculada - enviada.

---> ATENCION: Se ha publicado la funcion clear_factura( factura ) para limpiar todos los campos de una factura, previo a cargar datos por el usuario.

Es muy recomendable su uso, ya que algunos campos, especialmente los boolean tienden a quedar =true.

TVeriFactu.clearFactura(var afactura:TRegistroFactura);

Se añaden los siguientes campos en la factura: TRegistroFactura

subsanacion :boolean; // S
rechazoprevioExiste :boolean; // S
rechazoprevioNOExiste:boolean; // X

por defecto clear_factura los dejara a false (entre otros).

---> ATENCION: El indice inicial para analizar el resultado, consultas devueltas, etc... ahora comienzan en 1:

Los bucles quedaran asi:

for j:=1 to resultado.nFacturas do

....

for j:=1 to consulta.nfacturas do

Para una sola factura de consulta:

consulta.facturas[1]

---> ATENCION: Anulacion de facturas:

Añadido en el campo en factura, para la anulacion de factura: sinregistroPrevio:boolean;


Nueva funcion:

TVerifactu.factura(indice:integer; var aFactura:TRegistroFactura):boolean;

Devuelve la factura almacenada en la posicion indice del array. un indice de cero, devolvera los 3 apartados del registro inicial.

Ahora: En el array de resultado del envio de facturas, por cada factura, se envia su posicion indice en el array de facturas almacenadas

Al añadir una factura, se comprueba si existe en el array para ese numero y operacion, impidiendo añadir la misma factura dos veces en esa operacion.

Por tanto ahora las huellas y CSV en el resultado de envio se envian sin posibles fallos de identificacion.

Ver el formulario demo_d7 para comprobar estos cambios.


Modificaciones en consulta de registros:

Ahora la consulta se limpia correctamente antes de empezar su procesamiento

En TConsultaFactura

Timestamp se suprime (corresponde a fechaGenRegistro y horaGenRegistro)

Fecha pasa a FechaGenRegistro
Hora pasa a HoraGenRegistro

Se añaden: (todavia por comprobar)

idPeticion
FechaUltimaModificacion
HoraUltimaModificacion
TipoHuella
PrimerRegistro
Incidencia
clienteCodPais
clientetipoNIF
Subsanacion
RechazoPrevio
inversionSujetoPasivo
SinregistroPrevio

En el array de ivas

calificaciondeoperacion


Añadiendo facturas:

Chequeo de cuotas:

Ahora ya no es necesario indicar la cuotatotal en la factura
Si se indica cuotatotal=0 se sumaran las cuotas de iva y req del array de ivas
Si se indica cuotatotal<>0 debera cuadrar con las cuotas de iva y req del array de ivas

Parametros del sistema informatico:

Se suprime del envio y consulta por no obligatorio: TipoUsoPosibleSoloVerifactu y TipoUsoPosibleMultiOT


----------------------------------------------------------------------------------------------------------------------------
version 1.3 (no publicada)
-----------
Entrega de bienes a Canarias, ceuta y melilla, codigos postales 35 38, 51 y 52:->Automatizacion para entrega de bienes, regimen 02 exportacionn, E2, exentas por el capitulo 21

Corregida asignacion automatica de tiponif para ES

Correccion al enviar el nombre/password en certificados pfx p12

Mas correcciones en la carga de pfx y p12, ahora ya deberia estar correcto

Correccion en consultas, conDatos se quedaba a false, corregido

En tickets, F2 , automaticamente se coloca: canarias=false, e inversionSujetoPasivo=false

-> Se recomienda deshabilitar range check

Corregida asignacion de sesion al limpiar callbacks en inicio de sesion

[DarkDudae]

Empezado por seccion_31

Buenas noches

Ya esta enviada para publicacion la nueva version del componente la 2.0:

Sólo queda agradecerte, una vez más, el trabajazo que has hecho. ¡Gracias por compartirlo!

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

La versión 2 del proyecto ya está subida al FTP del club.

Se adjunta el fichero RAR y un pequeño fichero TXT descriptivo de la versión, con el enlace al mensaje y los créditos.

Un saludo.

[ramherfer]

Empezado por DarkDudae

Sólo queda agradecerte, una vez más, el trabajazo que has hecho. ¡Gracias por compartirlo!

Claramente y sin paños calientes, sin esta ayuda, hubiese sido incapaz adaptar la aplicación y hubiese tirado el proyecto de años y años de trabajo a la basura. Superé el reto del i.t.e. al i.v.a, superé el reto del efecto 2000, superé el reto del maldito Euro, superé los cambios contables del 2008. Pero esto con gran desesperación y mucha preocupación lo veía imposible. Y gracias al trabajo de este hombre y el inestimable apoyo de otros de vosotros, la aplicación dará más guerra. No se de que forma lo puedo agradecer, siempre considerando que agradecer se queda corto. Solo gracias Sección_31, gracias Foro Club Delphi y gracias a todos aquellos que habeis puesto vuestro granito de arena y habeis permitido que siga en la brecha. Nunca pensé durante dos años de incertidumbres y desesperación que llegaría donde he llegado, ni por asomo.
Tengo una nueva oportunidad "Gracias a vosotros" sin lugar a ninguna duda.

[CarlosMz]

Muchas gracias por tu trabajo y compartirlo de esta manera con la comunidad delphi,

A mi personalmente me ayudó mucho tu demo, pues no había usado SOAP nunca antes...

[delphiGar]

Aunque no utilizo el componente, vi tu primera demo, y la verdad es que me instruyo bastante, te lo agradeci en su momento y te lo vuelvo a agradecer, eres un maquina!!!!

[nincillo]

Yo me empezaré a poner en "serio" con este componente a partir de ahora que ya he conseguido finalizar otras cosas que tenía pendientes.

La verdad es que es de agradecer el curro que os habéis pegado para preparar esta demo y esta dll. Que nos va a servir a muchos como punto de partida para aprender muchas cosas.

Lo primero que voy a intentar entender es como poder aplicar esta dll a todas las variantes que se me pueden dar con mis clientes. Clientes que tienen un servidor y las tiendas se conectan por escritorio remoto, que cada tienda va a generar sus tickets con una numeración independiente y que la numeración de las facturas en unos casos las van a compartir y en otros casos van a tener diferentes series por delegación, etc.

Gracias de nuevo y voy leerme el hilo desde el principio para intentar entender lo más posible todo tu planteamiento.

Un saludo.

[mqm]

Muchas gracias. A más de uno nos has salvado la vida.

[ramherfer]

Buenos días

En la operaciones de baja / Anulación y teniendo en cuenta el nuevo dato sinRegistroPrevio en el registro de factura, ¿El siguiente código sería correcto?

Código Delphi [-]
      if QRegSifOPERACION.Value = 'BAJA' then begin

         actual.sinregistroPrevio := QRegSifAEAT_REGISTRO_PREVIO.Value;

         if QRegSifAEAT_RECHAZO_PREVIO.Value = 'S' then begin
            actual.rechazoprevioExiste := True;
            actual.rechazoprevioNOExiste := False;
         end;

         if QRegSifAEAT_RECHAZO_PREVIO.Value = 'N' then begin
            actual.rechazoprevioExiste := False ;
            actual.rechazoprevioNOExiste := True;
         end;

      end;

Ya que en el registro de anulación el dato RechazoPrevio está contemplado con el siguiente texto:

Indicador que especifica que se está generando -para volverlo a remitir- un nuevo registro de facturación de anulación subsanado tras haber sido rechazado en su remisión inmediatamente anterior, es decir, en el último envío que contenía ese registro de facturación de anulación rechazado. Si no se informa este campo se entenderá que tiene valor "N". Solo es necesario informarlo en caso de remisión voluntaria «VERI*FACTU». Este campo forma parte del detalle de las circunstancias de generación de los registros de facturación.

o los datos rechazoprevioExiste y rechazoprevioNOexiste, son válidos solo para los registros de subsanación.

Un saludo,

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

[nincillo]

Empezado por seccion_31

gracias DarkDudae

voy a incoporar la corrección y en un tiempo, quizas dos semanas publicare una nueva version.

¿tenemos alguna sugerencia para seguir mejorando el componente?

Voy a retirar el campo "situacion", porque creo que no se usa, y asi libero espacio de la pila.
Corregire las fechas cuando entreguen la fecha de emision con - en lugar de /

Hay un indicador que se llama incidencia, que se puede activar manual, o automaticamente, cuando la fecha de alguna factura es diferente a la del dia.
Habra otro indicador que se llamara primerRegistro si se detecta primer registro en el envio
-->Ambos indicadores, deberian poder ser consultados antes del envio.

(Es una lastima no poder encapsularlo en una DLL, mejoraría mucho)

Habria que probar el certificado pfx

Y hay que añadir mas casos a la generación de la facturación, en especial la de exentos de iva. ¿hay alguien por aqui que domine el tema?

Saludos !

Siento si la respuesta llega con retraso, pero me he puesto a leer el hilo desde el principio para ir probando/entendiendo las cosas poco a poco.

Estoy trabajando con Delphi 2007 y acabo de modificar el código de la DEMO_D7_DLL2 y la Validación del NIF para que lo haga utilizando un certificado en fichero .p12 y con contraseña (en lugar de un certificado instalado en el sistema y seleccionado mediante el combo) y me ha hecho la validación correctamente.

Genial!!!.

Muchas gracias!!!