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

[seccion_31]

Empezado por DarkDudae

Entiendo que para ventas desde la península a Canarias, estaríamos hablando de una operación general 01 con tipo de excención E03.

Para las operaciones que mencionas, creo que todas serían el tipo E04:

Tipo de Exención,ClaveRegimen en VeriFactu,Base Legal
Servicios médicos y sanitarios,04,Art. 20. Uno. 2º Ley IVA
Servicios educativos y formación,04,Art. 20. Uno. 9º y 10º Ley IVA
Servicios sociales (ONG, entidades sin ánimo de lucro),04,Art. 20. Uno. 8º Ley IVA
Servicios deportivos o culturales exentos,04,Art. 20. Uno. 13º y 14º Ley IVA
Operaciones exentas relacionadas con seguros y finanzas,04,Art. 20. Uno. 16º y 18º Ley IVA
Operaciones exentas por razones de interés general (ej. asociaciones, fundaciones),04,Art. 20. Uno. 12º Ley IVA

¿podemos estar seguro?

¿ entonces bajo el regimen general 01, la E4 ? esta tarde lo probare.

Automatizacion:

podemos automatizar, UE, fuera de UE, y canarias. Eso ya esta automatizado , (hay que modificar los tipos de exenciones que hay en el codigo, pero ya esta)

podemos automatizar facilmente, el E4, colocandole el regimen general 01. (si funciona).


Mas alla de esto, ¿ya no se puede automatizar?:

¿Quizas habria que crear un array particular para exenciones y cubrir el resto de casos?

[nincillo]

Empezado por seccion_31

¿podemos estar seguro?

¿ entonces bajo el regimen general 01, la E4 ? esta tarde lo probare.

Automatizacion:

podemos automatizar, UE, fuera de UE, y canarias. Eso ya esta automatizado , (hay que modificar los tipos de exenciones que hay en el codigo, pero ya esta)

podemos automatizar facilmente, el E4, colocandole el regimen general 01. (si funciona).


Mas allá de esto, ¿ya no se puede automatizar?:

¿Quizás habría que crear un array particular para exenciones y cubrir el resto de casos?

Yo por lo que he podido ver en algún otro programa, he querido entender que las exenciones pueden incluso ir a nivel de apunte.

Eso sería bueno que nos lo aclarara alguien que estuviera más "ducho" en temas contables/fiscales.

No es lo mismo productos al 0% de IVA que productos "exentos" de IVA, como en su momento creo que eran las mascarillas y cosas de "esas".

[seccion_31]

en la nueva version DLL hay un array para procesar exenciones, sin la automatizacion del array de ivas, con lo que quedaria solucionado. Eso si, hay que saber de fiscalidad para que el programa lo coloque corectamente. La nueva implementacion supera con creces la anterior.

Pero ese es el problema, yo al menos no se tanto de fiscalidad como asegurar que se estan generando bien los xml.

seria necesario y esto es una llamada de auxilio XD

un juego de XMLs para los casos principales, automatizados por el componente para verificar.


y otro despues para los menos comunes.

Pero sin eso aunque tecnicamente el componente funcione, estamos vendidos.

[ramherfer]

Hola buenas tardes.
Al procesar la respuesta resultado.facturas[j].tipoOperacion me está devolviendo "SistemaFac" cuando la factura contiene algún error y es rechazada.
Si la factura es correcta y es admitida resultado.facturas[j].tipoOperacion devuelve "Alta".
Solo proceso una factura y utilizo este dato para identificar en el registroFacturación la operación de la factura a la que se refiere y actualizar su estado, movimiento.

En operaciones Baja declaradas en el registroFacturación obtengo un Access Violation en el módulo msgVerifactu.exe. He probado como fecha de factura la fecha actual y la propia fecha de la factura que se da de baja, pero no se, obtengo el mismo resultado. Voy a darle un vistazo a ver si soy capaz de encontrar el problema.

