Ahí le has dado: usuarios + complejidad = sanciones + trabajo y/o problemas para nosotros.

Me da que nuestros SAC las van a pasar canutas por tiempo indefinido ya que la experiencia me dice que, cuando el usuario no sabe que hacer o tiene un problema, a los primeros que llama es "a los del programa" ¿o no?.

LROE 240 Facturas Recibidas
 

Hola, alguien sabe dónde se puede conseguir información para el LROE 240 de las facturas recibidas?

La forma de este registro va a ser similar a las facturas emitidas, me refiero a XML por cada factura recibida, y luego el LROE y dentro de él la factura recibida en Base64.

Graciasssss

Aquí puedes descargar Esquemas, ejemplos y ficheros de explicación en formato Excel para todos, incluídas las recibidas (tanto para 140 como 240):
https://www.batuz.eus/es/documentacion-tecnica

Con fecha de Mayo del 2021.
Te los adjunto al mensaje también.

Gracias, pero no existen ejemplos como hay en las facturas emitidas.

Te falta indicar el certificado en la llamada
 

Hola:

Te falta el parámetro en la llamada que indica el certificado y el password. Añade:

-store pkcs12: (la ruta de tu certificado)
-password (el password de tu certificado)
-filter (la ruta de tu certificado)

Gracias a mounteide y tejano.

Me funcionó la autofirma

Certificados TicketBAI y primeros pasos
 

Buenas!

Pues, como otros tantos usuarios de este foro, buscando en Google preguntas relacionadas con TicketBAI empujado por la falta de reciprocidad con las haciendas forales (cosa que al parecer también es bastante común) acabé ayer en este foro. Es mi primera intervención tras leerme todo el hilo del tema detenidamente y ver que TicketBAI no es moco de pavo...

Acabo de obtener la licencia de software para pruebas y pretendo realizar algunas pruebas en Postman (con los ejemplos oficiales otorgados) pero me surge el problema de los certificados con los que estoy poco familiarizado.
En el hilo se han mencionado estas URL (sede.fnmt.gob .es/certificados/persona-fisica/obtener-certificado-software y servicios.izenpe) pero IZENPE (correspondiente Identificación electrónica de Euskadi) solicita el acceso mediante BakQ o un certificado válido y en la Sede Electrónica de moneda y timbre no sé muy bien cómo proceder a la solicitud de los certificados correctos.
Reitero que, en principio, realizaría unas pruebas con Postman para luego desarrollar la solución en un entorno .NET. Cualquier ayuda es bien recibida. Gracias de antemano!

Un saludo

Aquí te adjunto un ejemplo de una factura recibida (240) y la respuesta de Batuz.

Muchas gracias Neftali, eso es lo que necesitaba :)

Hola,

Para empezar, consíguete un certificado digital FNMT de persona física.
Para ello, sigue los pasos de aquí
Es gratis y lo obtienes fácilmente.
Lo único que puede retrasarte algo es el tema de la acreditación de identidad porque ahora todas las entidades donde se puede hacer (AEAT, Seguridad Social, etc) piden cita previa.

Una recomendación: si tienes cerca alguna oficina del Instituto Social de la Marina es donde más rápido puedes hacer la acreditación de identidad.
Puedes pedir la cita previa al llegar a la puerta porque no suele haber cola ninguna.

Saludos

Hola,

Si estás utilizando PHP, mi recomendación es que hagas la firma con PHP, no con Autofirma, que utiliza Java.
Yo estuve haciendo pruebas con Autofirma, pero cada firma tardaba varios segundos.
Con PHP viene a tardar unos 15 milisegundos.

Utilizo el script de PHP de firma que publicó en este hilo el colega Bilbur ... ¡ y va de perlas !.

Saludos

Siempre puedes utilizar para las pruebas, los certificados de producción que ha puesto Izenpe. https://www.izenpe.eus/web_corporati...ificados.shtml

