me autocito, yo diria que no se pueden suprimir de la busqueda una vez que se activa el SIF.

En la demo se ha enviado registros con valores un poco random, en la 2 los he ajustado a modosoloverifactu=S y los otros dos a false, por tanto es posible que con filtro SIF ya no se vean esos registros.

He eliminado del XML de consulta estos apartados manualmente y el envio me da el error:

<faultstring>Codigo[4102].El XML no cumple el esquema. Falta informar campo obligatorio.: TipoUsoPosibleSoloVerifactu</faultstring>

se admiten ideas. como siempre.

Saludos !

Lo he solucionado poniendo:

esos son tus valores de envio, de cuando la DEMO enviaba sin preocuparse, por defecto verifactu colocaba esos valores. que no aparecen en rojo ni obligatorios en la hoja de caculo, pero que evidentemente creo que hay que enviar.

Ahora la demo pone modo verifactu a true, y los dos OT a false. (que es lo normal que hace la demo, 1 solo OT y modo soloverifactu)

Hay que ajustar BIEN esos valores en la aplicacion real. Antes de comenzar a enviar.

Saludos !

¿Alguien se ha planteado o sabe cómo pasar la dll a unit?
Estoy enfocando todo a un proceso externo en Delphi 10.1 y me es más cómodo usar la unidad original, pero no tengo ni idea de cómo hacerlo.

tienes una unidad de tipos (comun)
otra de funciones. (DLL)
otra con el componente (que importa de la anterior via DLL)


crea una unidad copia del componente para crearte un TVeriFactu alternativo
usa la unidad de funciones
elimina las importaciones a la DLL (de esa copia que acabas de hacer)
haz que llamen directo, quizas tengas que ajustar algo, nombres o asi.

y listo.

ese es el plan mas sencillo que se me ocurre. Seguiras teniendo un componente alternativo TVeriFactu que no necesitara la DLL.

Saludos !

Yo para probar, lo he compilado con Delphi 12.3 y con pocos cambios parece que funciona.
No he hecho grandes cosas, porque hasta ahora estaba desconectado del funcionamiento, pero al menos la pantalla principal carga y "hace cosas".

1) Descargar la versión actualizada de los ficheros desde aquí y sustituir los que hay (Quricol.inc, QuricolAPI.pas, QuricolCode.pas).
https://github.com/perevoznyk/qurico.../Delphi/Source
2) Generar la unit SistemaFacturacion.pas (para Delphi 12); La adjunto al mensaje.
3) Añadir condicionales a uVerifactuFuncs.pas para algunas firmas de procedimientos que han cambiado. Lo adjunto al mensaje.

Lo dicho. con esto compila.
Habrá que ver si todo funciona. No me he dedicado a realizar pruebas porque no se muy bien como va.

NOTA: La DLL también está compilada con la 12.3

Neftali [Germán.Estévez] puedo añadir los cambios a la version actual y asi mantener la compatibilidad en adelante, lass dudas que tengo son:

¿SistemaFacturacion.pas es compatible con las anteriores versiones de delphi ?

entiendo que la DLL de QuricolCode sera la misma....

gracias y Saludos !

He seguido haciendo alguna prueba más y llego a obtener el error de "S240015 Incorrecto 3000 Registro de facturación duplicado.", por lo tanto creo que ha llegado a realizar el envío y ha obtenido la respuesta de error.

La DLL de QRuiCol parece que funciona, porque me ha generado un QR que parece correcto, y almacena la URL.
El fichero <SistemaFacturacion.pas> tengo dudas de que sea compatible, porque normalmente los nuevos Delphi generan ficheros con tipos no existentes en los antiguos. Tengo un Delphi 7 por alguna máquina virtual. Déjame que lo pruebe y veo a ver cómo se comporta y cómo se puede integrar.

el sistemafacturacion.pas debe compilar en D10, lo pruebo yo. gracias !