Al final creo que entiendo el sistema y tengo todo el tema de comunicaciones en una tabla independiente llamada RegistroSIF con las operaciones de cada una de las facturas (Alta, baja, modificacion, etc) que se relaciona con la tabla de cabeceras de facturas. Si genero una baja entra en RegistroSIF como baja y la cabecera de factura tambien la pone como baja. De esta forma puede tener una factura distintos movimientos o estados FR250056 ALTA y FR250056 BAJA. Gracias a los que me aclarasteis mi monumental lio mental.

Un saludo,

[seccion_31]

Empezado por ramherfer

Hola buenas tardes.
Al procesar la respuesta resultado.facturas[j].tipoOperacion me está devolviendo "SistemaFac" cuando la factura contiene algún error y es rechazada.
Si la factura es correcta y es admitida resultado.facturas[j].tipoOperacion devuelve "Alta".
Solo proceso una factura y utilizo este dato para identificar en el registroFacturación la operación de la factura a la que se refiere y actualizar su estado, movimiento.

En operaciones Baja declaradas en el registroFacturación obtengo un Access Violation en el módulo msgVerifactu.exe. He probado como fecha de factura la fecha actual y la propia fecha de la factura que se da de baja, pero no se, obtengo el mismo resultado. Voy a darle un vistazo a ver si soy capaz de encontrar el problema.

Al final creo que entiendo el sistema y tengo todo el tema de comunicaciones en una tabla independiente llamada RegistroSIF con las operaciones de cada una de las facturas (Alta, baja, modificacion, etc) que se relaciona con la tabla de cabeceras de facturas. Si genero una baja entra en RegistroSIF como baja y la cabecera de factura tambien la pone como baja. De esta forma puede tener una factura distintos movimientos o estados FR250056 ALTA y FR250056 BAJA. Gracias a los que me aclarasteis mi monumental lio mental.

Un saludo,

Esta pendiente el cambio a la version DLL, asi a bote pronto recuerdo que la baja daba error.

En cuanto lo publiquen en el FTP, que ya tienen el enlace, lo readaptas y vuelves a probar

Estos son los cambios de la nueva version , donde tambien ha colaborado el usuario darkdudae, a quien agradezco su trabajo.
(Algunos de ellos estan sin comprobar).

> Nota general:
Ahora el servidor B10 ya no se suministra como aplicacion. Tenemos una DLL llamada veriFactu.dll


cuando se cambia un type (record). etc... en uTiposVeriFactu se deben recompilar verifactu.dll y aplicacion D7.
La compilacion de la DLL se guarda en la carpeta DEMO_D7 para facilitar las pruebas


Si ha utilizado la version anterior del componente, eliminarlo
Antes de registrar el componente copiar la DLL a syswow64
----------------------------------------------------------------------------------------------------------------------------


--------------------------------
---------------- version 1
--------------------------------
Se añade la funcion getCertificadosFecha para obtener no solo el nombre de los certificados si no su fecha de validez. En las funciones de certificados solo se devuelven certificados validos.

Aumentada longitud DescripcionError en el resultado de cada factura (array)

Se añade propiedad ultimo_error_verifactu con el texo de error al añadir una factura, de momento solo recoge algunos errores. Puede leerse si la funcion VeriFactuD7.addFactura retorna -1. (ver demo de ejemplo).


Se añaden en el componente las propiedades nsesion y nfacturas (numero de facturas altas y baja preparadas para enviar) como propiedades de solo lectura

Se eliminan del record TRegistroFactura nsesion y nfactura

En la DEMO se elimina del formulario el componente TVeriFactu pasando a ser creado al inicio del formulario, se incluye un ejemplo del nuevo evento OnRegFac, de esta forma ya no es necesario instalar el componente en Delphi y la DLL puede ser mantenida en el directorio de la Demo.

---> Se cambian las exenciones de operaciones EU a E5 y Export a E2, se automatiza el tipoNIF si NO esta indicado. Para EU 02 y para Export 06 (otro doc.probatorio).

Se incluye un array en la unidad uTiposVeriFactu llamado _AyudaExentas[1..6] que contiene un resumen textual de las exenciones a modo informativo.

Se añaden las funciones Paises PaisesEU PaisesExport Para obtener una lista de paises validos en un TStringList. ( ES: España se considera fuera de la lista en PaisesEU retornada )

Se añade la funcion validPais para validar el codigo de pais (ya con max. 3 digitos)

Automatizacion de facturas a España (canarias):
En codigoPais podemos enviar ahora el codigo postal de la provincia del cliente. Si se detecta valor numerico se procesara como españa, y ADEMAS si el codigo postal es 35 ó 38 se activara automaticamente el flag de canarias.

Se añade el evento OnRegFac que sera lanzado cuando se procese cada registro de facturacion, es decir, podemos dejar en blanco el pathXML_RegistroFacturacion y todavia guardar el archivo que nos ira enviando como un Stream al evento definido por el usuario: (o utilizar ambos, archivo y evento)

TRegistroFacEvent = procedure(Sender: TObject; numserieFactura:string; xml:TMemoryStream) of object;

Añadida busqueda por SIF en la funcion consulta(..... ) filtroSIF=true filtrara ademas por los datos del sistema informatico. Ver ejemplo en la Demo en consulta de periodo

Se añade refexterna en el dato de la factura, para indicar informacion libre, 60 digitos. tanto en alta/anulacion como en la consulta

Se añade el path para indicar donde guardar los registros de facturacion y una variable booleana para indicar si se guardan todos los registros o solo los aceptados, ATENCION: con una limitacion, podrian guardarse registros innecesarios de facturas con operaciones aceptadas y no aceptadas en la misma sesion de envio (si se da el caso).

pathXML_RegistroFacturacion (ruta a la carpeta, sin terminar en \)
Registro_soloAceptadas (true o false) (false= guardara todas los registros de facturacion)

Hay dos cambios de nombres en el archivo de XML:
Se cambian las variables de los xml de envio y de respuesta a: (para hacerlos mas consistentes)

filenameXML_Envio
filenameXML_Respuesta

Se corrije la consulta por fechas

La demo ha sido muy mejorada, con mas funciones y capacidad

Se añade el campo estadoderegistro en el array de la consulta para cotejar facturas (en cada factura) con los valores: Aceptada, Aceptada con errores, Anulada

Se corrigen las fechas devueltas por consulta a formato / /

Corregido fallo al dar de baja una factura, de momento solo se admiten bajas de facturas registradas en verifactu

-----------------------
Inversion del sujeto pasivo: Hay un nuevo flag que afecta todos los ivas llamado inversionSUjetoPasivo en el record de factura para facturas a ESPAÑA (no canarias):

"
- El proveedor o prestador del servicio registrará los datos de la factura en el Libro
registro de Facturas Expedidas consignando en el campo de tipo de operación la clave
“S2: Sujeta – No Exenta – Inv. Suj. Pasivo”. En los campos de tipo impositivo y cuota"
repercutida consignará “0”. -

"

> Toda la factura debe estar bajo ese regimen y utilizar el primer IVA para indicar unicamente la base imponible.
-----------------------

Corregido error al cotejar (consultar) una factura sin cliente, ni nif.

Eliminada variable situacion, por no usar

Si se suministra una fecha de factura en formato - - se convierte a / / que es el formato esperado

Se añade la extension .P12 para reconocer un certificado en disco al nombre del certificado: PFX y P12

Se añade el indicador primerRegistro para comprobar antes de enviar si no hay registro anterior en algun punto de las facturas a enviar.

Ahora hay dos indicadores: incidencia (lectura/escritura) y primerRegistro(lectura).

En la consulta a la AEAT, en desglose de iva ahora se carga la base imponible e incluye informacion sobre exencion,
revisar: TRegistroFacturaIVASConsulta

Cliente codpais pasa de 2 a 3 digitos

Se ha mejorado la limpieza de algunos records funciones clear_ internas del servidor B10 (ahora DLL)

Al validar el NIF ya se puede obtener el nombre validado (devuelto por la consulta)

EXENCIONES AUTOMATICAS : (en array iva)
------------------------
Las facturas con pais destino a la EU automaticamente se consideran tipoExenta E6 clave regimen 01 (ahora E5)

