El propio tar debería servir (no lo he usado).




Pero si no, cualquier otro (yo utilizo 7zip) debería servir:

https://thedeveloperblog.com/7-zip-examples

Gracias Neftali, quiero utilizar el tar por no estar instalando programas en los ordenadores.

Si a alguien le sirve, el comando que utilizo es "tar -cvzf fichero_origen fichero_gz"

Gracias.
^\||/^\||/^\||/^\||/

Buenos días, una pregunta en general y para Vizcaya en particular......

Hoy me ha venido un mensaje interno del SII porque han metido una factura como Exportación y deberían haberla metido en Nacional porque lleva IVA.

A alguien se le ocurre de cara al TicketBai como van a solucionar estos temas? Porque siempre existen casos extraños que van a pasar y que no están solucionados en programación.

Por una parte no se puede enviar el registro del LROE porque debería dar error y por otra parte no se puede anular la factura porque no se ha enviado, o por lo menos eso me dice la lógica.

Alguna idea??

De momento, se me ocurre anular la factura y volverla a enviar correctamente. Ya que no existe la opción de modificar nada.

Un Saludo.

Si, pero me imagino que no podrías enviarla en el LROE porque daría errores lo mismo que ha pasado con el SII.
El LROE es lo mismo que el SII pero inventado por nuestra GRAN HACIENDA!!! ��

En el caso de Vizcaya, está previsto que determinadas facturas se envíen en un libro diferente al "240 con SG" (240 con Software garante).
Por ejemplo, facturas que hayan dado error, que no apliquen a ese libro o que sean casos especiales no previstos.
En ese caso, hay otro libro de envío que es el "240 sin SG".
El formato es parecido, pero estos envíos no incluyen el TicketBAI.

Una factura que por lo que sea no se pueda subir en el "240 con SG" (el normal, por decirlo así), habrá que subirla utilizando el "240 sin SG".

Gracias Neftali

Gracias a landaga, sline, HerensugeBeltz por las respuestas. Al final y después de asegurarme del tema del BOM del fichero, temas de encoding, caracteres extraños que pudieran haber delante de la declaración xml, etc... di con el problema que para mi caso es particular. Os pongo mi solución por si a alguien más le pasa y usa curl para enviar.

Yo usaba para enviar el fichero este parámetro (repito, con curl):

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

y la solución ha sido cambiarlo por:

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

No me lo he mirado con detalle pero imagino que en el primer caso le debe estar colando algo en el envío, cosa que no hace en el segundo caso.

Proceso de envió Bizkaia
 

Buenos días,

Se me plantea una duda existencial.
En Gipuzkoa yo genero el xml lo firmo, lo envió y me devuelve el Qr. Entonces imprimo la factura con el Qr.

Pero en BIZKAIA:
Genero el xml, lo firmo y a los 3 meses o cuando sea lo envió en el modelo 140/240.
¿Las facturas al imprimir no van a llevar el Qr?
No se si estoy entendiendo el proceso en Bizkaia.

Buenos días Band, puedes enviar como te quedaría el curl?, yo también estoy intentando utilizarlo y más ahora que ese comando viene que el mismo Windows.
Cuando lo envío me da el error 400 de Bad Request.
Graciasssssss!!!!

Hola!

Para Gipuzkoa no se como será, pero en Bizkaia generas el Qr (con SG) y lo incrustas en el pdf.

Hola,

Tanto en Gipuzkoa como en Bizkaia, la firma del XML de la factura y la generación de los códigos TBAI y QR no requieren ningún envío.
Es un proceso que se hace en local o en tu servidor (dependiendo la arquitectura que utilices), pero no requiere nada de Hacienda.

