TICKET BAI (TicketBAI); Nuevo sistema de la Agencia Tributaria del Pais Vasco

[ermendalenda]

Empezado por keys

Cuales? Me tienes en ascuas?

JEJE.
Lo de que coincidan los cifs y que no hayan caducado upongo que ya lo sabes puse una función en php.
Para el resto solo hacer una consulta con el Curl que también puse sobre la existencia y correspondencia de un cif y nombre en hacienda(ya que pide que la consulta sea con certificado) y si el certificado es incorrecto, por estar revocado o caducado lo vas a saber. No recuerdo el error. Con eso ya tienes todo controlado previamente al envío de ticket

[misteradrian]

Empezado por Sistel

Hola keys,

El tema de utilizar certificados del cliente tiene sus problemas:
- Tienes acceso a dicho certificado por lo que podrías utilizarlo de forma fraudulenta (por ejemplo, para hacer "gestiones bancarias" en su nombre)
- Si el certificado es revocado, por cualquier razón, tú no te enteras.
- Cuando solicita renovación del certificado, se le revoca antes de tener el nuevo.
- Tienes que vigilar que esté en vigor cada vez que va a hacer una nueva factura o un nuevo envío
- ...

Yo en lugar de utilizar el certificado digital del cliente, utilizo para firmar los XML del cliente un certificado digital mío (que controlo en mi propio servidor).
Marco el campo EmitidaPorTercerosODestinatario como S y solucionado.
Y para enviar los XML también utilizo mi certificado.
Por supuesto, antes el cliente tiene que firmar un acuerdo por el que me autoriza a crear, firmar y enviar las facturas a Hacienda Foral en su nombre.
Y registro la representación en la correspondiente Hacienda Foral.

Y juego con dos certificados (FNMT e Izenpe).
Cuando tengo que renovar el que estoy utilizando, lo cambio por el otro mientras estoy haciendo dicha renovación (con su correspondiente revocación del antiguo)

Saludos

Yo lo utilizo tal cual sólo que con un sello de empresa que compramos de IZENPE.

[ermendalenda]

Empezado por keys

Hola a todos.

Nuestra aplicación no deja camiar la fecha de emisión de las facturas, coge la fecha del sistema y no se puede cambiar, ya que en teoria eso es lo que dice hacienda. Pero nos hemos encontrado con algunos listillos que lo que hacen es cambiar la fecha del sistema para hacer una factura anterior a la fecha del día. No se si os habrá pasado a alguno.

¿Alguien conoce algún servicio de internet que devuelva la fecha/hora del día?

Sí tb lo puse
Hay un webservice que te devuelve la hora y fecha de cualquier país. Lo tengo puesto antes de la emisión de cada factura. Lo único que si no hay Internet no hay comprobación

[Sistel]

Empezado por misteradrian

Yo lo utilizo tal cual sólo que con un sello de empresa que compramos de IZENPE.

Hola misteradrian,

Ojo cuando haya que renovarlo, porque normalmente (al menos los certificados normales) al pedir la renovación se revoca el anterior.
Y hasta que no tienes instalado el nuevo, estás en un limbo sin certificado válido.

Saludos

[ermendalenda]

Perdón por el título, puto corrector
*bufs=nifs
Me están llegando a los comercios clientes que quieren factura de distintos países y los datos que me aportan no cumplen con los nifs españoles ni con el vies(2 letras del país extranjero) por muchas vueltas que le doy nada, si le añado las 2 letras se salen de los 9 caracteres y además no están en el vies.
De verdad que esto es un lío, ahora que le digo al cliente, que no puedo darle factura por que no cumple normativa?
Ya lo he comentado con uno y me dijo que esta harto de pedir facturas con ese identificador.
Vaya tela, digo yo, tenemos que pelearnos con los clientes?, sin además tenelo ni claro. Si el cliente nos dice que está bien, quien somos nosotros., o al menos eso es lo que piensa el cliente.

[Sistel]

Empezado por ermendalenda