Las facturas con pais destino al resto del mundo (en clave regimen 02) y canarias (en clave regimen 01) automaticamente se consideran tipoExentas E3 (ahora E2)

Las facturas de inversion sujeto pasivo (para españa)


OTRAS EXENCIONES: (en array exenta)
-----------------
En el record de facturas hay un nuevo array para crear OTRAS exenciones:
Este array se procesa tal cual sin otro proceso generando el desglose equivalente.

Record Factura:

exenta: array[0..maxivas] of TRegistroFacturaExentas;


Array de:

TRegistroFacturaExentas=record
tipoExenta :string[2];
calificacionOperacion:string[2]; // ¿opcional?
claveRegimen :string[2];

baseImp :currency;
end;

Para indicar si la factura lleva alguna base imponible exenta, se hara de forma similar a la del iva, pero cambiando el array. (ver ejemplo en el importador de excel)

Asi mismo un record similar se encuentra en la consulta a la AEAT, para retornar informacion sobre las facturas exentas: (exenciones creadas automaticas, o manuales con el array).

Nota de uso: Cada sesion deberia limitarse a una serie de facturacion y por supuesto 1 solo objeto TVeriFactu

Saludos !

[seccion_31]

Empezado por ramherfer

Hola buenas tardes.
Al procesar la respuesta resultado.facturas[j].tipoOperacion me está devolviendo "SistemaFac" cuando la factura contiene algún error y es rechazada.
Si la factura es correcta y es admitida resultado.facturas[j].tipoOperacion devuelve "Alta".
Solo proceso una factura y utilizo este dato para identificar en el registroFacturación la operación de la factura a la que se refiere y actualizar su estado, movimiento.

En operaciones Baja declaradas en el registroFacturación obtengo un Access Violation en el módulo msgVerifactu.exe. He probado como fecha de factura la fecha actual y la propia fecha de la factura que se da de baja, pero no se, obtengo el mismo resultado. Voy a darle un vistazo a ver si soy capaz de encontrar el problema.

Al final creo que entiendo el sistema y tengo todo el tema de comunicaciones en una tabla independiente llamada RegistroSIF con las operaciones de cada una de las facturas (Alta, baja, modificacion, etc) que se relaciona con la tabla de cabeceras de facturas. Si genero una baja entra en RegistroSIF como baja y la cabecera de factura tambien la pone como baja. De esta forma puede tener una factura distintos movimientos o estados FR250056 ALTA y FR250056 BAJA. Gracias a los que me aclarasteis mi monumental lio mental.

Un saludo,

Aun asi puedes (y deberias) procesar la factura con

resultado.facturas[j].OK
y una vez OK entonces mirar tambien: resultado.facturas[j].aceptadoConErrores

tipoOperacion: Probablemente cuando es procesada la factura delphi interpretara ese valor dentro de los enum de tipo de operacion, muy probablemente en el campo XML no venga indicado si quiera. Si quieres postea el XML de resultado cuando ocurre eso. Ya adeverti que hace cosas raras cuando no hay valor un campo enum. quizas sea el caso.

Ver ejemplo en la demo:

            if resultado.facturas[j].OK then   // Es correcto ó aceptado con errores
            begin
                // colocar el csv y huella en la factura
                if facturasEnviadas.locate('emisor;NumSerieFactura',vararrayof([emisor, factura ]),[]) then
                begin
                    FacturasEnviadas.edit;
                    FacturasEnviadas.fieldbyName('csv').text      :=resultado.CSV;
                    FacturasEnviadas.FieldByName('huella').text   :=resultado.facturas[j].huellaFactura;
                    FacturasEnviadas.fieldbyName('situacion').text:=estado;
                    FacturasEnviadas.post;
                end;
                if resultado.facturas[j].aceptadoConErrores then inc(_oke) else inc(_ok);
            end
            else
                inc(_err);                            // Es erronea

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

En el FTP del clubdelphi ya está la última versión del proyecto con códo el código fuente incluído y todo lo que necesita.
De nuevo, desde aquí agradecer a [seccion_31] la aportación y la colaboración y aportes de [darkdudae].

[ramherfer]

Empezado por seccion_31

