Foros Club Delphi

Foros Club Delphi (https://www.clubdelphi.com/foros/index.php)
-   Internet (https://www.clubdelphi.com/foros/forumdisplay.php?f=3)
-   -   TICKET BAI (TicketBAI); Nuevo sistema de la Agencia Tributaria del Pais Vasco (https://www.clubdelphi.com/foros/showthread.php?t=94264)

HerensugeBeltz 07-07-2021 11:56:29

Cita:

Empezado por
<ResultadosValidacion>
<Codigo>004</Codigo>
<Descripcion>Error: Falta dato obligatorio o [B
el dato es erróneo[/b] [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>

No puedes enviar una factura futura :D

HerensugeBeltz 07-07-2021 11:57:34

Cita:

Empezado por HerensugeBeltz (Mensaje 541625)
No puedes enviar una factura futura :D

Ya te habían respondido. Perdón.

HerensugeBeltz 07-07-2021 12:01:57

Cita:

Empezado por Eric Mtz (Mensaje 541617)
Ya por curiosidad, ¿Lograste que te funcionara con el DNI electrónico?

Éstos son los que indican:
o Certificado de persona física.
...

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.

sEngine 07-07-2021 12:59:20

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

Código:

procedure TFMain.LHandlerGetPassword(var Password: string);
begin
  Password := 'IZProd2021';
 end;

Y luego ya el codigo del envio

Código:

  RequestBody := TFileStream.Create('tempBAi_firmado.xml', fmOpenRead);

  LHandler.SSLOptions.SSLVersions := [sslvTLSv1_2];
  LHandler.SSLOptions.CertFile := 'sello_entidad_act.p12';
  LHandler.SSLOptions.KeyFile := 'sello_entidad_act.p12';
  LHandler.ongetpassword := LHandlerGetPassword;
  idhttp_fac := TIdhttp.Create();
  idhttp_fac.IOHandler:=LHandler;
  idhttp_fac.Request.ContentType := 'application/xml';

  Respuesta := idhttp_fac.Post('h t t p s://tbai-prep.egoitza.gipuzkoa.eus/WAS/HACI/HTBRecepcionFacturasWEB/rest/recepcionFacturas/alta',RequestBody);

Espero que os sea util :D

JVelezGarcia 07-07-2021 13:01:23

Cita:

Empezado por tejano (Mensaje 541621)
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 ...

Gracias de antemano.

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

JVelezGarcia 07-07-2021 13:13:06

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.

Neftali [Germán.Estévez] 07-07-2021 13:18:18

Cita:

Empezado por edari (Mensaje 541620)
¿Os suben bien las facturas a Gipuzkoa pruebas?


A mi me están subiendo bien.

Neftali [Germán.Estévez] 07-07-2021 13:21:16

Cita:

Empezado por sEngine (Mensaje 541628)
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.

Espero que os sea util :D

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

b4aronDeLaBirr4 07-07-2021 13:40:59

Cita:

Empezado por b4aronDeLaBirr4 (Mensaje 541622)
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>

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?

b4aronDeLaBirr4 07-07-2021 13:54:34

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

HerensugeBeltz 07-07-2021 15:05:17

Cita:

Empezado por b4aronDeLaBirr4 (Mensaje 541633)
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?

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

Código:

<DescripcionFactura>Servicios Hotel</DescripcionFactura>
    <DetallesFactura>
                <IDDetalleFactura>
                    <DescripcionDetalle>Línea factura 1</DescripcionDetalle>
                                <Cantidad>1</Cantidad>
                                <ImporteUnitario>110.00</ImporteUnitario>
                                <Descuento>0.00</Descuento>  <==== este sí es opcional
                                <ImporteTotal>121.00</ImporteTotal>
                </IDDetalleFactura>
    </DetallesFactura>


tejano 07-07-2021 15:42:47

Cita:

Empezado por JVelezGarcia (Mensaje 541630)
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.

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

b4aronDeLaBirr4 07-07-2021 15:47:25

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>

bilbur 07-07-2021 15:57:15

Para mounteide sobre curl en nss
 
Cita:

Empezado por mounteide

Hola Bilbur.

Ahora me ha firmado correctamente. Muchísimas gracias.

Ahora me funciona todo perfectamente, en entorno en windows. Sin embargo cuando lo subo a un servidor centos me da error al enviarlo por curl

curl command - Unable to load client cert -8018

Esto es debido a el servidor tiene una versión de curl que no es openssl es nss.

A ti por casualidad te ha dado este problema? Sabes como pasar con curl los parámetros para que la firma sea con nss?

Muchísimas gracias y saludos.


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

b4aronDeLaBirr4 07-07-2021 17:26:01

Cita:

Empezado por b4aronDeLaBirr4 (Mensaje 541638)
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>

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:

Código:

<Codigo>007</Codigo>
<Descripcion>Error: Certificado remitente no válido para emisor factura.</Descripcion>

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

b4aronDeLaBirr4 08-07-2021 08:49:05

Buenas!

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

Un saludo.

JoseLeeTo 08-07-2021 08:59:42

Buenos días
 
Cita:

Empezado por b4aronDeLaBirr4 (Mensaje 541633)
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?


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.

Neftali [Germán.Estévez] 08-07-2021 09:32:05

Cita:

Empezado por tejano (Mensaje 541637)
Hola, sí hay que descomprimirlo 2 veces :confused:


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

:D:D:D:D

edari 08-07-2021 09:53:53

Cita:

Empezado por edari (Mensaje 541620)
¿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...


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

Galaxian 08-07-2021 09:57:24

Cita:

Empezado por Neftali [Germán.Estévez] (Mensaje 541659)
Segun ellos no. :o
A nosotros nos contestaron que lo estamos haciendo todos mal (menos ellos).

:D:D:D:D

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.


La franja horaria es GMT +2. Ahora son las 11:38:10.

Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi