Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[keno_71]

Empezado por CarlosR

Usas el httprio inyectando xml creado a pelo ?
Eso es interesante. Tendrás que retomarlo con lo de la factura electrónica, a menos que se pongan las pilas y saquen un wsdl.

Hay código en algún lugar para ver como el httprio puede subir un xml "prefabricado" ?

Me da igual delphi que c++ builder.
Un saludo.

No sé si te refieres a esto, así lo tengo yo pero lo cogí de un ejemplo del propio club creo recordar:

en el BeforeExecute envío un archivo xml que previamente he generado (e_FicFEMI) y que se encuentra en una carpeta del servidor:

Código Delphi [-]

procedure TfrmEnvioFraEmi.HTTPRIO1BeforeExecute(const MethodName: string;
  SOAPRequest: TStream);

    var
      ss:TFileStream;
      vlfichero : string;

begin

    // configurar parámetros para seleccionar el archivo a enviar

    try
        SOAPRequest.Size:=0;
        ss:=TFileStream.Create(e_FicFEMI, fmOpenRead);
        SOAPRequest.Position := 0;
        SOAPRequest.CopyFrom( ss, ss.Size);
    finally
        ss.Free;
        SOAPRequest.Position := 0;
    end;





end;

en el AfterExecute capturo la respuesta y la guardo en otra carpeta del disco duro

saludos

[CarlosR]

Empezado por keno_71

No sé si te refieres a esto, así lo tengo yo pero lo cogí de un ejemplo del propio club creo recordar:

en el BeforeExecute envío un archivo xml que previamente he generado (e_FicFEMI) y que se encuentra en una carpeta del servidor:

Código Delphi [-] procedure TfrmEnvioFraEmi.HTTPRIO1BeforeExecute(const MethodName: string; SOAPRequest: TStream); var ss:TFileStream; vlfichero : string; begin // configurar parámetros para seleccionar el archivo a enviar try SOAPRequest.Size:=0; ss:=TFileStream.Create(e_FicFEMI, fmOpenRead); SOAPRequest.Position := 0; SOAPRequest.CopyFrom( ss, ss.Size); finally ss.Free; SOAPRequest.Position := 0; end; end;


en el AfterExecute capturo la respuesta y la guardo en otra carpeta del disco duro

saludos

Veo que lo haces con un stream, muy interesante.
Lo traduciré a c++ builder y a hacer pruebas.
Un buen aporte.


Gracias.

[CarlosR]

Empezado por keno_71

No sé si te refieres a esto, así lo tengo yo pero lo cogí de un ejemplo del propio club creo recordar:

en el BeforeExecute envío un archivo xml que previamente he generado (e_FicFEMI) y que se encuentra en una carpeta del servidor:

Código Delphi [-] procedure TfrmEnvioFraEmi.HTTPRIO1BeforeExecute(const MethodName: string; SOAPRequest: TStream); var ss:TFileStream; vlfichero : string; begin // configurar parámetros para seleccionar el archivo a enviar try SOAPRequest.Size:=0; ss:=TFileStream.Create(e_FicFEMI, fmOpenRead); SOAPRequest.Position := 0; SOAPRequest.CopyFrom( ss, ss.Size); finally ss.Free; SOAPRequest.Position := 0; end; end;


en el AfterExecute capturo la respuesta y la guardo en otra carpeta del disco duro

saludos

Verás, si creas el xml y lo archivas en una tabla para poder cotejarlo posteriormente con los datos originales y el hash podría pasar algo curioso si usas los métodos creados automáticamente a partir del wsdl de la AEAT.
Podría pasar que cualquier espacio o signo que varíes en el envío con dicho código a la AEAT no se corresponda con el xml archivado con su hash y posiblemente certificado. O simplemente el código creado automáticamente a paritr de la wsdl te los cree. O que una etiqueta del xml tú la dejes en blanco por no uso y el código no te cree la propia etiqueta. Todo esto haría que el hash se fuera por la borda.

Estoy valorando cambiar lo que ya tengo creado por c++ builder a partir del wsdl y pasarlo a código hecho a mano de tal forma que el xml archivado sea el mismo que copio y envio a la AEAT. Simplemente estoy valorándolo pero hay varias papeletas a favor de optar por esa opción.



Gracias de nuevo.


P.D. en mi caso el código SII lo creé de forma automática hace ya años, cuando comenzó, y cada cambio que hace la AEAT me obliga a cambiar programación en diversos sitios. De forma manual me habría resultado mas sencillo el mantenimiento del soft.

[keno_71]

Empezado por CarlosR

Verás, si creas el xml y lo archivas en una tabla para poder cotejarlo posteriormente con los datos originales y el hash podría pasar algo curioso si usas los métodos creados automáticamente a partir del wsdl de la AEAT.
Podría pasar que cualquier espacio o signo que varíes en el envío con dicho código a la AEAT no se corresponda con el xml archivado con su hash y posiblemente certificado. O simplemente el código creado automáticamente a paritr de la wsdl te los cree. O que una etiqueta del xml tú la dejes en blanco por no uso y el código no te cree la propia etiqueta. Todo esto haría que el hash se fuera por la borda.

Estoy valorando cambiar lo que ya tengo creado por c++ builder a partir del wsdl y pasarlo a código hecho a mano de tal forma que el xml archivado sea el mismo que copio y envio a la AEAT. Simplemente estoy valorándolo pero hay varias papeletas a favor de optar por esa opción.



Gracias de nuevo.


P.D. en mi caso el código SII lo creé de forma automática hace ya años, cuando comenzó, y cada cambio que hace la AEAT me obliga a cambiar programación en diversos sitios. De forma manual me habría resultado mas sencillo el mantenimiento del soft.