Gracias por la respuesta! ¿Descargo los de desarrollo o los de producción? ¿Y luego, este certificado, en qué momento habría que hacer algo con ello?

Un saludo.

En mis pruebas yo utilizo el certificado de mi DNI electrónico, que exporté a un .pfx e instalé en el almacén de certificados de Windows.

Ya por curiosidad, ¿Lograste que te funcionara con el DNI electrónico?, yo hace tiempo estuve haciendo pruebas y no lo logré... además, aquí en el foro se me dijo que no era un tipo certificado válido. (Mirar el comentario #830 y la respuesta #832)

Aunque realmente tras leer la lista de certificados razón no les faltaba.

Éstos son los que indican:
o Certificado de persona física.
o Certificado de representante de entidad.
o Sello de empresa.
o Sello de autónomo.
o Certificado de dispositivo (debe estar censado para el obligado tributario en DFB/BFA).

Yo acabé solicitando el de persona física, pero deduzco que como no soy autónomo el servidor me dice "Pah tu casa... ¡payaso!", de todos modos si alguien está interesado en probar suerte aquí os dejo la lotería: (Solo necesitas el DNI, un email, algunos minutillos y paciencia... que en éste foro empieza a escasear :D).
https://www.sede.fnmt.gob.es/certifi...icado-con-dnie

En fin un saludo a todos, y no os desesperéis, recordad que el TicketBAI lleva al sufrimiento, el sufrimiento a la ira y la ira al lado oscuro.

¿Os suben bien las facturas a Gipuzkoa pruebas?


Subo la factura y de repente me ha empezado a salir

<Codigo>002</Codigo><Descripcion>Error: El fichero de alta TicketBAI no cumple el esquema XSD. Detalle del error: cvc-datatype-valid.1.2.1: 'codigo_HASH' is not a valid value for 'base64Binary'.</Descripcion>



Hasta hace un rato me subían bien (bueno miento me daba otro error de esquema porque me había comido las líneas de detalle...que ya lo sabía y me iba a poner con ello hoy) pero ahora siempre me devuelve este error...

Estoy haciendo pruebas de facturas emitidas LROE 240 y me da el error B4_1000025 - Operación errónea

Creo que en el apartado hay que poner el 2 y después la llamada es similar al de enviadas y a la misma dirección, pero como no hay mucha información no puedo asegurarlo.

c:\curl\1\bin\curl --insecure --cert-type P12 --cert Path_certificado:password -H "Accept-Encoding:gzip" -H "Content-Encoding:gzip" -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\":\"2\",\"inte\":{\"nif\":\"A48190839\",\"nrs\":\"TECNICAS DE REFRACTARIOS S.A.U\"},\"drs\":{\"mode\":\"240\",\"ejer\":\"2021\"}}" -v "https://pruesarrerak.bizkaia.eus/N3B4000M/aurkezpena" --data-binary "@nombre_fichero" --output salida_fichero -D c:\tmp\cabecera.txt

Gracias de antemano.

Bueno, ya parece que tengo contacto con el servicio (aunque sin ser aceptada la factura todavía, ahora pongo el problema) pero por si a alguien le sirve, mientras estoy esperando el certificado de persona física a la FNMT, he usado "sello_entidad_act.p12:IZProd2021" en POSTMAN y al menos me da respuesta. Aunque no entiendo este error cuando estoy usando un ejemplo de la hacienda foral:

<ResultadosValidacion>
<Codigo>004</Codigo>
<Descripcion>Error: Falta dato obligatorio o el dato es erróneo [CabeceraFactura:FechaExpedicionFactura].</Descripcion>
<Azalpena>Errorea: Derrigorrezko datua falta da edo datua ez da zuzena [CabeceraFactura:FechaExpedicionFactura].</Azalpena>
</ResultadosValidacion>

Esta es la fecha:

<CabeceraFactura>
<SerieFactura>B2022</SerieFactura>
<NumFactura>0100</NumFactura>
<FechaExpedicionFactura>01-01-2022</FechaExpedicionFactura>
<HoraExpedicionFactura>18:00:17</HoraExpedicionFactura>
</CabeceraFactura>

Factura con fecha anterior o actual, a TicketBAI no le gusta que factures servicios futuros.

Tip para todos: repasar vuestros sistemas de facturación y controlar la fecha para que no os ocurra lo mismo ;)

