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)

keys 11-02-2022 08:47:01

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?

Sistel 11-02-2022 09:13:24

Cita:

Empezado por keys (Mensaje 545323)
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?

Hola keys,

Puedes utilizar el servicio NTP (en UDP puerto 123).
Por ejemplo, para España, los servidores es.pool.ntp.org

Saludos

Neftali [Germán.Estévez] 11-02-2022 10:08:14

Aquí, en este hilo hemos hablado del tema:
https://www.clubdelphi.com/foros/showthread.php?t=1502


Nosotros en algunos casos lo que hacemos es cogerlo del servidor de Base de Datos, no del equipo local.
No se si esta opción la puedes aplicar a tu sistema.

Código SQL [-]
select GETDATE()

PepCat 11-02-2022 10:29:10

También hay la opción de obtener la fecha y hora oficial de Sede Electrónica de la Fábrica Nacional de Moneda y Timbre - Real Casa de la Moneda

Código:

https://www.sede.fnmt.gob.es/delegate/fechaoficial?nocache
que devuelve la fecha en JSON:

Código:

{
        "millis": 1644571217305
}

y se puede convertir en TDateTime con

Código Delphi [-]

uses System.DateUtils;

function jsDateToDelphiDate(millis: int64): TDateTime;
begin
    var UnixSeconds: Integer := Round(millis / MSecsPerSec);
    Result := UnixToDateTime(UnixSeconds, False);
end;

thinkows 11-02-2022 11:27:53

Zuendu Alavés
 
1 Archivos Adjunto(s)
Cachondos no, lo siguiente :


Buenos días,

Con el ánimo de seguir colaborando con los desarrolladores de software :D:D TicketBAI y de cara a mejorar la calidad de los datos que nos envían:eek::eek:, les hacemos llegar un documento donde se recogen algunos errores frecuentes y una serie de recomendaciones para subsanar los mismos.

Cualquier sugerencia o aportación no duden en trasladárnosla.

Un saludo.

keys 11-02-2022 11:43:57

Gracias por lo de la Fecha/Hora.

Ahora tengo otra cosa que no se si os ha pasado. A la hora de firmar los xml, pedimos al usuario que seleccione el certificado para firmarlo. Este se firma correctamente con ese certificado (ya que es valido para firmar). Pero luego a la hora de enviarlo a hacienda, lo rechaza por que el certificado de firma no es válido (Es de dispositivo y no esta dado de alta en hacienda, el certificado es de otra persona, etc....).

Hemos mandado una sugerencia a hacienda para que pongan un servicio web para indicar si un certificado es válido para una persona/empresa en concreto. Pero sólo responden con buenas palabras, pero na de na. ¿se os ocurre alguna otra forma?

Sistel 11-02-2022 12:00:02

Cita:

Empezado por thinkows (Mensaje 545329)
Cachondos no, lo siguiente :


Buenos días,

Con el ánimo de seguir colaborando con los desarrolladores de software :D:D TicketBAI y de cara a mejorar la calidad de los datos que nos envían:eek::eek:, les hacemos llegar un documento donde se recogen algunos errores frecuentes y una serie de recomendaciones para subsanar los mismos.

Cualquier sugerencia o aportación no duden en trasladárnosla.

Un saludo.

Hola thinkows y resto de colegas sufridores.

Acabo de contestar el email pidiendo que publiquen una aclaración:

Cita:

Hola,

Gracias por la información.

Como sugerencia, en la página 3 del documento enviado, donde indica:
- ImporteTotal de línea debe ir siempre con IVA (salvo si es exenta o no sujeta)
Debería indicar:
- ImporteTotal de línea debe ir siempre con IVA (y RE en caso de llevarlo) (salvo si es exenta o no sujeta)
A raíz de una consulta que hicimos a Álava y a Gipuzkoa, cada una de las dos administraciones respondió de forma diferente sobre si ese campo de ImporteTotal de la línea de detalle debe o no incluir el RE (en el caso de que el destinatario esté en dicho régimen).
Álava nos indicó que sí debía ir incluído (aunque en la tabla de estructura de TicketBAI no se indica).
Gipuzkoa nos indicó que no debía ir incluído.
Posteriormente, Gipuzkoa rectificó su criterio y nos lo comunicó, en posterior email.

Por ello, sería de gran interés para todos los desarrolladores de software garante TicketBAI que en el documento de recomendaciones que nos han enviado se rectificase el texto indicado.

Y que también se tenga en cuenta la rectificación en próximas versiones de la tabla de la estructura del fichero TicketBAI.

Un cordial saludo
Saludos

Sistel 11-02-2022 12:06:35

Cita:

Empezado por keys (Mensaje 545331)
...Pero sólo responden con buenas palabras, pero na de na. ¿se os ocurre alguna otra forma?