Eso es cierto, yo el código de SII lo he variado muy poco, si que capturo la respuesta con los métodos de la AEAT y esa parte por ejemplo si la he tenido que cambiar más en alguna actualización. Una razón más para hacerlo a mano, bueno habrá que valorar. Ya te digo, igual dentro de un mes pienso lo contrario

saludos

[keno_71]

Perdón, creo recordar que utilizo los métodos cuando consulto las facturas que he subido al SII, hay a veces si que hay más cambios, no en la respuesta del envío.

[ermendalenda]

Empezado por CarlosR

Verás, si creas el xml y lo archivas en una tabla para poder cotejarlo posteriormente con los datos originales y el hash podría pasar algo curioso si usas los métodos creados automáticamente a partir del wsdl de la AEAT.
Podría pasar que cualquier espacio o signo que varíes en el envío con dicho código a la AEAT no se corresponda con el xml archivado con su hash y posiblemente certificado. O simplemente el código creado automáticamente a paritr de la wsdl te los cree. O que una etiqueta del xml tú la dejes en blanco por no uso y el código no te cree la propia etiqueta. Todo esto haría que el hash se fuera por la borda.

Estoy valorando cambiar lo que ya tengo creado por c++ builder a partir del wsdl y pasarlo a código hecho a mano de tal forma que el xml archivado sea el mismo que copio y envio a la AEAT. Simplemente estoy valorándolo pero hay varias papeletas a favor de optar por esa opción.



Gracias de nuevo.


P.D. en mi caso el código SII lo creé de forma automática hace ya años, cuando comenzó, y cada cambio que hace la AEAT me obliga a cambiar programación en diversos sitios. De forma manual me habría resultado mas sencillo el mantenimiento del soft.

En el caso de vereifcatu va a ser dificl que pase, ya que el cálculo del hash se hará sobre nodos sueltos, numericos y el del CIF.
Algo así

<sum1:NIF>00000006Y</sum1:NIF>
<sum1:NumSerieFactura>1.1.1.8</sum1:NumSerieFactura>
<sum1:FechaExpedicionFactura>09-04-2024</sum1:FechaExpedicionFactura>
<sum1:TipoFactura>F2</sum1:TipoFactura>
<sum1:ImporteTotal>2.00</sum1:ImporteTotal>
<sum1:CuotaTotal>0.00</sum1:CuotaTotal>
<sum1:Huella>E6FE58EE455F233BFA429FA7A9D90EDC006CBB2421876EB2590D37E682414CB3</sum1:Huella>
<sum1:FechaHoraHusoGenRegistro>2024-04-09T19:12:03+01</sum1:FechaHoraHusoGenRegistro>

Con lo cual no creo que admita caracteres extraños
Lo único que hay tener claro es que concatenes los campos, para el calculo del hash, con retornos de carro, ni caracteres nulos.

[ermendalenda]

Empezado por ermendalenda

En el caso de vereifcatu va a ser dificl que pase, ya que el cálculo del hash se hará sobre nodos sueltos, numericos y el del CIF.
Algo así

<sum1:NIF>00000006Y</sum1:NIF>
<sum1:NumSerieFactura>1.1.1.8</sum1:NumSerieFactura>
<sum1:FechaExpedicionFactura>09-04-2024</sum1:FechaExpedicionFactura>
<sum1:TipoFactura>F2</sum1:TipoFactura>
<sum1:ImporteTotal>2.00</sum1:ImporteTotal>
<sum1:CuotaTotal>0.00</sum1:CuotaTotal>
<sum1:Huella>E6FE58EE455F233BFA429FA7A9D90EDC006CBB2421876EB2590D37E682414CB3</sum1:Huella>
<sum1:FechaHoraHusoGenRegistro>2024-04-09T19:12:03+01</sum1:FechaHoraHusoGenRegistro>

Con lo cual no creo que admita caracteres extraños
Lo único que hay tener claro es que concatenes los campos, para el calculo del hash, con retornos de carro, ni caracteres nulos.

Corrijo
No concatenar con retornos de carro ni caracteres extraños

[CarlosR]

Corrígeme si me equivoco (es posible en este caso) pero ¿ no hay que hacer el hash de toda la estructura XML ?
Incluyendo datos del fabricante y del producto.
Si no es así, ¿ puedes indicarme al menos si están descritos en algún pdf o comunicado de la AEAT ?


Gracias.

[ermendalenda]

Empezado por CarlosR

Corrígeme si me equivoco (es posible en este caso) pero ¿ no hay que hacer el hash de toda la estructura XML ?
Incluyendo datos del fabricante y del producto.
Si no es así, ¿ puedes indicarme al menos si están descritos en algún pdf o comunicado de la AEAT ?


Gracias.

En la primera Versión era así, pero debido a posibles problematicas que han reportado en el periodo de consulta corrigieron y dijeron que iban a ser solo unos campos(nodos), en la excell de los esquemas(extensiones) también hacen referencia que ya diran sibre que nodos se calcula, pero que serán algunos. En el esquema del webinar del día 14 hay una pequeña referencia en el que encabezan como "IMPORTANTE" y se ven unos "posibles nodos" sobre los que se calculará, vi en ese cuadro que aparecía un nuevo nodo, el de cuotatotal, y he visto que ahora también aparece en el nuevo esquema. Así que hay muchas posibilidades de que en un alto porcentaje sean esos nodos y quizás alguno más.

[ermendalenda]

Aquí el pantallazo de lo.que te comento