Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[jalvar28]

Buenos días.
Estoy enviado facturas y todo ok.
El tema es que veo que se traga todos los encadenamientos, le ponga lo que le ponga me dice que factura correcta ¿Alguien ha notado esto? ¿No lo están validando aún?

encadenamientoFacturaAnterior.IDEmisorFactura = cifEmisor;
encadenamientoFacturaAnterior.NumSerieFactura = NumSerieFacturaAnterior ;//numero factura anterior
encadenamientoFacturaAnterior.FechaExpedicionFactura = FechaFacturaAnterior;//fecha factura anterior
encadenamientoFacturaAnterior.Huella = HuellaFacturaAnterior;//huella registro anterior

[jlmoli_67]

Buenas,

No te dice aceptada con errores y te hace referencia al hash? En las pruebas que hice ayer asi me lo reflejaba.

un saludo

[jalvar28]

Te lo explico con ejemplo:

- Registro la factura 0001/2024 correctamente (utilizando PrimerRegistroCadenaType).

- Luego registro la factura 0002/2024 e indico que la anterior es la 0001/2024 (completando los campos correspondientes en EncadenamientoFacturaAnteriorType), y el sistema me lo valida correctamente.

- Posteriormente, intento registrar la factura 0003/2024 e indico, nuevamente, que la factura anterior es la 0001/2024 (utilizando los mismos datos en EncadenamientoFacturaAnteriorType), pero el sistema también lo valida como correcto, cuando en realidad debería haber detectado que la factura previa debió ser la 0002/2024.

No estoy seguro si estoy cometiendo algún error o si es el sistema el que no está validando correctamente la secuencia de encadenamiento de facturas.

- Además, si en el campo EncadenamientoFacturaAnteriorType incluyo una factura que nunca ha sido añadida al sistema, junto con una huella anterior generada aleatoriamente por una IA, también me indica que la factura es correcta. Creo que aún no se está validando correctamente. Si pueden probarlo, agradecería que me lo confirmaran.

var encadenamientoFacturaAnterior = new EncadenamientoFacturaAnteriorType();
encadenamientoFacturaAnterior.IDEmisorFactura = cifEmisor;
encadenamientoFacturaAnterior.NumSerieFactura = "00001/Pepito/2024";//numero factura nunca añadida anteriormente
encadenamientoFacturaAnterior.FechaExpedicionFactura = "02-02-2024";//fecha factura anterior
encadenamientoFacturaAnterior.Huella = "7F3D68A9B8C39A1D29C7B4F54E6FA318CBD26317F02C89DF1A6477E3952D8F3E";//huella generada por ia

[xevi]

Lo que yo si he notado es que puedes enviar TANTOS registros como quieras como PrimerRegistro

<sum1:Encadenamiento>
<sum1:PrimerRegistro>S</sum1:PrimerRegistro>
</sum1:Encadenamiento>


Eso tampoco es normal, ya que SOLAMENTE debería de existir un registo PrimerRegistro
A partir de ahí, si, he visto que si no le pongo correctamente la Huella y la correspondiente HuellaAnterior, lo Acepta con errores
Como si envias un registro que no esté calculado correctamente el ImporteTotal con las sumas de las bases... Lo Acepta con errores

Luego a partir de ahí es donde entra el hacer registros de Subsanación de errores... otro tema!!!

[jlmoli_67]

Pienso que si creas dos facturas, la 1 y la 3 , encadenadas correctamente y las envias secuencialmente porque no existe la nº 2 realmente el proceso es correcto pero llevas razon, deberia , pienso yo de avisar de que la 2 no existe, no es asi????? Hay que probarlo porque en ese caso ya te digo yo quien va a perder el tiempo en anulaciones.

En las pruebas que hice ayer, si el hash esta mal porque lo refiero a otra factura entonces si lo detecta pero realmente este caso no lo he probado.

[espinete]

Estoy empezando a darle caña a VeriFactu y veo que hay algunas diferencias con respecto a TicketBAI que me gustaría que me confirmaran, por si me estoy equivocando con el procedimiento...

Para TicketBAI, el procedimiento es el siguiente:

1. Generar el XML (por ejemplo, factura.xml)
2. Firmar el XML (por ejemplo, factura-firmada.xml)
3. Realizar el envío del archivo, firmando también el envío (yo uso el evento NetHTTPClient1NeedClientCertificate del componente TNetHTTPClient)

Pero según entiendo, con VeriFactu (al menos por ahora) no hay que firmar el XML, sino únicamente *el envío*.

