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

[delphiGar]

Empezado por seccion_31

Ahora mismo no los estoy enviando, y los registros son aceptados.
Pero dice que es obligatorio y en la hoja de calculo informativa NO aparecen en rojo.

Entiendo que es para indicar que el programa permite en teoria la facturacion de varios emisores.

Entiendo que es para indicar si en el programa de facturacion tienes registrados al menos dos emisores. (envien registros o no), pero que en tu base de datos figuran. Es decir un programa tiene dos emisores en su bd, envia registros de alta de uno de ellos, pero al tener dos emisores registrados este campo sera true.

¿porque no aparecen en rojo en la hoja de calculo? (como obligatorios)

¿estoy interpretando bien esos campos?

Saludos !

El campo TipoUsoPosibleMultiOT es para indicar si tu programa puege gestionar mas de un OT y el campo IndicadorMultiplesOT es para indicar si lo esta haciendo.

Si tu programa puede gestionar varios OT y tienes un solo OT seria:

TipoUsoPosibleMultiOT=S
IndicadorMultiplesOT=N

Si tu programa puede gestionar varios OT y tiene dos o mas:

TipoUsoPosibleMultiOT=S
IndicadorMultiplesOT=S

Si tu programa solo admite un OT:

TipoUsoPosibleMultiOT=N
IndicadorMultiplesOT=N

[jlmoli_67]

Buenas,
Si tu programa puede gestionar varios OT y tiene dos o mas:
Código:
TipoUsoPosibleMultiOT=S IndicadorMultiplesOT=S
En este caso supongo que un mismo sif puede encargarse de enviar de forma independiente (primero una empresa, luego otra, ....) los registros de facturacion, no?

[seccion_31]

Empezado por jlmoli_67

Buenas,
Si tu programa puede gestionar varios OT y tiene dos o mas:
Código:
TipoUsoPosibleMultiOT=S IndicadorMultiplesOT=S
En este caso supongo que un mismo sif puede encargarse de enviar de forma independiente (primero una empresa, luego otra, ....) los registros de facturacion, no?

gracias por las respuestas ! esto sera novedad en la 2.1

En mi caso particular desde dos puestos podrian enviar a la vez, siempre que el emisor sea distinto. (con un nivel muy muy bajo de facturas emitidas). Ni se va a dar.

[seccion_31]

ahora hay otra cosa que me preocupa.

y esto deberia preocuparnos a todos los que usamos el componente.

el uso del stack y los arrays.

Actualmente (2.0) soportamos tipo de operacion con un maximo de 255 caracteres para un array de envio de 1000 facturas. Cuando en realidad deberian ser 500 digitos. Eso esta mal. (yo no lo veo bien).

He conseguido colocar el widestring que soporta ya los 500 digitos para un array de 500 facturas. Creo que es mejor enviar 500 facturas correctas que 1000 no muy bien. (cortadas a 255).

Cuando he tratado de forzar esos limites, empieza a comportarse de forma erratica, incluso con errores de proteccion general. Creo que la limitacion viene en la consulta, porque pasan por el stack de la DLL a la aplicacion, no lo se muy bien. Con la 3.0 sacandolo del stack y colocando el evento (ver abajo), quizas quedaria corregido y podriamos volver a las 1000 de envio.

Deberiamos someter al componente 2.1 cuando este publicado, a una prueba de stress simulando 500 facturas con tipos de operacion de 500 digitos. (pienso que hacerlo en modo simulado sin enviar seria suficiente y analizar que pasa).


¿que opiniais?



Por otro lado creo que para la version 3 voy a incorporar un evento para recibir las consultas.

En una sola pagina de consulta te pueden enviar hasta 10.000 registros, pero el componente solo soporta 1000. Con un evento se podrían recibir los 10.000 sin problemas. Sin soportar paginacion creo que ya es mas que suficiente para un periodo de consulta y un emisor "normal".

de nuevo, ¿que opiniais?

[ramherfer]

Empezado por seccion_31

ahora hay otra cosa que me preocupa.

y esto deberia preocuparnos a todos los que usamos el componente.

el uso del stack y los arrays.

Actualmente (2.0) soportamos tipo de operacion con un maximo de 255 caracteres para un array de envio de 1000 facturas. Cuando en realidad deberian ser 500 digitos. Eso esta mal. (yo no lo veo bien).

He conseguido colocar el widestring que soporta ya los 500 digitos para un array de 500 facturas. Creo que es mejor enviar 500 facturas correctas que 1000 no muy bien. (cortadas a 255).

