TICKET BAI (TicketBAI); Nuevo sistema de la Agencia Tributaria del Pais Vasco - Página 3

Edgar7 · #1 02-06-2021

Cita:

Empezado por rci

Hola, no nos queda claro el concepto de “anular factura”.
Entendemos el funcionamiento pero no sus implicaciones.

Si se envía una anulación de una factura a TicketBAI y no se puede volver a utilizar esa numeración para otra factura, entendemos que por la parte de hacienda queda registrada esa factura como anulada pero ¿qué ocurre en la parte del emisor de la factura? ¿qué tiene que hacer con esa factura? ¿Eliminarla? Le quedará un vacio en la numeración y esto no es posible. El concepto “anular” no existe y nos crea muchas dudas.

Por favor ¿alguien puede aclararnos el tema?

Hemos enviado esa misma pregunta a las tres diputaciones forales para ver si nos aclaran el tema porque con la documentación y las consultas anteriores que hemos hecho no nos queda claro.

Muchas gracias

Hola,

Yo entiendo que por parte del emisor esa factura sigue estando pero anulada, es decir, no tendría valor fiscal, por lo que el salto en la numeración no existiría. La factura no se eliminaría se modificaría para añadir algún texto que indique que la factura ha sido anulada (por ejemplo en Portugal, se añade un sello rojo a la factura indicando que ha sido anulada)

Es como lo entiendo no se si será realmente así, a ver si alguien puede confirmarlo.

Por otra parte, ¿alguien podría indicarme que datos se han de enviar en el xml de una factura rectificativa? Es decir, se tiene que enviar en el bloque de DatosFactura y en el de TipoDesglose los datos de la factura anterior o solo se debería de enviar la información relacionada con la nueva factura rectificativa.

Un saludo

rci · #2 02-06-2021

Muchas gracias por las respuestas sline y Edgar7

Acaban de contestarme de Araba, citando la documentación y añadiendo un pequeño comentario al final.

Cita:

¿Se puede anular una factura emitida por el sistema TicketBAI?
Sí. Para ello se debe generar el fichero TicketBAI de anulación.
Pueden existir algunas situaciones, diferentes a aquellas en que según la normativa vigente deben expedirse facturas rectificativas (que es el mecanismo habitual), en las cuales es necesario dar de baja o anular la factura emitida y expedir, en su caso, una nueva que recoja correctamente la operación realizada: por ejemplo, cuando se expide una factura erróneamente por una operación que nunca llegó a realizarse y procede su anulación. (DGT V0611/ 11-3-2011)
En este caso, para anular la factura por la operación no realizada, se deberá utilizar el fichero XML TicketBAI de anulación. Por este motivo, en el fichero XML TicketBAI de anulación tan solo tendrá que identificar el emisor y la serie, el número y la fecha de expedición de la factura anulada.
Los casos de anulación de la factura pueden ser, además, entre otros, los siguientes:
a) Cuando la factura ha sido expedida por error o ha sido expedida pero todavía ni ha sido entregada o remitida.
b) Cuando la factura expedida por el destinatario por cuenta y nombre del proveedor no ha sido aceptada por éste. (En cuyo caso procede la anulación del fichero sin que haya existido factura propiamente dicha.)

En todos esos casos las factura queda anulada, pero su número no puede volver a ser utilizado. El emisor tendrá ese número de factura asociado a una que, posteriormente, ha sido anulada.

A ver si contestan las otras diputaciones.

Band · #3 02-06-2021

Buenas,

estoy usando el autofirma del gobierno (desde línea de comandos) y me encuentro algo curioso cuando firmo.

Lo primero, firmo el fichero de la siguiente manera:

Código Delphi [-]signParams := 'sign -format XAdES ' +
                '-config xadesSignFormat="XAdES Enveloped" ' +
                '-xml ' + 
                '-i "ficheroxmlorigen.xml" ' +
                '-o "ficheroxmlfirmado.xml" ' + 
                '-store pkcs12:"sello_entidad_act.p12" ' + // certificado prueba izenpe
                '-filter "imported" ' + 
                '-password "IZDesa2021" ';

Después ejecuto el autofirmaCommandLine.exe con estos parámetros. Me devuelve una respuesta correcta y cuando abro el fichero firmado, me encuentro que me pone una parte antes del tag de apertura de <T:TicketBai>

Código:

<?xml version="1.0" encoding="UTF-8"?><ds:Signature xmlns:ds="htxp://ww.w3.org/2000/09/xmldsig#" Id="Signature-8fa9da36-336e-45d6-b3dd-b71754940975-Signature"><ds:SignedInfo><ds:CanonicalizationMethod Algorithm="htxp://ww.w3.org/TR/2001/REC-xml-c14n-20010315"/><ds:SignatureMethod Algorithm="htxp://ww.w3.org/2001/04/xmldsig-more#rsa-sha512"/><ds:Reference Id="Reference-7022344d-8098-40e2-85a1-9b6fac8e7fe2" Type="htxp://ww.w3.org/2000/09/xmldsig#Object" URI="#Object-85d35cbb-4970-4879-9b8f-36a791abaa3e"><ds:Transforms><ds:Transform Algorithm="htxp://ww.w3.org/TR/2001/REC-xml-c14n-20010315"/></ds:Transforms><ds:DigestMethod Algorithm="htxp://ww.w3.org/2001/04/xmlenc#sha512"/><ds:DigestValue>Ez+74wZNxKZZKtEqJ316cqdmFS8PleD/FYXLGPJlLRbzy9m3cBPhnBlVBfy5bfXO1v7sDrWDytdpIC6j7G+sqw==</ds:DigestValue></ds:Reference><ds:Reference Type="htxp://uri.etsi.org/01903#SignedProperties" URI="#Signature-8fa9da36-336e-45d6-b3dd-b71754940975-SignedProperties"><ds:DigestMethod Algorithm="htxp://ww.w3.org/2001/04/xmlenc#sha512"/><ds:DigestValue>UlcCCa03GKj736PTmA4XE75OKg1t0H5s6Wy6wnNYK4CQz8RhSI+E5qawUZlTaR8A4HYC7an1gZ7uYLcOzOBfyw==</ds:DigestValue></ds:Reference><ds:Reference URI="#Signature-8fa9da36-336e-45d6-b3dd-b71754940975-KeyInfo"><ds:DigestMethod Algorithm="htxp://ww.w3.org/2001/04/xmlenc#sha512"/><ds:DigestValue>Qi/soITpAWmbm4ijl/kbUO24PpZosIDoBFjT7idNWrZRShw3+7WxehTxFYy0+BZI8vaHegq0p4ybuzQ1+zQfUA==</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue Id="Signature-8fa9da36-336e-45d6-b3dd-b71754940975-SignatureValue">MSzBViTRZjMXM6kpQXs/AD/eMTfCnY/iN5NJMeYjLjVF4K/f5xzXSJjjIQFpc6zTtN3WzYGtKnCISOqXQfYy0AsxH6MEtQsGjUGVVNEyjOyRN4n4tiP6YFhZSesAZkkY9J03qOxWxAN/KphKqCi2iQkflEpuCqgVta51zfop9sLf8w/8iNzSj3JbUz88LBihlpMSgPTCv5UFXvGczji4dq1P5wkqlT5Mfbwt75zRKnwBtuhCIIFm/0ZqrMGeCspHXEMKfR2LIUIXVVkQvG5LaUTL9LbizIPEXkFxzOzFZxATTGrv9s/FxJ9so2ro6RlWYHqiHXf5rmk+Lvz1uTbsZg==</ds:SignatureValue><ds:KeyInfo Id="Signature-8fa9da36-336e-45d6-b3dd-b71754940975-KeyInfo"><ds:X509Data><ds:X509Certificate>MIIJHDCCBwSgAwIBAgICG34wDQYJKoZIhvcNAQELBQAwgZcxCzAJBgNVBAYTAkVTMRQwEgYDVQQKDAtJWkVOUEUgUy5BLjE6MDgGA1UECwwxTlpaIFppdXJ0YWdpcmkgcHVibGlrb2EgLSBDZXJ0aWZpY2FkbyBwdWJsaWNvIFNDSTE2MDQGA1UEAwwtQ0EgZGUgQ2l1ZGFkYW5vcyB5IEVudGlkYWRlcyAoNCkgLSBERVNBUlJPTExPMB4XDTIxMDMxNTEwMTgzOFoXDTI1MDMxNTEwMTgzOFowgeoxCzAJBgNVBAYTAkVTMSwwKgYDVQQKDCNaaXVydGFwZW4gZXRhIFplcmJpdHp1IEVucHJlc2EgUy5BLjEyMDAGA1UECwwpWmlnaWx1IHppdXJ0YWdpcmlhIC0gQ2VydGlmaWNhZG8gZGUgc2VsbG8xGDAWBgNVBGEMD1ZBVEVTLVM3ODM2MTA3SDEUMBIGA1UEAwwLSVpFTlBFIFMuQS4xFTATBgNVBCoMDFNFTExPRU5USURBRDEYMBYGA1UEBAwPRklDVElDSU8gQUNUSVZPMRgwFgYDVQQFEw9JRENFUy05OTk5OTk3NlIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDaIEXGD0UM/aKVjsAQvQQUhUpIryTesYjH6Ws8y1r5N4ZKDIdQif6K/cqaEEF24XIdXMPsz1u/Bz5OCq+l7vLlVtj37jDWZvDO5moqFAQu0Zf364NU54NmJOsHEm2b/umnhfnlCuy4DUmEvsCZ9zgjBfxZkbRZzRLT9BuUFrHWxNDjDFvus6c58xICpx1nRccIzqXtNCvCCZDiBlbfkGxduA7W5P1NkaGEM1pkPDNwvipJzsWI8ahS5MsPc5vgfihe8ZxsPE4tn9VRa8NAJmJZjyI9c/ih/YsqCdJ0M/NvddWGoCTg/+25Cc0AuG9yOhv//PILF8G6l9ggjb0MLmwTAgMBAAGjggQbMIIEFzCBxwYDVR0SBIG/MIG8hhVodHRwOi8vd3d3Lml6ZW5wZS5jb22BD2luZm9AaXplbnBlLmNvbaSBkTCBjjFHMEUGA1UECgw+SVpFTlBFIFMuQS4gLSBDSUYgQTAxMzM3MjYwLVJNZXJjLlZpdG9yaWEtR2FzdGVpeiBUMTA1NSBGNjIgUzgxQzBBBgNVBAkMOkF2ZGEgZGVsIE1lZGl0ZXJyYW5lbyBFdG9yYmlkZWEgMTQgLSAwMTAxMCBWaXRvcmlhLUdhc3RlaXowDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUcfMP8AjaVNQ6WEeB6MT8IA0u73owHwYDVR0jBBgwFoAUb//9DfIMYw8mcV0a4G9lZGY4a5MwggEpBgNVHSAEggEgMIIBHDCCAQ0GCSsGAQQB8zlmCzCB/zAlBggrBgEFBQcCARYZaHR0cDovL3d3dy5pemVucGUuY29tL2NwczCB1QYIKwYBBQUHAgIwgcgMgcVLb250c3VsdGEgd3d3Lml6ZW5wZS5jb20tZW4gYmFsZGludHphayBldGEga29uZGl6aW9hayB6aXVydGFnaXJpYW4gZmlkYXR1IGVkbyBlcmFiaWxpIGF1cnJldGlrIC0gQ29uc3VsdGUgZW4gd3d3Lml6ZW5wZS5jb20gbG9zIHTDqXJtaW5vcyB5IGNvbmRpY2lvbmVzIGFudGVzIGRlIHV0aWxpemFyIG8gY29uZmlhciBlbiBlbCBjZXJ0aWZpY2FkbzAJBgcEAIvsQAEBMIGiBggrBgEFBQcBAQSBlTCBkjAlBggrBgEFBQcwAYYZaHR0cDovL29jc3BkZXMuaXplbnBlLmNvbTBpBggrBgEFBQcwAoZdaHR0cDovL3d3dy5pemVucGUuY29tL2NvbnRlbmlkb3MvaW5mb3JtYWNpb24vY2FzX2l6ZW5wZS9lc19jYXMvYWRqdW50b3MvQ0NFRVJfY2VydF9zaGEyNTYuY3J0MIHRBggrBgEFBQcBAwSBxDCBwTAIBgYEAI5GAQEwCwYGBACORgEDAgEPMHwGBgQAjkYBBTByMCQWHmh0dHBzOi8vd3d3Lml6ZW5wZS5jb20vcGRzL2VuLxMCZW4wJBYeaHR0cHM6Ly93d3cuaXplbnBlLmNvbS9wZHMvZXUvEwJldTAkFh5odHRwczovL3d3dy5pemVucGUuY29tL3Bkcy9lcy8TAmVzMBMGBgQAjkYBBjAJBgcEAI5GAQYCMBUGCCsGAQUFBwsCMAkGBwQAi+xJAQIwNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybGRlcy5pemVucGUuY29tL2NnaS1iaW4vY3JsMjANBgkqhkiG9w0BAQsFAAOCAgEAAg9GYZrcIQk/W2yY5a/JPdxRSz54j3f/73WzXGqluv7rqk+F0oOPRPsXsq5tZAKJOAWmv+z+vNQaNmtdgSJF+G8OyxkhjsbIlLqL/UlkJtOKJWL6iYHAsJzqfatrBUByZudIMdM3kuH+rr1WWujuXgR8VYWoe2dWh+TSqaMVclLaRrQikEwaQArzVVEiUZffOGyQ1OC9bucbdj82gcUqZtcuyKEfDwLYFc5mwNnrXub+AE4skELPC0fqeiS5CPQr5nAZrc/PFI9iKrMbVkDtR8cJ54a3ugN2ad8f/spFnd8vtotVhbRMDttkf+gXpLjSsQQX/MrisVz7Np9O9fNkTQYDmgMyM2kDNevk7XoOUPgPXlcr/InOYe3fGp6EfFN8l8wG9OolRC29J9zbyOUDT6f/J6GGOlJTGMAqW6i6M3tUyCjZVg5CpATQxBWnsPqrG5NU8VPs1m26EPohpU8iXRJy4EDfh/seFHw5/bK5hnOJKc4yz24wv15bdY+4UMEbFzWNmNuCtCJGCVh1L6U86x7aDfUJ2r01dE+p51QdimzmPH5wzZySEwkcAELt8JQARKgvCl4TSDCdaByg3W3QxMfF4pKONdQgtRlWRm+t9dQPa10nyzWpHt/G+naOZgoXRj8jKadZ5eajWx6eD5YgOR+RfYtRFMbBMlb5Lx3ruv4=</ds:X509Certificate></ds:X509Data><ds:KeyValue><ds:RSAKeyValue><ds:Modulus>2iBFxg9FDP2ilY7AEL0EFIVKSK8k3rGIx+lrPMta+TeGSgyHUIn+iv3KmhBBduFyHVzD7M9bvwc+Tgqvpe7y5VbY9+4w1mbwzuZqKhQELtGX9+uDVOeDZiTrBxJtm/7pp4X55QrsuA1JhL7Amfc4IwX8WZG0Wc0S0/QblBax1sTQ4wxb7rOnOfMSAqcdZ0XHCM6l7TQrwgmQ4gZW35BsXbgO1uT9TZGhhDNaZDwzcL4qSc7FiPGoUuTLD3Ob4H4oXvGcbDxOLZ/VUWvDQCZiWY8iPXP4of2LKgnSdDPzb3XVhqAk4P/tuQnNALhvcjob//zyCxfBupfYII29DC5sEw==</ds:Modulus><ds:Exponent>AQAB</ds:Exponent></ds:RSAKeyValue></ds:KeyValue></ds:KeyInfo><ds:Object Id="Object-85d35cbb-4970-4879-9b8f-36a791abaa3e" MimeType="text/xml"><T:TicketBai xmlns:T="urn:ticketbai:emision">