Una vez se tiene la factura (XML) firmada (y generados los códigos TBAI y QR), hay que enviarla a Hacienda Foral.
En el caso de Gipuzkoa, el envío debe ser inmediato nada más firmarse cada factura.
En el caso de Bizkaia se deben enviar las facturas firmadas dentro del capítulo 1.1 del LROE (Libro Registro de Operaciones Económicas, modelo 140 para autónomos y modelo 240 para empresas).
Pero en este caso de Bizkaia hay un plazo para el envío igual al que hasta ahora había para las declaraciones de IVA (trimestrales en la mayoría de los casos, mensuales en algunos casos y en un plazo de 4 días para las empresas obligadas hasta ahora al SII)

Saludos

Consulta DBF
 

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

Adjunto en envío que he hecho con el comando curl y la respuesta de la DBF. El error creo que está aquí "* Mark bundle as not supporting multiuse"

curl --cert certificado.pem --key clave_certificado.pem -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_SAU"},"drs ":{"mode":"240","ejer":"2021"}} -X POST -v https://pruesarrerak.bizkaia.eus/N3B4001M/kontsulta -d data=c:\tmp\consulta.gz --output c:\tmp\respuesta.txt
Note: Unnecessary use of -X or --request, POST is already inferred.
% 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:443...
* Connected to pruesarrerak.bizkaia.eus (80.245.2.232) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: c:\curl\1\bin\curl-ca-bundle.crt
* CApath: none
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [81 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [4450 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [527 bytes data]
* TLSv1.2 (IN), TLS handshake, Request CERT (13):
{ [36 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Certificate (11):
} [2210 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [134 bytes data]
* TLSv1.2 (OUT), TLS handshake, CERT verify (15):
} [264 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / DHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: jurisdictionC=ES; jurisdictionST=BIZKAIA; jurisdictionL=BILBAO; businessCategory=Government Entity; postalCode=48009; C=ES; ST=BIZKAIA; L=BILBAO; street=GRAN VÍA 25; O=BIZKAIKO FORU ALDUNDIA - DIPUTACION FORAL DE BIZKAIA; OU=IT; serialNumber=P4800000D; CN=pruesarrerak.bizkaia.eus
* start date: Jul 3 12:41:06 2020 GMT
* expire date: Jul 3 12:41:06 2022 GMT
* subjectAltName: host "pruesarrerak.bizkaia.eus" matched cert's "pruesarrerak.bizkaia.eus"
* issuer: C=ES; O=IZENPE S.A.; OU=BZ Ziurtagiri publikoa - Certificado publico EV; CN=CA de Certificados SSL EV
* SSL certificate verify ok.
} [5 bytes data]
> POST /N3B4001M/kontsulta HTTP/1.1
> Host: pruesarrerak.bizkaia.eus
> User-Agent: curl/7.73.0
> Accept: */*
> Content-Type:application/json
> eus-bizkaia-n3-data={con:LROE,apa:1.1,inte:{nif:A48190839,nrs:TECNICAS_DE_REFRACTARIOS_SAU},drs:{mode:240,ejer:2021 }}
> Content-Length: 23
>
} [23 bytes data]
* upload completely sent off: 23 out of 23 bytes
{ [5 bytes data]
* Mark bundle as not supporting multiuse
< HTTP/1.1 400 Bad Request
< Date: Tue, 01 Jun 2021 15:32:31 GMT
< Content-Length: 226
< Connection: close
< Content-Type: text/html; charset=iso-8859-1
< Set-Cookie: TS0171c831=0147f0636e5196e806220013a9ac432d8ddb6b0939537abc2a9c686853ccc6150ba84f4e4e510f66131b57d88 8b4728c8c1c3b5923; Path=/
<
{ [226 bytes data]
100 249 100 226 100 23 784 79 --:--:-- --:--:-- --:--:-- 864
* Closing connection 0
} [5 bytes data]
* TLSv1.2 (OUT), TLS alert, close notify (256):
} [2 bytes data

A quien pueda decirme dónde falla, se lo agradeceré para siempre.

Saludos

Prueba a cambiar en las cabeceras el "=" por ": " (dos puntos)
-H "Content-Encoding=gzip" -> -H "Content-Encoding: gzip"
...


y posiblemente esto así:
-H "eus-bizkaia-n3-data: {\"con\":\"LROE\",\"apa\":\"1.1\",\"inte\":{\"nif\":\"A48190839\",\"nrs\":\"TECNICAS_DE_REFRACTARIOS _SAU\"},\"drs\":{\"mode\":\"240\",\"ejer\":\"2021\"}}"

o asi:
-H 'eus-bizkaia-n3-data: {"con":"LROE","apa":"1.1","inte":{"nif":"A48190839","nrs":"TECNICAS_DE_REFRACTARIOS_SAU"},"drs ":{"mode":"240","ejer":"2021"}}'

hola tejano, yo lo hago así:

// Lleno variable de parámetros

Código Delphi [-]
curlCommand := '-d "@' + nombreArchivo + '" ' + // Archivo que voy a enviar
    ' --cert-type P12 --cert sello_entidad_act.p12:IZDesa2021 ' + //Certificado pruebas izenpe (usando sello entidad)
    ' -D "' + PATH_CURL + '\header-dump.txt" ' + //Fichero donde guardo el header de respuesta (es innecesario)
    ' -H "Content-Type: application/xml;charset=UTF-8" ' +  
    ' -H "Accept-Encoding: ''gzip''" ' +
    ' -H "Content-Encoding: ''gzip''" ' +   
    ' -X POST ' + URL_ALTA; //URL de alta guipuzkoa

// Uso de curl con shellexecute (función creada por un compañero mío, con la siguiente especificación)
//

Código Delphi [-]
ShellExecute(Operation:string;FileName:string;Parameters:string;Directory:string;ShowCmd:integer):Ca  rdinal

//No tengo el código fuente de esta función pero realmente lo interesante és el llenado de la variable curlCommand

Código Delphi [-]
ShellExecute(
    'open',
    'cmd',
    '/v:1 /c curl.exe ' + curlCommand +                                 
    ' > "' + pathRespuesta + '"', // Fichero xml donde guardo la respuesta
    PATH_CURL, // Path donde hay el curl.exe
    0
  );

Entiendo lo que dices pero si no esta registrada en el sistema el QR que genere no ira a ningún sitio . Y además que pasa si a posteriori esa factura resulta rechazada.

Correcto.
En Vizcaya se asume que hasta que la factura no esté enviada, el QR es inútil. Sólo podrás consultarla cuando esté enviada.
Diagamos que ese QR funcionará "mas tarde" cuando la subas...



Si la factura acaba siendo rechazada y el problema se puede solventar (por ejemplo por una caída del servidor), volverás a enviarla y no pasará nada. Si la factura es rechazada por un error en la fatura (que no puedes solventar, porque no puedes modificarla -ya has generado y firmado el TBAI-), pues la tendrás que enviar de otra forma (240 sin SG) y ese QR quedará sin efecto.


(Corregidme si alguien lo ve de otra forma)

Dudas concepto "Anular factura"
 

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

Es un concepto un tanto confuso pero creo que se puede "anular la factura" cuando se ha emitido la factura con errores y antes de mandársela al cliente, pero una vez enviada al cliente creo que mejor usar una rectificativa con devolución total. No sé si es correcto así.

En mi caso tampoco tiene cabida "anular factura".

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

Dudas concepto "Anular factura"
 

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.


A ver si contestan las otras diputaciones.

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

Problema autofirma
 

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>


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


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

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:


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

Emails Batuz DFB
 

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: [email protected].
- Consultas técnicas: [email protected].

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.

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 ([email protected]) se cierra.

Gracias por el aviso.

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/


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.

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

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... :cool::cool::D:D:D

Dudas concepto "Anular factura"
 

Muchas gracias Keys y Neftali por las respuestas.



Saludos

* 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

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


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

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?

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

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

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

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


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!

Cabeceras respuesta curl
 

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