TICKET BAI (TicketBAI); Nuevo sistema de la Agencia Tributaria del Pais Vasco

[Edgar7]

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]

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.

¿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.

[tejano]

A alguien que se le ocurra algo, se queda colgado en este punto * upload completely sent off: 23 out of 23 bytes
100 23 0 0 0 23 0 0 --:--:-- 0:03:51 --:--:-- 0

He descargado el certificado de pruebas/producción, pero aún así nada. Si se utiliza este certificado hay que cambiar el CIF/Razón social en la llamada?


C:\tmp>curl --cert-type P12 --cert c:\amis\exes\sello_entidad_act.p12:IZProd2021 -H "Content-Type:application/json" -H "Accept-Encoding:gzip" -H "Content-Encoding:gzip" -H "Content-Length:534" -H "Content-Type:application/octet-stream" -H "eus-bizkaia-n3-version:1.0" -H "eus-bizkaia-n3-content-type:application/xml" -H "eus-bizkaia-n3-data:{\"con\":\"LROE\",\"apa\":\"1.1\",\"inte\":{\"nif\":\"A48190839\",\"nrs\":\"TECNICAS DE REFRACTARIOS S.A.U\"},\"drs\":{\"mode\":\"240\",\"ejer\":\"2021\"}}" -v https://pruesarrerak.bizkaia.eus/N3B4001M/kontsulta -d data:c:\tmp\consulta.gz --output c:\tmp\respuesta.xml
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 80.245.2.232...
* TCP_NODELAY set
* Connected to pruesarrerak.bizkaia.eus (80.245.2.232) port 443 (#0)
* schannel: SSL/TLS connection with pruesarrerak.bizkaia.eus port 443 (step 1/3)
* schannel: checking server certificate revocation
* schannel: sending initial handshake data: sending 195 bytes...
* schannel: sent initial handshake data: sent 195 bytes
* schannel: SSL/TLS connection with pruesarrerak.bizkaia.eus port 443 (step 2/3)
* schannel: failed to receive handshake, need more data
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* schannel: SSL/TLS connection with pruesarrerak.bizkaia.eus port 443 (step 2/3)
* schannel: encrypted data got 4096
* schannel: encrypted data buffer: offset 4096 length 4096
* schannel: encrypted data length: 4010
* schannel: encrypted data buffer: offset 4010 length 4096
* schannel: received incomplete message, need more data
* schannel: SSL/TLS connection with pruesarrerak.bizkaia.eus port 443 (step 2/3)
* schannel: encrypted data got 1024
* schannel: encrypted data buffer: offset 5034 length 5034
* schannel: encrypted data length: 6
* schannel: encrypted data buffer: offset 6 length 5034
* schannel: received incomplete message, need more data
* schannel: SSL/TLS connection with pruesarrerak.bizkaia.eus port 443 (step 2/3)
* schannel: encrypted data got 3
* schannel: encrypted data buffer: offset 9 length 5034
* schannel: sending next handshake data: sending 4433 bytes...
* schannel: SSL/TLS connection with pruesarrerak.bizkaia.eus port 443 (step 2/3)
* schannel: encrypted data got 51
* schannel: encrypted data buffer: offset 51 length 5034
* schannel: SSL/TLS handshake complete
* schannel: SSL/TLS connection with pruesarrerak.bizkaia.eus port 443 (step 3/3)
* schannel: stored credential handle in session cache
> POST /N3B4001M/kontsulta HTTP/1.1
> Host: pruesarrerak.bizkaia.eus
> User-Agent: curl/7.55.1
> Accept: */*
> Content-Type:application/json
> Accept-Encoding:gzip
> Content-Encoding:gzip
> Content-Length:534
> Content-Type:application/octet-stream
> eus-bizkaia-n3-version:1.0
> eus-bizkaia-n3-content-type:application/xml
> eus-bizkaia-n3-data:{"con":"LROE","apa":"1.1","inte":{"nif":"A48190839","nrs":"TECNICAS DE REFRACTARIOS S.A.U"},"drs":{"mode":"240","ejer":"2021"}}
>
} [23 bytes data]
* upload completely sent off: 23 out of 23 bytes
100 23 0 0 0 23 0 0 --:--:-- 0:03:51 --:--:-- 0

Graciassssss

[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>

<?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>

</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:

<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:

<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]

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>

<?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>

</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:

<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:

<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

[tejano]

Buenas tardes,

Me acaba de llegar este email de Batuz, diciendo que cambian el email para consultas.

Os adjunto los nuevos emails:

Puede dirigir sus consultas relativas al proyecto Batuz a las siguientes direcciones:
- Consultas fiscales: batuz.zergak@bizkaia.eus.
- Consultas técnicas: batuz.programak@bizkaia.eus.

[keys]

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.

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

Empezado por tejano

Me acaba de llegar este email de Batuz, diciendo que cambian el email para consultas.

Actualizados los Mails en el mensaje inicial.
Los nuevos entran en funcionamiento a partir del 8 de Junio; Y desde ese momento el anterior buzon (batuz@bizkaia.eus) se cierra.

Gracias por el aviso.

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

En general, bastante de acuerdo con lo comentado por [keys].
Anular y rectificar son 2 conceptos distintos.
https://rodriguezyasoc.com/lo-una-fa...ctura-anulada/

Empezado por rci

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?

Dependerá de cómo se gestione en tu programa.
Puedes borrarla, o dejarla marcada como "anulada", eso es una gestión que quedará para tu programa y de cómo decidáis hacerlo.
En ningún caso "desaparece" de tu sistema, porque toda la información referente a TicketBAI/Batuz debes conservarla.

Empezado por rci

¿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.

Personalmente, optaría por "marcarla como anulada". Aunque eso es una decisión vuestra.
Sea cual sea la decisión, debes guardar la información necesaria, para si es necesario justificar ese salto (por una anulación).

Empezado por rci

El concepto “anular” no existe y nos crea muchas dudas.

Como he dicho antes, si que existe, aunque es poco probable.
Básicamente se anula una factura, cuando el trabajo facturado (por ejemplo) no se ha realizado. En ese caso no puedes "rectificar", porque estarías facturando y rectificando sobre un trabajo que no se ha llevado a cabo.
En ese caso, la factura inicial, se anula, no se rectifica.

Entiendo que en general son casos puntuales.
Si en tu sistema aparecen "muchas" facturas anuladas, es posible que alguien en hacienda decida hacerte una visita...

[rci]

Muchas gracias Keys y Neftali por las respuestas.



Saludos

[landaga]

Empezado por tejano

Buenas tardes, no sé si alguien puede decirme que estoy haciendo mal a la hora de mandar el XML a la DBF. El XML es correcto y gzip también

* No pongas -H "Content-Type:application/json" (sólo -H "Content-Type:application/octet-stream")
* En lugar del signo igual =, pon dos puntos :
* En el Json escapa las dobles comillas (\")
* -H "Content-Length=534" no es necesario, cURL envía el Content-Lenght automáticamente
* La barra baja en la Razon Social no es necesaria


Un saludo

[landaga]

Empezado por tejano

Buenas tardes, no sé si alguien puede decirme que estoy haciendo mal a la hora de mandar el XML a la DBF. El XML es correcto y gzip también

Otra cuestion, los comprimidos son datos binarios así que envia el gzip de esta manera


--data-bynary @c:\tmp\consulta.gz

[landaga]

Empezado por sline

Estoy realizando consultas a lroe a batuz pero siempre tengo el mismo resultado:

eus-bizkaia-n3-mensaje-respuesta: Operación errónea.
eus-bizkaia-n3-codigo-respuesta: B4_1000025
eus-bizkaia-n3-numero-registro: 
eus-bizkaia-n3-tipo-respuesta: Incorrecto

El xml que uso para enviar es el mismo que el del ejemplo (cambiando lo necesario) Ejemplo_Consulta_1_LROE_PJ_240_FacturasEmitidasConSG_B00000034.xml



¿A alguien mas le pasa?

Puede ser que estes intentando hacer una Consulta de algo de lo que no has enviado el Alta?

[tejano]

Empezado por landaga

Puede ser que estes intentando hacer una Consulta de algo de lo que no has enviado el Alta?

Gracias landaga, creo que ya estoy más cerca.

Ahora me da el error N3_0000007 No existe un apoderamiento para la pareja de interesado y representante indicada.

Sabéis a que puede ser debido?

[Sistel]

Empezado por tejano

Gracias landaga, creo que ya estoy más cerca.

Ahora me da el error N3_0000007 No existe un apoderamiento para la pareja de interesado y representante indicada.

Sabéis a que puede ser debido?

Hola,

Creo que puede ser porque el que envía (con su certificado) el LROE no es el mismo que emite la factura.

En ese caso, se precisa que el emisor de la factura haya autorizado al que la envía en el LROE.

Hay un registro de apoderamientos para poder realizar esos envíos en representación del emisor de la factura:
https://www.euskadi.eus/registro-ele...web01-sede/es/
(Aunque no sé si ese registro sirve para apoderar en el caso de Batuz)

Saludos

[Sistel]

Empezado por Sistel

Hola,

Creo que puede ser porque el que envía (con su certificado) el LROE no es el mismo que emite la factura.

En ese caso, se precisa que el emisor de la factura haya autorizado al que la envía en el LROE.

Hay un registro de apoderamientos para poder realizar esos envíos en representación del emisor de la factura:
https://www.euskadi.eus/registro-ele...web01-sede/es/

Saludos

Ampliando un poco más el tema.

Hace tiempo hicimos una consulta a BATUZ:
¿Podríamos emplear, también, para el envío de los LROE, correspondientes a nuestros clientes, nuestro certificado digital en lugar del de cada contribuyente?

La respuesta es Sí.

Aun no se han publicado las órdenes forales que regulan el envío de las anotaciones al LROE. No obstante, en el texto de las mismas se recogerán dos situaciones distintas, ya previstas en la actualidad en relación con el SII, y que se trasladarán igualmente a Batuz:

- El suministro electrónico de las anotaciones al LROE podrá ser efectuado por un tercero o tercera que actúe en representación del contribuyente, de acuerdo con lo establecido en la normativa tributaria.
- Asimismo, al igual que en el SII, el Departamento de Hacienda y Finanzas habilitará el suministro electrónico de las anotaciones al LROE en representación de terceras personas a las entidades que lo soliciten a través del formulario electrónico que se apruebe al efecto. En particular, si se utiliza esta figura, los estatutos de las sociedad solicitante deberán completar, dentro de las actividad que conforman su objeto social, la realización de actividades de representación.
- En estos dos casos de representación, la entidad representante podrá utilizar su propio certificado para realizar los envíos.

Saludos

[tejano]

Gracias por responder Sistel,

En este caso lo estoy enviando con un certificado de Representante de Persona Jurídica de la FNMT a nombre de la empresa. Hacemos el IVA y cualquier otro trámite administrativo con este certificado.

[Sistel]

Empezado por tejano

Gracias por responder Sistel,

En este caso lo estoy enviando con un certificado de Representante de Persona Jurídica de la FNMT a nombre de la empresa. Hacemos el IVA y cualquier otro trámite administrativo con este certificado.

Pues si el certificado utilizado para firmar la factura y el utilizado para enviarla por LROE son el mismo y pertenecen al NIF del emisor de la factura, es bastante raro el error.
Puedes consultarles a Batuz a ver qué dicen.

Saludos

[Band]

Ya he dado con el error que tenía en lo de la firma. Estaba poniendo el "format=XAdES Enveloped" mal. Esta que acabo de poner es la manera correcta y yo lo hacía así: format="XAdES Enveloped". Esto hacía que me partiera la firma y no la colocase bien.


Os comento otro detalle en el envío del fichero con CURL, por si alguien se encuentra con esto.

Yo hasta ahora enviaba el fichero así:

Código Delphi [-]
'-d "@' + nombreArchivo+ '" '

Con lo que me encontraba todo el rato con este "error":

Reference URI="" failed to verify. [src/xml2signatureobj.cpp(315)] - (10606)

La manera correcta o que a mi me funciona es así:

Código Delphi [-]
'--data-binary "@' + nombreArchivo + '" '

Eso, dicho sin mirármelo a fondo, creo que se debe a que con el -d a secas probablemente se esté enviando algún carácter mal codificado (o creo que por aquí va la cosa). Luego hay una discordancia con el fichero firmado ya que "se ha modificado algo" después de la firma cuando lo recibe el servicio.

Saludos!

[landaga]

Yo tambien utilizo curl para enviar el LROE pero no veo la forma de recibir las cabeceras de la respuesta, el cuerpo de la respuesta si lo recibo y lo archivo pero no los headers.
El asunto es que algunas veces no envia nada y como en estos casos no devuelve nada en el body no se cual es la razón del fallo.
Alguien lo tiene resuelto?
Gracias