A mi me va bien, acabo de subir una factura-tbai a guipuzkoa y todo ok

No puedes enviar una factura futura :D

Ya te habían respondido. Perdón.

El DNI electrónico no deja de ser un certificado de persona física emitido por la FNMT. Lo único que hice diferente, por facilitar las pruebas, fue instalarlo en el almacén de certificados de Windows.
En el XML de la factura ponía como ID del emisor mi propio DNI y la factura era aceptada.

Buenas soy nueva por aqui, buscando como pelearme con ticketbai llegué a este foro.

Estaba teniendo problemas con el envío desde delphi, ya que en mi version no tengo "TNetHTTPClient" por lo que he estado investigando con el Idhttp (que habia leido que no se podia) y he conseguido que se envie con su certificado.
Os dejo el codigo que me ha funcionado por si a alguien más le puede ser útil.

De primeras hay que crear un componente TIdSSLIOHandlerSocketOpenSSL y otro TIdhttp en el formulario.

En el TIdSSLIOHandlerSocketOpenSSL hay que añadirle al evento OnGetPassword lo siguiente

Y luego ya el codigo del envio

Espero que os sea util :D

Yo he estado enviando facturas emitidas 240 y el valor en apa es 1.1

Hola, al realizar el envío usando curl por línea de comandos obtengo el fichero respuesta comprimido.
Cuando lo descomprimo obtengo un fichero con el mismo nombre y sin extensión. Si descomprimo ese segundo fichero ya obtengo el fichero xml de respuesta. Es como si tuviera que descomprimirlo dos veces.

El envío lo hago así :

curl -H "Accept-Encoding: gzip" -H "Content-Encoding: gzip" -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\": \"CIF\",\"nrs\": \"EMPRESA\"},\"drs\": {\"mode\": \"240\",\"ejer\": \"2021\"}}" --data-binary @LROE240.XML.gz --cert CERTIFICADO.pem --key CERTIFICADO_KEY.pem -v URL_SERVIDOR_PRUEBAS --output RESP_240.gz -D cabecera.txt

No sé si estoy haciendo algo mal en el envío (parámetro --output) o es que tengo que hacer algo más.

A mi me están subiendo bien.

Gracias por compartirlo.
Actualizado el mensaje que recopila códigos y ejemplos.

He puesto la fecha de hoy y el error ha cambiado (no me imaginaba que tuviera que ser la misma fecha que el envío). Ahora tengo:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:TicketBaiResponse xmlns:ns2="urn:ticketbai:emision">
<Salida>
<FechaRecepcion>07-07-2021 13:38:45</FechaRecepcion>
<Estado>01</Estado>
<Descripcion>Rechazado</Descripcion>
<Azalpena>Baztertua</Azalpena>
<ResultadosValidacion>
<Codigo>003</Codigo>
<Descripcion>Error: La factura no incluye líneas de detalle.</Descripcion>
<Azalpena>Errorea: TicketBAI altako fitxategiak ez du xehetasun lerrorik.</Azalpena>
</ResultadosValidacion>
</Salida>
</ns2:TicketBaiResponse>

Es que no entiendo que un fichero de ejemplo dado por ellos no sea suficiente para el sistema de validación. O que esté dejándome algo... Ideas?

Ahora estoy intentando formar un documento con el que poder probar un envío correcto a la hacienda de Gipuzkua. Si alguien dispone de un ejemplo que cumpla con todos los requerimientos por ahí, se lo agradecería (estoy trabajando con los subidos por las haciendas forales).

