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

[seccion_31]

gracias por las respuestas !

¿y si el emisor tiene varias series? (una para tickets, y otra para facturas )

por ejemplo

F0003 ACEPTADA ENLAZADO CON F0002
V0002 ACEPTADA ¿ENLAZADO CON F0003?

saludos !

[bmfranky]

Empezado por seccion_31

gracias por las respuestas !

¿y si el emisor tiene varias series? (una para tickets, y otra para facturas )

por ejemplo

F0003 ACEPTADA ENLAZADO CON F0002
V0002 ACEPTADA ¿ENLAZADO CON F0003?

saludos !

Da igual el contenido del registro, yo lo hago , encadeno 3 series de facturas, F1 de reparacion FR1, F1 de materiales FV1, y F2 de contado FC1, aparte de cuando haga las R que tambien lo hare.

0005 - F0003 ACEPTADA ENLAZADO CON 0004
0006 - V0002 ACEPTADA ENLAZADO CON 0005

Al calcular el nuevo hash de encadenamiento usas el contenido del anterior, sea cual sea.(Hojo siempre del mismo NIF/Empresa)

[delphiGar]

Siempre se encadena con el ultimo registro enviado, da igual si es correcto, Incorrecto o Aceptada con Errores.

Tambien da igual el tipo de factura y el tipo de registro Alta o Anulacion.

Lo mejor es guardar los datos del ultimo registro enviado y con eso construyes el siguiente.

[rci]

Empezado por delphiGar

Siempre se encadena con el ultimo registro enviado, da igual si es correcto, Incorrecto o Aceptada con Errores.

Tambien da igual el tipo de factura y el tipo de registro Alta o Anulacion.

Lo mejor es guardar los datos del ultimo registro enviado y con eso construyes el siguiente.

yo creo que no es el último enviado, sino el último registro de facturación generado

[delphiGar]

Empezado por rci

yo creo que no es el último enviado, sino el último registro de facturación generado

A buen entededor pocas palabras bastan.

Se entiende que ultimo enviado = ultimo generado.

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

Empezado por rci

yo creo que no es el último enviado, sino el último registro de facturación generado

Creo que eso es lo correcto.

Empezado por delphiGar

Se entiende que ultimo enviado = ultimo generado.

No es por ser puristas, pero [rci] tiene razón (piensa siempre en sistemas verifactu y no-verifactu).
En Verifactu es posible que generado=enviado, pero en No-Verifactu no se envía nada y tal vez alguien se esté liando con eso.

[delphiGar]

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

Creo que eso es lo correcto.


No es por ser puristas, pero [rci] tiene razón (piensa siempre en sistemas verifactu y no-verifactu).
En Verifactu es posible que generado=enviado, pero en No-Verifactu no se envía nada y tal vez alguien se esté liando con eso.

Se entiende que en un sistema NO verifactu no envias mientras no haya requerimiento, sigues facturando y claro es el utlimo generado, y ese es el que hay que tener en cuenta.

Y como decia lo he echo sobre la base de ultimo registro generado = ultimo registro enviado en el caso de Verifactu y con el planteamiento que hacian los compañeros.

Lo importante aqui es que quede claro el concepto de lo que hay que utilizar.

[seccion_31]

Empezado por delphiGar

Siempre se encadena con el ultimo registro enviado, da igual si es correcto, Incorrecto o Aceptada con Errores.

Tambien da igual el tipo de factura y el tipo de registro Alta o Anulacion.

Lo mejor es guardar los datos del ultimo registro enviado y con eso construyes el siguiente.

Vamos a ver, que lo entienda bien: (otro caso, espero que el ultimo)

si envio la F3 con error en DNI y es la ultima del envio, y da resultado Incorrecto....

¿ El siguiente envio de la F3 ira enlazado con la huella de la F3 que dio errores (Incorrecta) ? (¿y en teoria no esta en la AEAT?)


hoy me he quedado sorprendido, porque hasta ahora no lo entendia asi.

Las que dan errores, No se quedan en la AEAT ¿no?, esto me descoloca un poco, a mi esto de enlazar me cuadraba con las aceptadas, o aceptas con errores, pero con las incorrectas... ahi ya me quede.

Saludos y gracias a todos

[bmfranky]

Empezado por seccion_31

Vamos a ver, que lo entienda bien: (otro caso, espero que el ultimo)

si envio la F3 con error en DNI y es la ultima del envio, y da resultado Incorrecto....

¿ El siguiente envio de la F3 ira enlazado con la huella de la F3 que dio errores ?


hoy me he quedado sorprendido, porque hasta ahora no lo entendia asi.