y otra parte al final del documento, después del tag </T:TicketBai>

Código:

</T:TicketBai></ds:Object><ds:Object><xades:QualifyingProperties xmlns:xades="htxp://uri.etsi.org/01903/v1.3.2#" Id="Signature-8fa9da36-336e-45d6-b3dd-b71754940975-QualifyingProperties" Target="#Signature-8fa9da36-336e-45d6-b3dd-b71754940975-Signature" xmlns:ds="htxp://ww.w3.org/2000/09/xmldsig#"><xades:SignedProperties Id="Signature-8fa9da36-336e-45d6-b3dd-b71754940975-SignedProperties"><xades:SignedSignatureProperties><xades:SigningTime>2021-06-02T11:04:53+02:00</xades:SigningTime><xades:SigningCertificate><xades:Cert><xades:CertDigest><ds:DigestMethod Algorithm="htxp://ww.w3.org/2001/04/xmlenc#sha512"/><ds:DigestValue>lF2EMvVHlIK9Aa4kMV3nRJ1/JiKlclPKKqMNR/tB0bEWzijflNYzT204iuMKfWTEDRu1+k++TT66aBV/9fX7Ow==</ds:DigestValue></xades:CertDigest><xades:IssuerSerial><ds:X509IssuerName>CN=CA de Ciudadanos y Entidades (4) - DESARROLLO, OU=NZZ Ziurtagiri publikoa - Certificado publico SCI, O=IZENPE S.A., C=ES</ds:X509IssuerName><ds:X509SerialNumber>7038</ds:X509SerialNumber></xades:IssuerSerial></xades:Cert></xades:SigningCertificate></xades:SignedSignatureProperties><xades:SignedDataObjectProperties><xades:DataObjectFormat ObjectReference="#Reference-7022344d-8098-40e2-85a1-9b6fac8e7fe2"><xades:Description/><xades:ObjectIdentifier><xades:Identifier Qualifier="OIDAsURN">urn:oid:1.2.840.10003.5.109.10</xades:Identifier><xades:Description/></xades:ObjectIdentifier><xades:MimeType>text/xml</xades:MimeType><xades:Encoding/></xades:DataObjectFormat></xades:SignedDataObjectProperties></xades:SignedProperties></xades:QualifyingProperties></ds:Object></ds:Signature>

Si envio el fichero tal cual después de firmarlo, obtengo la siguiente respuesta:

Código:

<Codigo>002</Codigo>
<Descripcion>Error: El fichero de alta TicketBAI no cumple el esquema XSD. Detalle del error: cvc-complex-type.2.4.b: The content of element 'T:TicketBai' is not complete. One of '{"htxp://ww.w3.org/2000/09/xmldsig#":Signature}' is expected.</Descripcion>

Lo cual es normal, ya que no estoy cumpliendo con el esquema.
Pero si luego simplemente pongo bien a mano la firma donde toca, como está en sus ejemplos, me devuelve la siguiente respuesta:

Código:

<Salida>
        <IdentificadorTBAI>TBAI-B12345679-270819-LyOCa+YH/nwde-017</IdentificadorTBAI>
        <FechaRecepcion>02-06-2021 11:39:48</FechaRecepcion>
        <Estado>00</Estado>
        <Descripcion>Recibido</Descripcion>
        <Azalpena>Jasota</Azalpena>
        <ResultadosValidacion>
            <Codigo>008</Codigo>
            <Descripcion>El mensaje ha sido modificado en tránsito o la firma no está bien realizada -- SignedInfo failed to verify. Reference URI="#Object-76fa901b-053f-4a52-a1c7-99ea25d23551" failed to verify. Reference URI="#Signature-cf5f9ae0-96fb-4306-bd15-709cde0c3501-SignedProperties" failed to verify. Reference URI="#Signature-cf5f9ae0-96fb-4306-bd15-709cde0c3501-KeyInfo" failed to verify. [src/xml2signatureobj.cpp(315)] - (10606)</Descripcion>
            <Azalpena>El mensaje ha sido modificado en tránsito o la firma no está bien realizada -- SignedInfo failed to verify. Reference URI="#Object-76fa901b-053f-4a52-a1c7-99ea25d23551" failed to verify. Reference URI="#Signature-cf5f9ae0-96fb-4306-bd15-709cde0c3501-SignedProperties" failed to verify. Reference URI="#Signature-cf5f9ae0-96fb-4306-bd15-709cde0c3501-KeyInfo" failed to verify. [src/xml2signatureobj.cpp(315)] - (10606)</Azalpena>
        </ResultadosValidacion>
        <ResultadosValidacion>
            <Codigo>010</Codigo>
            <Descripcion>Aviso: Posible error de encadenamiento.</Descripcion>
            <Azalpena>Abisua: Litekeena da kateamendu errorea gertatzea.</Azalpena>
        </ResultadosValidacion>
        <CSV>TBAIab94d122-fb84-4828-9e5e-45f565ed7536</CSV>
    </Salida>

Así que me lo acepta pero me sale este mensaje: "El mensaje ha sido modificado en tránsito o la firma no está bien realizada" que es correcto, ya que no se debe modificar el fichero una vez firmado (o creo que es a causa de esto).

Agradecería si alguien sabe porque la firma no sale donde toca (supongo que debe ser antes del cierre del tag <T:TicketBai> ya que así sale en sus ejemplos) Si es que estoy generando algo mal en el xml o algo me falla en los parámetros del autofirma.

Gracias!

tejano · #4 02-06-2021

Cita:

Empezado por Band

Buenas,

estoy usando el autofirma del gobierno (desde línea de comandos) y me encuentro algo curioso cuando firmo.

Lo primero, firmo el fichero de la siguiente manera:

Código Delphi [-]signParams := 'sign -format XAdES ' +
                '-config xadesSignFormat="XAdES Enveloped" ' +
                '-xml ' + 
                '-i "ficheroxmlorigen.xml" ' +
                '-o "ficheroxmlfirmado.xml" ' + 
                '-store pkcs12:"sello_entidad_act.p12" ' + // certificado prueba izenpe
                '-filter "imported" ' + 
                '-password "IZDesa2021" ';

Después ejecuto el autofirmaCommandLine.exe con estos parámetros. Me devuelve una respuesta correcta y cuando abro el fichero firmado, me encuentro que me pone una parte antes del tag de apertura de <T:TicketBai>

