[HerensugeBeltz]

Empezado por espinete

Señor@s... PROBLEMA RESUELTO.

O mejor dicho... motivo descubierto.

El problema está en el proceso de envío con NetHTTPClient1. Si utilizo idhttp1, no hay ningún problema y la factura se envía sin problemas, sin cambiar NADA en el proceso de creación del archivo, firma, etc.

Gracias iMia por sugerir el envío con idhttp1. La verdad es que estaba (estábamos) enfocados en que el problema no estaba ahí, sino en la generación del XML o en la firma.

Dado que usas los componentes SecureBlackBox 2020, no sería más sencillo usarlos también para el envío?
Ejemplo en C++ Builder:

  sbxHTTPClient1->ClientCertHandle[0]= sbxCertStore->CertHandle[m_ndxCertificadoSeleccionado];
  // Cargo el fichero como un array de bytes. Con otros métodos se desvirtuaba el
  // contenido y el envío fallaba.
  DynamicArray<byte> cnt;
  std::unique_ptr<TFileStream> fs(new TFileStream(XMLOrigen,	fmOpenRead));
  cnt.Length= fs->Size;
  fs->Read(cnt, 0, cnt.Length);

  bool resul(true);
  try
  {
    sbxHTTPClient1->TLSAutoValidateCertificates= true; //== 02/07/21. Añadido
    sbxHTTPClient1->TLSVersions= TsbxConstants::csbTLS12;
    sbxHTTPClient1->ReqParamsContentType= L"application/xml;charset=UTF-8";
    sbxHTTPClient1->ReqParamsAcceptCharset= L"UTF-8";
    sbxHTTPClient1->ReqParamsAccept= L"*/*";
    sbxHTTPClient1->ReqParamsHTTPVersion= TsbxHTTPClientReqParamsHTTPVersions::chvHTTP11;
    sbxHTTPClient1->TLSRenegotiationAttackPreventionMode= TsbxHTTPClientTLSRenegotiationAttackPreventionModes::crapmAuto;
    sbxHTTPClient1->Config(L"UseSystemCertificates=true"); 

    sbxHTTPClient1->PostBytes(endPoint, cnt);
  }
  catch (Exception &e)
  {
    codigoError= -6;
    err= L"Error en el envío de la factura XML.\r\n"+ e.Message + L"\r\n" +
      sbxHTTPClient1->ReasonPhrase;
    resul= false;
  }