Con VeriFactu creo entender que el procedimiento es este:
1. Generar la(s) Factura(s) (no veo forma de obtener el XML de UNA factura concreta)
2. Generar el XML del envío, que contiene la(s) factura(s)
3. Realizar el envío, firmando el envío con el certificado

¿Es correcto?

No veo la forma de obtener el XML de la factura antes de hacer el envío. Solo al enviarla, con el evento HTTPRIO1BeforeExecutedel componente THTTPRIO
No sé si es posible usar el componente TNetHTTPClient, aunque esto lo de menos ya que me da igual que funcione uno u otro.
Al no tener que firmar el XML de la factura, entiendo que no hace falta lo de las políticas de firma, SigPolicyID, SigPolicyHash, r_SigPolicyURI, etc. que sí eran necesarios en TicketBAI

¿Podría alguien confirmarme esto antes de seguir empeñado en hacerlo como en TicketBAI?

[xamminf]

Empezado por espinete

Estoy empezando a darle caña a VeriFactu y veo que hay algunas diferencias con respecto a TicketBAI que me gustaría que me confirmaran, por si me estoy equivocando con el procedimiento...

Para TicketBAI, el procedimiento es el siguiente:

1. Generar el XML (por ejemplo, factura.xml)
2. Firmar el XML (por ejemplo, factura-firmada.xml)
3. Realizar el envío del archivo, firmando también el envío (yo uso el evento NetHTTPClient1NeedClientCertificate del componente TNetHTTPClient)

Pero según entiendo, con VeriFactu (al menos por ahora) no hay que firmar el XML, sino únicamente *el envío*.

Con VeriFactu creo entender que el procedimiento es este:
1. Generar la(s) Factura(s) (no veo forma de obtener el XML de UNA factura concreta)
2. Generar el XML del envío, que contiene la(s) factura(s)
3. Realizar el envío, firmando el envío con el certificado

¿Es correcto?

No veo la forma de obtener el XML de la factura antes de hacer el envío. Solo al enviarla, con el evento HTTPRIO1BeforeExecutedel componente THTTPRIO
No sé si es posible usar el componente TNetHTTPClient, aunque esto lo de menos ya que me da igual que funcione uno u otro.
Al no tener que firmar el XML de la factura, entiendo que no hace falta lo de las políticas de firma, SigPolicyID, SigPolicyHash, r_SigPolicyURI, etc. que sí eran necesarios en TicketBAI

¿Podría alguien confirmarme esto antes de seguir empeñado en hacerlo como en TicketBAI?

espinete,

No me atrevo a responder a su pregunta pero si a plantear alguna diferencia mas:

Con TicketBAI no hay "flujo", con lo cual, conforme se hace se envia. Con VF si hay flujo y puede ser necesario demorar el envio, porque claro, no se va a demorar la generacion-impresion de la factura
Ademas en TB el xml hay que hacerlo en el momento de la impresion porque en el QR va un trozo de la firma. En VF me pareciera que no porque 1º no hay que firmarla el xml y segundo en el QR no se incluye un trozo de la firma. Esto a mi modo de ver es determinante porque "determina" la manera de hacer y si cambiara también habría que cambiar la forma

[thinkows]

Buenos días, gracias a todos por vuestras aportaciones, hoy he enviado a mano el primer XML mediante ARC (Advanced Rest Client) y la primera en la frente tanto el NIF del emisor de la factura como el del certificado mediante el cual me iidentifico son los mismos, el problema es que me devuelve un error cuyo codigo [4118] no se corresponde con la descripción del mismo :

<?xml version="1.0" encoding="UTF-8"?><env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"><env:Body><env:Fault><faultcode>env:Client</faultcode><faultstring>Codigo[4118].Error La direccion no se corresponde con el fichero de entrada.</faultstring><detail><callstack>Error La direccion no se corresponde con el fichero de entrada.

La verdad voy muy despistado... parece que algo no está correcto en el encabezado, os adjunto el envío por si alguno le puede hechar un vistazo...