Las que dan errores, No se quedan en la AEAT ¿no?, esto me descoloca un poco, a mi esto de enlazar me cuadraba con las aceptadas, o aceptas con errores, pero con las incorrectas... ahi ya me quede.

Saludos y gracias a todos

Hola, realmente lo que se encadenan son los registros que crea tu SIF, que se almacenan inmutables , no los que acepta o no la AEAT.

Para la aeat, el registro anterior con o sin errores , es el que hay que tener en cuenta para encadenar.

Osea creas el REgistro, lo almacenas, lo envias, se rechaza, creas otro registro , que soluciona los errores del registro enviado, encadenas con el anterior de la lista, sea o no correcto, enviado o no, rechazado o no, y continuas con la serie.

Mira en mi caso, hubo un error en el envio.

[DarkDudae]

Empezado por bmfranky

Hola, realmente lo que se encadenan son los registros que crea tu SIF, que se almacenan inmutables , no los que acepta o no la AEAT.

Para la aeat, el registro anterior con o sin errores , es el que hay que tener en cuenta para encadenar.

Exacto. Así es. Pensad que un auditor de Hacienda nos puede pedir (y debemos tener disponibles para ellos de forma sencilla desde la interface del programa) un registro de facturación, que no dejan de ser los registros que crea el SIF y que deben almacenarse inmutables, independientemente si los ha aceptado Verifactu o no. Además, esta es nuestra garantía de que nosotros (como mínimo) intentamos hacer las cosas de forma correcta.

[bmfranky]

En esta captura se ve , que tube que modificar a huevos por un fallo mio al enviar, si veis es el mismo numero de factura, distinto contenido, la anterior no reza en la AEAT para nada.


Me pase de 3.000€, Si lo se la forma correcta es una rectificativa, pero aun no las implemento.

[seccion_31]

gracias a todos

ahora si, ya quedo claro.


la semana que viene publicare una nueva version con los tres flags nuevos para permitir la correccion del registro, como he indicado.

Saludos !

[delphiGar]

Empezado por seccion_31

Vamos a ver, que lo entienda bien: (otro caso, espero que el ultimo)

si envio la F3 con error en DNI y es la ultima del envio, y da resultado Incorrecto....

¿ El siguiente envio de la F3 ira enlazado con la huella de la F3 que dio errores (Incorrecta) ? (¿y en teoria no esta en la AEAT?)


hoy me he quedado sorprendido, porque hasta ahora no lo entendia asi.

Las que dan errores, No se quedan en la AEAT ¿no?, esto me descoloca un poco, a mi esto de enlazar me cuadraba con las aceptadas, o aceptas con errores, pero con las incorrectas... ahi ya me quede.

Saludos y gracias a todos

Correcto, tienes que utilizar para el encadenamiento esos datos sean del tipo que sean y sin o con errores!

[mqm]

Da igual si tienes variuas series. Simpre es sobre la ultima y por lo que he visto hasta ahora lo esta haciendo bien.

[seccion_31]

por cierto, yo diria que la ayuda de la 4.6a esta algo mal detallada sobre la F3, creo que con indicar los datos de cliente, emision, y el record de sustitucion deberia funcionar. Vamos que no lo tengo claro, pero funcionar, funciona.

Saludos !

: )

[Matorral]

Buenas tardes¡¡

Gracias anticipadas de nuevo a todos por el enorme esfuerzo.

Acabo de darme cuenta de que al realizar la consulta de la AEAT de registros de facturación enviados, me aparecen todos como Subsanacion = 'S' y PrimerRegistro = 'S'.

La consulta la hago por medio del componente, capturando los registros en el evento onRegConsultaD7.

Los RF los envío sin valor en el campo Subsanacion, y trazando la función AddRegistroInicial el valor fPrimero tiene valor False, no entiendo por que al hacer la consulta me devuelve 'S' en esos dos campos (Subsanacion y RegistroInicial).

El xml de envio esta bien generado y el encadenamiento es correcto. Y el xml de respuesta también es correcto

A alguien le pasa esto?

[Matorral]

Quería comentaros, por si le sirve a alguien, que estoy utilizando el evento onRegTrasEspera para gestionar la cola de envío, y va de cine.

Mi software es de hostelería y comercio, y en principio había pensado en realizar los envíos cada vez que se cobra una factura, pero no las tenia todas conmigo, porque en muchos bares y comercios realizan varios cobros por minuto, y quien sabe si los banearían.

Para gestionar la cola de envíos hago lo siguiente:

Cuando cobro una factura compruebo la propiedad AutoEspera. Si está a False la pongo a true y realizo el envío. Y si esta a True guardo la factura en la cola (FIFO) sin realizar envío.

