|
|
 |
 |
|
Paypal | |
|
FTP | |
|
CCD | |
|
Buscar | |
|
Trucos | |
|
Trabajo | |
|
Foros | |
|
|||||||
| Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Buscar | Temas de Hoy | Marcar Foros Como Leídos |
 |
|
|
Herramientas | Buscar en Tema | Desplegado |
|
|
|
#1
09-08-2022
|
||||
|
||||
|
Cita:
La respuesta es: Código:
HTTP/1.1 200 OK Date: Tue, 09 Aug 2022 06:45:24 GMT Server: Apache/2.4.16 (Unix) OpenSSL/1.0.1e-fips X-Powered-By: Servlet/3.0 Content-Length: 861 Content-Type: application/xml;charset=utf-8 Content-Language: en-US No se si se refiere a:
Código:
Fichero RESPUESTA_1.GZ
(que contiene texto XML ya que el Content-Type de la respuesta es application/xml;charset=utf-8)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:TicketBaiResponse xmlns:ns2="urn:ticketbai:emision">
<Salida>
<FechaRecepcion>09-08-2022 09:04:18</FechaRecepcion>
<Estado>01</Estado>
<Descripcion>Rechazado - ALTA PREP</Descripcion>
<Azalpena>Baztertua - ALTA PREP</Azalpena>
<ResultadosValidacion>
<Codigo>017</Codigo>
<Descripcion>El tamaño del mensaje no es válido: ha superado el tamaño permitido. Le recomendamos que eliminen espacios, tabulaciones u otro tipo de caracteres innecesarios.</Descripcion>
<Azalpena>Mezuaren tamaina ez da zuzena: baimendutako tamaina gainditu du. Espazioak, tabulazioak edo beharrezkoak ez diren bestelako karaktereak ezabatzea gomendatzen dizugu.</Azalpena>
</ResultadosValidacion>
</Salida>
</ns2:TicketBaiResponse>
Os dejo el BAT con el que estoy trabajando hasta ahora. Código:
@echo off
cd C:\Users\Usuario\AppData\Local\Temp\
rem HEADER del mensaje que enviamos.
set CAB1=-H "Accept-Encoding: gzip"
set CAB2=-H "Content-Encoding: gzip"
set CAB3=-H "Content-Type: application/xml;charset=UTF-8"
set CAB4=-H "eus-bizkaia-n3-version: 1.0"
set CAB5=-H "eus-bizkaia-n3-content-type: application/xml"
rem JSON de la cabecera con datos de la presentacion
set CAB6=-H "eus-bizkaia-n3-data: { \"con\":\"LROE\", \"apa\":\"1.1\", \"inte\":{ \"nif\":\"B95642500\", \"nrs\":\"ECOTHERM ENERGY SL\", \"ap1\":\"\", \"ap2\":\"\" }, \"drs\":{ \"mode\":\"240\", \"ejer\":\"2022\" } } "
rem Fichero que contiene el XML de presentacion comprimido en formato GZ.
set FICHERO=--data-binary "@Presentacion_1.gz"
rem Certificado
rem set CERT_TYPE=--cert-type PEM
set CERT=--cert Certificado_crt.pem
set CERT_KEY=--key Certificado_key.pem
rem URL a donde enviamos el mensaje. (Alta y Baja en produccion o en pruebas)
set URL=-v https://tbai-z.prep.gipuzkoa.eus/sarrerak/alta
rem Fichero con el mensaje de respuesta. Puede ser un mensaje de error en formato XML (<ns2:TicketBaiResponse xmlns:ns2="urn:ticketbai:emision">).
set FICHERORESPUESTA=--output Respuesta_1.gz
rem La primera linea sera el codigo de error. Por ejemplo "HTTP/1.1 200 OK".
rem Tambien devolvera el yipo de contenido de la respuesta. Por ejemplo "Content-Type: application/xml;charset=utf-8".
set HEADERRESPUESTA=-D Respuesta_1.txt
cls
.\curl.exe -v --insecure %CAB1% %CAB2% %CAB3% %CAB4% %CAB5% %CAB6% %FICHERO% %CERT_TYPE% %CERT% %CERT_KEY% %URL% %FICHERORESPUESTA% %HEADERRESPUESTA%
pause
|
|
#2
09-08-2022
|
||||
|
||||
|
Cita:
Código PHP:
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi  P.D: Más tiempo dedicado a la pregunta=Mejores respuestas.
|
|
#3
09-08-2022
|
||||
|
||||
|
Cita:
Lo he comparado con lo que genero yo y son iguales, excepto la parte de la firma, donde la estructura es un poco diferente. Como parece que lo aceptan, no voy a mirar eso mucho más. De todos modos, me refería al envío del Libro de Registro. Esto lo formo con una parte JSON en la cabecera Código:
{
"con":"LROE",
"apa":"1.1",
"inte":{
"nif":"B95642500",
"nrs":"ECOTHERM ENERGY SL",
"ap1":"",
"ap2":""
},
"drs":{
"mode":"240",
"ejer":"2022"
}
}
Código:
<?xml version="1.0"?>
<lrpjfecsgap:LROEPJ240FacturasEmitidasConSGAltaPeticion xmlns:lrpjfecsgap="https://www.batuz.eus/fitxategiak/batuz/LROE/esquemas/LROE_PJ_240_1_1_FacturasEmitidas_ConSG_AltaPeticion_V1_0_2.xsd">
<Cabecera>
<Modelo>240</Modelo>
<Capitulo>1</Capitulo>
<Subcapitulo>1.1</Subcapitulo>
<Operacion>A00</Operacion>
<Version>1.0</Version>
<Ejercicio>2022</Ejercicio>
<ObligadoTributario>
<NIF>B95642500</NIF>
<ApellidosNombreRazonSocial>ECOTHERM ENERGY SL</ApellidosNombreRazonSocial>
</ObligadoTributario>
</Cabecera>
<FacturasEmitidas>
<FacturaEmitida>
<TicketBai>PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiPz48VDpUaWNrZXRC
YWkgeG1sbnM6VD0idXJuOnRpY2tldGJhaTplbWlzaW9uIj4KCTxDYWJlY2VyYT4K
...
PjwvZHM6T2JqZWN0PjwvZHM6U2lnbmF0dXJlPjwvVDpUaWNrZXRCYWk+
</TicketBai>
</FacturaEmitida>
</FacturasEmitidas>
</lrpjfecsgap:LROEPJ240FacturasEmitidasConSGAltaPeticion>
|
|
#4
09-08-2022
|
|||
|
|||
|
Duda sobre encadenamiento
Saludos a todos y gracias por vuestra ayuda.
La duda que no me ha quedado clara leyendo los post es si, tras enviar el fichero firmado, nos devuelve un mensaje de error. 1. Si el error es de datos, creo que el fichero se acepta y queda registrado. (¿y que hay que hacer en este caso?) 2. Si el error es por otra causa y es rechazado (error en el formato o la firma por ejemplo) ¿queda registrado y su signaturevalue es válida para la siguiente factura? Supongo que no, pero no me ha quedado claro que ocurre en este caso. El proceso que voy a seguir para realizar los envios es este, por si a alguien le sirve de ayuda y por si veis que hay algo que corregir: Primero creo el fichero XML desde la factura sin los datos de encadenamiento y luego los recupero con otro programa que hace lo siguiente: 1. Lee el fichero XML 2. Busca la ultima factura procesada 3. Guarda los datos de encadenamiento 4. Firma el fichero 5. Envía el fichero 6. Si el resultado es correcto a. Actualiza la ultima factura b. Imprimo o envío la factura c. Muevo el fichero xml a otro directorio Si el resultado es incorrecto a. Borro el fichero XML b. Notifico el error 7. Inicio el proceso con el siguiente fichero Gestionar el encadenamiento desde la misma aplicación de facturación, en entornos con múltiples terminales era una pesadilla, por eso la idea de crear una cola y gestionarla con otra aplicación. No se si ya existe algo así Muchas gracias a todos.
|
|
#5
11-08-2022
|
|||
|
|||
|
Cita:
Teóricamente según TBAI, el software garante tiene que ser capaz de emitir una factura (firmarla e imprimir su QR) sin necesidad de conectarse con ellos (que era el principal problema que había al principio). En mi caso, hemos desligado la generación, firmado e impresión de la factura del envío que va por un servicio de cola que únicamente se encarga de enviar las facturas que va generando el software y notifica posibles errores para luego poder solventarlos de manera manual, que es la única manera que hemos encontrado ya que automatizar algo es prácticamente imposible ...
|
|
#6
11-08-2022
|
|||
|
|||
|
Cita:
Yo hago algo parecido: un programa crea el xml en una carpeta compartida en la red y luego otro programa gestiona la cola firmando, enviando el fichero y luego comunicando al programa de facturación el resultado. La idea de borrar el xml es para eliminarlo de la lista de ficheros pendientes de firmar y enviar. Tras hacerlo, notifico a la factura que ha habido un error y que hay que volver a generar el fichero y, por tanto, no puede imprimirse. Después de borrar el fichero, el programa continúa con la cola. Esto te permite seguir trabajando y te asegura que el QR impreso siempre es correcto. Lo peor que puede pasar es que los servidores TBai no funcionen y los clientes se tengan que ir sin el tiquet o esperarse un rato. La diferencia que veo con tu método es que se corre el riesgo de que el el fichero sea rechazado y no ingrese en su sistema. Estarías imprimiendo un QR que apunta a una URL inexistente y se estaría rompiendo el encadenamiento real.
|
|
#7
11-08-2022
|
|||
|
|||
|
Cita:
Creo que el procedimiento, como ya han indicado más de una vez los de TicketBAI, no es esperar a conseguir que el sistema informático de Hacienda Foral dé el visto bueno al XML firmado y enviado. Se trata de: - Recopilar los datos para emitir la factura (la factura no está emitida, realmente, hasta que no se ha obtenido el XML firmado) - Crear el XML - Firmarlo (ahora es cuando la factura está realmente emitida) - Recopilar los datos de códigos TBAI y QR a partir de los datos del XML firmado - Imprimir o enviar la factura al destinatario con los códigos TBAI y QR. - Y, a continuación, enviar el XML firmado a Hacienda. Que Hacienda dé por bueno o no el XML es independiente: la factura ya está emitida. Si Hacienda da por bueno el XML recibido, genial. Si Hacienda no lo da por bueno, dependiendo del tipo de código que retorne, habrá que hacer una u otra cosa. Pero la factura ya está emitida y va a misa. Saludos
|
|
#8
12-08-2022
|
|||
|
|||
|
Cita:
Deberías de diseñar el sistema para que fuese autónomo de manera que si hubiese un problema de conexión (los servidores de IZEMPE se caen o están "en mantenimiento", o la conexión a inet se va por avería), el software pueda seguir emitiendo facturas con encadenamiento, QR e identificador tbai. Eso fue una de las cosas que más me costó entender en un principio ...
|
|
| Herramientas | Buscar en Tema |
| Desplegado | |
|
|
Temas Similares
|
||||
| Tema | Autor | Foro | Respuestas | Último mensaje |
| SII -Nuevo sistema de la Agencia Tributaria española de envío de datos vía Webservice | newtron | Internet | 3716 | 19-01-2026 20:01:34 |
| Como utilizar la ayuda del nuevo Sistema Operativo | gluglu | Humor | 3 | 24-09-2007 09:39:05 |
| Aplicacion Agencia De Viajes | ArdiIIa | Varios | 9 | 20-01-2007 16:49:53 |
| El Vasco Aguirre | Al González | La Taberna | 5 | 26-05-2006 09:22:28 |
| Microsoft ha lanzado su nuevo sistema operativo | DarkByte | Humor | 0 | 25-01-2004 09:21:14 |
 |
|
![Avatar de Neftali [Germán.Estévez]](image.php?u=3561&dateline=1185205509)
![Neftali [Germán.Estévez] is online now](images/statusicon/user_online.gif)
Modo Híbrido