POST /wlpl/TIKE-CONT/ws/SistemaFacturacion/VerifactuSOAP HTTP/1.1
Host: prewww1.aeat.es:443
Content-Type: text/xml

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:sfLR="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroLR.xsd" xmlns:sf="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd">
<soapenv:Header/>
<soapenv:Body>
<sfLR:AltaFactuSistemaFacturacion>
<sf:Cabecera>
<sf:IDVersion>1.0</sf:IDVersion>
<sf:ObligadoEmision>
<sf:NombreRazon>EMPRESA,S.L.</sf:NombreRazon>
<sf:NIF>Bnnnnnnnn</sf:NIF>
</sf:ObligadoEmision>
</sf:Cabecera>
<sfLR:RegistroAltaFacturas>
<sfLR:RegistroFacturacion>
<sf:IDFactura>
<sf:IDEmisorFactura>
<sf:NIF>Bnnnnnnnn</sf:NIF>
</sf:IDEmisorFactura>
<sf:NumSerieFacturaEmisor>T1966968</sf:NumSerieFacturaEmisor>
<sf:FechaExpedicionFacturaEmisor>27-09-2024</sf:FechaExpedicionFacturaEmisor>
</sf:IDFactura>
<sf:NombreRazonEmisor>EMPRESA,S.L.</sf:NombreRazonEmisor>
<sf:TipoRegistroSIF>S0</sf:TipoRegistroSIF>
<sf:TipoFactura>F1</sf:TipoFactura>
<sf:TipoRectificativa>S</sf:TipoRectificativa>
<sfescripcionOperacion>Venta Artículos Jardineria</sfescripcionOperacion>
<sf:FacturaSimplificadaArticulos7.2_7.3>S</sf:FacturaSimplificadaArticulos7.2_7.3>
<sf:FacturaSinIdentifDestinatarioArticulo6.1.d>S</sf:FacturaSinIdentifDestinatarioArticulo6.1.d>
<sf:Cupon>N</sf:Cupon>
<sfesglose>
<sfetalleDesglose>
<sf:ClaveRegimen>01</sf:ClaveRegimen>
<sf:CalificacionOperacion>S1</sf:CalificacionOperacion>
<sf:TipoImpositivo>21.00</sf:TipoImpositivo>
<sf:BaseImponibleOimporteNoSujeto>21.82</sf:BaseImponibleOimporteNoSujeto>
<sf:CuotaRepercutida>4.58</sf:CuotaRepercutida>
</sfetalleDesglose>
</sfesglose>
<sf:CuotaTotal>4.58</sf:CuotaTotal>
<sf:ImporteTotal>26.40</sf:ImporteTotal>
<sf:PrimerRegistro>
<sf:IDEmisorFacturaRegistroAnterior>S</sf:IDEmisorFacturaRegistroAnterior>
</sf:PrimerRegistro>
<sf:EncadenamientoRegistroAnterior>
<sf:IDEmisorFacturaRegistroAnterior>
<sf:NIF>B58292129</sf:NIF>
</sf:IDEmisorFacturaRegistroAnterior>
<sf:NumSerieFacturaRegistroAnterior>T1966967</sf:NumSerieFacturaRegistroAnterior>
<sf:FechaExpedicionFacturaRegistroAnterior>27-09-2024</sf:FechaExpedicionFacturaRegistroAnterior>
<sf:HuellaRegistroAnterior/>
</sf:EncadenamientoRegistroAnterior>
<sf:SistemaInformatico>
<sf:NombreRazon>EMPRESA INFORMATICA,SL</sf:NombreRazon>
<sf:NIF>Bxxxxxxxx</sf:NIF>
<sf:NombreSistemaInformatico>ELSOFTWARE</sf:NombreSistemaInformatico>
<sf:IdSistemaInformatico>A.01</sf:IdSistemaInformatico>
<sf:Version>1.0</sf:Version>
<sf:NumeroInstalacion>100</sf:NumeroInstalacion>
<sf:TipoUsoPosibleSoloVerifactu>S</sf:TipoUsoPosibleSoloVerifactu>
<sf:TipoUsoPosibleMultiOT>S</sf:TipoUsoPosibleMultiOT>
<sf:IndicadorMiltipleOT>S</sf:IndicadorMiltipleOT>
</sf:SistemaInformatico>
<sf:FechaHoraHusoGenRegistro>2024-09-27T13:21:20+02:00</sf:FechaHoraHusoGenRegistro>
</sfLR:RegistroFacturacion>
<sf:TipoHuella>1</sf:TipoHuella>
<sf:Huella>C32E027863DBD555C84FD80E5A52D84EE30693DE3F28B599DDCB4461DD320811</sf:Huella>
</sfLR:RegistroAltaFacturas>
</sfLR:AltaFactuSistemaFacturacion>
</soapenv:Body>
</soapenv:Envelope>


Gracias de antemano, verremos como evoluciona el tema.
Un Saludo.