¿Tal vez apostándose en la puerta e increpando a los responsables?:(

La verdad es que ante las decisiones unilaterales, absurdas y a traición que van tomando sin consultar lo más mínimo a los perjudicados (desarrolladores de software garante) no podemos ejercer ningún tipo de presión.

Nos ignoran olímpicamente y no nos queda más que aguantar.

keys 11-02-2022 12:24:34

Cita:

Empezado por Sistel (Mensaje 545335)
¿Tal vez apostándose en la puerta e increpando a los responsables?:(

La verdad es que ante las decisiones unilaterales, absurdas y a traición que van tomando sin consultar lo más mínimo a los perjudicados (desarrolladores de software garante) no podemos ejercer ningún tipo de presión.

Nos ignoran olímpicamente y no nos queda más que aguantar.

Cuando decia si se os ocurre otra forma, es la de como comprobar los certificados no como comunicarnos con hacienda. Ya que creo que de eso ya estamos todos de acuerdo de como hacerlo :rolleyes:

tejano 11-02-2022 12:58:59

Cita:

Empezado por keys (Mensaje 545338)
Cuando decia si se os ocurre otra forma, es la de como comprobar los certificados no como comunicarnos con hacienda. Ya que creo que de eso ya estamos todos de acuerdo de como hacerlo :rolleyes:

Hola Keys, yo tengo metido en la Base de datos el usuario y certificado que puede usar, de forma que no puede utilizar otro.

Esto sería un tema del admisnitrador del sistema, de forma que si se equivoca el administrador del sistema en poner un usuario u otro creo que ya no es competencia nuestra.

Espero que te sirve la idea.

Saludos

keys 11-02-2022 13:34:09

Cita:

Empezado por tejano (Mensaje 545340)
Hola Keys, yo tengo metido en la Base de datos el usuario y certificado que puede usar, de forma que no puede utilizar otro.

Esto sería un tema del admisnitrador del sistema, de forma que si se equivoca el administrador del sistema en poner un usuario u otro creo que ya no es competencia nuestra.

Espero que te sirve la idea.

Saludos

Gracias, más o menos estamos haciendo lo mismo. Pero claro hasta que no hace el envío no sabemos si el certificado con el que firma es correcto o no para hacienda.

ermendalenda 11-02-2022 14:58:01

Por si os viene bien la información.
Problema con un cliente y me he enterado a las 2 semanas. Le pongo última actualización a mediados de diciembre y hace un Par de semanas tiene corte de luz y el equipo le pregunta si quiere continuar el arranque o restaurar.
El cliente sin saber realmente lo que está haciendo, a él le parece bien, por que en su casa le ha pasado y se arregló, restaura y como aparentemente sigue funcionando bien pues sigue adelante, hasta que como estoy haciendo seguimiento miro el xml y veo algo raro... Joder vaya tela.
Veo el mismo fallo que tenía y al mirar la versión que grabó en el xml tb veo que es la anterior.
Vaya tela. No se cuantas cosas nos va a pasar. Deberíamos hacer un manual de posibles incidencias no contempladas. Vaya desastre.

Sistel 11-02-2022 16:36:36

Cita:

Empezado por keys (Mensaje 545343)
Gracias, más o menos estamos haciendo lo mismo. Pero claro hasta que no hace el envío no sabemos si el certificado con el que firma es correcto o no para hacienda.

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

ermendalenda 11-02-2022 18:26:12

Cita:

Empezado por keys (Mensaje 545343)
Gracias, más o menos estamos haciendo lo mismo. Pero claro hasta que no hace el envío no sabemos si el certificado con el que firma es correcto o no para hacienda.

Hay formas de probarlo

keys 14-02-2022 08:17:52

Cita:

Empezado por ermendalenda (Mensaje 545352)
Hay formas de probarlo

Cuales? Me tienes en ascuas?

keys 14-02-2022 08:21:33

Cita:

Empezado por Sistel (Mensaje 545348)
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

Buena solución, pero para nosotros que se trata de intalaciones en los equipos del cliente (con muchas instalaciones), sería un poco complicado.

Sistel 14-02-2022 08:54:46

Hola,

Os comenté, hace unos días, que les escribí a TicketBAI de Álava a raíz de su último email con recomendaciones sobre el software:

Cita:

...
Como sugerencia, en la página 3 del documento enviado, donde indica:
- ImporteTotal de línea debe ir siempre con IVA (salvo si es exenta o no sujeta)
Debería indicar:
- ImporteTotal de línea debe ir siempre con IVA (y RE en caso de llevarlo) (salvo si es exenta o no sujeta)
A raíz de una consulta que hicimos a Álava y a Gipuzkoa, cada una de las dos administraciones respondió de forma diferente sobre si ese campo de ImporteTotal de la línea de detalle debe o no incluir el RE (en el caso de que el destinatario esté en dicho régimen).
Álava nos indicó que sí debía ir incluído (aunque en la tabla de estructura de TicketBAI no se indica).
Gipuzkoa nos indicó que no debía ir incluído.
Posteriormente, Gipuzkoa rectificó su criterio y nos lo comunicó, en posterior email.

Por ello, sería de gran interés para todos los desarrolladores de software garante TicketBAI que en el documento de recomendaciones que nos han enviado se rectificase el texto indicado.

Y que también se tenga en cuenta la rectificación en próximas versiones de la tabla de la estructura del fichero TicketBAI.
Me acaban de contestar:
Cita:

Hemos revisado lo que nos indicas y lo vamos a corregir lo antes posible para volverlo a publicar lo antes posible.
Muchas gracias por su aportación y tener el detalle de comunicárnoslo.
Esperemos ver pronto esas, y otras, rectificaciones.

Saludos

nuevo1234 14-02-2022 09:14:48

Pasar a Base64 antes de firmar
 
Hola a todos,

Me ha parecido leer en el foro que se debe pasar el fichero XML a base 64 anter de firmar. Aparece eso publicado en algún sitio?? o es solo una recomendación para evitar problemas con los caracteres "raros".

Entiendo que si es una obligación hacerlo así debe estar claramente puublicado para que pase las validaciones de la firma al presentar el fichero.

Gracias de antemano. Es que la firma me preocupa bastante.

Neftali [Germán.Estévez] 14-02-2022 11:27:31

Cita:

Empezado por nuevo1234 (Mensaje 545363)
Me ha parecido leer en el foro que se debe pasar el fichero XML a base 64 anter de firmar. Aparece eso publicado en algún sitio?? o es solo una recomendación para evitar problemas con los caracteres "raros".
Entiendo que si es una obligación hacerlo así debe estar claramente puublicado para que pase las validaciones de la firma al presentar el fichero.


Sí hay que hacerlo así en el caso de Vizcaya. En Álava y Guipuzcoa no hay que pasar a base64.
Aquí tienes los pasos (resumen comprimido) para Vizcaya en el caso de los libro 140/240.En la documentación está explicado.
Documento_ Batuz_LROE_Especificaciones_Envío_Masivo_V1_0_7.pdf

Sistel 14-02-2022 12:04:19

Cita:

Empezado por nuevo1234 (Mensaje 545363)
Hola a todos,

Me ha parecido leer en el foro que se debe pasar el fichero XML a base 64 anter de firmar. Aparece eso publicado en algún sitio?? o es solo una recomendación para evitar problemas con los caracteres "raros".

Entiendo que si es una obligación hacerlo así debe estar claramente puublicado para que pase las validaciones de la firma al presentar el fichero.

Gracias de antemano. Es que la firma me preocupa bastante.

Hola nuevo1234,

Como muy bien te ha explicado nuestro colega Neftali [Germán.Estévez], hay que pasarlo sólo a base64 en el caso del envío a Bizkaia.
Pero ojo, siempre hay que firmar previamente el XML (igual para las 3 provincias)

Saludos

ermendalenda 14-02-2022 14:20:20

Cita:

Empezado por keys (Mensaje 545360)
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 14-02-2022 16:42:40

Cita:

Empezado por Sistel (Mensaje 545348)
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 14-02-2022 17:10:10

Cita:

Empezado por keys (Mensaje 545323)
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 14-02-2022 17:18:54

Cita:

Empezado por misteradrian (Mensaje 545384)
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 14-02-2022 17:26:33

Que hacer con los bufs/vies que no cumplen
 
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 14-02-2022 17:41:27

Cita:

Empezado por ermendalenda (Mensaje 545387)
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 14-02-2022 18:07:35

Esquema de Errores y sus soluciones
 
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 14-02-2022 18:24:24

Cita:

Empezado por Sistel (Mensaje 545388)
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 14-02-2022 18:33:02

Cita:

Empezado por joselugrk (Mensaje 545390)
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 14-02-2022 18:54:10

Esquema de Errores y sus soluciones
 
Cita:

Empezado por misteradrian (Mensaje 545393)
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 14-02-2022 22:18:50

Cita:

Empezado por joselugrk (Mensaje 545394)
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 15-02-2022 09:07:13

Entorno de pruebas Alaba
 
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 15-02-2022 13:24:59

Cita:

Empezado por thinkows (Mensaje 545094)
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 ....:mad::mad::mad:

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

Neftali [Germán.Estévez] 15-02-2022 15:15:08

Cita:

Empezado por thinkows (Mensaje 545398)
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 15-02-2022 16:46:13

Cita:

Empezado por Neftali [Germán.Estévez] (Mensaje 545413)
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 15-02-2022 16:47:56

Cita:

Empezado por Sistel (Mensaje 545396)
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 15-02-2022 18:01:02

Pues sigo igual
 
Cita:

Empezado por Neftali [Germán.Estévez] (Mensaje 545413)
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 15-02-2022 18:03:15

Gracias por probar
 
Cita:

Empezado por misteradrian (Mensaje 545416)
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 15-02-2022 18:26:49

Cita:

Empezado por thinkows (Mensaje 545419)
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 15-02-2022 18:39:55

Pruebas Alava
 
Cita:

Empezado por misteradrian (Mensaje 545420)
¿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^\||/


La franja horaria es GMT +2. Ahora son las 01:59:13.

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