Hola buenas tardes y disculpar mi torpeza.
Estoy revisando todo el tema de encadenamiento y acabo de caer en el asunto y creo que lo estoy haciendo incorrectamente en algunos casos (subsanación). A ver si por favor alguien me echa un cablecillo.

Tengo en el sif los siguientes registros:

La factura FA250079 la aceptan con errores y al día siguiente habiendo revisado el problema la subsano, al estar revisando el registro hoy con las pruebas realizadas, creo que las dos últimas incluida la de subsanación lo tengo, mal no, peor. Estoy en lo cierto verdad?
Un saludo,

Tiene que diferenciar los registros enviados , de las facturas a las que pertenecen, no es lo mismo, siempre ha de encadenar con lo enviado en el registro anterior, independientemente de su contenido.

Con este tema, no termino bien, ya te lo digo.

Muchas gracias!!!

En este hilo nos lo explicaron a todos. (entre ellos a mi), por eso se colocó el registroinicial y se anulo el envio de factura anterior.

En la ayuda.txt del componente cuando se añadió el registroinicial lo explique.

A mi me costo entenderlo, pero el encadenamiento es un dato tuyo, que encadena con el registro anterior del mismo OT (y SIF, segun instalacion). y ya. Cronologicamente hablando. Para mi mucho mas simple.

Saludos !

Buenos días.
Estoy con la versión 2.1 y el tema de encadenamientos y tengo el siguiente problema:

Código Delphi [-]
      FacturasEnviadas.Last;
      VeriFactuD7.addRegistroInicial(facturasEnviadas.fieldbyName('NumSerieFactura').text, facturasEnviadas.fieldbyName('FechaExpedicioFactura').text, facturasEnviadas.fieldbyName('huella').text);

Me pone como encadenamiento una factura que está a mitad de facturas.xml (no la última enviada) y al hacer el envío me lo rechazan dado que en NumeroSerieFactura está poniendo en lugar de la serie de factura la huella.

No se si solo me está pasando a mi o alguien más a tenido problemas con esto.

Un saludo,

Bdias !
Funciona correctamente. De echo hoy he estado enviando. :)

Ahora bien..., estás usando la demo con algun fin?? Fuera del de servir de demostrativo?

Porque el encadenamiento inicial en la demo no es que me preocupe mucho. Voy a la última enviada y ya, pero igual los datos están regular cargados ahí. Y tendría que revisarlo.

Entiendo que para tu programa estás escribiendo código y no sirviéndote de la demo como tal, porque si es así no creo que sea buena idea.

Revisaré la demo.

Saludos !

No la estoy de forma que la app envie los datos. El encadenamiento que estaba haciendo era erróneo y he querido utilizar el de la demo con esas dos instrucciones, pero me ha extrañado mucho que me asignara mal la factura anterior, ya que más simple no puede ser con el codigo de la demo. Cierto es que tengo rectificativas con distintas series, es decir, Facturas xml tiene numeros de serie FA00000, RF00000 y la última se me va a la última RF que está a mitad de tabla ya que es una rectificativa de prueba que hice hace unos días. Voy a realizar una prueba eliminando los registros RF de rectificativas.

Si, En principio es mucho más sencillo

Vas a la última factura o ticket generada y enviada y cargas los datos del registro inicial después añades tu factura o ticket y envías. No hay más.

Que la demo en facturas.xml tenga los datos mal puede ser.

Quizás tenga algún índice activo que habrá que quitar. No me acuerdo.

Reviso la demo.

Creo que el problema está en las series, ya que según esto:

Código Delphi [-]
      // cargar el archivo xml de facturas ya enviadas
      FacturasEnviadas.LoadFromFile( xmlFacturas );
      FacturasEnviadas.IndexFieldNames:='Emisor;NumSerieFactura';
      FacturasEnviadas.Active:=true;

lo esta haciendo bien por lógica ya que de un mismo emisor, la serie FA250092 (que es la anterior que debía seleccionar) está antes que la RF250003 que es la última y la que seleciona como factura anterior. Pero erróneo en la práctica ya que la anterior debiera ser la FA250092.