-- UPDATE --

En el documento de FAQ para desarrolladores he encontrado esto: "El esquema XSD de TicketBAI indica las líneas de detalle como opcionales, pero en Gipuzkoa es obligatorio indicar este dato." por lo que el error está claro (madre mía con las estructuras no comunes...).

Aunque en el esquema no sea obligatorio, en Gipuzkoa te obligan a especificar los detalles de todas las líneas.

Hola, sí hay que descomprimirlo 2 veces :confused:

Gracias por la respuesta!
Lo que me fastidia es que, aún poniendo dicho detalle y aquellos campos obligatorios en Gipuzkua, me dice lo siguiente:

<ResultadosValidacion>
<Codigo>002</Codigo>
<Descripcion>Error: El fichero de alta TicketBAI no cumple el esquema XSD. Detalle del error: cvc-complex-type.2.4.a: Invalid content was found starting with element 'DetallesFactura'. One of '{RetencionSoportada, BaseImponibleACoste, Claves}' is expected.</Descripcion>
<Azalpena>Errorea: TicketBAI altako fitxategiak ez du betetzen XSD eskema. Errorearen xehetasuna: cvc-complex-type.2.4.a: Invalid content was found starting with element 'DetallesFactura'. One of '{RetencionSoportada, BaseImponibleACoste, Claves}' is expected.</Azalpena>
</ResultadosValidacion>

Para mounteide sobre curl en nss
 

Lo uso en windows y opensuse linux ambos con ssl
De todas forma pregunta en el foro por formas de envío con o sin curl


Suerte

Vale, al parecer el orden de los campos en el XML es muy estricto con el XSD y al estar mirando entre Gipuzkoa y Bizkaia había confundido un par. Ahora no entiendo por qué, tras mostrarme todos estos errores, me vuelve al problema del certificado con el siguiente error ya conocido:

Recuerdo que he utilizado el certificado sello_entidad_act.p12:IZProd2021 obtenido de Izenpe (certificados de producción) así que no sé si se podrá usar otro certificado de esos o tener que recurrir por fuerza al de persona física solicitado (aún sin recibir) por la FNMT. :(

Buenas!

¿Qué certificado estás utilizando? Ya que veo que te funciona!

Un saludo.

Buenos días
 

Hola. En su momento, cuando consulté a los de Batuz, me comentaron que las facturas que admiten pueden tener fecha del ejercicio 2021 e incluso del 2020 (para entorno de pruebas se entiende).
Ya a partir del 2022, es cuando se podrán emitir dichas facturas de su mismo ejercicio.

Segun ellos no. :o
A nosotros nos contestaron que lo estamos haciendo todos mal (menos ellos).

:D:D:D:D

Sigo con este error y me estoy volviendo loco para que suba una factura


Estoy comparando mi xml con un zip de ejemplos que hay en el hilo y veo una diferencia,



No estoy grabando "NumSerieDispositvo" porque en la documentación de su web lo siguen poniendo en "negro" (opcional)


¿Es opcional o no?


No tengo ni idea si es por esto pero es el camino que se me ocurre de momento

Seguro que no se han dado cuenta de que el software que usan comprime automáticamente los datos si descubre el encabezado Content-Encoding: gzip, y lo digo porque las librerías que uso (Chilkat) hacen exactamente eso: comprimen y descomprimen automáticamente los datos si encuentra dicho encabezado. De hecho, al objeto html le envío datos xml y él los comprime y envía un gz, pero al recibir la respuesta, en vez de un XML recibo un GZ.

Como no podía ser de otra manera, lo primero que hice fue acceder a los datos realmente recibidos, descomprimí el gz y el resultado fue otro gz.

He optado por no decírselo a los de batuz porque hay ciertos "dioses de la programación" (entre los que se encuentran ellos según he comprobado en otras preguntas) que no reconocen un error ni ante el mismísimo Tomás de Torquemada.