Código Delphi [-]
        if VerifactuD7.AutoEspera=false then begin    // si esta a false se puede enviar
          try
            HazAvisoVerifactu('Enviando registro de facturación ... ');

            VerifactuD7.AutoEspera:=true;    // ponemos en marcha onTrasEspera

            enviarVerifactu_Simplificada( cSer,cTicket,'A'); // Enviamos Verifactu

            CierraAvisoVerifactu(Proc_Ventas);

          except
            showmessage('Fallo al enviar Factura');
          end;
        end
        else
          Graba_Pendiente_Envio(cSerieTickets,TTicket.FieldByName('SERIE').AsString,TTicket.FieldByName('CODIG  O').AsString,'S', 'N', 'N', 'N');

Luego en el evento onTrasEspera, si hay registros pendientes realizo el envío de las facturas guardadas en cola y si no hay registros pendientes de envío vuelvo a poner a False la propiedad AutoEspera.

Código Delphi [-]
/////// VERIFACTU
// autoenvio automatico de facturas pendientes REGISTROSPENDIENTESENVIO.DB
procedure TProc_Ventas.OnTrasEsperaD7( Sender: TObject );
begin

  if TRegistrosPendientesEnvio.IsEmpty then
    VerifactuD7.AutoEspera:=False
  else
    enviarVerifactu_Pendientes;

end;

Espero que le pueda servir a alguien.

[DarkDudae]

Empezado por Matorral

Quería comentaros, por si le sirve a alguien, que estoy utilizando el evento onRegTrasEspera para gestionar la cola de envío, y va de cine.

Mi software es de hostelería y comercio, y en principio había pensado en realizar los envíos cada vez que se cobra una factura, pero no las tenia todas conmigo, porque en muchos bares y comercios realizan varios cobros por minuto, y quien sabe si los banearían.

Para gestionar la cola de envíos hago lo siguiente:

Cuando cobro una factura compruebo la propiedad AutoEspera. Si está a False la pongo a true y realizo el envío. Y si esta a True guardo la factura en la cola (FIFO) sin realizar envío.

Código Delphi [-]
        if VerifactuD7.AutoEspera=false then begin    // si esta a false se puede enviar
          try
            HazAvisoVerifactu('Enviando registro de facturación ... ');

            VerifactuD7.AutoEspera:=true;    // ponemos en marcha onTrasEspera

            enviarVerifactu_Simplificada( cSer,cTicket,'A'); // Enviamos Verifactu

            CierraAvisoVerifactu(Proc_Ventas);

          except
            showmessage('Fallo al enviar Factura');
          end;
        end
        else
          Graba_Pendiente_Envio(cSerieTickets,TTicket.FieldByName('SERIE').AsString,TTicket.FieldByName('CODIG  O').AsString,'S', 'N', 'N', 'N');

Luego en el evento onTrasEspera, si hay registros pendientes realizo el envío de las facturas guardadas en cola y si no hay registros pendientes de envío vuelvo a poner a False la propiedad AutoEspera.

Código Delphi [-]
/////// VERIFACTU
// autoenvio automatico de facturas pendientes REGISTROSPENDIENTESENVIO.DB
procedure TProc_Ventas.OnTrasEsperaD7( Sender: TObject );
begin

  if TRegistrosPendientesEnvio.IsEmpty then
    VerifactuD7.AutoEspera:=False
  else
    enviarVerifactu_Pendientes;

end;

Espero que le pueda servir a alguien.

Vaya, me ha alegrado ver que mi pequeña aportación al componente le ha servido a alguien. Pensaba que era el único que usaba algo así.
Comentarte que el componente intercepta el tiempo de espera entre operaciones devuelto en cada envío desde la AEAT para modificar el timer interno que se usa antes de lanzar el evento OnTrasEspera. Se incorporó para hacer exactamente lo que estás haciendo y lo estás usando de forma muy similar a la que lo hago yo mismo.

Un saludo!

[seccion_31]

La 4.7 ya esta enviada para su publicación, corrigiendo esas variables de la consulta

Saludos !

[Matorral]

Empezado por DarkDudae

Vaya, me ha alegrado ver que mi pequeña aportación al componente le ha servido a alguien. Pensaba que era el único que usaba algo así.
Comentarte que el componente intercepta el tiempo de espera entre operaciones devuelto en cada envío desde la AEAT para modificar el timer interno que se usa antes de lanzar el evento OnTrasEspera. Se incorporó para hacer exactamente lo que estás haciendo y lo estás usando de forma muy similar a la que lo hago yo mismo.

Un saludo!

Pues sinceramente, me parece una gran aportación. Muy útil, y te olvidas de manejar timers y controlar segundos devueltos por hacienda, etc...

Gracias¡¡¡¡¡