Perdón por el título, puto corrector
*bufs=nifs
Me están llegando a los comercios clientes que quieren factura de distintos países y los datos que me aportan no cumplen con los nifs españoles ni con el vies(2 letras del país extranjero) por muchas vueltas que le doy nada, si le añado las 2 letras se salen de los 9 caracteres y además no están en el vies.
De verdad que esto es un lío, ahora que le digo al cliente, que no puedo darle factura por que no cumple normativa?
Ya lo he comentado con uno y me dijo que esta harto de pedir facturas con ese identificador.
Vaya tela, digo yo, tenemos que pelearnos con los clientes?, sin además tenelo ni claro. Si el cliente nos dice que está bien, quien somos nosotros., o al menos eso es lo que piensa el cliente.

Hola ermendalenda,

¿Qué tal si en el nodo IDType utilizas el valor 06 (Otro documento probatorio) de la tabla L2 (Tipos de identificación en el país de residencia)?
Así ya podrías poner como documento en ID (Número de identificación en el país de residencia) cualquier valor hasta 20 caracteres (da igual que sea el pasaporte, número de seguridad social, carnet de conducir, dni, nif o lo que sea de su país).

Por supuesto, esta solución sólo es válida en el caso de que el emisor y el destinatario no tengan que hacer declaración de operaciones intracomunitarias por estas operaciones en su país.

Ya me contarás si te vale.

Saludos

[joselugrk]

Hola, quería preguntaros si existe algún documento en BATUZ que hable de como actuar cuando se ha producido un envío de ficheros XML y algunos han sido rechazados.

Por ejemplo, de 10 ficheros XML enviados todos menos uno han sido aceptados. El envío es PARCIALMENTECORRECTO.

Por ejemplo, el error es que el NIF no es correcto (B4_2000001).
¿Qué tendría que realizar? ¿Anular esa factura y crear una nueva?

¿Existe algún documento en el que indique como se deber actuar ante los errores de envío?

NOTA: A partir de ahora validaré los NIF antes de generar la factura.

Saludo y muchas gracias,
Joselu

[ermendalenda]

Empezado por Sistel

Hola ermendalenda,

¿Qué tal si en el nodo IDType utilizas el valor 06 (Otro documento probatorio) de la tabla L2 (Tipos de identificación en el país de residencia)?
Así ya podrías poner como documento en ID (Número de identificación en el país de residencia) cualquier valor hasta 20 caracteres (da igual que sea el pasaporte, número de seguridad social, carnet de conducir, dni, nif o lo que sea de su país).

Por supuesto, esta solución sólo es válida en el caso de que el emisor y el destinatario no tengan que hacer declaración de operaciones intracomunitarias por estas operaciones en su país.

Ya me contarás si te vale.

Saludos

Ole gracias. Después de tu respuesta he caído que esto ya se había preguntado. A ver si lo pongo rápido para no volver a caer. Gracias Sistel.

[misteradrian]

Empezado por joselugrk

Hola, quería preguntaros si existe algún documento en BATUZ que hable de como actuar cuando se ha producido un envío de ficheros XML y algunos han sido rechazados.

Por ejemplo, de 10 ficheros XML enviados todos menos uno han sido aceptados. El envío es PARCIALMENTECORRECTO.

Por ejemplo, el error es que el NIF no es correcto (B4_2000001).
¿Qué tendría que realizar? ¿Anular esa factura y crear una nueva?

¿Existe algún documento en el que indique como se deber actuar ante los errores de envío?

NOTA: A partir de ahora validaré los NIF antes de generar la factura.

Saludo y muchas gracias,
Joselu

Siempre y cuando quieras generar NIF de pruebas utilizaba esta página.
https://generadordni.es/#home

En caso de ser ya dni´s en un entorno real. Utiliza algún validador en el lenguaje de programación que estés utilizando y adaptalo a los posibles errores.

[joselugrk]

Empezado por misteradrian

Siempre y cuando quieras generar NIF de pruebas utilizaba esta página.
https://generadordni.es/#home

En caso de ser ya dni´s en un entorno real. Utiliza algún validador en el lenguaje de programación que estés utilizando y adaptalo a los posibles errores.

