Facturas electrónicas [España]

[espinete]

NOTA DEL MODERADOR:=======================================
Como hemos hecho con otros temas similares, voy a "fijar" este hilo para dedcarlo a la Facturación electrónica (Facturae).
Además adjunto links de otros hilos (que no quedan fijados) sobre el mismo tema:


Enviar factura electronica via webservice (http://www.clubdelphi.com/foros/showthread.php?t=87738)
Firma en factura electrónica facturaE (https://www.clubdelphi.com/foros/showthread.php?t=90242)
Factura electrónica "Facturae" (https://www.clubdelphi.com/foros/showthread.php?t=87512)
Factura Electronica Factura-E (https://www.clubdelphi.com/foros/showthread.php?t=66724)
libreria Delphi para factura electronica Facturae (https://www.clubdelphi.com/foros/showthread.php?p=525032)
EFactura SecureBlackBox (https://www.clubdelphi.com/foros/showthread.php?t=94875)


=======================================================

[Movido desde esta otra conversación (http://www.clubdelphi.com/foros/showthread.php?t=87738)]

Bueno, voy a aportar lo que tengo por ahora, que es la parte que crea el .XML (o .XSIG para la Admón. Pública) y lo firma con certificado digital o DNIe. Pero esto no puede quedarse ahí, hay que seguir con la tercera parte (que es la finalidad de este post), que es enviar la factura al webservice de face, a ver si entre todos lo conseguimos.

Con este código se puede crear un .XML (manualmente) y firmarlo para que sea válido y aceptado en la web de facturae. La web de facturae tiene un "validador online" aquí...
http://sedeaplicaciones2.minetur.gob.es/FacturaE/
...que nos servirá para comprobar si las facturas creadas son correctas, están bien firmadas, etc.

Componentes necesarios de SecureBlackBox: TEIWinCertStorage y TEIX509Certificate.
Otros componentes: TXMLDocument

(los componentes SecureBlackBox vienen con un montón de proyectos de ejemplo, entre ellos uno para firmar archivos PDF o XML).

Primera parte: crear el .XML

Yo he decidido crearlo "a mano". Un XML no es más que un archivo de texto con una estructura concreta, así que utilizo un Memo y le voy añadiendo las líneas con cuidado...
No voy a ponerlo todo porque es muy largo. Quizás más tarde subiré el código completo. El XML requiere un montón de valores variables que debemos rellenar (datos del emisor, receptor, factura, artículos, totales, impuestos...). Esta parte es algo tediosa, pero muy sencilla.

Antes de nada, cargamos los certificados digitales instalados en el sistema, por ejemplo en el OnCreate del Form1, en un ComboBox.
Esto hará que en el combobox veamos los certificados digitales instalados en Windows, ya sean certificados de empresa, el del DNIe, etc.
Nos harán falta más tarde para la firma del XML.


procedure TForm1.FormCreate(Sender: TObject);
var i:integer;
begin
for i := 0 to WinCertStorage.Count - 1 do
begin
Cert := WinCertStorage.Certificates[i];
ComboCertificate.Items.Add('Título: ' + Cert.SubjectName.CommonName + ', Emisor: ' + Cert.IssuerName.CommonName);
end;
end;


Empezamos a crear el XML a mano...


memo1.Lines.Clear;
memo1.lines.append('<?xml version="1.0" encoding="ISO-8859-1"?>');
memo1.lines.append('<fe:Facturae> xmlns:fe="http://www.facturae.es/Facturae/2009/v3.2/Facturae" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"');
memo1.lines.append('<FileHeader>');
memo1.lines.append('<SchemaVersion>3.2</SchemaVersion>');
{.....}


Cuando tengamos todo el texto del XML, guardamos el memo en un archivo con extensión xml.


memo1.Lines.SaveToFile('c:\pruebas\factura.xml');


Ahora abrimos el archivo con el componente XMLDocument para tenerlo ahí cargado, y lo volvemos a guardar. ¿por qué? Porque así se guarda bien estructurado, identado, etc. y es más fácil leerlo si nos hiciera falta.


XMLDocument1.LoadFromFile(archivo);
xmldocument1.Active:=true;
xmldocument1.SaveToFile(archivo);


Y ahora a firmar...

Segunda parte: Firmar el XML

Este código no es mío. Tiene partes extraídas de clubdelphi, de los ejemplos de secureblackbox y de otros ejemplos de firma digital.
En el código le decimos qué certificado utilizar para la firma, de entre los cargados en el combobox anterior.
Probablemente el código se pueda mejorar. He dejado los comentarios del creador original porque explican bastante bien lo que se hace en él.


function Firma:boolean;
var XML_Doc:ElXMLDOMDocument;
XML_Refs:TElXMLReferenceList;
XML_RefDocu,XML_RefCert:TElXMLReference;
XML_Signer:TElXMLSigner;
XML_XAdES:TElXAdESSigner;
XML_KeyData:TElXMLKeyInfoX509Data;
XML_Nodo:ElXMLDOMNode;
MS:TStream;
XML_Buf:ByteArray;

F: {$ifndef DELPHI_NET}TFileStream{$else}FileStream{$endif};
begin
result:=false;
with form1 do
begin

// ************************
// ** Firmar fichero XML **
// ************************

XML_Doc:= ElXMLDOMDocument.create; //Documento XML a ser firmado
XML_Refs:= TElXMLReferenceList.create; //Lista de nodos a ser firmados
XML_RefDocu:= TElXMLReference.create; //Nodo que representa al XML completo
XML_RefCert:= TElXMLReference.create; //Nodo del certificado utilizado
XML_Signer:= TElXMLSigner.Create(nil); //Objeto firmante en XML...
XML_XAdES:= TElXAdESSigner.Create(nil); //Sujeto firmante con info adicional XAdES
XML_KeyData:= TElXMLKeyInfoX509Data.create(false); //Certificado a utilizar...

try
//Leo el fichero XML
//==================
// Por defecto en UTF-8 y normalizando los finales de linea (si llegan
// CR+LF entonces la firma no se validará luego pues los digest no
// deberían incluir estos CR+LF).

{$ifndef DELPHI_NET}
F := TFileStream.Create(archivo, fmOpenRead or fmShareDenyWrite);
{$else}
F := FileStream.Create(archivo, FileMode.Open, FileAccess.Read);
{$endif}
try
XML_Doc.LoadFromStream(F, '', true);
except
on E : Exception do
begin
MessageDlg('Error: ' + E.Message, mtError, [mbOk], 0);
end;
end;

FreeAndNil(F);

if not XML_Doc.Loaded then
raise Exception.create('Firma XML: No se pudo cargar el documento XML.');

//Configuro el objeto firmador de XML
//===================================
// Se han de firmar la lista de nodos referenciados en XML_Refs
XML_Signer.References:= XML_Refs;
XML_Signer.SignatureMethodType:= xmtSig;
// Se firma en formato "enveloped"
XML_Signer.SignatureType:= xstEnveloped;
// Se canoniza -ver ejemplos de la web facturae- el XML
XML_Signer.CanonicalizationMethod:= xcmCanon;
// La firma con el metodo mas estandar posible
XML_Signer.SignatureMethod:= xsmRSA_SHA1;
// La parte publica del certificado se debe incluir
XML_Signer.IncludeKey:= true;
// Necesito incrustar info adicional "XAdES" (XML Advanced Electronic Signatures )...
XML_XAdES:= TElXAdESSigner.Create(nil);
XML_Signer.XAdESProcessor:= XML_XAdES;

//Configuro la parte XAdES del objeto firmador
//============================================
//
// Se pide usar XAdES V1.2.2 o superior pero ha de ser "compatible" (?)
// Algunos ejemplos usando V1.3.2 validan, asi que lo uso.
XML_Signer.XAdESProcessor.XAdESVersion:= XAdES_v1_3_2;
//SignerRole (en calidad de qué firmamos): supplier, customer o third_party
// Firmamos facturas emitidas por nosotros (supplier) en este caso.
// Si recibimos una factura firmada por el supplier, la podemos volver
// a firmar como que la damos por recibida usando "customer".
//NOTA: El validador de www.facturae.es no comprueba este dato (2-2010)
XML_Signer.XAdESProcessor.Included := [xipSignerRole];
XML_Signer.XAdESProcessor.SignerRole.ClaimedRoles.AddText(
XML_Signer.XAdESProcessor.XAdESVersion, XML_Doc, 'supplier');
// La politica de firmado es la definida en el PDF V3.1 sobre firmado Facturae
XML_Signer.XAdESProcessor.PolicyId.SigPolicyId.Identifier:= 'http://www.facturae.es/politica_de_firma_formato_facturae/politica_de_firma_formato_facturae_v3_1.pdf';
//NOTA: Si vas a la web, este PDF esta en otro link diferente (WTF):
//'http://www.facturae.es/es-ES/Documentacion/Politicas/Politicas/Versi%C3%B3n%203_1/Politica_Firma_formato_facturae_v3_1.pdf';
XML_Signer.XAdESProcessor.PolicyId.SigPolicyId.Description:= 'Política de firma electrónica para facturación electrónica con formato Facturae';
//Ahora el hash del propio PDF en SHA1 (en la web esta debajo del PDF)...
XML_Signer.XAdESProcessor.PolicyId.SigPolicyHash.DigestMethod:= 'http://www.w3.org/2000/09/xmldsig#sha1';
//El digest en SHA-1 de la web (en formato hex), esta MAL, no corresponde
//con ese PDF, y ademas, en su ejemplo de la V3.0 el digest es correcto
//y NO se corresponde con el digest que dan!
// '613c46e7bac7df5b266e6be0349b5fe8bb4944e2' ESTA MAL EN LA WEB
//Uso el digest SHA1 correcto generado a partir del PDF:
SetLength(XML_Buf,0); //Evito un warning tonto
if not HexStr2ByteArray('3A18B197ABA90FA6AFF0DEE912F0C006110BEA13', XML_Buf) then
raise Exception.Create('Firma XML: Error convirtiendo digest de política de firmado a Base64.');
{NOTA: Sustituido por HexStr2ByteArray()
XML_Digest:= LowerCase('3A18B197ABA90FA6AFF0DEE912F0C006110BEA13');
SetLength(XML_Buf, Length(XML_Digest) div 2);
//En delphi 7 HexToBin va bien, en Delphis mas moderno, no vale porque
//WideChar y pChar se tratan de forma diferente, asi que se hace a mano.
//HexToBin(PChar(XML_Digest), PChar(XML_Buf), Length(XML_Digest) div 2);
for j:= 0 to Length(XML_Buf)-1 do begin
k1:= SBMath.HexToDecDigit(XML_Digest[j*2 + 1]);
k2:= SBMath.HexToDecDigit(XML_Digest[j*2 + 2]);
if (k1<0) or (k2<0) then
raise Exception.Create('Firma XML: Error convirtiendo digest de política de firmado a Base64.');
XML_Buf[j]:= k1 shl 4 + k2;
end;}

XML_Signer.XAdESProcessor.PolicyId.SigPolicyHash.DigestValue:= XML_Buf;

//-----------------------
// FECHA/HORA DE LA FIRMA
//-----------------------
//Anoto la fecha y hora del firmado (del PC no es legalmente valida)

XML_Signer.XAdESProcessor.SigningTime := LocalTimeToUTCTime(Now);

//Pre-Genero los nodos de firmado necesarios
//==========================================
// Esta es la parte mas "confusa": He de firmar partes del XML que no
// existen hasta que este firmado ¿Como? El objeto Signer, junto con el
// prepocesador XAdES, crean esos nuevos nodos para que podamos
// referenciarlos -decirle al firmador que son unas referecnias a ser
// firmadas- y al final, al firmar, unira el XML original con estos
// nuevos nodos -formato de firma "enveloped"- y se graba el XML final.
//
// Primero genero la zona de informacion XAdES:
XML_Signer.XAdESProcessor.Generate;
// Ahora, al objeto firmador "generico" le pido lo mismo, con lo que
// tambien se crea el nodo "KeyInfo" con el certificado a utilizar.
XML_Signer.UpdateReferencesDigest;
//Cargo certificado para firmar
//=============================
// Cargo el certificado a usarse en la firma en el objeto firmador
// NOTA: Se incluira la parte publica del certificado en base64.
// De los certificados que me pases, elijo el primero con parte privada,
// ya que no quiero incluir el certificado raiz del emisor (no se
// menciona en la politica de firmado y no aparece en los ejemplos):

XML_KeyData.IncludeKeyValue:= true;
Cert := WinCertStorage.Certificates[comboCertificate.ItemIndex];
if Cert.PrivateKeyExists then
XML_KeyData.certificate:= Cert;

//Compruebo que ha quedado algún certificado válido...
if not Assigned(XML_KeyData.certificate) then
raise Exception.create('FirmaXML: No se cargó un certificado válido para firmar, no contiene clave privada.');
XML_Signer.KeyData:= XML_KeyData;
//Añado a la lista de nodos a firmar
//==================================
//NOTA: El metodo SHA1 no es el mas seguro, pero el SHA256 no se usa mucho
//y puede dar problemas (WinXP SP2 no lo admite) por eso el DNIe tampoco
//lo usa aun, asi que mejor dejo el valor por defecto.
//
// NODO 1: Se ha de firmar el documento original XML completo...
//
XML_RefDocu.DigestMethod:= xdmSHA1; //El mas estandard/compatible de todos
XML_RefDocu.URINode:= XML_Doc.DocumentElement; //El XML completo
XML_RefDocu.URI:= ''; //No hay nombre especifico para este nodo
// En los ejemplos aparece la transformacion "Enveloped-Signature"
// aunque en el PDF de la firma V3.1 no lo menciona.
XML_RefDocu.TransformChain.Add(TElXMLEnvelopedSignatureTransform.Create);
XML_Refs.Add(XML_RefDocu); //Lo sumo a las cosas a ser firmadas
// Actualizo digest con este nuevo nodo.
XML_Signer.UpdateReferencesDigest;
// NODO 2: Se han de firmar las propiedades de firmado (XAdES)....
//
// El nodo SignedProperties es parte de la informacion XAdES que se
// creo en XML_Signer.XAdESProcessor.Generate y se firma siempre en
// el standard XAdES. Dejo el codigo abajo como referencia solo, pero
// no funcionaría si se activa porque ya esta siendo firmado una vez.
//XML_Signer.XAdESProcessor.QualifyingProperties.SignedProperties.ID:= 'SignedPropertiesID';
//XML_RefProp.DigestMethod:= xdmSHA1;
//XML_RefProp.URI:= '#SignedPropertiesID';
//XML_Refs.Add(XML_RefProp);
//XML_Signer.UpdateReferencesDigest;
//
// NODO 3: Se ha de firmar el propio certificado utilizado
//
// El nodo KeyInfo ha de ir identificado por 'Certificate1' -segun los
// ejemplos, el PDF no da ningun nombre concreto-
// si se firma dos veces un mismo XML no chocan aunque el
// nombre coincida por estar dentro de diferentes nodos "Signature".

XML_RefCert.URI:= '#Certificate1';
XML_RefCert.DigestMethod:= xdmSHA1;
XML_Refs.Add(XML_RefCert); //Lo sumo a las cosas a ser firmadas
//Como ya tengo todos los nodos, ahora genero la firma y consigo que
//exista el nodo KeyInfo, de forma que pueda darle el nombre que le toca
//antes de unir el XML original con el nuevo nodo de la firma.
XML_Signer.Sign;
XML_Signer.Signature.KeyInfo.ID:= 'Certificate1';
//Añado la firma al XML
//=====================
XML_Nodo:= ElXMLDOMNode(XML_Doc.DocumentElement);
XML_Signer.Save(XML_Nodo);
//Actualizo el stream MS con el XML final firmado.

{$ifndef DELPHI_NET}
F := TFileStream.Create(archivo, fmCreate or fmOpenWrite);
{$else}
F := System.IO.FileStream.Create(archivo, FileMode.Create, FileAccess.ReadWrite);
{$endif}
try
XML_Doc.SaveToStream(F, xcmNone, '');
except
on E : Exception do
begin
MessageDlg('Error: ' + E.Message, mtError, [mbOk], 0);
end;
end;
FreeAndNil(F);

result:= true;
finally
//NOTA: Los XML_Ref se destruyen solos junto al XML_Refs
XML_Doc.free;
XML_Refs.free;
XML_Signer.free;
XML_XAdES.free;
XML_KeyData.Free;
end;
end;
end;


Y ya tenemos firmado nuestro XML. Y si el certificado es válido, la fecha/hora es válida, etc. entonces la factura electrónica es perfectamente legal. Podremos comprobarlo en la web de validación de facturae, que además nos dirá donde está el error, si lo hubiera.

IMPORTANTE:
Cuando la factura es para una Administración Pública, el .XML debe tener unas secciones obligatorias (Oficina contable, órgano gestor, etc.) y el archivo, en vez de tener extensión XML, lo guardaremos al final como .xsig. Y eso es todo.

Y ahora, lo difícil...

Enviar la factura al webservice...

Importamos el WSDL del webservice del face desde Delphi. Hay dos versiones, la de producción y la de desarrollo para pruebas. El de pruebas es este: https://se-face-webservice.redsara.es/sspp?wsdl

En el IDE, vamos a Component -> Import WSDL e indicamos la url anterior. Siguiente -> Siguiente y Finish.
Esto creará una unit llamada 'sspp.pas', que guardaremos en la misma carpeta de nuestro proyecto, y añadiremos al uses de nuestro form.

Y hasta aquí puedo leer. Y no porque no quiera seguir, sino porque no tengo ni idea.

Este es el código, supuestamente, para enviar la factura al webservice, pero antes hay que hacerle varias cosas que desconozco. Creo que incluso puede hacerse sin los SecureBlackBox, pero de verdad que estoy atascado.


var facturasspp : SSPPFactura;
fichero_fac : SSPPFicheroFactura;
answ : SSPPResultadoEnviarFactura;
PO:SSPPWebServiceProxyPort;
begin
PO := GetSSPPWebServiceProxyPort(FALSE, '', nil);
facturasspp := ssppfactura.Create;
facturasspp.correo := 'correo@micorreo.com';
fichero_fac := ssppficherofactura.Create;
fichero_fac.nombre := 'c:\pruebas\factura.xml';
fichero_fac.factura := '12345';
fichero_fac.mime := 'application/xml';
facturasspp.fichero_factura := fichero_fac;

try
answ:=PO.enviarFactura(facturasspp);
except
on e:exception do showmessage(e.Message);
end;
end;

[newtron]

Bueno, voy a aportar lo que tengo por ahora

Espinete, gracias por aportar tu código pero no es eso lo que te quería decir. Yo en particular no tengo las SBB y no podría usar ese código para firmar el fichero, y la verdad es que no me apetece comprar los componentes solo para eso. Lo que te decía es si puedes preparar un .exe que dándole el fichero de entrada y el de salida te firme el fichero de entrada y genere el de salida firmado para poder usarlo como programa externo.

Luego ya vendrá el tema del webservice (que yo en particular tampoco tengo ni idea).

Saludos

[espinete]

Si le vas a dar uso a los componentes, porque los necesitas, no te quedará más remedio que comprarlos. De nada te sirve que te haga yo un ejecutable "puente", sin su código fuente, y que dentro de un mes pueda fallar, o requerir más parámetros, o requerir una nueva versión del SecureBlackBox, quedándote obsoleto. Lo de "no me apetece comprar los componentes solo para eso"... no sé, depende de a qué te refieras exactamente con "solo para eso". Yo creo que es bastante.

Tengo entendido que hay otras formas de firmar el XML sin usar los SecureBlackBox, pero lo desconozco. Este post es para intentar averiguar entre todos cómo enviar las facturas al webservice.

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

Este es el código, supuestamente, para enviar la factura al webservice, pero antes hay que hacerle varias cosas que desconozco. Creo que incluso puede hacerse sin los SecureBlackBox, pero de verdad que estoy atascado.


Pues yo creo que ya tienes lo más complicado.
Para el tema del envío no hacen falta los BlackBox.

Un código similar al que pones debería funcionar:


var
resultado:SSPPResultadoEnviarFactura;
facturaWS:SSPPFactura;
begin

facturaWS := SSPPFactura.Create();
facturaWS.correo := ...
...

// Según el rellenado llamamos a uno u otro
resultado := (HTTPRIO1 as SSPPWebServiceProxyPort).enviarFactura(facturaWS);


La configuración del componente supongo que es la que toca:

http://s26.postimg.org/towwoc22x/Captura_1295.png

A partir de ese punto, ¿obtienes algún error? ¿Alguna respuesta?

[espinete]

Hola, Netfali

El error que obtengo es el mismo que utilizando la otra forma de hacer el envío:

La petición SOAP no está bien construida: No se encuentra el SOAP Header

El componente HTTPRIO está bien configurado (igual que en tu imagen).

Así ha quedado el código por ahora:


var facturasspp : SSPPFactura;
fichero_fac : SSPPFicheroFactura;
answ : SSPPResultadoEnviarFactura;
PO:SSPPWebServiceProxyPort;
begin
if opendialog1.Execute then //Para elegir el .XML que queremos enviar al webservice
begin
PO := GetSSPPWebServiceProxyPort(FALSE, '', nil);
facturasspp := ssppfactura.Create;
facturasspp.correo := 'XXXXXXXXXX';

fichero_fac := ssppficherofactura.Create;
fichero_fac.nombre := extractfilename(opendialog1.FileName);
fichero_fac.factura := '72345';
fichero_fac.mime := 'application/xml';

facturasspp.fichero_factura := fichero_fac;

try
answ := (HTTPRIO1 as SSPPWebServiceProxyPort).enviarFactura(facturasspp);
except
on e:exception do showmessage(e.Message);
end;
end;

end;

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

No se si lo has puesto, no me ha parecido leerlo.
¿Con qué versión de delphi estás trabajando?

[espinete]

Hola...

Con Delphi XE7 o con Delphi Seattle.

Un saludo

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

Vale.
Es porque con los antiguos D6/D7 había un problema con las cabeceras de las Indy.
En algunos casos había que añadir algo manualmente.

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

¿Puedes hacer algún envío envío de pruebas desde algún otro sitio? ¿Aplicación de ejemplo? ¿web?

Lo digo para intentar hacer un envío de ejemplo que funcione, y utilizando algún debugger (tipo Fiddler (http://www.telerik.com/fiddler)) intertar ver la cabecera completa que se está enviando.
Una vez que tengas la cabecera completa que se envía cuando el envío es correcto, intentar ver qué estás enviando cuanto utilizas la Indy y ver si hay diferencias.

No se si me explico...

[espinete]

Hola

He hecho la prueba con el Fiddler 4 "escuchando". Tengo un montón de información, pero no sé cómo interpretarla o donde debo mirar.

Request Header:
POST /sspp HTTP/1.1
SOAPAction: "https://webservice.face.gob.es#enviarFactura"
Content-Type: text/xml; charset=utf-8
User-Agent: CodeGear SOAP 1.3
Host: se-face-webservice.redsara.es
Content-Length: 960
Connection: Keep-Alive
Cache-Control: no-cache

Request TextView:
<?xml version="1.0"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"><SOAP-ENV:Body xmlns:NS1="https://webservice.face.gob.es" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><NS1:enviarFactura><facturaWS href="#1"/></NS1:enviarFactura><NS1:SSPPFactura id="1" xsi:type="NS1:SSPPFactura"><correo xsi:type="xsd:string">prueba@miemail.com</correo><fichero_factura href="#2"/><ficheros_anexos xsi:type="SOAP-ENC:Array" SOAP-ENC:arrayType="NS1:SSPPFicheroAnexo[0]"/></NS1:SSPPFactura><NS1:fichero_factura id="2" xsi:type="NS1:SSPPFicheroFactura"><factura xsi:type="xsd:string">72345</factura><nombre xsi:type="xsd:string">Factura 177.xml</nombre><mime xsi:type="xsd:string">application/xml</mime></NS1:fichero_factura></SOAP-ENV:Body></SOAP-ENV:Envelope>

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

Dentro de "Inspectors" tienes los "Headers", la sección "Auth" y "Raw", que por ahora parece que es lo que nos debe interesar.

El siguiente paso sería comparar eso, con un envío correcto.

[espinete]

Hola

En Fiddler tengo 4 procesos. Supongo que 2 envíos y dos respuestas. No sé muy bien cómo funciona fiddler y si debo mirar en la parte superior derecha o inferior derecha de cada evento:
3277

En los envíos, la pestaña Auth dice lo siguiente:
No Proxy-Authorization Header is present.

No Authorization Header is present.

De todas formas, es demasiada información para poner aquí. La he exportado y subido aquí 3278

[Ñuño Martínez]

Veo un problema en esto: ¿Es imperativo usar SOAP? Lo digo por los que no usamos (o usamos poco) el Windows. La verdad es que no sé si ese protocolo está disponible para otros sistemas operativos (no sólo Linux, también UNIX, MacOS, Solaris, BSD, OS/400, eComStation...), pero teniendo en cuenta la deriva de la administración española en lo referente a nuevas tecnologías que en realidad no son tan nuevas, no sería la primera vez que hacen algo que únicamente puede usarse desde Windows (¡Hola, DNI electrónico!).

[espinete]

Pues no lo sé, pero ya bastante tengo con que no lo consiga hacer desde Windows. Supongo que habilitarán más protocolos en el futuro.

[Casimiro Notevi]

.... Supongo que habilitarán más protocolos en el futuro. :rolleyes:

[iMia]

SOAP (Simple Object Access Protocol) no es exclusivo de windows... es un protocolo de comunicaciones, para el intercambio de información... Inicialmente en xml...

Espinete... seguramente el problema lo tienes que al importar el WSDL, hay que hacer un cambio por que el server Tomcat, requiere SOAP 1.1 y no 1.2...
¿donde? os preguntareis...

Al registrar las opciones de invocación, hay que cambiar el TypeInfo, del tipo ioDocument por ioDefault
con eso queda arreglado...


// InvRegistry.RegisterInvokeOptions(TypeInfo(xxxx), ioDocument);
InvRegistry.RegisterInvokeOptions(TypeInfo(xxxx), ioDefault);



Saludos

[espinete]

Hola, iMia...

Gracias por tu aportación... pero tras importar el WSDL, en la unit resultante (sspp.pas), no hay ninguna referencia a InvRegistry.RegisterInvokeOptions(), por lo que no puedo sustituirlo (Delphi XE7 y Delphi Seattle).

Lo más parecido está en la parte initialization de esa unit:


initialization
{ SSPPWebServiceProxyPort }
InvRegistry.RegisterInterface(TypeInfo(SSPPWebServiceProxyPort), 'https://webservice.face.gob.es', 'UTF-8');
InvRegistry.RegisterDefaultSOAPAction(TypeInfo(SSPPWebServiceProxyPort), 'https://webservice.face.gob.es#%operationName%');
{...}
{...}


¿Dónde exactamente debo hacer el cambio que sugieres?

[iMia]

Si correcto, lo acabo de importar para verlo...
y no aparece esa linea....
prueba de añadirla tal que...


InvRegistry.RegisterInvokeOptions(TypeInfo(SSPPWebServiceProxyPort), ioDefault);


justo debajo de las dos que muestras...

Saludos...

Yo tambien en XE7...

[espinete]

Hecho.

Pero sigue igual:

La petición SOAP no está bien construida: no se encuentra el SOAP Header.

[iMia]

Uffff...

Voy a probar..
pero al importar el wsdl, el codigo me da un error...
En la funcion "consultarListadoFacturas" el parámetro pone que es de tipo Array... pero no de que es ese array...


function consultarListadoFacturas(const listadoFacturas: Array): ArrayOfSSPPResultadoConsultarFactura; stdcall;


¿como lo has arreglado tu?

[espinete]

Para poder compilar y empezar a hacer pruebas, lo "solucioné" con un "array of string".

No sé si será la solución, pero al menos podremos empezar a probar cosas y poco a poco ir avanzando.

[Ñuño Martínez]

SOAP (Simple Object Access Protocol) no es exclusivo de windows... es un protocolo de comunicaciones, para el intercambio de información... Inicialmente en xml... Gracias por la info. ^\||/

[iMia]

bueno os informo de los progresos que estamos haciendo con espinete...

Empezado por espinete
Creo que tengo algo...

He buscado por cómo añadir headers a la petición soap antes de hacer el envío y encontré un post en StackOverflow (en Delphi):
http://stackoverflow.com/questions/2...814937#2814937

Concretamente, en el evento BeforeExecute del componente HTTPRIO, obtenemos la petición que se va a enviar y la podemos "cambiar" sobre la marcha. Precisamente este usuario necesitaba hacer algo parecido a lo que intentamos nosotros (añadir la sección headers).

Luego he usado ese mismo evento para obtener lo que envía nuestra aplicación al webservice, en un Memo, y efectivamente, falta la sección <soapenv:Header> en el XML.

Bien

No obstante, no creo que esta sea la forma de conseguirlo. El XML podemos rellenarlo antes (incrustar la sección header con la firma, certificado, etc.). Lo que no me parece muy lógico es tener que firmar 2 veces el XML (una para firmar la factura y otra para el header), pero bueno, supongo que es normal.

Sí, aunque lo normal sería algo así...


var
sphdr: TSOAPHEADERS;
htpr: THTTPRIO;
ws: SSPPWebServiceProxyPort;
...
begin
sphdr := TSOAPHEADERS.create;
htpr := THTTPRIO.create(self);
htpr.SOAPHeaders.Send(sphdr);
ws := GetSSPPWebServiceProxyPort(false, '', htpr);
...


Pero hay que enviar en la cabecera, todo el mensaje entero firmado...
por lo que hay que parsearlo o meterlo a mano antes de enviarlo con el evento BeforeExecute del httprio.
Es decir, en el evento, se coge el mensaje que se va a enviar (lo que hay en body, aunque contenga documentos firmados o no...), se firma, y se mente en la cabecera.
De esta forma ellos pueden comprobar que el mensaje que les llega, no está manipulado, ya que les llega sin firmar y firmado, comprueba la firma y si es correcta, al abrirlo, lo comparan con lo enviado... si es igual, está todo correcto y continúan...

Por lo que para ello hay que definir la función que capturará en evento...


procedure HTTPRIO_BeforeExecute(const MethodName: string; SOAPRequest: TStream);


definir el httprio, asignarle el evetno y utilizarlo como vehículo del webservice...


var
ws: SSPPWebServiceProxyPort;
...
begin
htpr := THTTPRIO.create(self);
htpr.OnBeforeExecute := HTTPRIO_BeforeExecute;

ws := GetSSPPWebServiceProxyPort(false, '', htpr);
...


el evento se define tal que...


procedure TMDIMainForm.HTTPRIO_BeforeExecute(const MethodName: string; SOAPRequest: TStream);
var
xmlCall: TXMLDocument;
begin
try
// Posicionarse al inicio del stream
SOAPRequest.Position := 0;
// pasar el stream a un xmlDoc... o donde se quiera...
xmlCall.LoadFromStream(SOAPRequest);
// Firmarlo y meterlo en la cabecera...

...

[espinete]

Hola

Bien, vamos avanzando...

He conseguido añadir una cabecera a la petición, y gracias al evento BeforeExecute, puedo ver que efectivamente ahora el XML sí tiene sección cabecera:


<SOAP-ENV:Header SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:NS1="urn:Soap.InvokeRegistry">
<NS1:TSOAPHeader xsi:type="NS1:TSOAPHeader"/>


Casi lloro.

Bien. Yo lo he hecho de otra forma, no sé si ves algún problema:


procedure TForm1.Button2Click(Sender: TObject);
var facturasspp : SSPPFactura;
fichero_fac : SSPPFicheroFactura;
answ : SSPPResultadoEnviarFactura;
PO:SSPPWebServiceProxyPort;

htpr: THTTPRIO;
sphdr: TSOAPHEADER;
ws: SSPPWebServiceProxyPort;
begin
if opendialog1.Execute then
begin
//Creamos los headers, necesarios para la petición SOAP
sphdr := TSOAPHEADER.create;

//Aquí rellenaríamos la sección header, pero no sé si es el mejor lugar.

PO := GetSSPPWebServiceProxyPort(FALSE, '', nil);
facturasspp := ssppfactura.Create;
facturasspp.correo := 'prueba@miemail.com';
fichero_fac := ssppficherofactura.Create;
fichero_fac.nombre := extractfilename(opendialog1.FileName);
fichero_fac.factura := '72345';
fichero_fac.mime := 'application/xml';
facturasspp.fichero_factura := fichero_fac;

//Aquí asignamos los headers que hemos creado a nuestra petición soap
HTTPRIO1.SOAPHeaders.Send(sphdr);

try
answ := (HTTPRIO1 as SSPPWebServiceProxyPort).enviarFactura(facturasspp);
except
on e:exception do showmessage(e.Message);
end;
end;

end;



Tu código es diferente, creo que utilizas un XMLDocument que contendría las cabeceras ya rellenadas?

Ahora lo complicado es cómo meter el mensaje FIRMADO en la cabecera... ¿A mano?

Por ejemplo, en la petición SOAP que uso para pruebas, el body es este:


<SOAP-ENV:Body xmlns:NS2="https://webservice.face.gob.es" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<NS2:enviarFactura>
<facturaWS href="#2"/>
</NS2:enviarFactura>
<NS2:SSPPFactura id="2" xsi:type="NS2:SSPPFactura">
<correo xsi:type="xsd:string">prueba@miemail.com</correo>
<fichero_factura href="#3"/>
<ficheros_anexos xsi:type="SOAP-ENC:Array" SOAP-ENC:arrayType="NS2:SSPPFicheroAnexo[0]"/>
</NS2:SSPPFactura>
<NS2:fichero_factura id="3" xsi:type="NS2:SSPPFicheroFactura">
<factura xsi:type="xsd:string">72345</factura>
<nombre xsi:type="xsd:string">Factura 177.xml</nombre>
<mime xsi:type="xsd:string">application/xml</mime>
</NS2:fichero_factura>


Cómo se "firma" ese trozo de texto?

Aquí tengo una muestra de petición "REAL" sacada de la documentación, que debería servirnos como ejemplo, aunque a estas alturas ya dudo de lo que puede servir y lo que no.
Le he quitado la parte de los ficheros anexos (por ahora) para simplificarlo un poco.


<soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:web="https://webservice.face.gob.es">

<soapenv:Header>

<!-- // Security Content -->

</soapenv:Header>

<soapenv:Body>

<web:enviarFactura soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<facturaWS xsi:type="sspp:SSPPFactura">

<!--You may enter the following 3 items in any order-->
<correo xsi:type="xsd:string">XXXX correo electronicoXXXX</correo>
<fichero_factura xsi:type="sspp:SSPPFicheroFactura">

<!--You may enter the following 3 items in any order-->
<factura xsi:type="xsd:string"> _contenido enbase_64 del fichero factura_ </factura>
<nombre xsi:type="xsd:string"> _nombre del ficherofactura_ </nombre>
<mime xsi:type="xsd:string"> _mimeType del ficherofactura_ </mime>
</fichero_factura>

</facturaWS>
</web:enviarFactura>

</soapenv:Body>
</soapenv:Envelope>


Y el ejemplo de Security-Content que pone en la documentación es este (lo que va dentro del header):


<wsse:Security soapenv:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<wsse:BinarySecurityToken EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" wsu:Id="CertId-5A5C126069B253F2B0135998798458616" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
MIIEpDCCBA2gAwIBAgIEPLPTKTANBgkqhkiG9w0BAQUFADA2MQswCQYDVQQGEwJFUzENMAsGA1UEChMERk5NVDEYMBYGA1UECxMP Rk5NVCBDbGFzZSAyIENBMB4XDTALS6PmAJWFoOUT3Xvp8UxYptb9/YK93ykPj5NYLcsXeh8L9SRWbFSnozoiATZoECDnrcMd054DdPrNVYLTZNhZ9Y2U9JqJpnIWR+a64Mo3iiMk/KBkI2jo3QIuaCjvPK+k6LQCwTIaRvnHGRxwIDAQABo4IB1DCCAdAwgdgGA1UdEQSB0DCBzaSByjCBxzEYMBYGCSsGAQQBrGYBDxM JUzI4MjYwMTVGMUMwQQYJKwYBBAGsZgEOEzRJTlRFUlZFVc9fS1I6qgUkmwCZKHiwgJ4tS1Mv3gKMZ+8ulc8JErYo661ql3GVmLs fdH5g3eWyC5rBEcCjkHSKO0qDhzg==

</wsse:BinarySecurityToken>

<ds:Signature Id="Signature-11" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethodAlgorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#id-12">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms>
<ds:DigestMethodAlgorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>vfoQe7yobzrB5LzQZ/HD4B2F1BY=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
HOZFzxAsMAH8BDbuXOHekl+yyLXfodmPka5727t3LDFSkbxICkL92wy6dSbWyU07zK/dhfLl2a4c
33FcvOxAtYAEvQVRLcQM3VU9+L2SX9NReQaGTPPmtBb8UAWeH5m56nM9uxT7yIwfO424+lNEYEeo
1pYC+0DBI6WcN4LRgV4=
</ds:SignatureValue>
<ds:KeyInfo Id="KeyId-5A5C126069B253F2B0135998798458717">
<wsse:SecurityTokenReference wsu:Id="STRId-5A5C126069B253F2B0135998798458718"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsse:ReferenceURI="#CertId-5A5C126069B253F2B0135998798458616"
ValueType="http://docs.oasis-open.org/wss/2004/01/
oasis-200401-wss-x509-token-profile-1.0#X509v3"/>
</wsse:SecurityTokenReference>
</ds:KeyInfo>
</ds:Signature>
<wsu:Timestamp wsu:Id="Timestamp-10" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsu:Created>2013-02-04T14:26:24.586Z</wsu:Created>
<wsu:Expires>2013-02-04T14:31:24.586Z</wsu:Expires>
</wsu:Timestamp>
</wsse:Security>


Los componentes de SecureBlackBox permiten firmar peticiones SOAP usando certificados de diferentes tipos, y añaden la sección security al header, PERO no de la misma forma que en este ejemplo. Además, estaría bien saber si es posible hacerlo sin dichos componentes, ya que hay muchos usuarios que no los utilizan.

[iMia]

Bien!!
bueno, varias cosas.... yo no utilizo SBB... Además, no estoy programando nada sobre el Face, aún... me pondré más adelante... simplemente te intentaba ayudar un poco...

En el tema de la cabecera, el código que pones yo lo haría diferente... simple cuestión de estilo...


procedure TForm1.Button2Click(Sender: TObject);
var
facturasspp : SSPPFactura;
fichero_fac : SSPPFicheroFactura;
answ : SSPPResultadoEnviarFactura;


htpr: THTTPRIO;
sphdr: TSOAPHEADER;
WS: SSPPWebServiceProxyPort;
begin
if opendialog1.Execute then
begin
//Creamos los headers, necesarios para la petición SOAP
sphdr := TSOAPHEADER.create;

// Creo el HTTP, que utilizaré como vehiculo, así no tengo que hacer Typecasts que no me gustan nada...
htpr := THTTPRIO.create(Self);

//Aquí trabajamos con el propio httprio, donde podemos poner cabeceras, asignar eventos, etc...

htpr.SOAPHeaders.Send(sphdr);
// htpr.OnBeforeExecute := BeforeExecuteHttpRio(...
// htpr.OnAfterExecute := AfterExecuteHttpRio(...

// Al crear la instancia del WS, le asigno el httprio que he creado y he manipulado...

WS:= GetSSPPWebServiceProxyPort(FALSE, '', htpr);

facturasspp := ssppfactura.Create;
facturasspp.correo := 'prueba@miemail.com';
fichero_fac := ssppficherofactura.Create;
fichero_fac.nombre := extractfilename(opendialog1.FileName);
fichero_fac.factura := '72345';
fichero_fac.mime := 'application/xml';
facturasspp.fichero_factura := fichero_fac;

try
// Me cargo el typecast... que para eso se ha instanciado el ws sobre la variable WS
answ := WS.enviarFactura(facturasspp);
except
on e:exception do showmessage(e.Message);
end;
end;

end;



el tema de utilizar un TxmlDocuemnt, es simplemente para ponerlo de ejemplo, para firmarlo y re-inyectarlo en la cabecera.
Se puede hacer como quieras...

El tema de lo que debe ir en el header... ese ya es otro tema que habría que aclarar...

Si con SBB te permite firmar llamadas SOAP, esta claro que debe ir en el header... capturar la llamada, firmarla, inyectarla en el header y seguir enviando la llamada original, con la llamada firmada en el header... (donde pone "security content")...

[espinete]

Bueno...

Estoy viendo las demos de SecureBlackBox, que permiten añadir la firma al header del soap, pero tienen varias opciones y compatibilidad con varios certificados, así que habrá que averiguar cual hay que elegir.
Estas capturas de pantalla son de la aplicación demo que se incluye en los SecureBlackBox.
La aplicación nos permite abrir un XML y, entre otras cosas, añadir una firma, verificarla, quitarla, o actualizarla, y volver a guardar el XML resultante ya firmado.

Lo primero que nos pregunta es el Signature Handler. 3 opciones. Yo he elegido la WSS Signature Handler, que no sé si es la correcta porque NO ME ENTERO DE NADA:
3285

En esa misma ventana nos pregunta si queremos crear la cabecera, o sustituir una ya existente. Como nuestro XML no tiene cabecera, le decimos que la cree.
Además, hay otra opción "sign body" que no sé qué hace. Tendré que hacer pruebas diferentes y comparar un resultado con otro para entenderlo mejor.

El siguiente paso es elegir el certificado con el que queremos firmar el XML, el Key Name, etc. y aquí tenemos otras opciones que debemos elegir de una lista: Embed Certificate Option, que supongo que es la forma en la que se incrusta el certificado:
3286

Como tampoco tengo ni idea, pues tendré que hacer pruebas y rezar para que alguna de ellas funcione.

Una vez hemos añadido la firma y el securiyu header al XML, la sección HEADER de nuestro XML quedará así (más o menos)


<SOAP-ENV:Header SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:NS1="urn:Soap.InvokeRegistry">
<NS1:TSOAPHeader xsi:type="NS1:TSOAPHeader"/>
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<wsse:BinarySecurityToken ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" wsu:Id="id-278627682" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">MIIIkTCCB3mgAwIBAgIJAK2....................................</wsse:BinarySecurityToken>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#id-1455977767">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>pyHVuQqgYvQ3F1PIb+Cw39jfq2M=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo><ds:SignatureValue>kDLUYUxnRCmiR6TPwBAg/..................................</ds:SignatureValue><ds:KeyInfo><ds:KeyValue><ds:RSAKeyValue>
<ds:Modulus>AIHDAKJSAS.....................................................</ds:Modulus>
<ds:Exponent>AQAB</ds:Exponent>
</ds:RSAKeyValue></ds:KeyValue>
<wsse:SecurityTokenReference wsu:Id="" TokenType="" Usage="" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsse:Reference URI="#id-278627682" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/>
</wsse:SecurityTokenReference><ds:X509Data><ds:X509Certificate>MIIIkTCCB3mgAw...................</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
</wsse:Security>
</SOAP-ENV:Header>


Esto se parece más al header del XML que aparece en la documentación del face, aunque no es exacto (hay muchas más cosas).

Durante estos días intentaré probar todas las opciones y averiguar si es posible crear el tipo de firma que exige face.

[iMia]

Tal uy como te puse por privado, según el manual de los servicios Web....

Las peticiones tanto como las respuestas deben ir firmadas según el estandar OASIS WSSecurity 1.0 X509 Token Profile
• http://en.wikipedia.org/wiki/WS-Security
• http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-tokenprofile-1.0.pdf
La plataforma FACe delega sobre la plataforma @firma
(http://administracionelectronica.gob.es/ctt/afirma) la validación y la firma electrónica
digital de los servicios web, por lo que usted puede encontrar la documentación completa
en la misma.

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

Aunque no estoy interviniendo actívamente porque ahora no estoy con este tema, agradeceros (al menos a nivel personal) toda la información detallada que estáis adjuntando en este hilo.

Creo que antes o después nos será útil a michos de nosotros.

[newtron]

Aunque no estoy interviniendo actívamente porque ahora no estoy con este tema, agradeceros (al menos a nivel personal) toda la información detallada que estáis adjuntando en este hilo.

Creo que antes o después nos será útil a michos de nosotros.

Totalmente de acuerdo.

[espinete]

Esta mañana he conseguido averiguar qué tipo de firma usar, y comparando los resultados con el de la dlcumentacion, creo que es la correcta.

Hasta mañana no podré seguir probando, pero en cuanto avance algo más lo iré publicando.

Eso sí, habrá que hacerlo con los SecureBlackBox. Al menos yo no sé si habrá otro método...

[espinete]

Bueno, creo que lo he conseguido :)

Aquí pongo una captura de pantalla de la respuesta que me da el webservice después de crear la petición soap, firmarla y enviar una factura:
3287

Voy a limpiar un poco el código, añadir comentarios y hacer pruebas con un certificado ya dado de alta en el webservice para comprobar que funciona correctamente, e iré publicando los pasos poco a poco.

Lo que he hecho es lo siguiente. A partir de un proyecto de ejemplo suministrado por los componentes SecureBlackBox, que permite firmar peticiones SOAP (que es lo que nos faltaba), lo he ido adaptando y simplificando para que, a partir de la factura electrónica que creamos en el primer post, añada la firma, cabeceras, etc. requeridas por el webservice.

Hay que hacer dos firmas: la primera, para crear la factura electrónica (primer post), y la segunda para firmar la petición soap. Para ambas firmas usaríamos el mismo certificado. Los componentes SecureBlackBox permiten usar cualquier tipo de certificado (a partir de un .p12, .cer, de los certificados instalados en Windows, etc.).

No he conseguido hacerlo sin los componentes SecureBlackBox, lo siento. Supongo que es posible usar un certificado del almacén de certificados de Windows con código puro y duro, pero no he tenido tiempo de averiguar eso. Además, habría que incrustar al SOAP las cabeceras y toda la información del certificado a mano, y aunque es posible, lo veo una locura. Los SecureBlackBox lo hacen automáticamente.

Intentaré publicar los pasos esta tarde o mañana.

[espinete]

Sigo vivo. Llevo esperando una semana respuesta desde face, porque el webservice me devuelve el siguiente error:

100 - La firma de la petición soap no es válida

Así que a esperar.

[iMia]

Bueno, creo que lo he conseguido :)

No he conseguido hacerlo sin los componentes SecureBlackBox, lo siento. Supongo que es posible usar un certificado del almacén de certificados de Windows con código puro y duro, pero no he tenido tiempo de averiguar eso. Además, habría que incrustar al SOAP las cabeceras y toda la información del certificado a mano, y aunque es posible, lo veo una locura. Los SecureBlackBox lo hacen automáticamente.

Intentaré publicar los pasos esta tarde o mañana.

Ni lo conseguirás... por desgracia... no hay ninguna librería que firme y que sea free en Delphi...

[espinete]

Me he quedado atascado, y la única respuesta que me dan los de soporte del webservice es la misma respuesta que me da el validador online de firma (https://valide.redsara.es/valide/inicio.html):

"Id is not an attribute"

Así que ni idea.

Estoy hablando con el soporte de Eldos, creadores de los SecureBlackBox, a ver si me ayudan a ver qué pasa. Me niego a dejar esto ahora ya que creo que tengo el 90% conseguido, pero la verdad es que hay días que me dan ganas de abandonar y esperar a que pase algo más de tiempo para que haya más información en la red.

Seguiré intentándolo

[elguille]

Hola Espinete, despues de mucho tiempo voy a retomar este tema. Cuando lo deje estaba atascado con el error "connection lost" ahora no me da error pero el servicio retorna

<faultcode>500</faultcode>
<faultstring>20151127135337151899 - 300 - El certificado electr&#xF3;nico no est&#xE1; dado de alta en FACe. Para la presentaci&#xF3;n automatizada de facturas es necesario registrarse previamente en https://face.gob.es/es/proveedores</faultstring>

me fijo que he empleado el servicio definido en

https://webservice.face.gob.es/sspp

el cual segun la nueva documentacion es antiguo (aunque esta activo :confused:)

si empleo los nuevos, recibo diferentes errores para la misma peticion soap que antes (que no da error)

STAGING (https://se-face-webservice.redsara.es/facturasspp2) RCP-Literal
Decode from base64 failed

PROD (https://webservice.face.gob.es/facturasspp2) RCP-Literal
Xml parse error at position 1 (0x1)

¿Alguna idea? Gracias

Este el el codigo
// pruebas con cliente secureblackboc
FXMLDocument := TElXMLDOMDocument.Create;
FXMLDocument.LoadFromFile(extractfilepath(application.exename) + 'requestsoap.xml');
FSOAPClient := TElXMLSOAPClient.Create(nil);
try
FSOAPClient.SOAPPrefix := 'soap';
FSOAPClient.SOAPVersion := SOAP_v1_2;
FSOAPClient.OperationName := 'enviarFactura';

FSOAPClient.MessageNamespaces.Clear;
FSOAPClient.HTTPClient := HTTPSClient;
// entorno pruebas que no funciona
// FSOAPClient.URL := 'https://se-face-webservice.redsara.es/facturasspp';
// produccion
FSOAPClient.URL := 'https://webservice.face.gob.es/facturassspp2';
FSOAPClient.OperationNamespaceURI := 'https://webservice.face.gob.es';
FSOAPClient.SOAPAction := 'https://webservice.face.gob.es#enviarFactura';

fsoapclient.GenerateMessage;
FSOAPClient.XMLDocument.LoadFromFile(extractfilepath(application.exename) + 'requestsoap.xml');
FSOAPClient.SOAPMessage.LoadFromXML(FSOAPClient.XMLDocument); // reload a SOAP message if needed

FSOAPClient.SendMessage;
fsoapclient.ResponseXMLDocument.SaveToFile('resul.xml');

except
on E: Exception do
begin
MessageDlg('Failed to send SOAP message: ' + E.Message, mtError, [mbOk], 0);
end;
end;

[espinete]

Hola, elguille

Lo siento, yo no uso el componente TElXMLSOAPClient. Sólo uso los componentes de SecureBlackBox necesarios para hacer las firmas.
Para enviar la petición SOAP, importo el wsdl y hago la petición tal como indiqué en un post anterior.

Los técnicos de SecureBlackBox están intentando ayudarme a crear/firmar la petición SOAP, pero siempre obtengo "La firma de la petición soap no es válida".

Si existiera UN SOLO EJEMPLO de una petición soap completa para poder comparar sería todo maravilloso, pero en las instrucciones solo hay peticiones sin firmar.

[espinete]

Hola de nuevo.

He hecho una mezcla entre mi código y el de elguille, y he usado el webservice nuevo de STAGING para pruebas. PARECE QUE FUNCIONA, pero obtengo un error:

411 - No existe o inactiva la Oficina Contable asociado al código "A05003410"

He usado una oficina contable, unidad tramitadora, etc. al azar. ¿Alguien sabe si puede usarse cualquiera en el entorno de pruebas? ¿O es que he tenido mala suerte y esa no vale?

Al menos ya no obtengo el error 100 (La firma de la petición soap no es válida) ni ningún otro error!!!!

[espinete]

Bueno, creo que funciona :):):)

He conseguido obtener el listado de Administraciones, que también requiere una petición soap firmada. No puedo enviar captura de pantalla porque los límites de tamaño y dimensiones para los archivos son un tanto peculiares en el foro... :rolleyes:

Mañana intentaré enviar una factura (necesitaría saber qué código de administración es válido) y poner el código que he usado

[elguille]

Espinete, ¿lo has conseguido? ¿Puedes ilustrarnos?

Gracias

[espinete]

Hola!

Pues sí, creo que lo tengo todo, a falta de probar en modo producción.
Esta semana ha habido varios cortes del servicio (avisan por email cuando tienen previsto uno), pero conseguí hacer pruebas para enviar una factura, consultar el estado de una factura, obtener el listado de organismos disponibles, anular una factura, etc.

Mañana intentaré poner algunos ejemplos, pero ahora mismo tengo este a mano: Consultar Administraciones:


procedure TfrmMain.Button3Click(Sender: TObject);
var
answ : ConsultarAdministracionesResponse;
htpr: THTTPRIO;
sphdr: TSOAPHEADER;
WS: FacturaSSPPWebServiceProxyPort;
UnidadDir : UnidadDir3;
i:integer;
begin
if comboCertificate.ItemIndex=-1 then
begin
showmessage('Debe seleccionar primero un certificado en el desplegable.');
exit;
end;

Listbox1.items.clear;

//Creamos los headers, necesarios para la petición SOAP
sphdr := TSOAPHEADER.create;

// Creo el HTTP, que utilizaré como vehículo
htpr := THTTPRIO.create(Self);

//Aquí trabajamos con el propio httprio, donde podemos poner cabeceras, asignar eventos, etc...

htpr.SOAPHeaders.Send(sphdr);
htpr.OnBeforeExecute := HTTPRIO1BeforeExecute;

// Al crear la instancia del WS, le asigno el httprio que he creado y he manipulado...
WS:= GetFacturaSSPPWebServiceProxyPort(FALSE, '', htpr);
try
answ := WS.consultarAdministraciones;
except
on e:exception do showmessage(e.Message);
end;

if answ.resultado.codigo='0' then
begin
UnidadDir := UnidadDir3.Create;
for i:=0 to length(answ.administraciones)-1 do
begin
UnidadDir := answ.administraciones[i];
begin
listbox1.items.append(UnidadDir.codigo + ' - ' + UnidadDir.nombre )
end;
end;
UnidadDir.Free;
end;
end;



El evento HTTPRIO1BeforeExecute creo recordar que ya lo publiqué en otro post más arriba.
Cuando tenga más tiempo editaré el post original añadiendo todas las funciones.

[newtron]

Hola.

¿Qué pasó al final con este tema?

Saludos

[Ñuño Martínez]

Iba a ponerte un enlace, pero creo que ya has encontrado el hilo tú mismo. :)

[newtron]

Iba a ponerte un enlace, pero creo que ya has encontrado el hilo tú mismo. :)

¿Qué hilo? :confused:

[Ñuño Martínez]

¿Qué hilo? :confused:

Este (http://www.clubdelphi.com/foros/showpost.php?p=514632&postcount=430http://), ¿no?

[newtron]

Este (http://www.clubdelphi.com/foros/showpost.php?p=514632&postcount=430http://), ¿no?

Qué va. el hilo ese está relacionado con el llamado SII (Suministro inmediato de información) y yo preguntaba por el envío de facturas electrónicas por webservice.

Bueno... algo tienen en común, usan webservices. :D:D

[Ñuño Martínez]

Ah... Vale. Disculpen, conozco la salida. *Se va*

[bey23]

Hola!

Actualmente estoy buscando información sobre FACe, cómo subir las facturas automáticamente, y visto lo visto hay poquísima documentación sobre esto o ejemplos.

Me he leído de pe a pa todo este hilo, y por cierto, sois unos máquinas!!

Sólo quería preguntar si ahora mismo conseguisteis completar el proceso, crear el XML firmado y subirlo automáticamente, y si está en algún sitio ese proyecto o ejemplos del mismo...

Lo siento si es un tema que ya estaba cerrado, pero la verdad es que me urge y este es el único foro que de verdad se lo ha estado currando.

Muchas gracias a todos!!

[manelb]

Nosotros hemos ido atacando el proyecto por fases.
Ahora generamos el xml de la factura y lo firmamos, pero tenemos pendiente el envío directo a FACE.

Supongo que en unas semanas como mucho volveremos al proyecto y debe servirnos como experiencia el trabajo realizado con el SII.

Si queréis podemos mantener este hilo para ir compartiendo avances o, si a los moderadores les parece mejor, crear un hilo nuevo.

Saludo

[newtron]

Espinete en su último post comentaba que lo había conseguido y que pondría unos ejemplos pero al final ahí se quedó la cosa.

Saludos

[newtron]

Buenas a tod@s.

Voy a intentar ponerme con este tema.

¿Alguien ha avanzado algo con respecto a lo que ya hay por aquí?

Saludos

[newtron]

Hola de nuevo.

Estoy empeñado en sacar este tema adelante. Dándole vueltas, la documentación que hay en la web de face es erronea, las direcciones de las wsdl son incorrectas y no funcionan.

Rebuscando por internet he encontrado este (http://www.uco.es/facturae/pdf/proveedores/wsproveedores.pdf) documento que si parece que es correcto y tiene bastante más información que el que se puede descargar de la web de face, por si a alguien le interesa.

Yo por mi parte estoy haciendo pruebas con los últimos trozos de código que se pusieron aquí pero no consigo gran cosa. En principio el fichero XML no hay gran problema para crearlo y el tema de la firma electrónica se puede resolver usando el programa autofirma con lo que solo quedaría hacer la llamada al webservice que es donde estoy atascado.

Ahora yo pregunto... ¿hay alguien más en la actualidad interesado en este tema? ¿alguien que sepa de webservice que pueda echar una mano?

Gracias y un saludo

[manelb]

Hola Newtron, compañeros....
Yo estoy muy interesado en el tema.

Tal como he comentado en algún mensaje anterior mi experiencia en web services es solo la adquirida con el proyecto SII.

En el proyecto Facturae solo nos falta el envío directo y he ido retomando el proyecto varias veces.

Voy a ponerme de nuevo con la nueva documentación que adjuntas y expongo resultados.

Saludos

[manelb]

En la primera verificación que realizo constato que no me funcionan los links a los servicios wdsl que aparecen en el punto 4.1 de este nuevo documento que indicas(pagina13). Mensaje:El servicio no está disponible

Sí me funcionan en cambio otros que tengo en otro documento que descargué hace un tiempo de FACE
https://www.dropbox.com/s/uac1gyax7gf4z2q/servicio-web-facturasspp_estes_wsdl_funcionen.pdf?dl=0

Tu documento y el mio creo que tienen el mismo origen aunque el mio es mas grande:):).
Los servicios aparecen también en el punto 4.1 de la pagina 13.

Yo voy investigando por aquí.

Saludos

[newtron]

Bueno.

He estado haciendo pruebas para enviar una petición que me diera la lista de administraciones y la llamada de Espinete no me funciona, me da "error 104" que, consultando la documentación dice que es "La petición SOAP no está bien construida: no se encuentra el SOAP Header". Esto ya se ha comentado por aquí pero no sé exactamente cómo lo resolvieron.

He capturado el XML que se envía desde el evento "BeforeExecute" del objeto HTTPRIO y parece correcto pero, mirando un ejemplo de la documentación, veo que esa petición tiene que ir firmada dentro del bloque "header" por lo que los tiros deben de ir por ahí. He probado a "interceptar" el envío del XML y sustituirlo por otro en el evento "BeforeExecute" firmado con el autofirma pero no se lo traga. Esto debe de ser porque la firma la inserta en otra parte del fichero XML y ahí me he quedado.

Imagino que habría que buscar la forma de firmar la petición de forma que se inserte en el bloque "header" del fichero XML de petición pero hasta ahí llego, no sé si a alguien se le ocurre algo.

Saludos

[elguille]

Hola, visto q ahora hay gente interesada voy a retomar el tema a ver si entre todos lo sacamos. Os voy informando...

[newtron]

Hola a tod@s.


Viendo que este asunto no prosperaba y que necesitaba resolverlo le encargué el proyecto a alguien que sabe más que nosotros y que domina varias herramientas de programación.


Había que resolver dos problemas, primero el de firmar el fichero XML en tiempo de ejecución, cosa que estaba complicada sin componentes externos porque desde Delphi no conocemos a nadie que haya sido capaz de hacerlo así que se ha desarrollado una dll en .NET que hace la función de firmado y que se llama desde el proyecto Delphi. Posteriormente había que hacer la llamada al webservice firmada con el protocolo X.509, cosa que tampoco sabíamos resolver y que tampoco ha sido fácil de desarrollar.


Resumiendo, aquí os adjunto un ejemplo operativo que hace las funciones más habituales de llamadas al webservice de FACE, firma y envía ficheros XML, consulta de facturas, consulta de unidades y alguna cosa más que no he probado porque en principio tampoco voy a necesitar. Por supuesto también se pueden usar sus funciones para solamente firmar un fichero XML para enviarlo por otros medios.



Está compilado en Delphi Berlín e imagino que funcionará igualmente en Tokyo, para que funcione en versiones anteriores posiblemente habría que hacer algunos retoques.



Aunque lo pongo en un LEEME.TXT lo único que hay que hacer es tener instalada y registrada la dll de CAPICOM (no incluida) y posteriormente ejecutar el fichero REGISTER.BAT para registrar la dll que se usa para la firma.


Link para la descarga (https://drive.google.com/drive/folders/1WzmOToKrvu-h2gw40mPYEWVfUUJoSkZL).



Saludos y que aproveche.

Edito:

Se me olvidaba comentar dos temas:

1º Para poder enviar facturas a FACE hay que estar dado de alta como proveedor. Si quieres usar los wsdl de prueba hay que estar dado de alta por el entorno de pruebas y si quieres usar los de producción hay que darse de alta también en producción. Si no me equivoco, el entorno de pruebas es https://se-face.redsara.es/es/login

2º El programa que adjunto tiene los WSDL del entorno de pruebas, para pasar al de producción solo hay que cambiar en el objeto HTTPRIO el wsdl, puerto y servicio.

[espinete]

Me alegro de que por fin exista una alternativa que no necesite los componentes de SecureBlackBox, que por cierto, han subido de precio desorbitadamente desde que /n software compró Eldos.

Llevo tiempo trabajando con la factura electrónica de varios países (España, México, Costa Rica, Chile, Guatemala...) y estoy intentando crear una aplicación/módulo lo más sencilla y automática posible para que nuestro software de facturación sea compatible con todas ellas, pero me surge una duda.

Actualmente, para España, nuestro software necesita que el usuario (vendedor/emisor) indique manualmente si el destinatario (comprador/receptor) es persona Física o Jurídica, ya que el proceso es diferente (xml o xsig, con envío o sin envío, etc.).

¿No hay forma de saber eso a partir del NIF/CIF del Destinatario de la factura (dato que obviamente ya conocemos) con el fin de automatizarlo más y que no requiera intervención del usuario?

En otros países no es necesario especificarlo (no hay diferencia, ya que la factura se envía a Hacienda siempre), pero tengo entendido que en España solo es obligatorio para las Administraciones Públicas. ¿No hay forma entonces de saber, a partir del NIF/CIF del destinatario, si es una Admón. Pública o no, para en su caso, hacer automáticamente el proceso completo (xsig + enviar).

¿O es que estoy confundido del todo?

[newtron]

Me alegro de que por fin exista una alternativa que no necesite los componentes de SecureBlackBox, que por cierto, han subido de precio desorbitadamente desde que /n software compró Eldos.

Llevo tiempo trabajando con la factura electrónica de varios países (España, México, Costa Rica, Chile, Guatemala...) y estoy intentando crear una aplicación/módulo lo más sencilla y automática posible para que nuestro software de facturación sea compatible con todas ellas, pero me surge una duda.

Actualmente, para España, nuestro software necesita que el usuario (vendedor/emisor) indique manualmente si el destinatario (comprador/receptor) es persona Física o Jurídica, ya que el proceso es diferente (xml o xsig, con envío o sin envío, etc.).

¿No hay forma de saber eso a partir del NIF/CIF del Destinatario de la factura (dato que obviamente ya conocemos) con el fin de automatizarlo más y que no requiera intervención del usuario?

En otros países no es necesario especificarlo (no hay diferencia, ya que la factura se envía a Hacienda siempre), pero tengo entendido que en España solo es obligatorio para las Administraciones Públicas. ¿No hay forma entonces de saber, a partir del NIF/CIF del destinatario, si es una Admón. Pública o no, para en su caso, hacer automáticamente el proceso completo (xsig + enviar).

¿O es que estoy confundido del todo?


Bueno, yo la verdad es que hasta ahora solo la estoy usando para la administración pública así que no se me ha dado ese problema. Pero bueno, siempre puedes pedir los datos que necesites en la ficha del cliente, ¿no?


Saludos

[manelb]

Actualmente, para España, nuestro software necesita que el usuario (vendedor/emisor) indique manualmente si el destinatario (comprador/receptor) es persona Física o Jurídica, ya que el proceso es diferente (xml o xsig, con envío o sin envío, etc.).

¿No hay forma de saber eso a partir del NIF/CIF del Destinatario de la factura (dato que obviamente ya conocemos) con el fin de automatizarlo más y que no requiera intervención del usuario?


No te sirve con esto (https://www.agenciatributaria.es/AEAT.internet/Inicio/La_Agencia_Tributaria/Campanas/Censos__NIF_y_domicilio_fiscal/Empresas_y_profesionales__Declaracion_censal__Modelos_036_y_037/Informacion/NIF_de_personas_juridicas_y_entidades.shtml)??


Saludos

[espinete]

Cierto, eso serviría para diferenciar entre persona física y jurídica, pero no para las Administraciones Públicas (que requiere xsig + envío a face).

¿Cómo saber si el destinatario de la factura es una Admón. Pública y, a partir del CIF, obtener el Órgano Gestor, Unidad Tramitadora y Oficina Contable?

El WSDL tiene varias funciones para obtener las Administraciones y sus órganos, y otra función para obtener todos los NIFs existentes en el directorio DIR3 de administraciones adheridas, PERO ninguna de esas funciones devuelve todos los datos necesarios (Dirección, Población, Provincia, País, etc.) de cada unidad, porque creo que son obligatorios.

Eso me obliga a tener que crear una base de datos enorme que el cliente tendrá que rellenar, o bien solicitar esos datos para introducción manual cada vez que el usuario envíe una factura a una Administración. Lo veo demasiado tedioso, aunque funcione y las facturas a administraciones públicas sean "pocas", pero hoy en día creo que esto se puede automatizar muchísimo más.

[elguille]

Hola a tod@s.


Viendo que este asunto no prosperaba y que necesitaba resolverlo le encargué el proyecto a alguien que sabe más que nosotros y que domina varias herramientas de programación.


Había que resolver dos problemas, primero el de firmar el fichero XML en tiempo de ejecución, cosa que estaba complicada sin componentes externos porque desde Delphi no conocemos a nadie que haya sido capaz de hacerlo así que se ha desarrollado una dll en .NET que hace la función de firmado y que se llama desde el proyecto Delphi. Posteriormente había que hacer la llamada al webservice firmada con el protocolo X.509, cosa que tampoco sabíamos resolver y que tampoco ha sido fácil de desarrollar.


Resumiendo, aquí os adjunto un ejemplo operativo que hace las funciones más habituales de llamadas al webservice de FACE, firma y envía ficheros XML, consulta de facturas, consulta de unidades y alguna cosa más que no he probado porque en principio tampoco voy a necesitar. Por supuesto también se pueden usar sus funciones para solamente firmar un fichero XML para enviarlo por otros medios.



Está compilado en Delphi Berlín e imagino que funcionará igualmente en Tokyo, para que funcione en versiones anteriores posiblemente habría que hacer algunos retoques.



Aunque lo pongo en un LEEME.TXT lo único que hay que hacer es tener instalada y registrada la dll de CAPICOM (no incluida) y posteriormente ejecutar el fichero REGISTER.BAT para registrar la dll que se usa para la firma.


Link para la descarga (https://drive.google.com/drive/folders/1WzmOToKrvu-h2gw40mPYEWVfUUJoSkZL).



Saludos y que aproveche.

Edito:

Se me olvidaba comentar dos temas:

1º Para poder enviar facturas a FACE hay que estar dado de alta como proveedor. Si quieres usar los wsdl de prueba hay que estar dado de alta por el entorno de pruebas y si quieres usar los de producción hay que darse de alta también en producción. Si no me equivoco, el entorno de pruebas es https://se-face.redsara.es/es/login

2º El programa que adjunto tiene los WSDL del entorno de pruebas, para pasar al de producción solo hay que cambiar en el objeto HTTPRIO el wsdl, puerto y servicio.
Gracias Newtron por el codigo. Trasteando con el he enviado sin problemas una factura a la webservice de pruebas, pero para poderla emplear necesitaria poder añadir el PDF correspondiente a la imagen fisica de la factura, mirando el WDSL he añadido el siguiente codigo al enviar la factura


miarr:arrayofanexofile;
miarr1:anexofile;

if ficheropdf<>'' then
begin
MIARR1:=anexofile.create;
miarr1.mime:='application/pdf';
MIARR1.nombre:=extractfilename(ficheropdf);
MIARR1.anexo:=tfile.ReadAllText(ficheropdf);
SetLength(miarr, Length(miarr)+1);
miarr[0]:=miarr1;
SenderEnviarFactura.anexos := miarr;
end;

pero al hacerlo recibo el error "Se encontró un carácter no valido en el contenido del texto", imagino que tengo que codificar de alguna manera el texto resultante de tfile.ReadAllText(ficheropdf); ¿alguien sabe cómo se haría?
Gracias

[newtron]

Guille.


Me alegro de que te haya servido el código. Sobre el tema del problema que tienes la verdad es que no sabría decirte pero si te puedo comentar que tuvimos bastantes problemas con la codificación de los "strings" que se enviaban y al final funcionó codificando con UTF8Encode(...), no sé si los tiros en este caso irán por ahí.


Saludos

Edito: Si das con la solución compártelo por favor por si alguno lo necesitamos.

[elguille]

Guille.


Me alegro de que te haya servido el código. Sobre el tema del problema que tienes la verdad es que no sabría decirte pero si te puedo comentar que tuvimos bastantes problemas con la codificación de los "strings" que se enviaban y al final funcionó codificando con UTF8Encode(...), no sé si los tiros en este caso irán por ahí.


Saludos

Edito: Si das con la solución compártelo por favor por si alguno lo necesitamos.
Ya me fije con los comentarios que habiais hecho muchas pruebas. Lo que comentas y varias cosas mas ya las habia probado y no se me ocurre que empaquetado es el que quieren, en fin haré mas pruebas a ver si me viene alguna idea.

Gracias y saludos

[Al González]

[...]firmar el fichero XML en tiempo de ejecución, cosa que estaba complicada sin componentes externos porque desde Delphi no conocemos a nadie que haya sido capaz de hacerlo[...]
Y una vez que Embarcadero o algún programador lo consiga con código 100% en Delphi, será la noticia de la década.

[elguille]

var
miarr:arrayofanexofile;
miarr1:anexofile;

if edit1.Text<>'' then
begin
MIARR1:=anexofile.create;
miarr1.mime:='application/pdf';
MIARR1.nombre:=utf8encode(extractfilename(EDIT1.Text));
MIARR1.anexo:=Encode64(tfile.ReadAllText(edit1.Text),tetUTF8);
SetLength(miarr, Length(miarr)+1);
miarr[0]:=miarr1;
SenderEnviarFactura.anexos := miarr;
end;

A falta de hacer una prueba real este es el codigo correcto para añadir un pdf de imagen de la factura.

[newtron]

Código Delphi [-] (http://www.clubdelphi.com/foros/#)var miarr:arrayofanexofile; miarr1:anexofile; if edit1.Text<>'' then begin MIARR1:=anexofile.create; miarr1.mime:='application/pdf'; MIARR1.nombre:=utf8encode(extractfilename(EDIT1.Text)); MIARR1.anexo:=Encode64(tfile.ReadAllText(edit1.Text),tetUTF8); SetLength(miarr, Length(miarr)+1); miarr[0]:=miarr1; SenderEnviarFactura.anexos := miarr; end;

A falta de hacer una prueba real este es el codigo correcto para añadir un pdf de imagen de la factura.


^\||/^\||/ muchas gracias por la info, el que primero lo pruebe que lo confirme.


Saludos

[Virman]

Buenos días,
Tengo que realizar un programa que consulte el estado de las facturas pero sin certificado. En la web de FACE he visto que rellenando unos campos se permite realizar la consulta de facturas.

Entiendo que podría usar el programa que habéis aportado para realizar estas consultas, verdad?

Muchas gracias!

[newtron]

Buenos días,
Tengo que realizar un programa que consulte el estado de las facturas pero sin certificado. En la web de FACE he visto que rellenando unos campos se permite realizar la consulta de facturas.

Entiendo que podría usar el programa que habéis aportado para realizar estas consultas, verdad?

Muchas gracias!


Dudo que puedas consultar las facturas sin tener que introducir el certificado.

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

Tengo que realizar un programa que consulte el estado de las facturas pero sin certificado. En la web de FACE he visto que rellenando unos campos se permite realizar la consulta de facturas.



Tendrías quue acalarar qué sistema quieres utilizar. Hay varios.
Habría que ver si se puede enviar información de registro a la web utilizando las Indy o similares.



Entiendo que podría usar el programa que habéis aportado para realizar estas consultas, verdad?
No se de qué programa hablas. Está en este hilo.
¿Puedes dar un link al programa? No sigo con mucho detalle este hilo.


Dudo que puedas consultar las facturas sin tener que introducir el certificado.


Si se puede. Hay varios sistemas de consulta:


https://i.imgur.com/m4T0rrO.png

[Virman]

Si se puede. Hay varios sistemas de consulta:


https://i.imgur.com/m4T0rrO.png[/QUOTE]

Esta opción es a través de su web y obliga a introducir un captcha.

Lo que yo estoy preguntando es si habría posibilidad de, usando el web service, realizar esa consulta de una factura sin identificación y no tener que introducir captcha alguno.

Cualquier ayuda o sugerencia es agradecida.

Un saludo.

[Casimiro Notevi]

Esta opción es a través de su web y obliga a introducir un captcha.
Lo que yo estoy preguntando es si habría posibilidad de, usando el web service, realizar esa consulta de una factura sin identificación y no tener que introducir captcha alguno.Cualquier ayuda o sugerencia es agradecida.Un saludo.
Algún control debe tener, ya que entonces cualquiera podría ver las facturas de quien quisiera.

[newtron]

;531051']

Si se puede. Hay varios sistemas de consulta:


https://i.imgur.com/m4T0rrO.png


Me refería a que no creo que pueda hacer consultas sin identificarse.

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

Si se puede. Hay varios sistemas de consulta:
Esta opción es a través de su web y obliga a introducir un captcha.



Lo que yo preguntaba es ¿Cual de ellas?
Quitando la del certificado quedan 3.


Revisa estos hilos que explican cómo interactuar con una web:
http://www.clubdelphi.com/foros/showthread.php?t=37050
https://www.clubdelphi.com/foros/showthread.php?t=72067


Si buscas encontrarás más...

[Virman]

Usando el botón de Sin Identificación.

En el formulario que aparece a continuación te pide algún dato que identifique la factura e introducir un captcha. https://1drv.ms/u/s!Ar8oZnzvbJ7FmVRITrDI51MC9xPk

Mi consulta es si usando los métodos del webservice se podría hacer esta consulta a través de un programa, para no tener que usar la web y sin tener que introducir el captcha alguno.

Muchas gracias.

[Virman]

Usando el botón de Sin Identificación.

En el formulario que aparece a continuación te pide algún dato que identifique la factura e introducir un captcha. https://1drv.ms/u/s!Ar8oZnzvbJ7FmVRITrDI51MC9xPk

Mi consulta es si usando los métodos del webservice se podría hacer esta consulta a través de un programa, para no tener que usar la web y sin tener que introducir el captcha alguno.

Muchas gracias.

Me auto respondo.
Al final he optado por hacer una aplicación que interactúe con la web, como recomendaba Neftali [Germán.Estévez] :), es un tostón tener que estar introduciendo el captcha, pero al menos puedes consultar el estado de una factura sin tener que identificarte en el portal de FACE.

Gracias a todos por vuestros comentarios y ayuda.

[keys]

Hola a todos.

Tengo una aplicación que genera facturas en formato facturae y ahora quiero hacer que se envién directamente a face. ¿Sabeis donde se puede encontrar la informacion de los servicios web, wsdl, entornos de desarrollo, etc?. No lo encuentro en la página de face o ¿igual te lo envían cuando te das de alta?.

Gracias.

[nincillo]

Hola a todos.

Tengo una aplicación que genera facturas en formato facturae y ahora quiero hacer que se envién directamente a face. ¿Sabeis donde se puede encontrar la informacion de los servicios web, wsdl, entornos de desarrollo, etc?. No lo encuentro en la página de face o ¿igual te lo envían cuando te das de alta?.

Gracias.

Mira a ver si este post en concreto te puede servir para algo: https://www.clubdelphi.com/foros/showpost.php?p=547744&postcount=514

El hilo no es de FacturaE precisamente, pero ese ejemplo que posteó @ermendalenda si que parece que es para eso.

Yo creo que estoy en tu caso, actualmente genero el xml, pero luego lo subo manualmente a la plataforma y me gustaría poder enviarlo en modo "automático".

Prueba y cualquier cosa me dices para ver si avanzamos.

[nincillo]

Hola a todos.

Tengo una aplicación que genera facturas en formato facturae y ahora quiero hacer que se envién directamente a face. ¿Sabeis donde se puede encontrar la informacion de los servicios web, wsdl, entornos de desarrollo, etc?. No lo encuentro en la página de face o ¿igual te lo envían cuando te das de alta?.

Gracias.

¿Conseguiste avanzar algo?

Yo un poquito...

Me he dado de alta como integrador y ya consigo hacer consultas contra el webservice en el entorno de pruebas tras pedir que me diera de alta, etc...

Mi pregunta ahora es la siguiente, cuando mi aplicación la ponga en marcha en el ordenador de mi cliente, ¿voy a poder utilizar los webservice con el mismo certificado que hasta ahora estaba utilizando él para enviar las facturas manualmente o hay que pedir que también lo den de alta como "integrador"?. Es un punto que ahora mismo no tengo nada claro...

[newtron]

Buenas.

Yo creo que el certificado da igual, la diferencia es atacar a las urls de prueba o a las de producción.

Saludos.

[nincillo]

Buenas.

Yo creo que el certificado da igual, la diferencia es atacar a las urls de prueba o a las de producción.

Saludos.

Si selecciono el certificado que tengo dado de alta como integrador y pongo el programa "apuntando" a las url de prueba y le pido por ejemplo "SolicitarUnidades" me responde correctamente. (correcto)

Si con el mismo certificado, apunto al entorno real, me da error de que no estoy dado de alta (correcto también)

El problema viene cuando hago las prueba de envío con el certificado de "proveedor", no de "integrador". En ese caso me da error tanto en el entorno de pruebas como en el real.

Es como si hiciera falta también dar de alta o activar algo para poder hacer envíos mediante webservice con el certificado de proveedor...

Les he mandado una consulta, pero de momento no me han contestado...

[nincillo]

Hola a tod@s.


Viendo que este asunto no prosperaba y que necesitaba resolverlo le encargué el proyecto a alguien que sabe más que nosotros y que domina varias herramientas de programación.


Había que resolver dos problemas, primero el de firmar el fichero XML en tiempo de ejecución, cosa que estaba complicada sin componentes externos porque desde Delphi no conocemos a nadie que haya sido capaz de hacerlo así que se ha desarrollado una dll en .NET que hace la función de firmado y que se llama desde el proyecto Delphi. Posteriormente había que hacer la llamada al webservice firmada con el protocolo X.509, cosa que tampoco sabíamos resolver y que tampoco ha sido fácil de desarrollar.


Resumiendo, aquí os adjunto un ejemplo operativo que hace las funciones más habituales de llamadas al webservice de FACE, firma y envía ficheros XML, consulta de facturas, consulta de unidades y alguna cosa más que no he probado porque en principio tampoco voy a necesitar. Por supuesto también se pueden usar sus funciones para solamente firmar un fichero XML para enviarlo por otros medios.



Está compilado en Delphi Berlín e imagino que funcionará igualmente en Tokyo, para que funcione en versiones anteriores posiblemente habría que hacer algunos retoques.



Aunque lo pongo en un LEEME.TXT lo único que hay que hacer es tener instalada y registrada la dll de CAPICOM (no incluida) y posteriormente ejecutar el fichero REGISTER.BAT para registrar la dll que se usa para la firma.


Link para la descarga (https://drive.google.com/drive/folders/1WzmOToKrvu-h2gw40mPYEWVfUUJoSkZL).



Saludos y que aproveche.

Edito:

Se me olvidaba comentar dos temas:

1º Para poder enviar facturas a FACE hay que estar dado de alta como proveedor. Si quieres usar los wsdl de prueba hay que estar dado de alta por el entorno de pruebas y si quieres usar los de producción hay que darse de alta también en producción. Si no me equivoco, el entorno de pruebas es https://se-face.redsara.es/es/login

2º El programa que adjunto tiene los WSDL del entorno de pruebas, para pasar al de producción solo hay que cambiar en el objeto HTTPRIO el wsdl, puerto y servicio.

Hola.

Estoy intentando poner en marcha el intercambio de información con la sede electrónica de Facturae utilizando D2007 y poco a poco, partiendo del ejemplo que compartió en su momento newtron (muchas gracias por hacerlo) voy consiguiendo hacer casi "todo".

Actualmente, si las peticiones las hago utilizando los certificados instalados en el sistema, la petición se envía y la respuesta se recibe. Sin embargo, si la petición la intento hacer utilizando un certificado que está en fichero del disco duro, la petición no se llega a lanzar ya que me salta el siguiente error: 'wsu' es un espacio de nombres sin declarar. Línea 2, posición 327.

Si la contraseña que pongo no es la correcta, me salta el mensaje de que no es correcta, con lo cual el chequeo de la contraseña lo hace correctamente, pero cuando luego "entiendo" que intenta montar el Xml, algún problema problema hay.

Entonces me he conseguido montar en entorno de pruebas con una versión de delphi más moderna para probar el ejemplo tal cual se publicó en su momento, y me he encontrado que presenta el mismo problema. Al firmar con el certificado del sistema lo hace correctamente, pero si se intenta firmar con el certificado en fichero, sale el mismo mensaje de error.

A ver si alquilen me puede "iluminar".

Gracias y un saludo.

[ermendalenda]

Un pelin más cerca de la otra obligación
Factura electrónica.
Si el moderador piensa que es mejor abrir otro hilo sin problema
https://www.boe.es/eli/es/l/2022/09/28/18

[elcharlie]

Si selecciono el certificado que tengo dado de alta como integrador y pongo el programa "apuntando" a las url de prueba y le pido por ejemplo "SolicitarUnidades" me responde correctamente. (correcto)

Si con el mismo certificado, apunto al entorno real, me da error de que no estoy dado de alta (correcto también)

El problema viene cuando hago las prueba de envío con el certificado de "proveedor", no de "integrador". En ese caso me da error tanto en el entorno de pruebas como en el real.

Es como si hiciera falta también dar de alta o activar algo para poder hacer envíos mediante webservice con el certificado de proveedor...

Les he mandado una consulta, pero de momento no me han contestado...

Hola, Tengo la misma duda, ¿Te han contestado algo? Me toca ahora integrar el envío de la factura a FACE y me estaba planteando la misma duda.

[ermendalenda]

Hola, Tengo la misma duda, ¿Te han contestado algo? Me toca ahora integrar el envío de la factura a FACE y me estaba planteando la misma duda.

Imaginaos que se ponen de acuerdo Ministerio de Economía y Transformación Digital con Hacienda y para la factura electrónica amplían el XML de Verifactu a los campos que faltan y los entornos de prieba y prodccuion sean los mismos que los de Verifactu.no sé, lo mismo estamos currando de más.

[ermendalenda]

Buenas de nuevo.
Estoy dándole vueltas al procedimiento desee que me pieennuna factura electrónica, independientemente de cual sea el reglamento, mínimo pedirán datos normales eel cliente + datos DIR3.
Teniendo en cuenta esto veo una gran complicación para puestos de facturación rápidas, por ejemplo en tiendas de ventas al por menor en los que esa gestión se hace inviablemQue os parece la idea de que se le envíe un correo con un enlace al cliente para que :
1. Sirva como autorización expresa
2. Rellene el formulario con todos los dato para generar la factura.
3. Devuelva el error al mismo cliente en caso de que la comunicación sea fallida por datos incorrectos
4. En caso de repetición de cliente ya están guardados los datos
5.posibilidad de que el vendedor pueda reenviar una factura electronica o pueda revocar la autorización a petición del cliente.

Creo que de esta forma liberamos la carga y responsabilidad de los comercios. Pero no se a efectos legales y si esta dentro de los límites.
Como lo veis?

[antoine0]

Que os parece la idea de que se le envíe un correo con un enlace al cliente para que :
1. Sirva como autorización expresa
2. Rellene el formulario con todos los dato para generar la factura.
3. Devuelva el error al mismo cliente en caso de que la comunicación sea fallida por datos incorrectos
4. En caso de repetición de cliente ya están guardados los datos
5.posibilidad de que el vendedor pueda reenviar una factura electronica o pueda revocar la autorización a petición del cliente.

Creo que de esta forma liberamos la carga y responsabilidad de los comercios. Pero no se a efectos legales y si esta dentro de los límites.
Como lo veis?

Primero me parece que la casuística es la típica de las tiendas, hipermercados y demás, cuando el cliente autónomo quiere factura en lugar de ticket.
En la practica veo dos maneras de hacerlo: o vas a algún mostrador (o directo en el programa del cajero) y tienen un proceso para registrarte (suelen usar tu NIF como clave) y luego emiten la factura de sustitución. o te conectes a alguna web donde tu haces el mismo proceso creando una «cuenta», das tu datos, entres el número del tique y te sacas la factura; y la tienda no paga el cajero, ni lo forma
En mi practica, odio a la segunda manera y prefiero la primera, pero no me dan la elección. :(
Del punto de vista de la seguridad de datos, supongo que se da un número seudo-aleatorio al tique (o ligado al tique, por ejemplo impreso en él) para evitar que alguien pueda traerse una factura sin haber comprado la mercancía. No sé si usando la fecha-hora sería suficiente. Tampoco sé si se puede (o se debe) evitar que alguien recoge un tique en el suelo. Pero me imagino que ya está estudiado.
Y estos sistemas deben ser legales sí o sí.
Con la factura electrónica la segunda opción será fundamente la misma. En el caso de la primera, si las facturas electrónicas se ponen a disposición directamente del proveedor al cliente (y no pasan por un punto central, como ocurre en demás países o con FACe) supongo que pedirán una dirección de correo electrónico, o pedirán que el cliente se conecte después a alguna web con un certificado ligado a su NIF, o lo que les ocurre a los redactores de los ministerios. Aquí no sabe nadie dónde estarán las lindes...

Luego la idea del link por correo electrónico supone que el comerciante debe pedir su correo electrónico al cliente (y al cliente puede ser que no le hace gracia, por ejemplo si no quiere recibir «comunicación» de «promociones») y luego no equivocarse a la hora de entrarlo en el sistema. Creo que dar a conocer una dirección web (mi caso 2) resulta más o menos igual en la gestión cliente y bastante menos posibilidades de error a nivel informático; pero se pierde el vinculo...

[ermendalenda]

Primero me parece que la casuística es la típica de las tiendas, hipermercados y demás, cuando el cliente autónomo quiere factura en lugar de ticket.
En la practica veo dos maneras de hacerlo: o vas a algún mostrador (o directo en el programa del cajero) y tienen un proceso para registrarte (suelen usar tu NIF como clave) y luego emiten la factura de sustitución. o te conectes a alguna web donde tu haces el mismo proceso creando una «cuenta», das tu datos, entres el número del tique y te sacas la factura; y la tienda no paga el cajero, ni lo forma
En mi practica, odio a la segunda manera y prefiero la primera, pero no me dan la elección. :(
Del punto de vista de la seguridad de datos, supongo que se da un número seudo-aleatorio al tique (o ligado al tique, por ejemplo impreso en él) para evitar que alguien pueda traerse una factura sin haber comprado la mercancía. No sé si usando la fecha-hora sería suficiente. Tampoco sé si se puede (o se debe) evitar que alguien recoge un tique en el suelo. Pero me imagino que ya está estudiado.
Y estos sistemas deben ser legales sí o sí.
Con la factura electrónica la segunda opción será fundamente la misma. En el caso de la primera, si las facturas electrónicas se ponen a disposición directamente del proveedor al cliente (y no pasan por un punto central, como ocurre en demás países o con FACe) supongo que pedirán una dirección de correo electrónico, o pedirán que el cliente se conecte después a alguna web con un certificado ligado a su NIF, o lo que les ocurre a los redactores de los ministerios. Aquí no sabe nadie dónde estarán las lindes...

Luego la idea del link por correo electrónico supone que el comerciante debe pedir su correo electrónico al cliente (y al cliente puede ser que no le hace gracia, por ejemplo si no quiere recibir «comunicación» de «promociones») y luego no equivocarse a la hora de entrarlo en el sistema. Creo que dar a conocer una dirección web (mi caso 2) resulta más o menos igual en la gestión cliente y bastante menos posibilidades de error a nivel informático; pero se pierde el vinculo...
Bueno. Me refiero a algo intermedio la factura la generamos con los datos principales, da igual de a
Sustitucion, ordinaria o de canje con los datos esenciales cif, nombre dirección... e incluso un pdf con la factura ordinaria, pero para solicitar la factura electrónica se le envía un formulario con los datos ya introducidos por el vendedor y el número de factura asignada a un correo del mismo cliente, a falta de rellenar los fatos necesarios para la factura electronica , con lo cual no da lugar a poder emitir algo que no es y ya aprovechamos para, si el cliente quiere, guardar esos datos.

[ermendalenda]

Os dejo un enlace interesante que da la idea de por donde van los tiros de por donde podemos ir tirando con lo de la nueva ley de factura electronica que ha salido recientemente en el BOE sobre creacion y crecimiento de empresas (BOE de Septiembre de 2022)

Este enlace tiene la parte mas interesante en las páginas 7 y 8 en los que hace referencia de usar la red de Face/Faceb2b como nodo común de los proveedoress de servicios de factura electronica:
https://administracionelectronica.gob.es/comunidades/resources/Comunidades/201/Descargas/Acuerdos%20Foro%20Factura%20Electronica-28012019.pdf?idElemento=463&idComunidad=201

Teniendo en cuenta que ya han pasado 3 años desde este acuerdo pueden haber repensado el tema y como os decia, no me extraña que se use como base Veri*Factu y los campos que faltan para realizar la factura electronica: DIR, Productos y servicios, pero que finalmente vayan a la redsara de Faceb2b. Son conjeturas mías, ¿que pensais vosotros?

Este es el enlace de la web de PAE donde esta ubicada la información: https://administracionelectronica.gob.es/comunidades/forofacturae/documentacion

[elcharlie]

Buenas a tod@s, ¿sabe alguien si hay algún ejemplo de envío con SecureBlackBox?
Estoy intentando de todo y me da error de cabecera.

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

En este otro hilo (sobre TicketBAI) (https://www.clubdelphi.com/foros/showthread.php?t=94264) hay varios ejemplos de envío con SecureBlackBox.
El tema es diferente, pero tal vez si miras el código te de alguna ayuda o pista para resolverlo.

En el segundo mensaje del hilo (https://www.clubdelphi.com/foros/showpost.php?p=532431&postcount=2), hay referencias a códigos y ejemplos de envío con diferentes componentes.
Ahí encontrarás algunos de firma y envío con los SecureBlackBox.

NOTA: por favor no mezcles mensajes entre hilos.

[ermendalenda]

Estoy haciendo todo esto en php como el firmador.php de ticketbai, pero un php para cada utilidad de face y faceb2 sin pagar nada de apis:.
Firmador.php
Envio_face_faceb2b.php (con la creación del soap)
Servicios_face_faceb2b.php (cambios de estado, consultas, anulaciones...)
Tanto para staging(pruebas) como producción
De modo que se pueda ejecutar con órdenes sencillas curl y devuelva el resultado en un archivo y así poderlo usar desde cualquier lenguaje
Vaya currada

[elcharlie]

;548679']En este otro hilo (sobre TicketBAI) (https://www.clubdelphi.com/foros/showthread.php?t=94264) hay varios ejemplos de envío con SecureBlackBox.
El tema es diferente, pero tal vez si miras el código te de alguna ayuda o pista para resolverlo.

En el segundo mensaje del hilo (https://www.clubdelphi.com/foros/showpost.php?p=532431&postcount=2), hay referencias a códigos y ejemplos de envío con diferentes componentes.
Ahí encontrarás algunos de firma y envío con los SecureBlackBox.

NOTA: por favor no mezcles mensajes entre hilos.

Gracias Germán, pero el envío de Facturas Electronicas a Face es completamente distinto al de los del TicketBai, de ahí mi pregunta,
por otro lado perdona si me he equivocado de hilo, pero he dado por hecho que seria en este, Facturas Electronicas.
No obstante, muchas gracias por info, y de nuevo mis disculpas.

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

pero el envío de Facturas Electronicas a Face es completamente distinto al de los del TicketBai, de ahí mi pregunta

Si, se que es diferente, pero pensé que te podía dar pistas de las propiedades a la hora de configurar los componentes.


por otro lado perdona si me he equivocado de hilo, pero he dado por hecho que seria en este, Facturas Electronicas.

Para nada, este es el hilo correcto.
Me refería a que si preguntabas algo en el foro de TicketBAI referente al envío, que intentaras no mezclar.

[nuevo1234]

Verifactu y facturae son dos cosas diferentes? Tienen alguna relación?
Perdón por mi desconocimiento. Pero con tantas novedades me pierdo

[ermendalenda]

Verifactu y facturae son dos cosas diferentes? Tienen alguna relación?
Perdón por mi desconocimiento. Pero con tantas novedad, de foema similar al siis me pierdo

Sí, son diferentes , Verifactu es una normativa que te obliga a generar unos ficheros xmls que puedes enviarlo a la aeat (como el sii) o conservarlos firmados ante posibles requerimientos de la aeat.
La factura electronica es el intercambio de facturas entre un proveedor y un cliente, también esttructurada.
Relación habrá si un cliente te pide una factura electrónica, seguramente hebras que ponerle el código generado con verifactu en algún campo de la factura electrónica.

[newtron]

Hola a tod@s.

Por si a alguien le sirve, aquí (https://varonasupport.com/circular-25-2022-obligatoriedad-facturacion-electronica/) tenéis un buen resumen del tema de la facturación electrónica con plazos concretos de entrada en vigor.

Saludos.

[keys]

Gracias.

Me hace gracia lo siguiente :

Para ello, las soluciones tecnológicas y plataformas ofrecidas por empresas
proveedoras de facturación electrónica, deberán garantizar la gratuidad de las
mismas.

Con un par.

[newtron]

Pues si, la verdad es que no me cuadra mucho ese párrafo. Quiero entender que al cliente que solicite una factura electrónica a su proveedor no se le cobre por emitirsela.

Saludos.

[Casimiro Notevi]

Me hace gracia lo siguiente :
Con un par.
:eek:
Pues nada, que habiliten una renta vitalicia para "informáticos".

[espinete]

Hola a tod@s...

Entre la "Ley Antifraude", FacturaE (face, faceb2b), SII, TicketBAI y la "nueva factura electrónica" de la que se está hablando ahora, ya tengo la cabeza que no me da para más. A ver si me lo podéis aclarar, si es que es posible aclararlo...

La "Ley Antifraude" exigía a las aplicaciones de facturación a cumplir una serie de requisitos: no permitir borrar o modificar facturas, exigir hacer rectificativas, que si la integridad de los datos, accesibilidad, blablabla.
FacturaE lleva con nosotros varios años ya, así como el SII (que ya de por sí, encima algunas comunidades autónomas tienen sus diferencias).
Luego País Vasco decidió ir por su cuenta y sacó el TicketBAI, adelantándose al resto.
Y ahora anuncuan la "Factura Electrónica", entiendo que para 2024-2025 (o a saber si se retrasa).

Entiendo que esta factura electrónica nueva es la evolución lógica de la "Ley Antifraude" y una copia del TicketBAI, pero para toda España. Pero... ¿qué pasará con todo lo demás? (face, sii, ticketbai...)? ¿País Vasco seguirá por su lado? ¿Se sabe algo de otras comunidades?

Me parece MUY FUERTE lo de "...las soluciones tecnológicas y plataformas ofrecidas por empresas proveedoras de facturación electrónica, deberán garantizar la gratuidad de las mismas...". ¿Peeerdooonaaa? ¿Pero esta gente se cree que trabajamos para ellos o qué?

En fin, que me gustaría saber qué es cada cosa, y hay que centrarse únicamente en desarrollar la "nueva factura electrónica", porque tengo la cabeza hecha un lío.
Actualmente nuestro software ya es compatible con FacturaE, SII y TicketBAI. Entiendo (espero) que esta nueva factura electrónica se parezca más al TicketBAI, que bastantes dolores de cabeza nos supuso en su momento a todos.

Ya podría Hacienda enrollarse con las empresas de software y habilitarnos un periodo con una reducción de impuestos, por las molestias :rolleyes:

[kuan-yiu]

Para ello, las soluciones tecnológicas y plataformas ofrecidas por empresas
proveedoras de facturación electrónica, deberán garantizar la gratuidad de las
mismas.
Creo que es un problema de redacción, espero que lo sea.
A los que hacen estos textos no les iría mal hacer un curso de escritura, volver a la secundaria o algo para aprender a redactar. (O que Google incluya en su traductor: lenguaje oficial :D )

[adolphsys]

Hola a tod@s...

...

Entiendo que esta factura electrónica nueva es la evolución lógica de la "Ley Antifraude" y una copia del TicketBAI, pero para toda España. Pero... ¿qué pasará con todo lo demás? (face, sii, ticketbai...)? ¿País Vasco seguirá por su lado? ¿Se sabe algo de otras comunidades?

...

Hola espinete, la "Ley Antifraude" y la factura electrónica son asuntos distintos, en mi opinión:

- La "Ley Antifraude" (VeriFactu) es el TicketBAI de la AEAT. Si ya tenemos la aplicación hecha para TicketBAI, cuando se publique el reglamento VeriFactu se desarrolla en la misma línea como "cuarta hacienda foral", o quinta si contamos con Navarra, que al final no se sabe si irá por TicketBAI o VeriFactu, esta es otra...
- FACE sigue siendo lo mismo: si prestamos un servicio al Ayuntamiento de Madrid éste espera que le envíes un XML FacturaE firmado mediante FACE, si no, no te pagará la factura.
- Si el servicio lo prestamos a una Administración Pública del País Vasco, tendremos que cumplir con la normativa TicketBAI y además generar el XML firmado.
- Con el SII también vamos a convivir, en este caso presentamos los datos de facturas de venta, y también de compra a la AEAT con un margen de 4 días.
- Se nos olvidaba el FACeB2B, una extensión de FACE que permite facturar a subcontratistas especificando la obra del contratista en el XML, y algunas cosas más...
...

Un follón, no cabe duda, pero lamentablemente esto ha llegado para quedarse.

[adolphsys]

Hola a tod@s...

...

Me parece MUY FUERTE lo de "...las soluciones tecnológicas y plataformas ofrecidas por empresas proveedoras de facturación electrónica, deberán garantizar la gratuidad de las mismas...". ¿Peeerdooonaaa? ¿Pero esta gente se cree que trabajamos para ellos o qué?

...
:

Desde mi punto de vista se están refiriendo a los protocolos de comunicación entre plataformas: si la empresa A usa B2BRouter para emitir facturas electrónicas a la empresa B que las recibe por EDICOM, dichas plataformas se tendrán que poner de acuerdo en cuanto a la interconexión e interoperabilidad, cuyo reglamento además está pendiente de publicar (Artículo 2 bis, Apartado 10, Ley 18/2022, de 28 de septiembre).

[ermendalenda]

Hola a tod@s...

Entre la "Ley Antifraude", FacturaE (face, faceb2b), SII, TicketBAI y la "nueva factura electrónica" de la que se está hablando ahora, ya tengo la cabeza que no me da para más. A ver si me lo podéis aclarar, si es que es posible aclararlo...

La "Ley Antifraude" exigía a las aplicaciones de facturación a cumplir una serie de requisitos: no permitir borrar o modificar facturas, exigir hacer rectificativas, que si la integridad de los datos, accesibilidad, blablabla.
FacturaE lleva con nosotros varios años ya, así como el SII (que ya de por sí, encima algunas comunidades autónomas tienen sus diferencias).
Luego País Vasco decidió ir por su cuenta y sacó el TicketBAI, adelantándose al resto.
Y ahora anuncuan la "Factura Electrónica", entiendo que para 2024-2025 (o a saber si se retrasa).

Entiendo que esta factura electrónica nueva es la evolución lógica de la "Ley Antifraude" y una copia del TicketBAI, pero para toda España. Pero... ¿qué pasará con todo lo demás? (face, sii, ticketbai...)? ¿País Vasco seguirá por su lado? ¿Se sabe algo de otras comunidades?

Me parece MUY FUERTE lo de "...las soluciones tecnológicas y plataformas ofrecidas por empresas proveedoras de facturación electrónica, deberán garantizar la gratuidad de las mismas...". ¿Peeerdooonaaa? ¿Pero esta gente se cree que trabajamos para ellos o qué?

En fin, que me gustaría saber qué es cada cosa, y hay que centrarse únicamente en desarrollar la "nueva factura electrónica", porque tengo la cabeza hecha un lío.
Actualmente nuestro software ya es compatible con FacturaE, SII y TicketBAI. Entiendo (espero) que esta nueva factura electrónica se parezca más al TicketBAI, que bastantes dolores de cabeza nos supuso en su momento a todos.

Ya podría Hacienda enrollarse con las empresas de software y habilitarnos un periodo con una reducción de impuestos, por las molestias :rolleyes:

Normativa 1: Verifactu es similar a tickebai para enviar a hacienda
Normativa 2: factura electrónica, es el conjunto de las facturas electrónicas que existen(las que cumplen nomrat8vas), , facturae, People...,, es la obligación de enviar y recibir facturas a y desde proveedores... puede intervenir organos como el ministerio de economía y hacienda si hay o detecta morosidad excesiva.
Son 2 normativas y las 2 serán obligatorias, la gratuidad se refiere a que debe estar disponible para el receptor de la factura por los x años que esté vigente según ley, 4 ó 5 años creo.

[ermendalenda]

Hola a tod@s.

Por si a alguien le sirve, aquí (https://varonasupport.com/circular-25-2022-obligatoriedad-facturacion-electronica/) tenéis un buen resumen del tema de la facturación electrónica con plazos concretos de entrada en vigor.

Saludos.
Gracias habrá que empaparse y apeovechar la poca información que hay de momento.

[espinete]

Hola...

Necesito obtener el listado de administraciones públicas y sus correspondientes "órgano gestor", "unidad tramitadora", "oficina contable", etc.

En Delphi lo tengo hecho, pero necesito ahora hacerlo en PHP y nunca he trabajado con WSDL desde PHP.

Sé que existe una API REST para obtener las entidades acogidas a DIRe (Directorio de Entidades), pero creo que no es lo mismo. Necesito obtener las administraciones públicas, y solo encuentro la opción WSDL:
://administracionelectronica.gob.es/ctt/face/descargas

¿No existe API REST para obtener ese listado?

[espinete]

Hola...

Necesito obtener el listado de administraciones públicas y sus correspondientes "órgano gestor", "unidad tramitadora", "oficina contable", etc.

En Delphi lo tengo hecho, pero necesito ahora hacerlo en PHP y nunca he trabajado con WSDL desde PHP.

Sé que existe una API REST para obtener las entidades acogidas a DIRe (Directorio de Entidades), pero creo que no es lo mismo. Necesito obtener las administraciones públicas, y solo encuentro la opción WSDL:
://administracionelectronica.gob.es/ctt/face/descargas

¿No existe API REST para obtener ese listado?

Me respondo a mi mismo...

(y acabo de darme cuenta que quien abrió este hilo hace ya 7 años fui yo!! :eek:)

Solo existe el SOAP, así que hay que currarse la creación del XML, la firma, etc. en PHP "a mano" (o usar alguna librería de FacturaE que lo haga).

Aclaro (a mi mismo también) que una cosa es DIRe y otra DIR3. Esta gente poniendo nombres son lo más.

Disculpen por postear sobre PHP, pero como en los hilos de ticketBai hay también algo de código php, lo pregunté aquí.

[JOSEA]

Hola a todos,
Expongo aquí alguna información de como va el temita de la facturación electrónica a falta de que se publiquen los requerimientos técnicos y nos compliquen la vida.
Al parecer, a diferencia de otros países como Italia, en España no va existir (...de momento) una plataforma única donde enviar y recibir las facturas electrónicas, se ha
optado por la vía de lo privado, de modo que cada empresa (o autónomo) deberá elegir una plataforma privada de las que ya existen (como por ejemplo Edicom) o de las
que seguro se crearan nuevas, a esa plataforma privada es a la que se enviarán y de la que se recibirán las facturas a cliente o de proveedores.
"La gratuidad" a la que se refiere la ley es a la interconectividad entre las plataformas, o sea, que la empresa contrata con una sola plataforma y esa plataforma es la que se encarga de conectarse con otras para enviar la factura a los clientes o recibirla de proveedores, independientemente de la plataforma que tenga contratada cada uno.
En cuanto a los formatos de la factura todavía no está claro, cuantos ni cuales serán admitidos, supongo que se publicará alguno con los datos mínimo, en principio la idea es admitir todos los formatos estándar internacionales Edifac , el propio del facturae a administraciones públicas, etc. Es de suponer que como cada plataforma opera con el suyo, admitirán varios formatos.(???)
En definitiva nos tocará pagar a todas las empresas las plataformas privadas y a nosotros como programadores pelearnos con sus formatos y sus enlaces. Espero que al ser privadas por lo menos que sean agiles a la hora de poner servidores de prueba.
De todas formas esto parece que va muy lento para el grueso de empresas será obligatorio en 2025 así que recomiendo no agobiarnos de momento.

[elcharlie]

Hola a todos,
Expongo aquí alguna información de como va el temita de la facturación electrónica a falta de que se publiquen los requerimientos técnicos y nos compliquen la vida.
Al parecer, a diferencia de otros países como Italia, en España no va existir (...de momento) una plataforma única donde enviar y recibir las facturas electrónicas, se ha
optado por la vía de lo privado, de modo que cada empresa (o autónomo) deberá elegir una plataforma privada de las que ya existen (como por ejemplo Edicom) o de las
que seguro se crearan nuevas, a esa plataforma privada es a la que se enviarán y de la que se recibirán las facturas a cliente o de proveedores.
"La gratuidad" a la que se refiere la ley es a la interconectividad entre las plataformas, o sea, que la empresa contrata con una sola plataforma y esa plataforma es la que se encarga de conectarse con otras para enviar la factura a los clientes o recibirla de proveedores, independientemente de la plataforma que tenga contratada cada uno.
En cuanto a los formatos de la factura todavía no está claro, cuantos ni cuales serán admitidos, supongo que se publicará alguno con los datos mínimo, en principio la idea es admitir todos los formatos estándar internacionales Edifac , el propio del facturae a administraciones públicas, etc. Es de suponer que como cada plataforma opera con el suyo, admitirán varios formatos.(???)
En definitiva nos tocará pagar a todas las empresas las plataformas privadas y a nosotros como programadores pelearnos con sus formatos y sus enlaces. Espero que al ser privadas por lo menos que sean agiles a la hora de poner servidores de prueba.
De todas formas esto parece que va muy lento para el grueso de empresas será obligatorio en 2025 así que recomiendo no agobiarnos de momento.

Pero..., disculpa mi ignorancia, pq todavia no me he metido con el tema. Pero no se supone que con FACE B2B, es ahí donde tendremos que enviar y recibir las facturas?, y ademas de forma gratuita? Pq siempre he pensado que para eso habian habilitado ese portal...

[espinete]

Pero vamos a ver una cosa...

¿Cómo que varios formatos? ¿Cómo que varias plataformas?

O sea, que la empresa de software debe encargarse de elegir una plataforma donde subir las facturas y permitir consultarlas (el alojamiento en la nube cuesta dinero)? Y además, probablemente, hacer que el software debe ser compatible con todos los formatos posibles?

No les sirvió Ticketbai como ejemplo, pese a sus problemas iniciales?

No se supone que FacturaE, FACe, SII deberían haber servido para algo?

Vamos a seguir siendo el país de los PARCHES?

[newtron]

Pues qué quereis que os diga. Dentro de mi ignorancia de cómo está la cosa en la actualidad dudo que obliguen a TODO EL MUNDO a asociarse con una plataforma para el tema de las facturas electrónicas. Eso vale dinero y yo en particular no lo veo necesario. En teoría la ley obligará a emitir y recibir facturas electrónicas. Muchos de nosotros ya emitimos facturas con formato "facturae" sin mayor problema y recibirlas tampoco debería de serlo porque no deja de ser un fichero XML y en internet hay lectores de facturas electrónicas. ¿Para qué queremos entonces una plataforma?

Saludos.

[antoine0]

Es de suponer que como cada plataforma opera con el suyo, admitirán varios formatos.(???)
Se puede esperar que si una empresa (cliente) utiliza más de un formato de intercambio, la plataforma le hace pagar más cuotas. Por tanto, para una empresa (pequeña) dada, al final opera siempre con un solo formato. Y para un desarrollador ocurre un poco lo mismo: elige a una plataforma de referencia, y a un formato; no hacerlo significaría suportar un suplemento de gasto y tiempo que no se puede facturar.

De hecho es una de las razones que hace que el mundo de las plataformas quedará reducido a unas pocas al paso del tiempo; que ¿serán las que han sabido atraer a los desarrolladores?

En definitiva nos tocará pagar a todas las empresas las plataformas privadas y a nosotros como programadores pelearnos con sus formatos y sus enlaces. Espero que al ser privadas por lo menos que sean agiles a la hora de poner servidores de prueba.
Me encontró en este posición; y he tenido la sorpresa que para usar la plataforma de pruebas, había que pagar un segundo contrato, como si fuese una segunda empresa.
Es cierto que usaba un contrato baratísimo, y que había otras formas de contrato más premium que incluyan el acceso a la plataforma de pruebas; y un desarrollador independiente debe optar al tipo de contrato que le será más adaptado; que será distinto del contrato de su cliente... (= más gasto o más facturación, según cómo se mira).
Aparte de ser más agiles, hay que recordar que las empresas privadas no suelen regalar medios o funcionalidades.
De todas formas esto parece que va muy lento para el grueso de empresas será obligatorio en 2025 así que recomiendo no agobiarnos de momento.
Hay dos vertientes: emitir facturas, y recibirlas. Lo de emitir sería en 2025 para muchas empresas. Pero de lo que he leído hasta la fecha, las que la empresa reciben serán electrónicas si así lo decide el emisor. En 2023 si el emisor es grande empresa.
Es cierto que las plataformas pueden aliviar el tema para las muchas empresas que manejan un número reducido de facturas, lo pondrán en PDF y con eso se apaña mucha gente. Pero si la empresa quiere ir un poco más lejos y recuperar los datos que están incorporadas en la factura electrónica, es decir modo ERP en lugar de ser una sencilla contabilidad, deberán lidiar con la API y el formato propuesto por la plataforma (después de haber pasado por caja). ¡Ya!

[antoine0]

¿Para qué queremos entonces una plataforma?
Creo que a esto ya ha respondido espinete:
(el alojamiento en la nube cuesta dinero)
Aunque estoy consciente que lo de «nosotros» y «queremos» tiene matices que pueden ser variopintas :rolleyes:

[afxe]

TENIA ENTENDIDO: que el FaceB2B es una plataforma suministrada por la AEAT para la remisión de facturas entre empresas que subcontraten con las Administraciones... pero que quedaría abierto para que cualquier empresa pueda usarla como plataforma de emisión y recepción de facturas. El formato electrónico es parecido al que generamos para el FACE.GOB.ES pero posiblemente haya que meter cambios... primero porque las empresas privadas tienen un identificador DIRe, mientras las administraciones públicas tienen 3 identificadores: Órgano Gestor, Unidad Tramitadora y Órgano Contable. Para Obtener un identificador DIRe sólo tienes que registrarte con un certificado válido, luego puedes de darte de alta en FACEB2B sin problemas como "Cliente".

¿Y programas y los desarrolladores? Para que nuestro software pueda automatizar el envío de facturas, creo que podemos darnos de alta en esa plataforma como ESF: Empresas de Servicios de Facturación, para lo cual nos tenemos que registrar y obtener un permiso, también solicitando un DIRe, con nuestro certificado, y rellenando un cuestionario... entonces, si nos aceptan, apareceremos en su bonito listado de ESF asociadas al FACEB2B. A partir de ahí, las empresas que tengan plataformas como el FACEB2B (voxtel, ingram, edicom...), están obligadas a comunicarse entre ellas (incluido el FACEB2B) para suministrar al consumidor final una factura en formato electrónico standard, cuando éste lo solicite... y si terceras plataformas incorporan facturas electrónicas de otros clientes, también están obligados a comunicarse con el FaceB2B para que los receptores puedan solicitar sus facturas a través de este único canal....

Imaginaros si para consultar las facturas de un proveedor tuviéramos que ir mendigando en todas las plataformas a ver si hay algo para mí !!!

Espero no estar equivocado, por lo que les pido que si alguien consigue darse de alta como ESF exponga su experiencia y confirme la metodología que he expuesto... estamos saturados de trabajo y nos queda unas semanas para que nosotros podamos abordar este tema.

[JOSEA]

Hola dejo enlace de webinar donde explican un poco el tema de la facturación electronica,
realizado por EDICOM, en colaboración con el Ministerio de Asuntos Económicos y Transformación Digital,
es un poco simple y aburrido pero adelanta como será el tema de las plataformas.
https://www.youtube.com/watch?v=YOuCOu2URTM

[PepCat]

Hola dejo enlace de webinar donde explican un poco el tema de la facturación electronica,
realizado por EDICOM, en colaboración con el Ministerio de Asuntos Económicos y Transformación Digital,
es un poco simple y aburrido pero adelanta como será el tema de las plataformas.


Muy interesante.

En el minuto 16:20 habla de comunicar los "Estado de la Factura", para mí ha sido una novedad.

Muchas Gracias

[newtron]

Gracias a ti compañero por la info. ^\||/

[JOSEA]

Pero..., disculpa mi ignorancia, pq todavia no me he metido con el tema. Pero no se supone que con FACE B2B, es ahí donde tendremos que enviar y recibir las facturas?, y ademas de forma gratuita? Pq siempre he pensado que para eso habian habilitado ese portal...

Pues eso pensaba yo también, he dejado un enlace a webinar que te puede ser interesante, donde explican un poco lo que nos viene.
espero que al final los precios sean económicos o estén subvencionados o terminen poniendo una plataforma gratuita.

[elcharlie]

Pues eso pensaba yo también, he dejado un enlace a webinar que te puede ser interesante, donde explican un poco lo que nos viene.
espero que al final los precios sean económicos o estén subvencionados o terminen poniendo una plataforma gratuita.

Ok, le echare un vistazo cuando pueda, gracias por la info.

[nuevo1234]

Alguna novedad con la publicación del reglamento?

[adolphsys]

Alguna novedad con la publicación del reglamento?

Por ahora nada, están apurando el plazo, aún les queda poco más de un mes desde la publicación de la ley... :D

[ermendalenda]

https://cincodias.elpais.com/cincodias/2023/02/28/pyme/1677619473_948933.html?id_externo_rsoc

Lo mismo que pensamos todos.
Esto tiene que ser por Face, lo que pasa es que poner fondos para terminar de desarrollar lo que ya se empezó con el EUROFACE, pero claro, hay que dedicar fondos, es más fácil que los empresarios se rasquen el bolsillo y arriesguen a que sus datos pasen por terceros

[newtron]

El tema es que todo se está convirtiendo en un despropósito con tanta ley aprobada sin saber cómo la van a desarrollar y tantas ocurrencias de un día para otro.

[keys]

Hola a todos.

Un enlace de una charla sobre lo que nos viene https://www.youtube.com/watch?v=IMIY_KN0n-8

[adolphsys]

El día 7 se abrió la consulta pública de la Ley Crea y Crece, os dejo enlace https://portal.mineco.gob.es/es-es/ministerio/participacionpublica/consultapublica/Paginas/Consulta_publica_creacion_crecimiento_empresas_factura_electronica_entre_empresas_y_profesional.aspx

[keys]

Me mondo :D:D:D:D

3. ¿Debe existir una infraestructura pública de intercambio de facturas electrónicas alternativa
o complementaria al uso obligatorio de plataformas de facturación electrónica para su
remisión a los clientes? ¿Por qué? ¿Para qué tipo de empresas o profesionales es necesaria
esta alternativa? ¿Qué alternativa sería?

[antoine0]

Un enlace de una charla sobre lo que nos viene https://www.youtube.com/watch?v=IMIY_KN0n-8

Muchas gracias Keys, esta charla es efectivamente muy interesante.

Pero me surge una duda. Está claro que no tienen ninguna idea precisa de cómo será el sistema final. Está previsto publicar un nuevo reglamento dentro de cuatro meses, con probablemente muchas incertidumbres y cosas pocas claras, al cual yo le nombraría «borrador», o «borrador final» si se prefiere (FDIS en lenguaje ISO). Sin embargo, será la base (con sus numerosos versiones y mejoras) para aplicación en real en ¿agosto del 2024? :confused:

[iMia]

Esto me ha enviado un proveedor de servicios de los grandes...

Si ya estas dando pasos con respecto a la factura electrónica obligatoria que se aprobó en la Ley "Crea y Crece", levanta el pie del acelerador.

El pasado día 7 de marzo se abrió consulta publica para que la participación ciudadana en el desarrollo reglamentario de como tiene que ser la factura electrónica que viene.

Paralelamente a esto, la AEAT presenta su propia propuesta en el foro de usuarios de SAP (AUSAPE), que reúne a un buen numero de las empresas usuarias de SAP en España.

Esto pone de manifiesto y sobre la mesa, dos lineas de actuación para el desarrollo reglamentario de la factura electrónica, que son diametralmente opuestas.

Por un lado, el Ministerio de Asuntos Económicos y Transformación Digital, base su propuesta en el uso de plataformas de facturación electrónica, mientras que el Ministerio de Hacienda y Función Pública, basa su propuesta en una plataforma de desarrollo propio donde habrá que enviar todas las facturas, y desde donde se pondrán a disposición de sus destinatarios.

Con este panorama, se podría augurar que hasta inicios del verano (probablemente junio), no va ha haber una publicación el el BOE con el desarrollo reglamentario definitivo.

[CyberManolo]

Buenas tardes:

Tenía programado un sistema de generación de facturas electrónicas que funciona correctamente, pero ahora estoy intentando que una vez generado el xml pueda firmarse con auto firma. Para ello uso ShellExecute de ShellAPI. De esta forma:

ShellExecute(0, 'open',PChar('C:\Program Files\Autofirma\AutoFirma\autofirma.exe') , nil , nil, SW_SHOW);

Se me abre correctamente el programa, pero el usuario tiene que buscar el fichero a firmar. Lo que quiero es pasarle como parámetro el fichero a firmar, pero no lo consigo. En teoría debiera ser así, según el manual técnico de Autofirma:

ShellExecute(0, 'open', PChar('C:\Program Files\Autofirma\AutoFirma\autofirma.exe') , Pchar(' -i c:\facturas\factura1.xml') , nil, SW_SHOW);

Pero si le paso la ruta del fichero a firmar como parámetro, el programa Autofierma no se arranca.

¿Alguien me puede arrojar luz sobre el asunto? Muchas gracias.

[duilioisola]

Prueba con
...AutoFirma\AutoFirma.exe" sign -gui ...

De todos modos, en la instalación de Autofirma, existe el fichero
AutoFirmaCommandLine.exe
Ese es el que utilizo yo desde un bat que genero con todos los parámetros que necesito:

"sign.bat" =

'"' + cPath + 'AutoFirma\AutoFirmaCommandLine.exe" sign ' +
// opcionalmente ' -gui ' +
'-i "' + DameTempPath + 'ToSign.xml' + '" ' +
'-o "' + DameTempPath + 'ToSign.xsig' + '" ' +
'-store windows -filter "subject.contains:' + PChar(cCert) + '" ' +
'-format facturae > "' + DameTempPath + 'sign_result.txt"';

[manelb]

Buenos días...

Este es el bat que nosotros utilizamos.
Ahora no tengo a mano cada uno de los parámetros, pero con la documentación supongo que no tendrás problema en descifrarlo.

De todas formas, si tienes algún problema, más tarde puedo detallar cada uno de ellos.


"c:\AutoFirma\AutoFirma\AutoFirmaCommandLine.exe" sign -i %1 -o %2 -store windows -alias %3 -format facturae -config signatureProductionCity=%4\nsignatureProductionProvince=%5\nsignatureProductionPostalCode=%6\nsignat ureProductionCountry=%7


Saludos

[CyberManolo]

Gracias a ambos.

Imagino que el bat lo lanzais con ShellExecute pasando desde ahí los parámetros que necesita dicho bat? (fichero a firmar, fichero firmado, certificado....)

[duilioisola]

Yo creo el fichero ToSign.xml, que es la factura a firmar.
Luego creo el bat como te muestro en el mensaje anterior con todo rellenado.
Este bat ejecuta AutorimaCommandLine.exe redirigido a un fichero llamado sign_result.txt.

"C:\...\AutoFirma\AutoFirmaCommandLine.exe" -i "C:\...\ToSign.xml" -o "C:\...\ToSign.xsig" -store windows -filter "subject.contains: EMPRESA SL" -format facturae > "C:\...\sign_result.txt"


Ejecuto el bat con un procedimiento que espera a que termine para evitar leer antes de tiempo:

function RunAndWait(Handle: THandle; Ejecutable, Argumentos: string; const RunDirectory: PChar = nil; const Visibilidad: integer = SW_SHOWNORMAL; MensajeSiCorrecto: boolean = True): DWORD;
var
Info : TShellExecuteInfo;
pInfo : PShellExecuteInfo;
ExitCode : word;
P : PChar;
begin
{ Puntero a Info }
{ Pointer to Info }
pInfo := @Info;
{ Rellenamos Info }
{ Fill info }
with Info do
begin
cbSize := SizeOf(Info);
fMask := SEE_MASK_NOCLOSEPROCESS;
wnd := Handle;
lpVerb := nil;
lpFile := PChar(Ejecutable);
{ Parametros al ejecutable }
{ Executable parameters }
lpParameters := PChar(Argumentos + #0);
if RunDirectory = '' then
lpDirectory := nil
else
lpDirectory := PChar(RunDirectory + #0);
nShow := Visibilidad;
hInstApp := 0;
end;
{ Ejecutamos }
{ Execute }
if not ShellExecuteEx(pInfo) then
begin
Result := GetLastError;
if FormatMessage(Format_Message_Allocate_Buffer + Format_Message_From_System,
nil,
Result,
0, @P,
0,
nil) <> 0 then
begin
// Display the string.
ShowMessage(P);
// Free the buffer.
LocalFree(integer(P));
end;
end
else
Result := 0; // Info.hInstApp;

{ Esperamos que termine }
{ Wait to finish }
repeat
ExitCode := WaitForSingleObject(Info.hProcess, 500);
Application.ProcessMessages;
until (ExitCode <> WAIT_TIMEOUT);
ExitCode := GetLastError;

GetExitCodeProcess(Info.hProcess, Result);
if ((Result < 32) and (ExitCode = 0)) then
begin
ExitCode := GetLastError;
if FormatMessage(Format_Message_Allocate_Buffer + Format_Message_From_System,
nil,
ExitCode,
0, @P,
0,
nil) <> 0 then
begin
// Display the string.
if MensajeSiCorrecto or (ExitCode <> 0) then
ShowMessage(P);
// Free the buffer.
LocalFree(integer(P));
end;
end
else
Result := 0; // Info.hInstApp;
end;


Finalmente miro si el fichero sign_result.txt tiene el texto "La operacion ha terminado corectamente"

if ((SysUtils.FileExists(DameTempPath + 'sign_result.txt')) and (Pos('ha terminado correctamente', MemoRead(DameTempPath + 'sign_result.txt')) > 0)) then


Si es así guardo el fichero ToSign.xsig con un nombre acorde (Pro ejemplo: Factura_A-123.xsig) en la carpera de ficheros firmados para seguir con el resto de procesos.

[CyberManolo]

Muchas gracias Duilio. Ahora lo he entendido: construyes el bat desde Delphi y luego lo lanzas.
Yo intentaba ejecutar la aplicación con ShellExecute, que tiene un parámetro para pasar, a su vez, los valores de los parámetros de la aplicación que se está llamando.
Un saludo desde Córdoba.

[ermendalenda]

https://www.youtube.com/watch?v=t-FahVwUHAU

[ermendalenda]

En 1 Semana otro Borrador :D

[ermendalenda]

Apuestas:

1. Verifactu + Face + FaceB2b

2. Verifactu + Otro formato Público(por RedSara)

3. Sistema centralizado por Redsara con solo un formato a la que habrá enlaces para que hacienda pueda recoger la información, los destinatarios de facturas puedan operar, rechazar y cambiar de estado las facturas... o sea como en Italia han hecho

4. Primero la opción 1(para arrancar rápido con lo desarrollado) y más adelante la opción 3.

[keys]

Apuestas:

1. Verifactu + Face + FaceB2b

2. Verifactu + Otro formato Público(por RedSara)

3. Sistema centralizado por Redsara con solo un formato a la que habrá enlaces para que hacienda pueda recoger la información, los destinatarios de facturas puedan operar, rechazar y cambiar de estado las facturas... o sea como en Italia han hecho

4. Primero la opción 1(para arrancar rápido con lo desarrollado) y más adelante la opción 3.

Opción 5- Elecciones + ¿Cambio de gobierno? + Se retrasa más todo + Por mis Huevos lo hacemos de otra forma. + todo lo que hemos hecho no vale para nada :eek:

[ermendalenda]

Opción 5- Elecciones + ¿Cambio de gobierno? + Se retrasa más todo + Por mis Huevos lo hacemos de otra forma. + todo lo que hemos hecho no vale para nada :eek:

Claro. La opción 5 siempre está ahí, con su rima:D

[CarlosMz]

Hola a todos,

alguien sabe qué base de datos es la que usa facturaE (la app del gobierno).
en la ayuda pone que se exporta a fichero con extensión fedb.

muchas graicas

[ermendalenda]

Hola a todos,

alguien sabe qué base de datos es la que usa facturaE (la app del gobierno).
en la ayuda pone que se exporta a fichero con extensión fedb.

muchas graicas
Hasta donde yo sé
Fedb es la extensión a la que se puede exportarpara importar desde otro software de facturacion

El software usa hsql con java, pero no se si solo lo usa como temporales para generar los xmls firmados y para generar los fedb. Encontrarás los xsig en la carpeta donde se instsala

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

alguien sabe qué base de datos es la que usa facturaE (la app del gobierno).
en la ayuda pone que se exporta a fichero con extensión fedb.



Se pueden Importar/Exportar de forma individual (cada factura un fichero) o como Base de Datos (.fedb).

Como ficheros individuales son XML con cada factura.
Si lo exportas como fichero .efdb, en realidad en un ZIP que lo puedes descomprimir en un directorio. dentro contiene 2 ficheros:
a) El primero con las propiedades de la Base de Datos:

#HSQL Database Engine 1.8.0.10
#Tue Jun 13 12:24:44 CEST 2023
hsqldb.script_format=0
runtime.gc_interval=0
hsqldb.incremental_backup=false
sql.enforce_strict_size=false
hsqldb.cache_size_scale=8
readonly=false
hsqldb.nio_data_file=true
hsqldb.cache_scale=14
version=1.8.1
hsqldb.default_table_type=memory
hsqldb.cache_file_scale=1
hsqldb.lock_file=true
hsqldb.log_size=200
modified=yes
hsqldb.cache_version=1.7.0
hsqldb.original_version=1.8.1
hsqldb.compatible_version=1.8.0


b) El segundo con toda la Base de Datos en DDL:


CREATE SCHEMA...
CREATE MEMORY TABLE ADDRESS(ADDRESS_ID I...
CREATE MEMORY TABLE OPERATION(COD...
ALTER TABLE ACCOUNT ADD CONSTRAINT FKE49F160DEEAF17F3 FOREIGN KEY(...
ALTER TABLE ADMCENTRE ADD CONSTRAINT FK9CB5AEE5BD01391 FOREIGN KEY(...
ALTER TABLE FACTURAE_INVOICES ADD CONSTRAINT FK9DF1...
INSERT INTO ADDRESS VALUES(1,'Spain-3.1','c/ Almendros',...
INSERT INTO BATCH VALUES(1,'3.2','C915374071Emit-',1,'121.0','121.0','121.0',44)

INSERT INTO FACTURAE VALUES(1,'3.2.1',0,0,1,1,'3c3f786d6c2076657273696f6e3d22312e302220656e636f6469...
....

[CarlosMz]

Excelente, muchísimas gracias

[newtron]

Pues nada chic@s.... ¡a estudiar! :D:D


https://portal.mineco.gob.es/RecursosArticulo/mineco/ministerio/participacion_publica/audiencia/ficheros/ECO_Pol_AP_20230619_RD_factura_electronica.pdf

[PepCat]

Muchas gracias!

[nuevo1234]

Pues nada chic@s.... ¡a estudiar! :D:D


https://portal.mineco.gob.es/RecursosArticulo/mineco/ministerio/participacion_publica/audiencia/ficheros/ECO_Pol_AP_20230619_RD_factura_electronica.pdf

De momento es un borrador. No corren plazos hasta q salda en breve lo definitivo. No?

[newtron]

De momento es un borrador. No corren plazos hasta q salda en breve lo definitivo. No?


Pues yo en particular no lo tengo muy claro porque los plazos ya estaban establecidos antes de esto, no sé si se mantendrán o pondrán unos plazos nuevos. Imagino que cuando aprueben la ley aclararán el tema de los plazos.


Saludos.

[PepCat]

Según el borrador en la pagina 19:


Disposición final tercera. Entrada en vigor

1. El Real Decreto entrará en vigor a los 12 meses de su publicación en el Boletín Oficial

[ermendalenda]

Apuestas:

1. Verifactu + Face + FaceB2b

2. Verifactu + Otro formato Público(por RedSara)

3. Sistema centralizado por Redsara con solo un formato a la que habrá enlaces para que hacienda pueda recoger la información, los destinatarios de facturas puedan operar, rechazar y cambiar de estado las facturas... o sea como en Italia han hecho

4. Primero la opción 1(para arrancar rápido con lo desarrollado) y más adelante la opción 3.

Parece que no estab descaminado
Face y verifactu. Alá a currar nos toca.

[newtron]

Parece que no estab descaminado
Face y verifactu. Alá a currar nos toca.


Id... id haciendo que ahora voy. :D:D

[ermendalenda]

Id... id haciendo que ahora voy. :D:D

Jajaj
A tu ritmo

[ermendalenda]

Supongo que cada cliente debe facilitar sus datos de identicador único independientemente de la plataforma, ya que si yo genero una factura electrónica, normalmente, no hay que indicar de qué plataforma es.
O sea el identicador/es que nos facilite debe ser el de hacienda. Algo así como.o el Dir de face.
Por que sobre wl mismo cif puede haber distintas administraciones de facturación...
Enfin, esa parte habrá que dejarla para la publicación del desarrollo, pero el resto voy a avanzar.

[keys]

Parece que no estab descaminado
Face y verifactu. Alá a currar nos toca.

¿Pero ya han publicado algo definitivo? :eek:

[ermendalenda]

Pues no es definitivo. Pero.el periodo de audiencia para las sugerencias de este borrador finaliza el 10 de Julio.
Esas posibles sugerencias pueden ser tenidas en cuenta o no... tic tac...

[trumbolt]

Pues nada chic@s.... ¡a estudiar! :D:D


https://portal.mineco.gob.es/RecursosArticulo/mineco/ministerio/participacion_publica/audiencia/ficheros/ECO_Pol_AP_20230619_RD_factura_electronica.pdf

Acabo de salir de un seminario que pensaba era de VERI*FACTU y me he encontrado con todo el pastel de la comunicación de las facturas B2B entre empresas que se establece en la Ley Crea y Crece que tenía un poco apartada porque pensaba que era más o menos lo mismo ... pero obviamente no :eek:

He leído el RD y confieso que estoy un poco perdido cuando se refieren a lo largo de todo el documento a una "solución pública de facturación electrónica" y a plataformas privadas que deberán de estar interconectadas. Bien, ¿se refieren con esa plataforma pública a faceb2b?, porque, que yo sepa, ésta está orientada a la obligación actual de enviar las facturas a la administración y no entre empresas, o ¿es alguna nueva plataforma que se tienen que sacar de la chistera?.

Y otra. En el seminario hablaban de la obligatoriedad de contratar con una plataforma privada (PIFE) para el envío de facturas y que no era posible el envío directo a esa plataforma pública, pero leyendo las disposiciones del RD, no veo que se restrinja nada. ¿Alguien sabe algo más?. ¿Hay que ser una plataforma privada (que cumple todos los requisitos de ISOs y demás según se detalla en el RD) para poder conectarse o también se pueden conectar PYMEs y profesionales?.

Parece que a principios de mes finalizó el plazo de alegaciones y están en estudio así que poco a poco ésto va a llegar a nuestras vidas (para complicarlas un pelín más) de manera inexorable :(

[ermendalenda]

Acabo de salir de un seminario que pensaba era de VERI*FACTU y me he encontrado con todo el pastel de la comunicación de las facturas B2B entre empresas que se establece en la Ley Crea y Crece que tenía un poco apartada porque pensaba que era más o menos lo mismo ... pero obviamente no :eek:

He leído el RD y confieso que estoy un poco perdido cuando se refieren a lo largo de todo el documento a una "solución pública de facturación electrónica" y a plataformas privadas que deberán de estar interconectadas. Bien, ¿se refieren con esa plataforma pública a faceb2b?, porque, que yo sepa, ésta está orientada a la obligación actual de enviar las facturas a la administración y no entre empresas, o ¿es alguna nueva plataforma que se tienen que sacar de la chistera?.

Y otra. En el seminario hablaban de la obligatoriedad de contratar con una plataforma privada (PIFE) para el envío de facturas y que no era posible el envío directo a esa plataforma pública, pero leyendo las disposiciones del RD, no veo que se restrinja nada. ¿Alguien sabe algo más?. ¿Hay que ser una plataforma privada (que cumple todos los requisitos de ISOs y demás según se detalla en el RD) para poder conectarse o también se pueden conectar PYMEs y profesionales?.

Parece que a principios de mes finalizó el plazo de alegaciones y están en estudio así que poco a poco ésto va a llegar a nuestras vidas (para complicarlas un pelín más) de manera inexorable :(

Hola, aún no hay nada definitivo.
En principio no va a haber obligación de usar plataformas privadas, eso fue la primera propuesta del reglamento, pero en la segunda ya han propuesto de crear (o aprovechar) una plataforma pública gratuita a la que todos los que emitan facturas deben estar conectados (directa o indirectamente, ya que aunque usen privada, las privadas tb tienen que enviarlas ahí) y enviar en formato Facturae, los proveedores privados deben estar interconectados y sí, tienen que estar conectados, aunque podrán usar dicha plataforma pública como punto de entrada común para esa interconexión, ya ellos deciden.

[trumbolt]

Hola, aún no hay nada definitivo.
En principio no va a haber obligación de usar plataformas privadas, eso fue la primera propuesta del reglamento, pero en la segunda ya han propuesto de crear (o aprovechar) una plataforma pública gratuita a la que todos los que emitan facturas deben estar conectados (directa o indirectamente, ya que aunque usen privada, las privadas tb tienen que enviarlas ahí) y enviar en formato Facturae, los proveedores privados deben estar interconectados y sí, tienen que estar conectados, aunque podrán usar dicha plataforma pública como punto de entrada común para esa interconexión, ya ellos deciden.

Gracias por la aclaración. Me parecía raro que obligaran a todos a pasar por caja teniendo que pagar a un intermediario privado. De todas formas, si tienen que desarrollar esa plataforma pública, ya me puedo echar a temblar vistas las anteriores experiencias como TicketBAI ...

[fmira]

Buenas tardes,

Estoy usando Delphi 10.4
He logrado generar y firmar una factura en formato FacturaE. La he validado con las utiliddes online y tanto el foramto como la firma son correctas.
Es más, puedo subirla manualmente al face y todo correcto.

Ahora estoy intentando usar el webservice de facturaE para enviar las facturas y aqui es donde me he atascado.
He logrado crear la peticion SOAP y enviarla pero resulta que además de la factura firmada también hay que firmar la petición.
Lo he intentado con librerias de Chilkat y tambien probando con SecureBlackBox, pero no logro avanzar.

Después de leer mucho en los foros , tampoco saco nada en claro.

Alguien me puede echar una mano?

Gracias

[adolphsys]

Hola fmira, para poder enviar facturas a FACE hay que estar dado de alta como proveedor.

Échale un vistazo a este hilo http://www.clubdelphi.com/foros/showthread.php?p=548659&nojs=1

[adolphsys]

Hola a todos.

Os dejo enlace para descargar presentación y vídeo del otro día del webinar de EDICOM sobre la implantación de la factura electrónica en España https://edicom.app.teenvio.com/v4/public/estadisticas/lee/edicom/94354/475913/e3a84f2a6fcfad1df0003bf5ff1958a1/

Por lo que vimos:


El RD podría estar publicado en tres meses (mi opinión es que se alargará más, entre otras cosas porque los web service de la plataforma pública aún no se han empezado a desarrollar).
La facturación B2C y B2G no sufre cambios (esto significa que tendremos que mantener FACe tal cual está, e implantar los procesos B2B).
Se ampliarán campos en el SII para aportar fecha de expedición (operación) y plazos de pago de facturas.
El cliente es el que debe remitir los estados de las facturas (cuando cobre, es el que tendrá que decir que ha cobrado).
Conviviremos con una plataforma pública de facturación electrónica, y con las plataformas privadas actuales (las funciones de unas y otras no serán las mismas, ver presentación).
Ya no se tiene claro qué sintaxis utilizar: inicialmente se pensó en FacturaE, pero parece que UBL es el formato que finalmente va a emplearse.


Aún están trabajando en las preguntas que lanzamos los más de 5700 asistentes al webinar, así que cuando publiquen las respuestas iremos avanzando.

[newtron]

^\||/ Gracias compañero.

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

Gracias por la info.
^\||/^\||/^\||/

[ermendalenda]

Hola a todos.
....
El cliente es el que debe remitir los estados de las facturas (cuando cobre, es el que tendrá que decir que ha cobrado).
....
Hola, muchas gracias por el aporte.
Parece contradictorio, para mi el cliente es el que paga, no el que cobra.. serias tan amable de aclara si es el que paga o el que cobra el que cambia el estado.
Gracias y saludos

[novatico]

Bueno días,

Ayer hubo un Seminario Informativo por parte de la AEAT, sobre novedades en diferentes parcelas.
También hablaron de la Factura Electrónica:
- No confirmaron fechas de publicación, más allá de decir que entraría en vigor 1 año después de la publicación del reglamento para las empresa de + 8 millones de facturación y 2 años para el resto.
- Se dieron 9 meses, a partir de la publicación, para que esté disponible la Plataforma Pública y el entorno de pruebas.
- Más allá del hecho de que las plataformas privadas admitan otros formatos, confirmaron que la Plataforma Pública, tras conversaciones de sus grupos de trabajo, usará el formato FACTURAe, y servirá como almacén central de todas las facturas enviadas.
- Las plataformas Privadas estarán obligadas a enviar a la Pública todas las facturas que reciban, pero no quedó claro quien deberá transformar a formato FACTURAe.

Creo que eso fue lo más importante de lo que se habló.

[adolphsys]

Bueno días,

Ayer hubo un Seminario Informativo por parte de la AEAT, sobre novedades en diferentes parcelas.
También hablaron de la Factura Electrónica:
- No confirmaron fechas de publicación, más allá de decir que entraría en vigor 1 año después de la publicación del reglamento para las empresa de + 8 millones de facturación y 2 años para el resto.
- Se dieron 9 meses, a partir de la publicación, para que esté disponible la Plataforma Pública y el entorno de pruebas.
- Más allá del hecho de que las plataformas privadas admitan otros formatos, confirmaron que la Plataforma Pública, tras conversaciones de sus grupos de trabajo, usará el formato FACTURAe, y servirá como almacén central de todas las facturas enviadas.
- Las plataformas Privadas estarán obligadas a enviar a la Pública todas las facturas que reciban, pero no quedó claro quien deberá transformar a formato FACTURAe.

Creo que eso fue lo más importante de lo que se habló.

Hola, te refieres a este seminario https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/2023/Seminario-EEDD-SIF-FE-1123.pdf ?

[novatico]

Hola, te refieres a este seminario https://www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/2023/Seminario-EEDD-SIF-FE-1123.pdf ?

Sí, efectivamente. En él se hablo tanto de la Ley Antifraude como de la Factura Electrónica, que es lo que en este foro nos atañe.

[ermendalenda]

Pués eso, "Chorus" va a ser la plataforma gratuita con el servicio mínimo para cumplir la B2B

https://sede.agenciatributaria.gob.es/Sede/colaborar-agencia-tributaria/relacion-cooperativa/foro-federaciones-asociaciones-trabajadores-autonomos/sesiones-pleno-foro-trabajadores-autonomos/2022/segunda-sesion-24-octubre-2022/acta-sesion.html

[keys]

Mirándolo por encima pone esto.

A través de un formato estándar EDI para el intercambio directo de información entre dos organizaciones de forma electrónica (punto a punto): la factura (o cualquier otro documento) se transmite desde el equipo del emisor, previamente transformada a formato EDI, al del receptor, donde se decodifica y se recibe.

En teoría en la última presentación de hacienda se dijo que sería sólo FacturaE. Igual algún día se aclaran.

[ermendalenda]

Mirándolo por encima pone esto.



En teoría en la última presentación de hacienda se dijo que sería sólo FacturaE. Igual algún día se aclaran.


Buebo si facturae es el formato del xml pero la plataforma gratuita puede llamarse chorus o choris!ñ o como quieran. Pero no dijeron la única, dijeron que podia ser privada. Lo que creo que si decían que todas tenían que comunicarse finalmente a la plataforma gratuita de la aeat.
Enfin parece que aún no está claro tal y como dices.

[antoine0]

Mirándolo por encima pone esto.
A través de un formato estándar EDI para el intercambio directo de información entre dos organizaciones de forma electrónica (punto a punto): la factura (o cualquier otro documento) se transmite desde el equipo del emisor, previamente transformada a formato EDI, al del receptor, donde se decodifica y se recibe.

Hay dos significados para EDI:
En general EDI significa intercambio electrónico de documentos. Técnicamente Factura-E es uno de los múltiples formatos posibles para facturas enviadas por EDI; entonces en tal caso la frase arriba no prohíbe el uso de Factura-e para facturas electrónicas: al contrario, la frase autoriza cualquier formato, si es estándar.
Ahora bien, muy a menudo EDI se entiende como EDIFACT, el formato heredado de los Americanos de las 70s y normalizado por Naciones Unidas en 1985:cool:, con sus UNB/UNS/UNT y sus ' al final de las «líneas» (e incluyendo a menudo también su translación a XML). Este formato es efectivamente muy habitual en las relaciones entre organizaciones.
Si EDI es meramente un sinónimo de facturas electrónicas, todo este frase es meramente una descripción de lo que es el EDI :o.
Alternativamente, puede ser que intentan asegurar a las empresas que utilizan formato(s) EDIFACT para publicar sus facturas, que nada tienen que cambiar: continuarán enviando sus facturas en el formato existente (si es conforme a la norma EN16931).
Y no hablan de prohibir cualquier otro formato que no siga EDI(FACT).

En teoría en la última presentación de hacienda se dijo que sería sólo FacturaE. Igual algún día se aclaran.
No creo que tampoco han dicho nunca que sería sólo Factura-E. Entre otras razones, por qué hay una normativa de la U.E. (directiva 2014/55 (https://www.boe.es/buscar/doc.php?id=DOUE-L-2014-80922)) que obliga los estados a aceptar dos formatos, CII y UBL (decisión de ejecución 2017/1870/UE (https://www.boe.es/buscar/doc.php?id=DOUE-L-2017-82054)), en todos los países, en paralelo con posibles estándares nacionales (como es el caso de Factura-E en España) y normas de facto (como parece ser es el caso para EDIFACT en España).
El artículo 6 del proyecto de RDL recoge explícitamente estas cuatro opciones, sin hacer ninguna distinción entre ellas.

[keys]

Esto es lo que dijeron en la reunión.

La Agencia Estatal de Administración Tributaria será el organismo encargado del desarrollo de la Solución
Pública de Facturación Electrónica (SPFE). dentro del Sistema español de factura electrónica. Dicha plataforma
pública se constituye la opción por defecto si no hay acuerdo entre emisores y destinatarios de facturas. La
sintaxis de facturas elegidas es FacturaE. Será depositaria de todas las facturas B2B a nivel del Estado.
Funciones de la plataforma pública: interconexión de plataformas, depósito de facturas originales y copias,
comunicación de pagos, descarga de facturas, etc. Se definirán los detalles de la misma en orden ministerial.

[newtron]

Y a mi se me ocurre una pregunta tonta a raiz de la movida esta de las facturas electrónicas.


¿Cuando esto esté en marcha para todo el mundo tendrá sentido las plataformas tipo EDI?


Saludos.

[antoine0]

Y a mi se me ocurre una pregunta tonta a raiz de la movida esta de las facturas electrónicas.

¿Cuando esto esté en marcha para todo el mundo tendrá sentido las plataformas tipo EDI?
Creo que sí. Para empresas de tamaño medio-grande que tienen informáticos en casa que han desarrollado un sistema súper-integrado para emitir y recibir los archivos EDIFACT (de los cuáles facturas INVOIC es solo una parte). No tienen que cambiar nada, ya lo tienen todo cocinado.
Incluso para un importe relativamente modesto podrían recuperar en formato electrónico las facturas de sus proveedores, luego desarrollar una herramienta que hace el cotejo de estas facturas contra las pendientes de recibir que tienen en cartera; y soñar, si este desarrollo sale bien, a poder «rentabilizarlo» sobre el departamento de Compras de la empresa... :(

De hecho, es la música que algunas plataformas EDIFACT están vendiendo ahora mismo. (O intentan vender; no sé si sale a cuenta, ya que tengo mis dudas sobre el rendimiento del cotejo; pero sus departamentos de marketing no paran).

Las que veo peor son las empresas, a menudo fabricantes de impresoras, que han vendido sistemas de G.E.D. con, básicamente, el mismo objetivo final («desengrasar» los departamentos de Compras), en las últimas 10-15 años. Dentro de poco la misma función será bastante más sencilla, solo se deberán recuperar las facturas en formato estructurado desde la plataforma SPFE. Si tienen una función de cotejo que funcione bien, entonces estupendo para ellas, van a poder rentabilizarla. Si no...

[ermendalenda]

Buenas amigos, en el seminario del día 14/2/24 han confirmado que el punto de entrada público(gratuito) será en formato Facturae, donde todos tendremos que enviar, ya sea a través del punto de entrada que contratemos a través de otra empresa o directamente, los servicios se suponen que serán parecidos a los actuales de face y faceb2b, consulta de administrcionws de un cif etc.
Ya os digo que esto tiene mucho curro, yo ya he empezado y para intentar evitar errores sobre los datos administrativos de las empresas a las que envías hay que currarse las consultas, os recomiendo también descargaos los códigos postales de todo el territorio español para que al poner el cp os aparezca la localidad y provincia
Dejad rn las bases dr dato un campo de más de 10caractwres pata el dir de la administración ya q8w me da la sensación de que alguna vez lo tendrían que ampliar.
Tened muy en cuenta si es persona física o jurídica para generar el xml 1ue cambia mucho.
Para saber si es persona física o jurídica para los nifs y nie españoles se puede saber por la configuración del código identificativo.
Hay que currar muchísimo para dárselo fácil al usuario.

[newtron]

^\||/ Gracias compañero. Al final se las apañarán para que nos caigan a la vez los dos truños Verifactu y Factura Electrónica. :mad::mad:

[ermendalenda]

Post erroneo

[ermendalenda]

No sé si alguien con más experiencia en factura electrónica sabe la equivalencia entre la factura sustitutiva o de canje con la factura electrónica.
Se me ocurren 2 formas:
Factura completa, insertando los documentos pdf de los tiquets
Factura recapitulativa e indicando fecha y número de tiquet de cada operación

Pero ninguna de las 2 formas encaja 100%

[afxe]

No sé si alguien con más experiencia en factura electrónica sabe la equivalencia entre la factura sustitutiva o de canje con la factura electrónica.
Se me ocurren 2 formas:
Factura completa, insertando los documentos pdf de los tiquets
Factura recapitulativa e indicando fecha y número de tiquet de cada operación

Pero ninguna de las 2 formas encaja 100%

A mi entender, las facturas electrónicas hay que subirlas cuando se emiten a una persona física o jurídica. Las facturas simplificadas sin identificación del sujeto, no tiene sentido ser enviadas a la plataforma, ya que es una plataforma para el intercambio de facturas entre empresas y autónomos. Otra cosa es el verifactu... ahí sí hay que enviarlas una a una, nada de recapitular, ya que cualquier cliente, con su ticket, tiene que tener la posibilidad de consultar si ese ticket está subido correctamente a la AEAT.

Otra cosa. He leido esto en un artículo:


Punto de entrada de las facturas
A la hora recibir facturas, los autónomos deberán comunicar a sus proveedores cuál es el punto de entrada de las mismas. Es decir, el software privado de facturación electrónica con el que trabajen. Esta información tendrá que ser pública en todas las comunicaciones con los proveedores y en la página web del negocio (en caso de disponer de ella). De no hacerlo así, se entenderá que el punto de entrada es la solución pública de facturación electrónica.


No lo entiendo bien... Se supone que el punto de entrada habrá que poner el DIRe de la empresa/autonomo receptor de la factura, para que éstos puedan recibir dichas facturas. ¿Qué pinta el software privado que usen?

[ermendalenda]

A mi entender, las facturas electrónicas hay que subirlas cuando se emiten a una persona física o jurídica. Las facturas simplificadas sin identificación del sujeto, no tiene sentido ser enviadas a la plataforma, ya que es una plataforma para el intercambio de facturas entre empresas y autónomos. Otra cosa es el verifactu... ahí sí hay que enviarlas una a una, nada de recapitular, ya que cualquier cliente, con su ticket, tiene que tener la posibilidad de consultar si ese ticket está subido correctamente a la AEAT.

Otra cosa. He leido esto en un artículo:



No lo entiendo bien... Se supone que el punto de entrada habrá que poner el DIRe de la empresa/autonomo receptor de la factura, para que éstos puedan recibir dichas facturas. ¿Qué pinta el software privado que usen?

Buebo estoy programando ya para factura electrónica, y sí, si admiten varias opciones facturas sinplificadas, ordinarias y eecapitulativas. Ahora bien, la simplificada puede bo tener mucho sentido o sí, ya que aunque sea simplificada se la puedes enviar a alguien con cif, por ende ya está nominada. Lo mismo va por ahí el asunto de la sustitutiva para las electrónicas.
Por otro lado, ese artículo de que fuente es ?
Eso podría hacerse sí facturae ampliase la estructura añadiendo otros nodos (proveedor o punto de entrada) y un campo dir3 más amplio, que actualmente sólo es de 10 caracteres.
No me extrañaría, pero por lógica la historia sería más normal justo al revés, o sea. El que tenga otro proveedor ya tendrá que currarse el proveedor de leer las facturas del punto de entrada público o incluso que estén todos los proveedores a crear ese punto de entrada público para enlazar. Así el comprador puede dar el dir3 de facturae o el del proveedor según el comercio, pienso yo que para no liar darán siempre los 2.
Por otro lado facturar admite el nodo "extensiones" lo cual sería una gran putada para nitroso que intentase que metieras ahí a todos los proveedores, ya que al final estaríamos en las mismas, para que quiero un punto de entrada público si no hay capacidad de tener en cuenta todas las extensiones....pero se me ocurre tb que hagan alguna extension común para enviar a cualquier proveedor, por ahí pueden ir los tiros, aunque también pueden querer aprovechar el nodo de información adicional de la factura para no tener que cambiar ni añadir estructuras
Hay muchas posiblidades

[keys]

Si no recuerdo mal en la charla de la aeat dijeron que todas las facturas tienen que ir al punto de entrada público, tengan o no contratado uno privado.

[ermendalenda]

Si no recuerdo mal en la charla de la aeat dijeron que todas las facturas tienen que ir al punto de entrada público, tengan o no contratado uno privado.
Si quieren controlar la morosidad (que creo que no va a ser lo unico que controlen) debe ser asi. No van a estar conectándose ellos a todos.
Creo que este control va a ir más allá y no sé hasta donde llegará ese control de morosidad y que recogerá el reglamento, me temo que vamos a tener que estudiar nos también los temas relaci9nados con límites en las fechas de pago...
Al final me voy a hacer asesor fiscal en vez de programador.
Vaya tela.

[ermendalenda]

Hola, sigo analizando facturae.
En cuanto a las equivalencias de tipos de factura:
-Para la sustitutiva ya que no hay una equivalencia explicita y como facturae está concebida para cobrar y pagar ( no es reporte a la AEAT), entonces Factura Sustitutiva(Verifactu)=Factura Completa(Facturae)
-Y ahora al revés, Factura Recapitulativa Facturae(albaranes, notas de entregas convertidas a factura)=Factura Completa Verifactu


En cuanto nodos que no contemplamos normalmente y que hay que tener en cuenta:
-Ibank=Cuenta donde solicitamos la transferencia (Si solitamos pago por transferencia)
-INETownCode=Código población segn el INE(Ojo no es el código Postal, podeis descargaros del INE la tabla, lo que es complicado es establecer la relación de las direcciones con los codigos de poblacion y los codigos postales, ni siquiere la Seguridad Social lo tiene bien, pero podeis dejarlo sin relacion y que lo escriban, aunque seguro el usuario se va a equivocar muchisimo si no vinculais y dais una ayuda)
InstallmentDueDate e InstallentAmountDate=Fecha e importe del efecto, pertenecen al nodo Installments(se repite tantos efectos tengas). Una factura puede emitirse para que pague en otra/s fecha/s, por transferencia o por otro metodo, aqui debes poner la/s fecha/s e importes
-AdministrativesCentres= Son datos opcionales que tendrá que darnos el cliente si quiere que le emitamos las facturas según estos Roles. Por ejemplo una empresa que tenga distintos centros de operaciones por provincia, tendremos que tener creado al mismo cliente con distintos centros administrativos para que cada uno accesa a sus facturas.
-AdditionalData=Esto va a ser un nodo importante en el que agregaremos información adicional. Casi seguro en un subnodo de este nodo insertaremos el QR(en modo texto), podremos insertar el pdf de la factura en un formato especifico para poder insertarlo, por ejemplo en BASE64.

Otros datos importantes que teneis que tener en cuenta:
CountryCode= a Rellenar según tabla de codigo de paises Alpha 3, que son los códigos de los paises en 3 caracteres según la normatica ISO 3166-1, que es la que usa facturae, aunque la nueva ley habla de la obligatoriedad de emitir al menos para los clientes de España, no sé si se va a dar algún caso en que haya que meter el codigo de pais por el tipo de cliente que no sea residente y sea de la UE, recordad que el CodigoPais para verifactu es Alpha 2.
Tipo de Cliente: Persona Fisica o Juridica=Es facil establecer (Para los nifs, cifs, españoles) si es Fisica o Juridica, pero dejaos un campo a rellenar por si las moscas.

[ermendalenda]

Hola, sigo analizando facturae.
En cuanto a las equivalencias de tipos de factura:
-Para la sustitutiva ya que no hay una equivalencia explicita y como facturae está concebida para cobrar y pagar ( no es reporte a la AEAT), entonces Factura Sustitutiva(Verifactu)=Factura Completa(Facturae)
-Y ahora al revés, Factura Recapitulativa Facturae(albaranes, notas de entregas convertidas a factura)=Factura Completa Verifactu


En cuanto nodos que no contemplamos normalmente y que hay que tener en cuenta:
-Ibank=Cuenta donde solicitamos la transferencia (Si solitamos pago por transferencia)
-INETownCode=Código población segn el INE(Ojo no es el código Postal, podeis descargaros del INE la tabla, lo que es complicado es establecer la relación de las direcciones con los codigos de poblacion y los codigos postales, ni siquiere la Seguridad Social lo tiene bien, pero podeis dejarlo sin relacion y que lo escriban, aunque seguro el usuario se va a equivocar muchisimo si no vinculais y dais una ayuda)
InstallmentDueDate e InstallentAmountDate=Fecha e importe del efecto, pertenecen al nodo Installments(se repite tantos efectos tengas). Una factura puede emitirse para que pague en otra/s fecha/s, por transferencia o por otro metodo, aqui debes poner la/s fecha/s e importes
-AdministrativesCentres= Son datos opcionales que tendrá que darnos el cliente si quiere que le emitamos las facturas según estos Roles. Por ejemplo una empresa que tenga distintos centros de operaciones por provincia, tendremos que tener creado al mismo cliente con distintos centros administrativos para que cada uno accesa a sus facturas.
-AdditionalData=Esto va a ser un nodo importante en el que agregaremos información adicional. Casi seguro en un subnodo de este nodo insertaremos el QR(en modo texto), podremos insertar el pdf de la factura en un formato especifico para poder insertarlo, por ejemplo en BASE64.

Otros datos importantes que teneis que tener en cuenta:
CountryCode= a Rellenar según tabla de codigo de paises Alpha 3, que son los códigos de los paises en 3 caracteres según la normatica ISO 3166-1, que es la que usa facturae, aunque la nueva ley habla de la obligatoriedad de emitir al menos para los clientes de España, no sé si se va a dar algún caso en que haya que meter el codigo de pais por el tipo de cliente que no sea residente y sea de la UE, recordad que el CodigoPais para verifactu es Alpha 2.
Tipo de Cliente: Persona Fisica o Juridica=Es facil establecer (Para los nifs, cifs, españoles) si es Fisica o Juridica, pero dejaos un campo a rellenar por si las moscas.

Por aclarar lo de los códigos postales.
Correos tiene sus parcelas de reparto para dividirlos por oficina (códigos postales) que no tirne que coincidir con los códigos de municipios que son códigos,como su nombre indica, de municipios para que cada administración del municipio al que pertenece, trate los datos, aytos, etc.
Esto quiere decir que un código postal puede estar en más de un código de municipio y esto lía un poco a los desarrolladores si quiren establecer vínculos directos. Y ya para liar más, hasta una misma calle puede pertenecer a varios códigos postales pero pertener a un solo municipio.

[Noe277]

Buenas,

Están cambiando la WEB de face y la de face B2B actualizando los documentos.
Tengo una duda ¿los WS para mandar a la administración publica son distintos de los de entre empresas?
Y en tal caso ¿Dónde encuentro los de admiración publica ?


Gracias,

[ermendalenda]

Buenas,
Están cambiando la WEB de face y la de face B2B actualizando los documentos.
Tengo una duda ¿los WS para mandar a la administración publica son distintos de los de entre empresas?
Y en tal caso ¿Dónde encuentro los de admiración publica ?

Las estructuras (esquemas ) de generacion del fichetro son las mismas perono los de los de envíos y respuestas lss ws son distintas en sitio y esquemas de envío y respuesta Face tiene su ws de pruebas y de producción y faceb2b los suyos. Ahora estoy con el móvil pero te los busco y te los pongo en cuanto pueda.

[ermendalenda]

Buenas,
Están cambiando la WEB de face y la de face B2B actualizando los documentos.
Tengo una duda ¿los WS para mandar a la administración publica son distintos de los de entre empresas?
Y en tal caso ¿Dónde encuentro los de admiración publica ?

Gracias,

Te dejo documentacion.

Aqui los Endpoints de conexion:
//************************************
//************* FACE **************
//************************************
// ENTORNO DE PRODUCCION
"https://webservice.face.gob.es/facturasspp2" :

// ENTORNO DE PRUEBAS
"https://se-face-webservice.redsara.es/facturasspp2";
//************************************


//************************************
//************ FACEB2B ************
//************************************
// ENTORNO DE PRODUCCION
"https://ws.faceb2b.gob.es/sv1/invoice" :

// ENTORNO DE PRUEBAS
"https://se-ws-faceb2b.redsara.es/sv1/invoice";
//************************************

Preproducción RPC Literal
https://se-ws-faceb2b.redsara.es/sv1/clients?wsdl
Preproducción RPC Encoded
https://se-ws-faceb2b.redsara.es/sv1/ie/clients?wsdl
Producción RPC Literal
https://ws.faceb2b.gob.es/sv1/clients?wsdl
Producción RPC Encoded
https://ws.faceb2b.gob.es/sv1/ie/clients?wsdl

https://www.google.com/url?esrc=s&q=&rct=j&sa=U&url=https://administracionelectronica.gob.es/ctt/resources/Soluciones/2811/Descargas/FACeB2B---Manual-de-uso-del-API-Clients.pdf%3FidIniciativa%3D2811%26idElemento%3D16796&ved=2ahUKEwjwgLeAj8yFAxUMwQIHHRpmC0AQFnoECAgQAg&usg=AOvVaw0GwrmBBYs0xp-AtugHBKHb
https://www.google.com/url?esrc=s&q=&rct=j&sa=U&url=https://administracionelectronica.gob.es/ctt/resources/Soluciones/2811/Descargas/Interfaz%2520Servicio%2520-%2520invoice.pdf%3FidIniciativa%3D2811%26idElemento%3D12209&ved=2ahUKEwj4v62nj8yFAxWhzgIHHTyIBq8QFnoECAoQAg&usg=AOvVaw3b3idl2dLZsQGz6jKS3Eit
https://www.facturae.gob.es/politica_de_firma_formato_facturae/politica_de_firma_formato_facturae_v3_1.pdf
https://www.google.com/url?esrc=s&q=&rct=j&sa=U&url=https://administracionelectronica.gob.es/ctt/resources/Soluciones/1951/Descargas/Integracion-con-FACeB2B.pdf%3FidIniciativa%3D1951%26idElemento%3D10449&ved=2ahUKEwjz35XQj8yFAxUe1wIHHTaEAEIQFnoECAAQAg&usg=AOvVaw1CBMX7zrgoYHSqSd7wmLGr
https://www.collegesidekick.com/study-docs/1339157

No sé si funcionan todos los links. Si no te pongo los nombres de los pdfs y te salen el enlace de gob.es para descargarlos en google

[Noe277]

Te dejo documentacion.

Aqui los Endpoints de conexion:
//************************************
//************* FACE **************
//************************************
// ENTORNO DE PRODUCCION
"https://webservice.face.gob.es/facturasspp2" :

// ENTORNO DE PRUEBAS
"https://se-face-webservice.redsara.es/facturasspp2";
//************************************


//************************************
//************ FACEB2B ************
//************************************
// ENTORNO DE PRODUCCION
"https://ws.faceb2b.gob.es/sv1/invoice" :

// ENTORNO DE PRUEBAS
"https://se-ws-faceb2b.redsara.es/sv1/invoice";
//************************************

Preproducción RPC Literal
https://se-ws-faceb2b.redsara.es/sv1/clients?wsdl
Preproducción RPC Encoded
https://se-ws-faceb2b.redsara.es/sv1/ie/clients?wsdl
Producción RPC Literal
https://ws.faceb2b.gob.es/sv1/clients?wsdl
Producción RPC Encoded
https://ws.faceb2b.gob.es/sv1/ie/clients?wsdl

https://www.google.com/url?esrc=s&q=&rct=j&sa=U&url=https://administracionelectronica.gob.es/ctt/resources/Soluciones/2811/Descargas/FACeB2B---Manual-de-uso-del-API-Clients.pdf%3FidIniciativa%3D2811%26idElemento%3D16796&ved=2ahUKEwjwgLeAj8yFAxUMwQIHHRpmC0AQFnoECAgQAg&usg=AOvVaw0GwrmBBYs0xp-AtugHBKHb
https://www.google.com/url?esrc=s&q=&rct=j&sa=U&url=https://administracionelectronica.gob.es/ctt/resources/Soluciones/2811/Descargas/Interfaz%2520Servicio%2520-%2520invoice.pdf%3FidIniciativa%3D2811%26idElemento%3D12209&ved=2ahUKEwj4v62nj8yFAxWhzgIHHTyIBq8QFnoECAoQAg&usg=AOvVaw3b3idl2dLZsQGz6jKS3Eit
https://www.facturae.gob.es/politica_de_firma_formato_facturae/politica_de_firma_formato_facturae_v3_1.pdf
https://www.google.com/url?esrc=s&q=&rct=j&sa=U&url=https://administracionelectronica.gob.es/ctt/resources/Soluciones/1951/Descargas/Integracion-con-FACeB2B.pdf%3FidIniciativa%3D1951%26idElemento%3D10449&ved=2ahUKEwjz35XQj8yFAxUe1wIHHTaEAEIQFnoECAAQAg&usg=AOvVaw1CBMX7zrgoYHSqSd7wmLGr
https://www.collegesidekick.com/study-docs/1339157

No sé si funcionan todos los links. Si no te pongo los nombres de los pdfs y te salen el enlace de gob.es para descargarlos en google

Gracias. Tiene pinta que dentro de poco sacaran la normativa de ley Crea y crece y nos va a volver a tocar ponernos con esto otra vez.

[ermendalenda]

Gracias. Tiene pinta que dentro de poco sacaran la normativa de ley Crea y crece y nos va a volver a tocar ponernos con esto otra vez.

Espero que tarden, aunque yo ya estoy trabajando sobre ello por que la base Facturae es lo más probable y dific8l es que cambien de opinión. Eso sí, tiene la pinta que el esquema facturae tenga algunos cambios, pero no creo que demasiado, ya que el tema de los programas de las administraciones cuesta mucho renovarlos