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