Cuando he tratado de forzar esos limites, empieza a comportarse de forma erratica, incluso con errores de proteccion general. Creo que la limitacion viene en la consulta, porque pasan por el stack de la DLL a la aplicacion, no lo se muy bien. Con la 3.0 sacandolo del stack y colocando el evento (ver abajo), quizas quedaria corregido y podriamos volver a las 1000 de envio.

Deberiamos someter al componente 2.1 cuando este publicado, a una prueba de stress simulando 500 facturas con tipos de operacion de 500 digitos. (pienso que hacerlo en modo simulado sin enviar seria suficiente y analizar que pasa).


¿que opiniais?



Por otro lado creo que para la version 3 voy a incorporar un evento para recibir las consultas.

En una sola pagina de consulta te pueden enviar hasta 10.000 registros, pero el componente solo soporta 1000. Con un evento se podrían recibir los 10.000 sin problemas. Sin soportar paginacion creo que ya es mas que suficiente para un periodo de consulta y un emisor "normal".

de nuevo, ¿que opiniais?

Por mi parte, aunque son cifras que mi aplicación en estos momentos son inimaginables, y que tampoco tengo un conocimiento extremo como para dar una opinión acertada, cualquier cosa que sea una mejora me parece correcta, no lo siguiente. Y por la lógica de la explicación siempre será mejor enviar menos pero correcto que más y que de problemas.

Aprovecho para realizar una observación. Teniendo el siguiente desglose que no debería ser, pero se podría dar el caso y a nivel de aplicación es totalmente correcto:

<Desglose>
<DetalleDesglose>
<ClaveRegimen>01</ClaveRegimen>
<CalificacionOperacion>S1</CalificacionOperacion>
<TipoImpositivo>21.00</TipoImpositivo>
<BaseImponibleOimporteNoSujeto>459.00</BaseImponibleOimporteNoSujeto>
<CuotaRepercutida>96.39</CuotaRepercutida>
</DetalleDesglose>
<DetalleDesglose>
<ClaveRegimen>01</ClaveRegimen>
<CalificacionOperacion>S1</CalificacionOperacion>
<TipoImpositivo>21.00</TipoImpositivo>
<BaseImponibleOimporteNoSujeto>722.50</BaseImponibleOimporteNoSujeto>
<CuotaRepercutida>151.73</CuotaRepercutida>
</DetalleDesglose>
</Desglose>
<CuotaTotal>248.12</CuotaTotal>
<ImporteTotal>1333.23</ImporteTotal>

Los codigos de iva los tengo codificados y en un albarán por error se asignó un codigo de iva distinto pero que iva tambien al 21%. La cuestión es que en una factura iban dos lineas con el 21% una con el codigo 01 y otra con el codigo 21 (Ya digo que es un error pero que debía haber sido aceptado y teniendo la base imponible bien y el total factura tambien), en el importe total se puede observar que falta sumar la primera linea de iva, cuando en la factura estaba incluidas ambas lineas y el total factura era 1429,62.

No he podido saber por que la primera cuota no se agregó al total factura. Desconozco si ha sido un filtro de la AEAT al haber un segundo registro de iva con el mismo porcentaje.

[seccion_31]

Empezado por ramherfer

Por mi parte, aunque son cifras que mi aplicación en estos momentos son inimaginables, y que tampoco tengo un conocimiento extremo como para dar una opinión acertada, cualquier cosa que sea una mejora me parece correcta, no lo siguiente. Y por la lógica de la explicación siempre será mejor enviar menos pero correcto que más y que de problemas.

Aprovecho para realizar una observación. Teniendo el siguiente desglose que no debería ser, pero se podría dar el caso y a nivel de aplicación es totalmente correcto:

<Desglose>
<DetalleDesglose>
<ClaveRegimen>01</ClaveRegimen>
<CalificacionOperacion>S1</CalificacionOperacion>
<TipoImpositivo>21.00</TipoImpositivo>
<BaseImponibleOimporteNoSujeto>459.00</BaseImponibleOimporteNoSujeto>
<CuotaRepercutida>96.39</CuotaRepercutida>
</DetalleDesglose>
<DetalleDesglose>
<ClaveRegimen>01</ClaveRegimen>
<CalificacionOperacion>S1</CalificacionOperacion>
<TipoImpositivo>21.00</TipoImpositivo>
<BaseImponibleOimporteNoSujeto>722.50</BaseImponibleOimporteNoSujeto>
<CuotaRepercutida>151.73</CuotaRepercutida>
</DetalleDesglose>
</Desglose>
<CuotaTotal>248.12</CuotaTotal>
<ImporteTotal>1333.23</ImporteTotal>

Los codigos de iva los tengo codificados y en un albarán por error se asignó un codigo de iva distinto pero que iva tambien al 21%. La cuestión es que en una factura iban dos lineas con el 21% una con el codigo 01 y otra con el codigo 21 (Ya digo que es un error pero que debía haber sido aceptado y teniendo la base imponible bien y el total factura tambien), en el importe total se puede observar que falta sumar la primera linea de iva, cuando en la factura estaba incluidas ambas lineas y el total factura era 1429,62.

No he podido saber por que la primera cuota no se agregó al total factura. Desconozco si ha sido un filtro de la AEAT al haber un segundo registro de iva con el mismo porcentaje.

en el registro que tienes se han enviado los 2, asi que ha sido la AEAT la que lo ha rechazdo.

¿que deberia hacer el componente?

¿generar una excepcion que impida añadir esa factura, con ese caso?

¿o sumar ambas cuotas y colocarlas con su iva?


Creo que lo mejor es el 1 er. caso.

Saludos !

[ramherfer]

Nada tranquilo, esta bien.
He modificado la aplicación para que no vuelva a ocurrir, que es lo más correcto. Antes de emitir las facturas comprueba que no hayan dos lineas de iva con el mismo porcentaje.
El componente está funcionando bien y hace lo que tiene que hacer.
Gracias.

[seccion_31]

ya esta publicada la version 2.1 en espera del enlace para el foro:

version 2.1
----------------------------------------------------------------------------------------------------------------------------
Elevar el max. stack a $00510000 (recomendado) (hoy x hoy el tema del stack es un terreno desconocido)

Descripcion de operacion pasa de string a widestring para albergar 500 digitos
Se reducen de 1000 facturas por envio a 500 facturas (maximo)

Si no se espcifica url endpoint no se inicia sesion (antes lo hacia con el de pre-produccion por defecto)

Respuesto, modificado: EN SISTEMA INFORMATICO:

SistemaInformatico.TipoUsoPosibleMultiOT:=false; // capacidad del software para gestionar varios emisores ?
SistemaInformatico.IndicadorMultiplesOT :=false; // 1 solo emisor registrado por el software ?
SistemaInformatico.TipoUsoPosibleSoloVerifactu:=true; // la aplicacion funciona unicamente en modo verifactu ?

Utilizados tambien en la consulta cuando se busca por SIF

Nuevo:

ClaveRegimen 18. Recargo de equivalencia
Cuando una factura lleva recargo se cambia automaticamente a claveRegimen=18

Corregida la demo cuando carga una excel, se borran filas y se volvia cargar de nuevo otra excel.

Ahora esta disponible una funcion para verificar que la AEAT esta funcionando:

function TVeriFactu.VerifactuActivo:boolean;

Ejemplo:
VeriFactuD7.Certificado :=comboCertificados.text;
VerifactuD7.Emisor.NombreRazonEmisor :=editEmisor.Text;
VerifactuD7.Emisor.nifEmisor :=editNIFEmisor.Text;
VerifactuD7.urlEndPoint :=editURL.text; // endpoint de la AEAT

if veriFactuD7.VerifactuActivo then
statusBar1.panels[1].Text:='AEAT Activa'
else
statusBar1.panels[1].Text:='AEAT Inactiva';

Para ello se realiza una consulta muy simple por numero de factura y se analiza si ha sido correcta.

Ese numero de factura puede ser cambiado al numero de factura que se desee mediate la variable global VERIFACTUACTIVOPING por ejemplo:

VERIFACTUACTIVOPING:='ACTIVOVERIFACTU'; aunque el valor inicial es '*' y funciona perfectamente.

coregido el form principal de la demo, visible=true

Advertencia: el LOG que se puede guardar al final de una sesion de envio, esta obsoleto desde la conversion a DLL y no devuelve nada.

Suprimido: outputdebugstring por incompatibilidad con otras veresiones de D7.

corregida asignacion de fecha y hora del resultado de envio, estaban cambiadas una por otra.

[NANAUJ1970]

Tengo unas dudas con las librerias.
Estaba usando hasta ahora D6 y acabo de instalar D7 y cuando quiero usar librerias tipo:

System.SysUtils, System.Classes, Soap.Rio, Xml.XMLIntf, Soap.SOAPHTTPClient, Soap.SOAPHTTPTrans etc

me dice que no encuentra el .dcu....

Alguien pude ayudarme por favor diciendome donde se encuentran y como instalarlas

Gracias de antemano

[NANAUJ1970]

Tengo unas dudas con las librerias.
Estaba usando hasta ahora D6 y acabo de instalar D7 y cuando quiero usar librerias tipo:

System.SysUtils, System.Classes, Soap.Rio, Xml.XMLIntf, Soap.SOAPHTTPClient, Soap.SOAPHTTPTrans etc

me dice que no encuentra el .dcu....

Alguien pude ayudarme por favor diciendome donde se encuentran y como instalarlas

Gracias de antemano

[NANAUJ1970]

Tengo unas dudas con las librerias.
Estaba usando hasta ahora D6 y acabo de instalar D7 y cuando quiero usar librerias tipo:

System.SysUtils, System.Classes, Soap.Rio, Xml.XMLIntf, Soap.SOAPHTTPClient, Soap.SOAPHTTPTrans etc

me dice que no encuentra el .dcu....

Alguien pude ayudarme por favor diciendome donde se encuentran y como instalarlas

Gracias de antemano

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

Se ha subido al FTP la versión 2.1 de la DLL.
https://terawiki.clubdelphi.com/Otro...%20Delphi%207/

[seccion_31]

La versión 3.0 incorporara:

Las 1.000 facturas de envío, con descripción de operación completa a 500 dígitos

Un evento para recibir consultas con mas de +1.000 facturas, hasta las 10.000 que puede enviar la AEAT en la primera pagina.

Además de mantener también las primeras 1.000 consultadas como en la actualidad en el array.

Demo mejorada, para mostrar el funcionamiento de los eventos.

Eso si, se restringe en la consulta la descripción de operación a 255 dígitos.

Saludos !

[Galahad]

Hola, buenas tardes.
Estoy intentando compilar el proyecto verifactuformd7 en delphi 12.1 y crea un ejecutable, pero no válido,, aparece el error:

'No se encuentra el punto de entrada del procedimiento setbackgroundcolor en la biblioteca de vinculos dinamicos verifactuformd7.exe'

es compatible el proyecto con delphi 12.1 ¿?

[seccion_31]

Empezado por Galahad

Hola, buenas tardes.
Estoy intentando compilar el proyecto verifactuformd7 en delphi 12.1 y crea un ejecutable, pero no válido,, aparece el error:

'No se encuentra el punto de entrada del procedimiento setbackgroundcolor en la biblioteca de vinculos dinamicos verifactuformd7.exe'

es compatible el proyecto con delphi 12.1 ¿?

Ni idea si es compatible con D12. La aplicacion demo es compatible con D7.

No hay un punto de entrada con ese procedimiento dentro de verifactu.dll, eso si, debes registrar capicom.dll

[Galahad]

Empezado por seccion_31

Ni idea si es compatible con D12. La aplicacion demo es compatible con D7.

No hay un punto de entrada con ese procedimiento dentro de verifactu.dll, eso si, debes registrar capicom.dll

Ok, muchas gracias

[mqm]

Hola, buenas tardes.
Estoy intentando compilar el proyecto verifactuformd7 en delphi 12.1 y crea un ejecutable, pero no válido,, aparece el error:
'No se encuentra el punto de entrada del procedimiento setbackgroundcolor en la biblioteca de vinculos dinamicos verifactuformd7.exe'
es compatible el proyecto con delphi 12.1 ¿?

El problema lo tienes en la unit QuricolAPI.pas. Puedes omitir la generación del QR e intentar compilarlo con delphi 12.

[Galahad]

Empezado por mqm

El problema lo tienes en la unit QuricolAPI.pas. Puedes omitir la generación del QR e intentar compilarlo con delphi 12.

Efectivamente, comentando el código de la generación del QR ya compila con delphi 12.1,,
Muchas gracias,,,

[mqm]

Con la última versión al realizar la consulta de un periodo, si marco filtrar SIF me devuelve 0, si lo desmarco me aparecen todas las pruebas realizadas incluyendo las que yo he hecho.
¿A alguien más le pasa esto?

[seccion_31]

Empezado por mqm

Con la última versión al realizar la consulta de un periodo, si marco filtrar SIF me devuelve 0, si lo desmarco me aparecen todas las pruebas realizadas incluyendo las que yo he hecho.
¿A alguien más le pasa esto?

esta filtrando con los valores por defecto de multiplesOT, indicador y modosoloverifactu. (añadidos a sistemaInformatico) si los colocas como se enviaron los registros te lo encontrara.

¿Es un tema, que habra que darle una vuelta para poder omitirlos o no en la busqueda por SIF? solucion, tenerlos como caracter para determinar S/N/blanco y asi poder incluirlos o no en el filtro. (o añadir algun indicador para buscar por cada uno de ellos opcionalmente:


filtroModoVerifactu:boolean;
filtroPosiblesMOT :boolean;
filtroIndicadorMOT :boolean;

Esto ira nuevo en la 3.0