Aun asi puedes (y deberias) procesar la factura con

resultado.facturas[j].OK
y una vez OK entonces mirar tambien: resultado.facturas[j].aceptadoConErrores

tipoOperacion: Probablemente cuando es procesada la factura delphi interpretara ese valor dentro de los enum de tipo de operacion, muy probablemente en el campo XML no venga indicado si quiera.
Si quieres postea el XML de resultado cuando ocurre eso. Ya adeverti que hace cosas raras cuando no hay valor un campo enum. quizas sea el caso.

Ver ejemplo en la demo:

            if resultado.facturas[j].OK then   // Es correcto ó aceptado con errores
            begin
                // colocar el csv y huella en la factura
                if facturasEnviadas.locate('emisor;NumSerieFactura',vararrayof([emisor, factura ]),[]) then
                begin
                    FacturasEnviadas.edit;
                    FacturasEnviadas.fieldbyName('csv').text      :=resultado.CSV;
                    FacturasEnviadas.FieldByName('huella').text   :=resultado.facturas[j].huellaFactura;
                    FacturasEnviadas.fieldbyName('situacion').text:=estado;
                    FacturasEnviadas.post;
                end;
                if resultado.facturas[j].aceptadoConErrores then inc(_oke) else inc(_ok);
            end
            else
                inc(_err);                            // Es erronea

Este es el XML del que intento localizar el tipoOperación de la factura para con ese dato y el numero de serie actualizar el RegistroSif para que indique que hay algo con error actualizando el codigo y la descripción del mismo para información del usuario (devuelve SistemaFac). Ojo los datos fiscales los he alterado en el nodo ObligadoEmision

<env:Header/>
<env:Body Id="Body">
<tikR:RespuestaRegFactuSistemaFacturacion xmlns:tikR="https://www2.agenciatributaria.gob.es/......" xmlns:tik="https://www2.agenciatributaria.gob.es/.....xsd">
<tikR:Cabecera>
<tik:ObligadoEmision>
<tik:NombreRazon>Nombre razon social del emisor</tik:NombreRazon>
<tik:NIF>00000000W</tik:NIF>
</tik:ObligadoEmision>
</tikR:Cabecera>
<tikR:TiempoEsperaEnvio>60</tikR:TiempoEsperaEnvio>
<tikR:EstadoEnvio>Incorrecto</tikR:EstadoEnvio>
<tikR:RespuestaLinea>
<tikR:IDFactura>
<tik:IDEmisorFactura>00000000W</tik:IDEmisorFactura>
<tik:NumSerieFactura>FR250056</tik:NumSerieFactura>
<tik:FechaExpedicionFactura>17-02-2025</tik:FechaExpedicionFactura>
</tikR:IDFactura>
<tikR:Operacion>
<tik:TipoOperacion>Alta</tik:TipoOperacion>
</tikR:Operacion>
<tikR:EstadoRegistro>Incorrecto</tikR:EstadoRegistro>
<tikR:CodigoErrorRegistro>1123</tikR:CodigoErrorRegistro>
<tikR:DescripcionErrorRegistro>El formato del NIF es incorrecto.. NIF:24369243S.</tikR:DescripcionErrorRegistro>
</tikR:RespuestaLinea>
</tikR:RespuestaRegFactuSistemaFacturacion>
</env:Body>
</env:Envelope>

[seccion_31]

en uVeriFactuFuncs

asi rapido

linea 1829 -31 aproximadamente, pone:

Código Delphi [-]
sesiones[sesion].resultado.facturas[n].tipoOperacion   :=getEnumName( TypeInfo(TipoOperacionType), ord(res.RespuestaLinea[ j ].EstadoRegistro ) );

y deberia poner:

Código Delphi [-]
            sesiones[sesion].resultado.facturas[n].tipoOperacion   :=getEnumName( TypeInfo(TipoOperacionType), ord(res.RespuestaLinea[ j ].Operacion.TipoOperacion ) );

Recompila la DLL y ya

Nota: no lo he probado. Cuando este confirmado que funciona, y haya pasado algo mas de tiempo volvere a publicar otra version.

Saludos !