Código:

<?xml version="1.0" encoding="UTF-8"?><ds:Signature xmlns:ds="htxp://ww.w3.org/2000/09/xmldsig#" Id="Signature-8fa9da36-336e-45d6-b3dd-b71754940975-Signature"><ds:SignedInfo><ds:CanonicalizationMethod Algorithm="htxp://ww.w3.org/TR/2001/REC-xml-c14n-20010315"/><ds:SignatureMethod Algorithm="htxp://ww.w3.org/2001/04/xmldsig-more#rsa-sha512"/><ds:Reference Id="Reference-7022344d-8098-40e2-85a1-9b6fac8e7fe2" Type="htxp://ww.w3.org/2000/09/xmldsig#Object" URI="#Object-85d35cbb-4970-4879-9b8f-36a791abaa3e"><ds:Transforms><ds:Transform Algorithm="htxp://ww.w3.org/TR/2001/REC-xml-c14n-20010315"/></ds:Transforms><ds:DigestMethod Algorithm="htxp://ww.w3.org/2001/04/xmlenc#sha512"/><ds:DigestValue>Ez+74wZNxKZZKtEqJ316cqdmFS8PleD/FYXLGPJlLRbzy9m3cBPhnBlVBfy5bfXO1v7sDrWDytdpIC6j7G+sqw==</ds:DigestValue></ds:Reference><ds:Reference Type="htxp://uri.etsi.org/01903#SignedProperties" URI="#Signature-8fa9da36-336e-45d6-b3dd-b71754940975-SignedProperties"><ds:DigestMethod Algorithm="htxp://ww.w3.org/2001/04/xmlenc#sha512"/><ds:DigestValue>UlcCCa03GKj736PTmA4XE75OKg1t0H5s6Wy6wnNYK4CQz8RhSI+E5qawUZlTaR8A4HYC7an1gZ7uYLcOzOBfyw==</ds:DigestValue></ds:Reference><ds:Reference URI="#Signature-8fa9da36-336e-45d6-b3dd-b71754940975-KeyInfo"><ds:DigestMethod Algorithm="htxp://ww.w3.org/2001/04/xmlenc#sha512"/><ds:DigestValue>Qi/soITpAWmbm4ijl/kbUO24PpZosIDoBFjT7idNWrZRShw3+7WxehTxFYy0+BZI8vaHegq0p4ybuzQ1+zQfUA==</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue Id="Signature-8fa9da36-336e-45d6-b3dd-b71754940975-SignatureValue">MSzBViTRZjMXM6kpQXs/AD/eMTfCnY/iN5NJMeYjLjVF4K/f5xzXSJjjIQFpc6zTtN3WzYGtKnCISOqXQfYy0AsxH6MEtQsGjUGVVNEyjOyRN4n4tiP6YFhZSesAZkkY9J03qOxWxAN/KphKqCi2iQkflEpuCqgVta51zfop9sLf8w/8iNzSj3JbUz88LBihlpMSgPTCv5UFXvGczji4dq1P5wkqlT5Mfbwt75zRKnwBtuhCIIFm/0ZqrMGeCspHXEMKfR2LIUIXVVkQvG5LaUTL9LbizIPEXkFxzOzFZxATTGrv9s/FxJ9so2ro6RlWYHqiHXf5rmk+Lvz1uTbsZg==</ds:SignatureValue><ds:KeyInfo Id="Signature-8fa9da36-336e-45d6-b3dd-b71754940975-KeyInfo"><ds:X509Data><ds:X509Certificate>MIIJHDCCBwSgAwIBAgICG34wDQYJKoZIhvcNAQELBQAwgZcxCzAJBgNVBAYTAkVTMRQwEgYDVQQKDAtJWkVOUEUgUy5BLjE6MDgGA1UECwwxTlpaIFppdXJ0YWdpcmkgcHVibGlrb2EgLSBDZXJ0aWZpY2FkbyBwdWJsaWNvIFNDSTE2MDQGA1UEAwwtQ0EgZGUgQ2l1ZGFkYW5vcyB5IEVudGlkYWRlcyAoNCkgLSBERVNBUlJPTExPMB4XDTIxMDMxNTEwMTgzOFoXDTI1MDMxNTEwMTgzOFowgeoxCzAJBgNVBAYTAkVTMSwwKgYDVQQKDCNaaXVydGFwZW4gZXRhIFplcmJpdHp1IEVucHJlc2EgUy5BLjEyMDAGA1UECwwpWmlnaWx1IHppdXJ0YWdpcmlhIC0gQ2VydGlmaWNhZG8gZGUgc2VsbG8xGDAWBgNVBGEMD1ZBVEVTLVM3ODM2MTA3SDEUMBIGA1UEAwwLSVpFTlBFIFMuQS4xFTATBgNVBCoMDFNFTExPRU5USURBRDEYMBYGA1UEBAwPRklDVElDSU8gQUNUSVZPMRgwFgYDVQQFEw9JRENFUy05OTk5OTk3NlIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDaIEXGD0UM/aKVjsAQvQQUhUpIryTesYjH6Ws8y1r5N4ZKDIdQif6K/cqaEEF24XIdXMPsz1u/Bz5OCq+l7vLlVtj37jDWZvDO5moqFAQu0Zf364NU54NmJOsHEm2b/umnhfnlCuy4DUmEvsCZ9zgjBfxZkbRZzRLT9BuUFrHWxNDjDFvus6c58xICpx1nRccIzqXtNCvCCZDiBlbfkGxduA7W5P1NkaGEM1pkPDNwvipJzsWI8ahS5MsPc5vgfihe8ZxsPE4tn9VRa8NAJmJZjyI9c/ih/YsqCdJ0M/NvddWGoCTg/+25Cc0AuG9yOhv//PILF8G6l9ggjb0MLmwTAgMBAAGjggQbMIIEFzCBxwYDVR0SBIG/MIG8hhVodHRwOi8vd3d3Lml6ZW5wZS5jb22BD2luZm9AaXplbnBlLmNvbaSBkTCBjjFHMEUGA1UECgw+SVpFTlBFIFMuQS4gLSBDSUYgQTAxMzM3MjYwLVJNZXJjLlZpdG9yaWEtR2FzdGVpeiBUMTA1NSBGNjIgUzgxQzBBBgNVBAkMOkF2ZGEgZGVsIE1lZGl0ZXJyYW5lbyBFdG9yYmlkZWEgMTQgLSAwMTAxMCBWaXRvcmlhLUdhc3RlaXowDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUcfMP8AjaVNQ6WEeB6MT8IA0u73owHwYDVR0jBBgwFoAUb//9DfIMYw8mcV0a4G9lZGY4a5MwggEpBgNVHSAEggEgMIIBHDCCAQ0GCSsGAQQB8zlmCzCB/zAlBggrBgEFBQcCARYZaHR0cDovL3d3dy5pemVucGUuY29tL2NwczCB1QYIKwYBBQUHAgIwgcgMgcVLb250c3VsdGEgd3d3Lml6ZW5wZS5jb20tZW4gYmFsZGludHphayBldGEga29uZGl6aW9hayB6aXVydGFnaXJpYW4gZmlkYXR1IGVkbyBlcmFiaWxpIGF1cnJldGlrIC0gQ29uc3VsdGUgZW4gd3d3Lml6ZW5wZS5jb20gbG9zIHTDqXJtaW5vcyB5IGNvbmRpY2lvbmVzIGFudGVzIGRlIHV0aWxpemFyIG8gY29uZmlhciBlbiBlbCBjZXJ0aWZpY2FkbzAJBgcEAIvsQAEBMIGiBggrBgEFBQcBAQSBlTCBkjAlBggrBgEFBQcwAYYZaHR0cDovL29jc3BkZXMuaXplbnBlLmNvbTBpBggrBgEFBQcwAoZdaHR0cDovL3d3dy5pemVucGUuY29tL2NvbnRlbmlkb3MvaW5mb3JtYWNpb24vY2FzX2l6ZW5wZS9lc19jYXMvYWRqdW50b3MvQ0NFRVJfY2VydF9zaGEyNTYuY3J0MIHRBggrBgEFBQcBAwSBxDCBwTAIBgYEAI5GAQEwCwYGBACORgEDAgEPMHwGBgQAjkYBBTByMCQWHmh0dHBzOi8vd3d3Lml6ZW5wZS5jb20vcGRzL2VuLxMCZW4wJBYeaHR0cHM6Ly93d3cuaXplbnBlLmNvbS9wZHMvZXUvEwJldTAkFh5odHRwczovL3d3dy5pemVucGUuY29tL3Bkcy9lcy8TAmVzMBMGBgQAjkYBBjAJBgcEAI5GAQYCMBUGCCsGAQUFBwsCMAkGBwQAi+xJAQIwNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybGRlcy5pemVucGUuY29tL2NnaS1iaW4vY3JsMjANBgkqhkiG9w0BAQsFAAOCAgEAAg9GYZrcIQk/W2yY5a/JPdxRSz54j3f/73WzXGqluv7rqk+F0oOPRPsXsq5tZAKJOAWmv+z+vNQaNmtdgSJF+G8OyxkhjsbIlLqL/UlkJtOKJWL6iYHAsJzqfatrBUByZudIMdM3kuH+rr1WWujuXgR8VYWoe2dWh+TSqaMVclLaRrQikEwaQArzVVEiUZffOGyQ1OC9bucbdj82gcUqZtcuyKEfDwLYFc5mwNnrXub+AE4skELPC0fqeiS5CPQr5nAZrc/PFI9iKrMbVkDtR8cJ54a3ugN2ad8f/spFnd8vtotVhbRMDttkf+gXpLjSsQQX/MrisVz7Np9O9fNkTQYDmgMyM2kDNevk7XoOUPgPXlcr/InOYe3fGp6EfFN8l8wG9OolRC29J9zbyOUDT6f/J6GGOlJTGMAqW6i6M3tUyCjZVg5CpATQxBWnsPqrG5NU8VPs1m26EPohpU8iXRJy4EDfh/seFHw5/bK5hnOJKc4yz24wv15bdY+4UMEbFzWNmNuCtCJGCVh1L6U86x7aDfUJ2r01dE+p51QdimzmPH5wzZySEwkcAELt8JQARKgvCl4TSDCdaByg3W3QxMfF4pKONdQgtRlWRm+t9dQPa10nyzWpHt/G+naOZgoXRj8jKadZ5eajWx6eD5YgOR+RfYtRFMbBMlb5Lx3ruv4=</ds:X509Certificate></ds:X509Data><ds:KeyValue><ds:RSAKeyValue><ds:Modulus>2iBFxg9FDP2ilY7AEL0EFIVKSK8k3rGIx+lrPMta+TeGSgyHUIn+iv3KmhBBduFyHVzD7M9bvwc+Tgqvpe7y5VbY9+4w1mbwzuZqKhQELtGX9+uDVOeDZiTrBxJtm/7pp4X55QrsuA1JhL7Amfc4IwX8WZG0Wc0S0/QblBax1sTQ4wxb7rOnOfMSAqcdZ0XHCM6l7TQrwgmQ4gZW35BsXbgO1uT9TZGhhDNaZDwzcL4qSc7FiPGoUuTLD3Ob4H4oXvGcbDxOLZ/VUWvDQCZiWY8iPXP4of2LKgnSdDPzb3XVhqAk4P/tuQnNALhvcjob//zyCxfBupfYII29DC5sEw==</ds:Modulus><ds:Exponent>AQAB</ds:Exponent></ds:RSAKeyValue></ds:KeyValue></ds:KeyInfo><ds:Object Id="Object-85d35cbb-4970-4879-9b8f-36a791abaa3e" MimeType="text/xml"><T:TicketBai xmlns:T="urn:ticketbai:emision">