correcto, elimina la linea FacturasEnviadas.IndexFieldNames:='Emisor;NumSerieFactura'; y listo. en la practica ira a la ultima generada/enviada cronologicamente independiemente de su serie/numero. (la demo solo permite un emisor/OT.)



En la version 3, esa linea ya no estara.

Saludos !

entiendo que sin esa linea el encadenamiento esta correcto, huella y demas?

de momento no. la última que tengo en facturas.xml está rechazada y no tiene huella, estoy probando con esa línea de definición del indice eliminada, pero en la primera prueba no "parece" estar funcionando bien

La demo no se cómo se comporta con facturas no aceptadas y huellas. En su envío, luego lo miro

Elimina facturas.xml y comienza otras pruebas

Saludos

La demo solo coloca y añade la huella en las facturas enviadas OK. El resto lo ignorara en su BD xml.

He tenido que modificar un poco el programa demo para que lo ordene cronologicamente bien. y envie como huella anterior la ultima aceptada. (que en una aplicacion real, seria la ultima generada).

Como digo es una demo.

Estas modificaciones iran en la version 3.0

donde si tiene un error es en la anulacion (DLL)


en la 3.0 estara corregido


pero si quereis corregirlo ya:


uverifactuFuncs.pas (D10):


reemplazar esta funcion:

En la anulación me devuelve esto

he comprobado y en VerifactuD7.addRegistroInicial(factura,fecha,huella)
Le estoy pasando los parametros correctos, pero la simulación me graba esos datos en el registro de anulación. Estoy dando de baja una factura enviada ayer.

En las altas funciona bien.

con la correccion que envie sobre la DLL deberia quedar solucionado. Usando la demo hice una baja sin problema. Estaba enviado como se ve en tu registro la huella como numserie.

slds

Correcto con la corrección la anulación funciona correctamente.
¡Gracias!

nueva version 3.0

En espera de su publicacion

Ya está publicada la versión 3.0 en el FTP del club.

TRegistroFacturaStatus:

empezamos bien:

para que funcione correctamente el tema del status segun la automatizacion ejecutada por el componente, algo que puede venir bien para documentar el registro, hay que cambiar esto en

la unidad uverifactuFuncs (D10) y recompilar la DLL

El resto de funciones estan correctas. Este cambio y otros apareceran la semana que viene en el 3.1


y

Generacion de huella

este es un tema sobre el que tengo dudas.

el componente, genera la huella durante el envio de la factura. Si enviamos en el momento de hacer la factura, no hay problema. La huella generada coincide con la generacion de la factura.

Si la factura no pasa (por motivos tecnicos, fallo de la AEAT o de internet), no se cambia nada de la factura, y se reenvia de nuevo, se generara otra huella con la fecha y hora actualizadas. Que podria diferir del momento de la generacion de la factura.

( Eso si: si la fecha de la factura es distinta a la actual se activara el flag de incidencia, pero con una fecha de generacion de registro actual que NO coincidira con la fecha de la factura )

Habiendo revisado la documentación y teniendo en cuenta que no es un reenvio, sino que en el intento anterior por algún motivo, no pudo hacerlo. La huella debería ser la misma que en el primer intento y debiendo coincidir con el envio que se complete, ya que esa coincidiría la fecha de expedición y la de generación (entrada en nuestro registro SIF - primer intento -). Yo genero el registro SIF pero por motivos ajenos al sistema de facturación, no puedo enviar el registro.

Es como lo entiendo y veo. Por favor corregirme si estoy en un error.
Un saludo,

Yo creo que, aunque no se pueda enviar la factura por lo que sea, la huella no habría que cambiarla. La factura se ha emitido en un momento determinado y eso no se debería de cambiar. Yo en particular no cambio absolutamente nada de la factura aunque la envíe más tarde, lo único es el parámetro de incidencia si veo que se retrasa más de lo estipulado.


Saludos.

si, yo pienso lo mismo. De ahi mis dudas. (gracias)

hare pruebas, en principio se me ha ocurrido:

1) un evento que se enviara al calcular la huella de una factura, asi pase lo que pase, siempre se podra guardar, y/o bien al añadir la factura. (ya hay una funcion sin uso, que podria hacer eso)

(es mas seguro guardar la huella antes del envio, que recogerla tras el envio como se hace ahora)

2) al añadir la factura, se adjunta la huella archivada (lo cual indicaria de facto una incidencia), o no se adjunta, lo cual indicaria que es la primera vez que se intenta enviar, por tanto se enviara el evento.

3) enviar con incidencia o no segun ocurra.

Saludos !

capicom
 

como hacemos si no usamos capicom para los certificados, de que forma puedo indicar el certificado y el password para poder transmitir la factura a la aeat.


No hay posibilidad de decirle nombre de certificado y password ?????

en el nombre del certificado el nombre de archivo .pfx o .p12
en passwordcertificado pues eso.

Ya esta todo prácticamente modificado. Para que funcione en esos "envios fallidos".

Pero.. una pregunta mas

El encadenamiento de esa factura reenviada, contra que se hace?

¿El encadenamiento original de cuando se genero el registro?

¿o el nuevo encadenamiento del registro anterior?

Saludos !

Ya lo hemos hablado.
Yo creo que ese comportamiento es erróneo según la documentación.

Creo que la huella dela factura, los encadenamientos, los QR,... se deben generar en el momento de crear la factura, independientemente de cuando se envíe.
Si por lo que sea el envío no puede hacerse, el sistema debe seguir funcionando de forma "normal".

Perdonad, si no estáis refiriéndoos a esto y estoy "meando fuera de tiesto".

Fecha a Guardar Encadenamieno
 

Hola, lo que teneis que tener en cuenta es que el dato

Significa, Fecha y Hora + Huso Horario "Generacion Registro"
No pide la fechaca hora del envio, el envio puede ser despues, por varios motivos, incluso no haber envio, si estamos en no Verifactu.
Por logica se tiene que guardar en el momento de emitir/crear la factura/registro, no en el momento del envio, tampoco se puede modificar y "Siempre", consultar los datos del ultimo HASH, del encadenamiento para continuar con la cadena, sea de lo que sea, porque si encadenamos las acciones, hemos de encadenar con su cadena independiente a los de registros de facturacion.

Si a lo que te refieres es si se ha de cambiar el encadenamiento , no de ningun modo, el encadenamiento se refiere a cada registro.
Que puede ser de alta , baja ,etc, esto es lo que hay que encolar, guardar, etc para enviar/ reenviar, con sus datos originales, tanto si se envia al momento , como en diferido.
Asignando en la cabecera , si ha habido algun error, etc...

Espero que entre todos lo dejemos mas claro.

gracias por las aclaraciones

En la proxima actualizacion sera posible enviar una factura con su huella original y anterior original. si han pasado mas de 2 minutos desde la huella proporcionada, marcara como incidencia ese envio. ¿ ese tiempo de 2 minutos esta bien ?

En principio la forma de trabajar con el componente sería, de forma simplificada.

INICIO

1) hago una factura
2) inmedatamente la envio, (con exito, o no, me da lo mismo, igual que imprimo la envio)
3) obtendre su huella, la archivo en la factura
4) proceso el envio (si es posible, podria ser que no, debido a causas externas, si es posible guardo el csv )

FIN

ADICIONALMENTE:

1) Crear una lista de facturas pendientes de envio
2) Enviarlas en cuanto sea posible, reutilizando esa huella y huella anterior almacenada


Creo que el proceso cumple. Para procesos de facturacion individuales.

Con este tema, creo que queda cerrado ya todos los flecos a falta de probarlo.

Su implementacion en los que lo esten usando sera muy simple.

gracias !

Nota: en mi caso particular, ni pregunto, ni hago pausas, se pulsa el boton de facturar y se envia la factura, despues se imprime. por tanto generacion del registro y envio van de la mano. Si el envio NO se completa, queda archivada la huella que sera reutilizada en su reenvio.