Ahora si funciona, muchas gracias!!

La especificación dice concretamente que para Araba debe quitarse la barra final para el CRC, pero YA no es así.

Estas cosas son las que vuelven loco a cualquiera: Se mira una y otra vez el código asumiendo que el error es tuyo y no un cambio de especificación

No consigo guardar el GZIP correctamente!
En la cabecera veo devuelve ContentEncoding: Gzip, el fichero me dice incorrecto, statuscode: 200(OK), pero cuando voy a guardar el fichero me lo guarda con 0Kb, he probado de varias formas pero siempre me encuentro lo mismo, el array de bytes es de 0.


Alguien tiene alguna idea de que puede ser? algo no hago bien, no?

Hola,
Yo tengo un contador de lineas y en el bucle creo los elementos asi:
xmlToSign.UpdateChildContent "Factura|DatosFactura|DetallesFactura|IDDetalleFactura[" & nLinea & "]|DescripcionDetalle", "texto detalle..."

Si la respuesta dada es "Incorrecto" puede ser que el envío no haya pasado los errores de validación antes de procesar los registros.
Debes mirar las cabeceras de código de error y mensaje de error a ver qué pone.


Entiendo que para que pase este caso es cuando el error es de tipo "N3_XXXXXXX" como sugiere en la documentación de "Características técnicas para llamada a
Servicio de entradas":

Buenos días a tod@s;

¿Alguien tiene alguna noticia sobre Zuzendu? ¿Ha salido o va a salir en breve?. Hace 3 meses decían que era inminente. Ya veo que no.
Y es que claro, el período voluntario empieza en Enero, y sin el servicio Zuzendu de subsanación, no sé si va a ser muy prudente el acogerse a dicho período voluntario al no poder realizar subsanaciones de algún error en la factura emitida.

Muchas gracias
Saludos

Hace unos días tuve el mismo problema. En principio era (o es) de ellos el problema. Ya les escribimos para que por favor lo solucionasen. Fué todo a raíz de que quitaron el .gz de la respuesta.
Ahora mismo no sé cómo estará el tema pues estoy con otro proyecto, pero sí que me ocurrió igual que a tí.
El hecho es que no estaban enviando correctamente el cuerpo de la respuesta, aunque en la cabecera podía verificarse el resultado de la operación.

Una pregunta rápida sobre Vizcaya y el nuevo entorno de pruebas
¿Funcionan ahí los enlaces QR de las facturas?

Mersi

A mi me estan funcionando, excepto cuando la url contiene un +


ejemplo que funciona: https://batuz.eus/QRTBAI/?id=TBAI-B6...11&i=75&cr=152

Gracias ^\||/

Tema fiscal: Error de consolidación 5021 y 5022 Gipuzkoa
 

Esta ClaveRegimenIVAOpTranscendencia 51 (Operaciones en recargo de equivalencia) sería la apropiada cuando la empresa emisora está incluida dentro del ámbito del RE ¿No?
¿Quiere esto decir que este tipo de empresas (las incluidas en el RE) no pueden facturar RE a un cliente que también esté incluido? Si sí pueden, como yo creía, ¿Cómo hacemos para informar ese RE repercutido?

Gracias

Por estar seguro de no liarla
En el link del QR de la factura en Vizcaya hay que sustituir los "+" y "/" por "%2B" y "%2F" pero en Alava y Guizpucoa no
Es así?

Graciass

el entorno de pruebas gipuzkoa está fallando?
 

hola, hoy estamos reciviendo varios fallos al enviar facturas al entorno de pruebas de gipuzkoa y creo que son un problema de su servidor.


primero hemos recibido errores como:
1- TxHttpSenderError; nested exception is:
javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.h: PKIX path building failed: java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl could not build a valid CertPath.; internal cause is:
java.security.cert.CertPathValidatorException: The certificate issued by CN=Untrusted is not trusted; internal cause is:
java.security.cert.CertPathValidatorException: Certificate chaining error


y mas tarde ya estamos recibiendo errores como:


2- Certificado remitente incorrecto (revocado o no homologado)



en el error 1 la factura quedaba correcta, en el error 2 la factura se rechaza.


lo hemos detectado en varias instalaciones, con varios certificados


a algiuén más le pasa

Errores en Gipuzkoa Entornos Pruebas
 

Sí, desde ayer están dando varios fallos al enviar facturas al entorno de pruebas de Gipuzkoa. Les envíe un email para consultar.
Hoy seguía fallando también.

Acaban de contestar hace un momento:


TicketBai - Kontsulta teknikoak / Consultas Ténicas

Egun on, buenos días

Al parecer hay un error en la plataforma de Izenpe, por lo que el sistema está devolviendo este tipo de error.

Esta situación es puntual y se espera solucionarla a la mayor brevedad posible.


Sentimos las molestias ocasionadas.


Un saludo,

Si quieres revisar esta página, ahí hablamos del tema:
https://www.clubdelphi.com/foros/sho...=94264&page=32

Está en PHP, pero se entiende bastante bien;)

A mi durante la mañana me ha pasado en PREPRODUCCION.

Tienen problemas con la plataforma de Izenpe desde ayer, y ya veo que hoy aún no lo tienen solucionado...

recargo de equivalencia en emisor y receptor no es posible
 

Hola unomasmas, teníamos la misma duda y lo preguntamos, tanto a una asesoria como a hacienda y nos dijeron que si un empresario tiene recargo de equivalencia, cuando haga una factura a un cliente que también tenga recargo de equivalencia, tiene que tratarlo como si el cliente no lo tuviera, por lo tanto no puede cobrarle un recargo.


De esta forma a la hora de enviar ya no hay problema porque no pueden coincidir las dos cosas a la vez en una factura (recargo en el emisor y recargo en el receptor)


Saludos

Sí, a mi me han contestado que es un error que van a corregir

Muchas gracias. Eso aclara todo mi problema :-)

El SII vasco se llama LIBURUBAI
 

Instagi, la asociación de los instaladores de Guipúzcoa, organizó el pasado 22 de noviembre una sesión TicketBAI.

https://www.youtube.com/watch?v=1rRJgS2uigI&t=53s

Es de resaltar que a partir del minuto 47:52 (si, me he tragado todo el vídeo :o) dan a conocer LIBURUBAI, el siguiente invento de la familia "BAI" que va a exigir que el contribuyente envíe las facturas de compras y gastos, o sea un SII (Sistema Inmediato de Información) aplicable a Euskadi.

Otra cosa, sigue sin haber noticias de ZUZENDU.

Gracias.
Veo que también hace incapie en las rectificativas.

gracias por esto, lo estaba buscando en el foro y no sabia como hacerlo :p

Gracias Neftali. De esa página precisamente lo programé en su día y me explico.



Yo por orden hice primero Alava/Guipuzcoa y cuando los tuve terminados he empezado con Vizcaya.


Cuando estoy haciendo pruebas con Vizcaya me doy cuenta que las que me fallan son las url con +/ y digo tate...algo estará mal en la rutina que hice en su día...voy a verla y me la encuentro comentarizada por mí mismo con el comentario que ya no hacia falta (de cuando hice Alava/(Guipuzcoa) y de ahí mi pregunta porque me funcionan los links de Alava/Guipuzcoa sin hacer los cambios de carácteres cuando en Vizcaya los tengo que hacer obligatoriamente.

Soy el único al que le da error 500 Vizcaya ???
Llevo así desde ayer...

Al "nuevo entorno de pruebas" subí yo ayer perfectamente y acabo de hacer una prueba ahora también y todo ok...

Hola a todos.

Pregunté a hacienda de bizkaia que pasa con las facturas que empiezan a enviar a TBAI a partir del 01/01/2022, es decir cuando ya esten trabajando en real, si tienen que apuntar a la última del 2021 o no. y me contestan los siguiente.

Por si a alguien le sirve.

Guardar credenciales de certificado
 

Hola a todos de nuevo,
estoy haciendo pruebas a enviar facturas con mi certificado.
Para ello pongo 2 variables: la ruta donde está el certificado y la contraseña de este.
Entiendo que poner estos datos "a pelo" en el código PHP no es nada recomendable en términos de seguridad.

¿Alguno me puede dar ideas de como hacer esto seguro?

Que es el nuevo entorno?....


Yo tengo esto:
Pruebas: https://pruesarrerak.bizkaia.eus/N3B4000M/aurkezpena
Producción:https://sarrerak.bizkaia.eus/N3B4000M/aurkezpena

Error en el servicio de alta en PRE?
 

Hola,

¿Aún siguen los errores en los entornos de prueba de Araba y Gipuzkoa?

Estoy recibiendo esta respuesta y no sé a qué se debe.

Respuesta de la petición:
<ns2:TicketBaiResponse xmlns:ns2="urn:ticketbai:emision">
<Salida>
<FechaRecepcion>02-12-2021 12:33:23</FechaRecepcion>
<Estado>01</Estado>
<Descripcion>Rechazado</Descripcion>
<Azalpena>Ezetsia</Azalpena>
<ResultadosValidacion>
<Codigo>001</Codigo>
<Descripcion>Certificado remitente incorrecto (revocado o no homologado)</Descripcion>
<Azalpena>Igorlearen ziurtagiria ez da zuzena (iraungita edo homologatu gabea)</Azalpena>
</ResultadosValidacion>
</Salida>
</ns2:TicketBaiResponse>

Facturas Enero-2022
 

Buenos días, respuesta de Batuz para gente que estamos en SII y vamos a empezar con Batuz en Enero.

"Una vez que se deba cumplir con Batuz, no se deberá llevar el SII, sino que exclusivamente se va a tener que llevar el LROE (ver pregunta frecuente nº 33 - ¿El cumplimiento del sistema TicketBAI exime del cumplimiento del SII?). En el periodo de transición al nuevo sistema Batuz, para saber si un registro hay que enviarlo al SII o al LROE habrá que atender a la fecha de expedición y de recepción de las facturas, como hemos comentado en el anterior correo. Ello, con independencia de que para generar las liquidaciones del IVA haya que tener otro criterio (como tener en cuenta la fecha de operación en vez de la de expedición de la factura). "

No sabíamos bien si teníamos que enviar en base a la fecha de devengo o por la fecha de factura de factura emisión, o recepción. Por lo que dice hay que hacerlo por la fecha de emisión o recepción.

Es por si os sirve a alguno.

Saludos

Mis pruebas las hago en este. Correcto y sin problemas.

Gracias por la info ^\||/^\||/^\||/

Acordaos que este de PRODUCCIÓN lo cierran en Diciembre (creo recordar el 10 de Diciembre) y luego lo volverán a abrir.
¿Cómo volverá? Eso es una incógnita... :o

Hola Sanduzelai,

Yo también utilizo PHP.
Almaceno el certificado digital ya convertido a sus componentes (sin necesidad de contraseña) en un fichero para el certificado público y otro fichero para el certificado privado.
Por supuesto, en un directorio oculto (empieza por ".") y en una ruta fuera de los directorios de la web y a la que no se puede acceder desde navegador.
Todo ello, en un servidor mío, en el que se realizan los procesos de creación y firma del XML y al que no tiene acceso físico ni remoto el cliente.

Saludos

Buenas, te han respondido algo al respecto? El tema de redondeos es un desmadre. Como dijeron mas arriba, la mayoría de nuestros clientes ponen el precio con IVA. Y el mismo se calcula en cada factura redondeo mas o menos.


La "solución" de darnos 8 decimales para ese campo me parece, la peor solución posible que pudieron encontrar. Porque no informar los % que tiene cada item?

Tener php y certificado en un servidor que tengas que hacer la petición con usuario y contraseña, con Curl es curl - u usuario:contraseña.. La contraseña del certificado en este caso ya la puedes tener en el php a pelo.
Si lo tienes en local puedes hacer algunos truquillos para confundir pero no es demasiado seguro, también puedes usar algún software que cree una unidad oculta con contraseña que manejes desde el programa, pero no lo he usado y no se bien como va.

Hola marianolc,

Hice la consulta a TicketBAI de Gipuzkoa el 29 de octubre.
Como no me respondían (mientras sí me respondieron a otras consultas), volví a reiterar la consulta el 19 de noviembre.
Y ahí seguimos, sin contestación.

No se les puede consultar por teléfono y, por email, si no lo ven claro, no responden.
Y eso cuando no responden con criterio diferente en Gipuzkoa y a Álava (como ya me ha ocurrido en otro tema)

Tampoco es que en Bizkaia vayan mucho mejor:
- Cosas que funcionan un día, al día siguiente no van
- Los servidores parece que en algunos momento también se toman vacaciones o puentes
- Cierran y abren los entornos de prueba al voleo sin explicar y justificar las razones
- Se están alargando los plazos desde que se presenta la solicitud de un software garante hasta que responden algo (del último presentado el 18 de noviembre, todavía ni una información al respecto)

Y lo que iba a ser un sistema común de las tres Diputaciones (auspiciado y promocionado por el Gobierno Vasco) se ha ido separando y ahora se necesitan modificaciones de software para cada territorio.
Sin contar las promesas pendientes como el Servicio Zuzendu en Gipuzkoa (las otras Diputaciones parece que ni han pensado en ello).
Ahora Gipuzkoa suelta el globo sonda de un posible servicio LiburuBAI (que tiene pinta de ser otra LROE-Batuz versión gipuzkoana)

Eso sí, charlas, presentaciones y promesas de deducciones y subvenciones muchas, pero soluciones, unificaciones e información puntual a los desarrolladores ... cero patatero.

Yo alucino con la falta de seriedad que están teniendo las tres Diputaciones Forales con un tema tan importante como éste.
Realmente, están quedando a la altura del betún.
No me esperaba tan bajo nivel de eficiencia.

Saludos

Perfectamente detallado. Creo que es un pensamiento que tenemos todos. Nos están tomando el pelo y les seguimos el juego por no estar organizados nosotros, incluidos los técnicos de la administración que, me temo, que también tienen que sufrir las presiones de sus superiores políticos...

Hola unomasmas,

Totalmente de acuerdo contigo.
Los responsables de este caos son los Diputados de Hacienda de cada uno de los tres territorios vascos.
Y el Diputado General de cada territorio por haber mantenido en el cargo al Diputado de Hacienda después de este desastre.

La cantidad de horas perdidas en empresas para intentar implementar soluciones para un TicketBAI, cambiante y heterogéneo, es inmensa.
Y me supongo que los técnicos de las administraciones (y de las empresas subcontratadas) también lo estarán pasando mal viendo como su prestigio como profesionales serios se va al garete por culpa de decisiones políticas caprichosas y sin fundamento.

Cuando parecía que Euskadi iba a ser la punta de lanza en desarrollar soluciones informáticas serias (y unificadas) para atajar el tema del fraude fiscal, nos han obsequiado con una cadena de desvaríos, cambios injustificados y contínuos retrasos que nos han dejado alucinados.
¡¡¡ Viva la improvisación, el desconcierto y la ineptitud !!!

Pero no, seguro que no veremos ninguna dimisión.
Y, al final, seguro que las culpas de todo las tenemos los informáticos que estamos sufriendo el tema.

Saludos

Esto es como todos los curros. Habrá gente que trabaja, gente que no y gente que se pone las medallas. El marrón nos lo comemos los que empecemos los que vengan después ya tendrán todo frito y cocido con mil herramientas.
Hay una cosa que no entiendo. Por que cojones hacienda no Dan un programa que se ejecute en segundo plano que haga todo el tema de envíos aunque dejemos todos los ficheros en alguna carpeta. Y que lo instalen y comprueben ellos tanto dejarnos responsabilidades.
Algo así como el tem de tpv datáfonos.