Ok, de acuerdo. Validar el NIF. Pero si pasa, ¿Qué se debe realizar? y con el resto de errores ¿Cómo debemos funcionar?. Es decir, hemos creado un XML firmado y ha sido rechazado. ¿Cómo lo soluciono?

Creo que es muy importante conocer la forma de actuar en caso de un posible error de envío.

Muchas gracias,
Joselu

[Sistel]

Empezado por joselugrk

Ok, de acuerdo. Validar el NIF. Pero si pasa, ¿Qué se debe realizar? y con el resto de errores ¿Cómo debemos funcionar?. Es decir, hemos creado un XML firmado y ha sido rechazado. ¿Cómo lo soluciono?

Creo que es muy importante conocer la forma de actuar en caso de un posible error de envío.

Muchas gracias,
Joselu

Hola Joselu,

En el caso de Bizkaia (BATUZ), los ficheros XML TicketBAI firmados, de facturas y anulaciones, se envían en el subcapítulo 1.1 (Ingresos con factura con software garante TicketBAI) del modelo 140 (personas físicas) o modelo 240 (personas jurídicas)

En el caso de no ser admitido algún fichero TicketBAI de factura por contener errores, se debe presentar en en el capítulo 1.2 (Ingresos con factura sin software garante TicketBAI de los mismos modelos (140 y 240).

Saludos

[thinkows]

Buenos días, el entorno de pruebas de Alaba sigue caído ? ... devuelve 006, soy yo que tengo algún otro problema ??? Hay algún hilo que no he leído ?

Url Alta en pruebas :
https://pruebas-ticketbai.araba.eus/...I/v1/facturas/


Gracias.

[misteradrian]

Empezado por thinkows

Buenos días, os funcionan correctamente las pruebas en Bizkaia ? ayer enviaba sin problemas y hoy :

response status code: 200 OK
response body:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:LROEPJ240FacturasEmitidasConSGAltaRespuesta xmlns:ns2="https://www.batuz.eus/fitxategiak/batuz/LROE/esquemas/LROE_PJ_240_1_1_FacturasEmitidas_ConSG_AltaRespuesta_V1_0_1.xsd">
<Cabecera>
<Modelo>240</Modelo>
<Capitulo>1</Capitulo>
<Subcapitulo>1.1</Subcapitulo>
<Operacion>A00</Operacion>
<Version>1.0</Version>
<Ejercicio>2022</Ejercicio>
<ObligadoTributario>
<NIF>A99802704</NIF>
<ApellidosNombreRazonSocial>4YUFFiRkH5hP4QDzEtm4npiQMxeHe5</ApellidosNombreRazonSocial>
</ObligadoTributario>
</Cabecera>
<Registros>
<Registro>
<Identificador>
<IDFactura>
<SerieFactura>F1</SerieFactura>
<NumFactura>202100923</NumFactura>
<FechaExpedicionFactura>28-01-2022</FechaExpedicionFactura>
</IDFactura>
</Identificador>
<SituacionRegistro>
<EstadoRegistro>Incorrecto</EstadoRegistro>
<CodigoErrorRegistro>B4_2000070</CodigoErrorRegistro>
<DescripcionErrorRegistroES>La firma no cumple los requisitos de la política de firma TicketBAI.(Atributo política de firma incorrecto. - (10641))</DescripcionErrorRegistroES>
<DescripcionErrorRegistroEU>Sinadurak ez ditu betetzen TicketBAI sinaduraren politikaren baldintzak.(Atributo política de firma incorrecto. - (10641))</DescripcionErrorRegistroEU>
</SituacionRegistro>
</Registro>
</Registros>
</ns2:LROEPJ240FacturasEmitidasConSGAltaRespuesta>

Con su certificado y no he modificado nada desde ayer ....

Me está pasando lo mismo ahora en el entorno de pruebas con Gipuzkoa sin yo haber cambiado nada.
Increible

[Neftali [Germán.Estévez]]

Empezado por thinkows

Buenos días, el entorno de pruebas de Alaba sigue caído ? ... devuelve 006, soy yo que tengo algún otro problema ??? Hay algún hilo que no he leído ?

A mi me está pasando lo mismo.
URL: https://pruebas-ticketbai.araba.eus/...I/v1/facturas/

[misteradrian]

Empezado por Neftali [Germán.Estévez]

A mi me está pasando lo mismo.
URL: https://pruebas-ticketbai.araba.eus/...I/v1/facturas/

Yo acabo de tirar hacia alava y me va bien.
Dejo la URL del QR de comprobación.

https://pruebas-ticketbai.araba.eus/...=250.00&cr=034

[joselugrk]

Empezado por Sistel

Hola Joselu,

En el caso de Bizkaia (BATUZ), los ficheros XML TicketBAI firmados, de facturas y anulaciones, se envían en el subcapítulo 1.1 (Ingresos con factura con software garante TicketBAI) del modelo 140 (personas físicas) o modelo 240 (personas jurídicas)

En el caso de no ser admitido algún fichero TicketBAI de factura por contener errores, se debe presentar en en el capítulo 1.2 (Ingresos con factura sin software garante TicketBAI de los mismos modelos (140 y 240).

Saludos

Hola Sistel,

Correcto. Gracias por tu respuesta.
He visto que en el documento de preguntas frecuentes. La pregunta 160 habla de ello. La adjunto

---------------------------------------------------------------------
CATEGORÍA: TicketBAI - Cuestiones comunes
Nº PREGUNTA: 160
PREGUNTA: ¿Qué hay que hacer si la anotación del fichero TicketBAI ha sido rechazada al enviarse a
Hacienda?
RESPUESTA:
Si la anotación del fichero TicketBAI (subcapítulo 1.1. del LROE) ha sido rechazada al
enviarse a Hacienda por incumplimiento de esquema o de validaciones, debe operarse
del siguiente modo:
En todo caso, la información de la operación debe remitirse por el capítulo 1.2,
superando las correspondientes validaciones. Si hay información que no puede
llegar por incumplimiento de las validaciones, debe llegar la información más
relevante.
•
Si hay que modificar alguno de los contenidos de la factura a que se refiere el
artículo 15 del Reglamento de facturación: Se deberá generar además una
factura rectificativa, generando el fichero TicketBAI correspondiente y
remitiendo la información por el subcapítulo 1.1.
•
Cuando se trate de una operación incorrecta: deberá realizarse además una
anulación de la operación original mediante el subcapítulo 1.2. Y, si procede,
deberá generarse una nueva factura, generando un fichero TicketBAI y
remitiendo la información por el subcapítulo 1.1

---------------------------------------------------------------------

[thinkows]

Empezado por Neftali [Germán.Estévez]

A mi me está pasando lo mismo.
URL: https://pruebas-ticketbai.araba.eus/...I/v1/facturas/

Ahora mismo sigo igual

Guipuzkoa y Bizkaia sin problemas !!!

Gracias Germán.

[thinkows]

Empezado por misteradrian

Yo acabo de tirar hacia alava y me va bien.
Dejo la URL del QR de comprobación.

https://pruebas-ticketbai.araba.eus/...=250.00&cr=034

Yo sigo igual, gracias por probar compañero

[misteradrian]

Empezado por thinkows

Yo sigo igual, gracias por probar compañero

¿Puedes poner el error que os da en el XML de vuelta?
Ó ¿simplemente no os conecta?

[thinkows]

Empezado por misteradrian

¿Puedes poner el error que os da en el XML de vuelta?
Ó ¿simplemente no os conecta?

Aquí lo pongo :

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><ns2:TicketBaiResponse xmlns:ns2="urn:ticketbai:emision"><Salida><FechaRecepcion>15-02-2022 18:06:18</FechaRecepcion><Estado>1</Estado><Descripcion>Rechazado</Descripcion><Azalpena>Ezetsia</Azalpena><ResultadosValidacion><Codigo>006</Codigo><Descripcion>El servicio de recepción no está disponible. Repita la operación más tarde</Descripcion><Azalpena>Jasotze zerbitzua ez dago erabilgarri. Errepikatu eragiketa geroago</Azalpena></ResultadosValidacion></Salida></ns2:TicketBaiResponse>

Esto ya me pasa con Alava desde la semana pasada y creo que a Sistel está igual que uo.

Gracias