y otra parte al final del documento, después del tag </T:TicketBai>

Código:

</T:TicketBai></ds:Object><ds:Object><xades:QualifyingProperties xmlns:xades="htxp://uri.etsi.org/01903/v1.3.2#" Id="Signature-8fa9da36-336e-45d6-b3dd-b71754940975-QualifyingProperties" Target="#Signature-8fa9da36-336e-45d6-b3dd-b71754940975-Signature" xmlns:ds="htxp://ww.w3.org/2000/09/xmldsig#"><xades:SignedProperties Id="Signature-8fa9da36-336e-45d6-b3dd-b71754940975-SignedProperties"><xades:SignedSignatureProperties><xades:SigningTime>2021-06-02T11:04:53+02:00</xades:SigningTime><xades:SigningCertificate><xades:Cert><xades:CertDigest><ds:DigestMethod Algorithm="htxp://ww.w3.org/2001/04/xmlenc#sha512"/><ds:DigestValue>lF2EMvVHlIK9Aa4kMV3nRJ1/JiKlclPKKqMNR/tB0bEWzijflNYzT204iuMKfWTEDRu1+k++TT66aBV/9fX7Ow==</ds:DigestValue></xades:CertDigest><xades:IssuerSerial><ds:X509IssuerName>CN=CA de Ciudadanos y Entidades (4) - DESARROLLO, OU=NZZ Ziurtagiri publikoa - Certificado publico SCI, O=IZENPE S.A., C=ES</ds:X509IssuerName><ds:X509SerialNumber>7038</ds:X509SerialNumber></xades:IssuerSerial></xades:Cert></xades:SigningCertificate></xades:SignedSignatureProperties><xades:SignedDataObjectProperties><xades:DataObjectFormat ObjectReference="#Reference-7022344d-8098-40e2-85a1-9b6fac8e7fe2"><xades:Description/><xades:ObjectIdentifier><xades:Identifier Qualifier="OIDAsURN">urn:oid:1.2.840.10003.5.109.10</xades:Identifier><xades:Description/></xades:ObjectIdentifier><xades:MimeType>text/xml</xades:MimeType><xades:Encoding/></xades:DataObjectFormat></xades:SignedDataObjectProperties></xades:SignedProperties></xades:QualifyingProperties></ds:Object></ds:Signature>

Si envio el fichero tal cual después de firmarlo, obtengo la siguiente respuesta:

Código:

<Codigo>002</Codigo>
<Descripcion>Error: El fichero de alta TicketBAI no cumple el esquema XSD. Detalle del error: cvc-complex-type.2.4.b: The content of element 'T:TicketBai' is not complete. One of '{"htxp://ww.w3.org/2000/09/xmldsig#":Signature}' is expected.</Descripcion>

Lo cual es normal, ya que no estoy cumpliendo con el esquema.
Pero si luego simplemente pongo bien a mano la firma donde toca, como está en sus ejemplos, me devuelve la siguiente respuesta:

Código:

<Salida>
        <IdentificadorTBAI>TBAI-B12345679-270819-LyOCa+YH/nwde-017</IdentificadorTBAI>
        <FechaRecepcion>02-06-2021 11:39:48</FechaRecepcion>
        <Estado>00</Estado>
        <Descripcion>Recibido</Descripcion>
        <Azalpena>Jasota</Azalpena>
        <ResultadosValidacion>
            <Codigo>008</Codigo>
            <Descripcion>El mensaje ha sido modificado en tránsito o la firma no está bien realizada -- SignedInfo failed to verify. Reference URI="#Object-76fa901b-053f-4a52-a1c7-99ea25d23551" failed to verify. Reference URI="#Signature-cf5f9ae0-96fb-4306-bd15-709cde0c3501-SignedProperties" failed to verify. Reference URI="#Signature-cf5f9ae0-96fb-4306-bd15-709cde0c3501-KeyInfo" failed to verify. [src/xml2signatureobj.cpp(315)] - (10606)</Descripcion>
            <Azalpena>El mensaje ha sido modificado en tránsito o la firma no está bien realizada -- SignedInfo failed to verify. Reference URI="#Object-76fa901b-053f-4a52-a1c7-99ea25d23551" failed to verify. Reference URI="#Signature-cf5f9ae0-96fb-4306-bd15-709cde0c3501-SignedProperties" failed to verify. Reference URI="#Signature-cf5f9ae0-96fb-4306-bd15-709cde0c3501-KeyInfo" failed to verify. [src/xml2signatureobj.cpp(315)] - (10606)</Azalpena>
        </ResultadosValidacion>
        <ResultadosValidacion>
            <Codigo>010</Codigo>
            <Descripcion>Aviso: Posible error de encadenamiento.</Descripcion>
            <Azalpena>Abisua: Litekeena da kateamendu errorea gertatzea.</Azalpena>
        </ResultadosValidacion>
        <CSV>TBAIab94d122-fb84-4828-9e5e-45f565ed7536</CSV>
    </Salida>

Así que me lo acepta pero me sale este mensaje: "El mensaje ha sido modificado en tránsito o la firma no está bien realizada" que es correcto, ya que no se debe modificar el fichero una vez firmado (o creo que es a causa de esto).

Agradecería si alguien sabe porque la firma no sale donde toca (supongo que debe ser antes del cierre del tag <T:TicketBai> ya que así sale en sus ejemplos) Si es que estoy generando algo mal en el xml o algo me falla en los parámetros del autofirma.

Gracias!

Yo utilizo este comando para firmarlo y creo que va bien, aunque todavía no he podido enviar ninguna por el problema con el curl

AutoFirmaCommandLine.exe sign
-i fichero_origen
-o fichero_destino
-store pkcs12:certificado_p12
-password password_certificado_p12
-filter certificado_p12
-format xades -xml
-config "format=XAdES Enveloped
\npolicyIdentifier=https://www.batuz.eus/fitxategiak/batuz/ticketbai/sinadura_elektronikoaren_zehaztapenak_
especificaciones_de_la_firma_electronica_v1_0.pdf
\npolicyIdentifierHash=Quzn98x3PMbSHwbUzaj5f5KOpiH0u8bvmwbbbNkO9Es=
\npolicyIdentifierHashAlgorithm=http://www.w3.org/2001/04/xmlenc#sha256
\npolicyQualifier=https://www.batuz.eus/fitxategiak/batuz/ticketbai/sinadura_elektronikoaren_zehaztapenak_
especificaciones_de_la_firma_electronica_v1_0.pdf

keys · #5 03-06-2021

Cita:

Empezado por rci

Hola, no nos queda claro el concepto de “anular factura”.
Entendemos el funcionamiento pero no sus implicaciones.

Si se envía una anulación de una factura a TicketBAI y no se puede volver a utilizar esa numeración para otra factura, entendemos que por la parte de hacienda queda registrada esa factura como anulada pero ¿qué ocurre en la parte del emisor de la factura? ¿qué tiene que hacer con esa factura? ¿Eliminarla? Le quedará un vacio en la numeración y esto no es posible. El concepto “anular” no existe y nos crea muchas dudas.

Por favor ¿alguien puede aclararnos el tema?

Hemos enviado esa misma pregunta a las tres diputaciones forales para ver si nos aclaran el tema porque con la documentación y las consultas anteriores que hemos hecho no nos queda claro.

Muchas gracias

La factura queda anulada a efectos fiscales. El emisor debe conservar el fichero xml de alta y el de anulación de la factura por una posible inspeccion de hacienda, como el resto de los xml. No se produce ningún salto en la facturación, por ejemplo la factura 000067 existe pero esta anulada.

CMB · #6 08-07-2021

He hecho una pequeña prueba usando uno de los ficheros de ejemplo de Batuz, y enviándolo al servidor de prueba de Gipuzkoa. El fichero Ejemplo_TicketBAI_79732487C_A2022_0399.xml está ligeramente modificado para cumplir con la spec actual de Gipuzkoa (se ha modificado las fechas para que no estén en el futuro, y se ha añadido la sección <DetallesFactura>).

Esta es la línea de comandos que uso para enviarlo:

Código:

curl.exe --data-binary @Ejemplo_TicketBAI_79732487C_A2022_0399.xml --cert-type P12 --cert sello_entidad_act.p12:IZProd2021 -H "Content-Type: application/xml;charset=UTF8" -X POST https://tbai-prep.egoitza.gipuzkoa.eus/WAS/HACI/HTBRecepcionFacturasWEB/rest/recepcionFacturas/alta

Y esta es la respuesta del servidor:

Código PHP:


			
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:TicketBaiResponse xmlns:ns2="urn:ticketbai:emision">
    <Salida>
        <FechaRecepcion>08-07-2021 18:24:48</FechaRecepcion>
        <Estado>01</Estado>
        <Descripcion>Rechazado</Descripcion>
        <Azalpena>Baztertua</Azalpena>
        <ResultadosValidacion>
            <Codigo>005</Codigo>
            <Descripcion>Error: Fichero de alta TicketBAI ya registrado en el sistema.</Descripcion>
            <Azalpena>Errorea: TicketBAI fitxategia sisteman erregistratuta dago jada.</Azalpena>
        </ResultadosValidacion>
    </Salida>
</ns2:TicketBaiResponse>

Mi duda es la siguiente: No me sorprende que este fichero ya esté registrado (está claro que no soy el primero al que se le ocurre hacer esto), no obstante lo que me gustaría saber es qué criterio usan para determinar que una factura está duplicada. ¿Alguien tiene una idea?

He probado cambiar la serie y número de factura, sin éxito. También eliminar el encadenamiento (campo <EncadenamientoFacturaAnterior>) pero obtengo el mismo resultado.

Curiosamente no parece que al servidor le importe que tras todos estos cambios la firma en <ds:Signature> siga siendo la misma (aparentemente, esta comprobación es posterior).

HerensugeBeltz · #7 09-07-2021

Cita:

Empezado por CMB

Mi duda es la siguiente: No me sorprende que este fichero ya esté registrado (está claro que no soy el primero al que se le ocurre hacer esto), no obstante lo que me gustaría saber es qué criterio usan para determinar que una factura está duplicada. ¿Alguien tiene una idea?

Te adjunto la respuesta de la Hacienda Foral a tu pregunta:

Egun on, buenos días

La validación que comprueba que una factura no esté ya enviada a TicketBAI y no suponga una duplicación comprueba que no exista otra factura con la misma clave funcional. Es decir que no contenga los mismos valores en los siguientes campos:

• NIF- Emisor + Serie + Numero + FechaExpedición

Si cambia la serie cambia la clave funcional, por lo que se considera otra factura. Es decir, MISERIE21-001 y MISERIE22-001 son dos facturas distintas.

Si no indica la serie, puede repetirse el número de factura pero la fecha de expedición ha de ser diferente.

Izan ongi,

tejano · #8 09-07-2021

Cita:

Empezado por HerensugeBeltz

Te adjunto la respuesta de la Hacienda Foral a tu pregunta:

Egun on, buenos días

La validación que comprueba que una factura no esté ya enviada a TicketBAI y no suponga una duplicación comprueba que no exista otra factura con la misma clave funcional. Es decir que no contenga los mismos valores en los siguientes campos:

• NIF- Emisor + Serie + Numero + FechaExpedición

Si cambia la serie cambia la clave funcional, por lo que se considera otra factura. Es decir, MISERIE21-001 y MISERIE22-001 son dos facturas distintas.

Si no indica la serie, puede repetirse el número de factura pero la fecha de expedición ha de ser diferente.

Izan ongi,

Es decir, que si soy un "cabrón" y emito 50.000 facturas en el LROE de recibidas de Iberdrola, aunque no sean para mí, pero pongo como que sí, con su número y fecha porque quiero fastidiar el sistema. El resto de personas ya no van a poder enviarlas como recibidas??

JoseLeeTo · #9 09-07-2021

Cita:

Empezado por tejano

Es decir, que si soy un "cabrón" y emito 50.000 facturas en el LROE de recibidas de Iberdrola, aunque no sean para mí, pero pongo como que sí, con su número y fecha porque quiero fastidiar el sistema. El resto de personas ya no van a poder enviarlas como recibidas??

Hombre, si todos tuviésemos el mismo NIF..... pero no es el caso.

tejano · #10 09-07-2021

Cita:

Empezado por JoseLeeTo

Hombre, si todos tuviésemos el mismo NIF..... pero no es el caso.

Pensaba que estabais hablando de las facturas recibidas.

No sé si pondrán problemas si 2 CIF diferentes emiten en el LROE el mismo número de factura recibida, CIF EMISOR+SERIE+NUMERO+FECHA EXPEDICION, pero con diferentes CIF RECEPCTORES.

Neftali [Germán.Estévez] · #11 09-07-2021

Cita:

Empezado por tejano

Es decir, que si soy un "cabrón" y emito 50.000 facturas en el LROE de recibidas de Iberdrola, aunque no sean para mí, pero pongo como que sí, con su número y fecha porque quiero fastidiar el sistema. El resto de personas ya no van a poder enviarlas como recibidas??

Bueno, supongo que de eso se trata.
En algun momento alguien validará las facturas que "envía" Iberdrola como emitidas y las que "envían" el resto de empresas como recibidas. Y eso debe "cuadrar".

Si tú envías esas facturas y otra empresa las envía se detectará la duplicidad (que de eso se trata).
Y a tí te caerá un puro por enviar como "recibidas" cosas que no has recibido...

Neftali [Germán.Estévez] · #12 09-07-2021

Cita:

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

Y a tí te caerá un puro por enviar como "recibidas" cosas que no has recibido...

Al final siempre acabamos en los mismo...

Cuando hay un error, le "cae un puro" a alguien y $$$$$$$$$$

(multa al canto y a recaudar)

Nessie · #13 07-08-2021

Hola, kaixo,

en primer lugar, gracias por toda la información que habéis colgado en este foro. ¡Excelente!

En segundo lugar, una duda sobre el campo DESCUENTO del XML de TicketBai Gipuzkoa: He visto que el descuento solo se puede aplicar a una línea detalle en concreto. En mi caso, me interesaría aplicar un descuento a la factura completa, no a una línea detalle concreta. No he visto que el XML tenga ese campo. ¿Alguien se encuentra en esta misma tesitura? (Voy a escribir a TicketBai Gipuzkoa para comentarlo, pero me gustaría saber si alguien tiene el mismo problema).

Muchas gracias.
Eskerrik asko.

bilbur · #14 08-08-2021

Hasta ahora, en desarrollo, guardo las contraseñas de los certificados .pfx en texto claro.
Evidente que esto no puede ser en producción.

Estoy haciendo lo siguiente:

Mediante formulario solicito al cliente su certificado.pfx y su contraseña de importación (la cual no "veo")

Guardo en el directorio que corresponde su certificado.pfx

lo paso y guardo a certificado.pem

y guardo la contraseña encriptada en certificado.pass

De este modo No guardo las contraseñas de importación del certificado y firma en texto claro.

A la hora de la firma desencripto la contraseña guardada en certificado.pass, firmo y destruyo la contraseña desencriptada. (mini modificación firmador.php probado y funcionando)

Cierto es que al final todo depende de la contraseña de encriptar desencriptar, la cual puede ser autogenerada por combinaciones de cif cliente, cif desarrollador, fechas, etc.

Seguro que se me pasa algo y mi pregunta es, ¿Vosotros cómo lo habéis planteado?

Un saludo y gracias

Si alguien necesita el script en PHP para pasar y guardar los certificados.pfx a .pem y .pass que lo diga y lo subo.

Sistel · #15 08-08-2021

Cita:

Empezado por bilbur

Hasta ahora, en desarrollo, guardo las contraseñas de los certificados .pfx en texto claro.
Evidente que esto no puede ser en producción.

Estoy haciendo lo siguiente:

Mediante formulario solicito al cliente su certificado.pfx y su contraseña de importación (la cual no "veo")

Guardo en el directorio que corresponde su certificado.pfx

lo paso y guardo a certificado.pem

y guardo la contraseña encriptada en certificado.pass

De este modo No guardo las contraseñas de importación del certificado y firma en texto claro.

A la hora de la firma desencripto la contraseña guardada en certificado.pass, firmo y destruyo la contraseña desencriptada. (mini modificación firmador.php probado y funcionando)

Cierto es que al final todo depende de la contraseña de encriptar desencriptar, la cual puede ser autogenerada por combinaciones de cif cliente, cif desarrollador, fechas, etc.

Seguro que se me pasa algo y mi pregunta es, ¿Vosotros cómo lo habéis planteado?

Un saludo y gracias

Si alguien necesita el script en PHP para pasar y guardar los certificados.pfx a .pem y .pass que lo diga y lo subo.

Hola bilbur,

Está bien pensado el tema de encriptar la contraseña del certificado del cliente.
Toda protección es poca.

En mi caso, todas mis aplicaciones son webs en Internet.
No pido a mis clientes ningún certificado digital.
Firmo yo los XML de sus facturas con mi propio certificado digital.
Y marco los XML como factura emitida por tercero (nodo EmitidaPorTercerosODestinatario)
Por supuesto, hago un contrato con mis clientes por el que me autorizan a dicha emisión y al envío de sus facturas a Hacienda.

Me da auténtico repelús dejar una aplicación en manos de un cliente (y más en este caso del software garante TicketBAI en el que las multas son de órdago).
Así que les monto una API para que su sistema de facturación se conecte con mi aplicación, que se encarga de todo (confeccionar el XML, firmarlo, almacenarlo, crear el código TBAI, crear el código QR y enviar el XML firmado a Hacienda)

Saludos

ermendalenda · #16 18-09-2021

Cita:

Empezado por bilbur

Hasta ahora, en desarrollo, guardo las contraseñas de los certificados .pfx en texto claro.
Evidente que esto no puede ser en producción.

Estoy haciendo lo siguiente:

Mediante formulario solicito al cliente su certificado.pfx y su contraseña de importación (la cual no "veo")

Guardo en el directorio que corresponde su certificado.pfx

lo paso y guardo a certificado.pem

y guardo la contraseña encriptada en certificado.pass

De este modo No guardo las contraseñas de importación del certificado y firma en texto claro.

A la hora de la firma desencripto la contraseña guardada en certificado.pass, firmo y destruyo la contraseña desencriptada. (mini modificación firmador.php probado y funcionando)

Cierto es que al final todo depende de la contraseña de encriptar desencriptar, la cual puede ser autogenerada por combinaciones de cif cliente, cif desarrollador, fechas, etc.

Seguro que se me pasa algo y mi pregunta es, ¿Vosotros cómo lo habéis planteado?

Un saludo y gracias

Si alguien necesita el script en PHP para pasar y guardar los certificados.pfx a .pem y .pass que lo diga y lo subo.

Hola bilbur, ante todo muchas gracias por ese script maravillos del firmador.php, agradecería que subieras el nuevo script para convertir los certificados.
Te debemos ya unas cuantas rondas de pinchos y bebidas.
Un saludo.

Neftali [Germán.Estévez] · #17 09-08-2021

Cita:

Empezado por Nessie

En segundo lugar, una duda sobre el campo DESCUENTO del XML de TicketBai Gipuzkoa: He visto que el descuento solo se puede aplicar a una línea detalle en concreto. En mi caso, me interesaría aplicar un descuento a la factura completa, no a una línea detalle concreta. No he visto que el XML tenga ese campo. ¿Alguien se encuentra en esta misma tesitura? (Voy a escribir a TicketBai Gipuzkoa para comentarlo, pero me gustaría saber si alguien tiene el mismo problema).

Buenos días.
Puestos a escoger una opción de las 2 a implementar, creo que la de las líneas es más lógica (además de la más habitual).
Sólo se me ocurre en tu caso, que apliques el descuento a una línea calculando cual sería (si es posible), o que lo prorratees en todas las líneas de la factura (teniendo en cuenta posibles errores de redondeo).

adolphsys · #18 09-08-2021

Cita:

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

Buenos días.
Puestos a escoger una opción de las 2 a implementar, creo que la de las líneas es más lógica (además de la más habitual).
Sólo se me ocurre en tu caso, que apliques el descuento a una línea calculando cual sería (si es posible), o que lo prorratees en todas las líneas de la factura (teniendo en cuenta posibles errores de redondeo).

Hola, creo que Nessie se refiere a la aplicación de descuentos o cargos globales (por ejemplo portes) en la factura.
Echad un vistazo a la FAQ de Gipuzkoa 12.13: "...cada uno de los descuentos globales también deberán figurar en la factura, consignándose cada uno de ellos como una nueva línea de detalle describiendo el concepto del descuento, en su caso, y el importe, que según se configure el mismo, pudiera tener signo negativo."

Nessie · #19 12-08-2021

Cita:

Empezado por adolphsys

Hola, creo que Nessie se refiere a la aplicación de descuentos o cargos globales (por ejemplo portes) en la factura.
Echad un vistazo a la FAQ de Gipuzkoa 12.13: "...cada uno de los descuentos globales también deberán figurar en la factura, consignándose cada uno de ellos como una nueva línea de detalle describiendo el concepto del descuento, en su caso, y el importe, que según se configure el mismo, pudiera tener signo negativo."

Gracias por la respuesta, Adosplsys, y por la referencia a las FAQ. No se me había ocurrido que el descuento podía ser una nueva línea de detalle con el importe negativo. Solucionado, entonces. Gracias!

iMia · #20 18-08-2021

Hola a tod@s...
Primero daros las gracias por compartir todos los conocimientos y dudas que os habéis ido encontrando con el TBAI (ese gran desconocido con el que acabas soñando...)
He conseguido, gracias a vosotros generar el xml, firmarlo (con el AutoFirmaCommandLine), generar el QR, enviarlo y casi lo más difícil, que lo acepten en Guipuzcoa...

Lo he hecho todo con Tokyo (10.2.3), si alguien tiene alguna duda... aquí estoy a vuestra disposición...

Sólo tengo un problemilla con la respuesta, por ahora leo la respuesta directamente a pelo en puro xml. (FindNode('Salida'), etc...) y funciona, pero no la puedo parsear al tipo IXMLTicketBaiResponse (generado automáticamente a partir del xsd)... que sería más elegante, legible y correcto.

intento esto:

Código Delphi [-]          
var
  idHttp: TIdHttp;
  xmlResp: IXMLDocument;
  xmlTBResp: IXMLTicketBaiResponse;
begin
          ...
          idhttp.Request.ContentType := 'application/xml; charset=utf-8'; // Para evitar el 'ón' de la firma.
          strResponse := idHttp.Post(tblTBAI_Admin.FieldByName('URL_Envia').AsString.Trim + '\alta', RequestBody);
          if not strResponse.isEmpty then
          begin
            xmlResp := TXMLDocument.create(nil);
            strResponse := strResponse.Replace('ns2:TicketBaiResponse','TicketBaiResponse',[rfReplaceAll]); // probado de quitar y nada...
            CoInitialize(nil);
            xmlResp.LoadFromXML(strResponse);
            xmlResp.Active := true;
            responseFileName := strFileName + '_Respuesta_' + formatDateTime(TBAI_DATE_FORMAT_FILE, now()) + FILE_EXT_XML;
            xmlResp.SaveToFile(responseFileName);
            // Aquí podría recorrer xmlResp sin problema...
            if fileExists(responseFileName) then
            begin
              xmlTBResp := NewTicketBaiResponse();
              CoInitialize(nil);
              // Aquí falla con el EIntfCastError 'interface not supported' al intentar meterlo en el tipo TBAIResponse con el LoadTicketBaiResponse
              xmlTBResp := LoadTicketBaiResponse(responseFileName);
              xmlTBResp.Active := true;
              if (xmlTBResp <> nil) and (xmlTBResp.Salida <> nil) then
              ....

Tambien he probado con

Código Delphi [-]              ...
              xmlTBResp := NewTicketBaiResponse();
              CoInitialize(nil);
              // Aquí falla con el EIntfCastError 'interface not supported' al intentar meterlo en el tipo TBAIResponse con el LoadTicketBaiResponse
              xmlTBResp := GetTicketBaiResponse(xmlResp);  /// Get del xml en vez de load, que es más directo y no hay que guardar a disco
              xmlTBResp.Active := true;
              if (xmlTBResp <> nil) and (xmlTBResp.Salida <> nil) then
              ...

y tampoco...

Si a alguien se le ocurre algo... si no lo dejaré moviéndome por los nodos a pelo...

Muchas gracias de nuevo...

Temas Similares
Tema	Autor	Foro	Respuestas	Último mensaje
SII -Nuevo sistema de la Agencia Tributaria española de envío de datos vía Webservice	newtron	Internet	3557	Hace 4 Días 17:42:47
Como utilizar la ayuda del nuevo Sistema Operativo	gluglu	Humor	3	24-09-2007 09:39:05
Aplicacion Agencia De Viajes	ArdiIIa	Varios	9	20-01-2007 16:49:53
El Vasco Aguirre	Al González	La Taberna	5	26-05-2006 09:22:28
Microsoft ha lanzado su nuevo sistema operativo	DarkByte	Humor	0	25-01-2004 09:21:14