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

[keys]

Yo estoy enviando sin problemas. Lo del código QR yo creo que no lo tienen operativo. Por cierto estan retornando en el estado "0", no "00". Por lo menos a mi.

[iMia]

Empezado por keys

Yo estoy enviando sin problemas. Lo del código QR yo creo que no lo tienen operativo. Por cierto estan retornando en el estado "0", no "00". Por lo menos a mi.

Sí, retornan 0 en vez de 00, y la fecha del mensaje está en formato que no cumple su xsd... está en formato yyyy-MM-dd cuando debería ser dd-MM-yyyy . Ya lo comenté ayer (http://www.clubdelphi.com/foros/show...postcount=1507), cuando hice la prueba...

[iMia]

Empezado por iMia

Sí, retornan 0 en vez de 00, y la fecha del mensaje está en formato que no cumple su xsd... está en formato yyyy-MM-dd cuando debería ser dd-MM-yyyy . Ya lo comenté ayer (http://www.clubdelphi.com/foros/show...postcount=1507), cuando hice la prueba...

Respondo con este mensaje para que lo podáis ver y seguir.
Me han contestado de Araba.

Buenas tardes Mia,

Hemos revisado los 2 apuntes que has realizado respecto a los campos FechaRecepcion y Estado y tenéis razón en vuestra apreciación. 
Ya está corregido e implantado en el entorno de Pruebas para que no vuelva a darse estos errores.

Respecto al envió repetido de la misma factura es correcto que te responda "01 - Rechazada". 
El código de estado de respuesta HTTP que devolvemos cuando detectamos que una factura es duplicada es “400 - Bad request”. 

En el XML de respuesta has tenido que recibir el siguiente mensaje de error:
  Código: 005
  Descripción: Fichero de alta TicketBAI ya está registrado en el sistema

Los 2 primeros temas de la fecha y el estado, Corregidos... Bien, han reaccionado bien...
El que no veo claro es la respuesta 400 si está duplicada... ¿por que es una bad request?. Eso debería ser si el mensaje que se envia está mal formado o el xml del alta está mal, si el mensaje enviado está corrupto... hasta si el certificado es incorrecto (que en este caso debería contestar otra cosa, pero bueno, se puede asumir,... ) ¿pero bad request? ¿porque si la resquest es correcta?... eso es una excepcion de comunicación, no de que en su sistema ya tienen los datos que les estoy indicando... simplemente tendrían que hacer como Gipuzkoa, devolver el mensaje que ya existe pero nunca un bad request... no lo entiendo...

De verdad que a veces pensamos con otra cosa en vez de con la cabeza...

saludos...


PD:
Tambien me han contestado sobre el tema del QR

Buenas tardes Mia,

La Consulta del QR, aún no tenemos en funcionamiento en el entorno de pruebas, está en fase de desarrollo.

En cuanto se encuentre disponible, lo comunicaremos a través de nuestra página web
 donde publicaremos la URL correspondiente a dicha consulta en el entorno de Pruebas https://web.araba.eus/es/hacienda/ticketbai

No obstante lo anterior, esperamos tenerlo disponible a lo largo de las próximas semanas.

Un saludo.

[ermendalenda]

Empezado por iMia

Respondo con este mensaje para que lo podáis ver y seguir.
Me han contestado de Araba.

Buenas tardes Mia,

Hemos revisado los 2 apuntes que has realizado respecto a los campos FechaRecepcion y Estado y tenéis razón en vuestra apreciación. 
Ya está corregido e implantado en el entorno de Pruebas para que no vuelva a darse estos errores.

Respecto al envió repetido de la misma factura es correcto que te responda "01 - Rechazada". 
El código de estado de respuesta HTTP que devolvemos cuando detectamos que una factura es duplicada es “400 - Bad request”. 

En el XML de respuesta has tenido que recibir el siguiente mensaje de error:
  Código: 005
  Descripción: Fichero de alta TicketBAI ya está registrado en el sistema

Los 2 primeros temas de la fecha y el estado, Corregidos... Bien, han reaccionado bien...
El que no veo claro es la respuesta 400 si está duplicada... ¿por que es una bad request?. Eso debería ser si el mensaje que se envia está mal formado o el xml del alta está mal, si el mensaje enviado está corrupto... hasta si el certificado es incorrecto (que en este caso debería contestar otra cosa, pero bueno, se puede asumir,... ) ¿pero bad request? ¿porque si la resquest es correcta?... eso es una excepcion de comunicación, no de que en su sistema ya tienen los datos que les estoy indicando... simplemente tendrían que hacer como Gipuzkoa, devolver el mensaje que ya existe pero nunca un bad request... no lo entiendo...

De verdad que a veces pensamos con otra cosa en vez de con la cabeza...

saludos...


PD:
Tambien me han contestado sobre el tema del QR

Buenas tardes Mia,

La Consulta del QR, aún no tenemos en funcionamiento en el entorno de pruebas, está en fase de desarrollo.

En cuanto se encuentre disponible, lo comunicaremos a través de nuestra página web
 donde publicaremos la URL correspondiente a dicha consulta en el entorno de Pruebas https://web.araba.eus/es/hacienda/ticketbai

No obstante lo anterior, esperamos tenerlo disponible a lo largo de las próximas semanas.

Un saludo.

Efectivamente se llama bageza.
Error 400: cualquier error de rechazo pde la conexión/petición por parte del servidor que te rechaza que no esté contemplado.

[iMia]

Empezado por ermendalenda

Efectivamente se llama bageza.
Error 400: cualquier error de rechazo pde la conexión/petición por parte del servidor que te rechaza que no esté contemplado.

Es que no se coge por ningún sitio...
Si ellos han recibido y leído mi request para saber que la factura ya existe, no puede nunca un bad request...
La comunicación ha ido bien a nivel de protocolo... por lo tanto es 200 no es 400...

Bueno, les he escrito exponiendo los motivos por los que no debería ser un error 400.

A ver qué contestan, por que cambiarlo,, no tengo esperanzas que lo cambien... ya van muy pillados en tiempo como para ponerse a cambiar algo que "les" funciona (aunque sin lógica)..

[tejano]

Por si alguien no lo ha recibido. Comunicación de Batuz DFB

Kaixo,
Dakizuen bezala, Batuz-en sustatutako borondatezko aldia 2022ko urtarrilaren 1ean hasiko da sistemari atxikitzen zaizkien pertsona eta erakundeentzat. Ondorioz, data horretan irekiko da Eragiketa Ekonomikoen Erregistro Liburuaren (EEEL) esparru erreala, Foru Ogasunaren web aplikaziorako nahiz Bizkaiko Foru Aldundiko sarrera masiboen zerbitzuaren bidez fitxategi informatikoak automatikoki partekatzeko.
Oraingoan, jakinarazten dizuegu urriaren erdialdetik aurrera eta abenduaren hasierara arte, proba gisa irekiko dela EEEL-ren esparru erreal hori. Helburu bikoitza dauka: batetik, zergadunak sistema berriarekin ohitzea; bestetik, softwarea garatzen duten enpresek probak egin ahal izatea sarrera masiboen zerbitzuaren esparru errealaren gainean. Edonola ere, aldi horretan egiten diren oharrak proba gisa erregistratuko dira, eta ez dute zergetan transzendentziarik izango.

Hori dela eta, https://pruesarrerak.bizkaia.eus sarreren zerbitzuaren oraingo proba esparrua 2021eko irailaren 30ean itxiko da.

Bidalketa masiboen sistemaren probak egiteko, honako esparru hauek egongo dira eskuragarri:
 EEEL-ren esparru erreala proba eran, ekoizpen ziurtagiri errealekin. URLa https://sarrerak.bizkaia.eus izango da, eta, esan bezala, 2021eko urriaren erdialdetik abenduaren hasierara arte eskuragarri egongo da.
 Proben esparru berria. Jasotako iradokizunei jarraikiz, proba ziurtagiriekin funtzionatuko du, eta azaroaren erdialdetik aurrera egongo da eskuragarri.
Esparru horiei buruzko informazio zehatza Batuz-en webgunean (www.batuz.eus) argitaratuko da, eta webgune horretako Berritasunen atalaren bidez nahiz postontzi honetatik bidalitako mezu elektroniko baten bidez jakinaraziko da.

Como sabéis, el periodo voluntario incentivado de Batuz se iniciará el 1 de enero de 2022 para las personas y entidades que se adhieran al sistema. En consecuencia, esta fecha supondrá la apertura del entorno real del Libro Registro de Operaciones Económicas (LROE), tanto para la aplicación web de la Hacienda Foral como para el intercambio automático de ficheros informáticos a través del servicio de entradas masivas de la Diputación Foral de Bizkaia.
Os escribimos ahora para informaros de que, a partir de mediados de octubre y hasta principios de diciembre, se abrirá a modo de pruebas este entorno real del LROE, con el doble objetivo de que, por un lado, las personas contribuyentes se familiaricen con el nuevo sistema, y, por otro lado, las empresas desarrolladoras de software puedan realizar pruebas sobre el entorno real del servicio de entradas masivas. En todo caso, las anotaciones que se realicen durante este periodo se registrarán a modo de prueba y no tendrán trascendencia tributaria.

Por ello, el entorno de pruebas actual del servicio de entradas https://pruesarrerak.bizkaia.eus se cerrará el próximo 30 de septiembre de 2021.

Para la realización de pruebas del sistema de envíos masivos estarán disponibles los siguientes entornos:
 Entorno real del LROE a modo de pruebas con certificados reales de producción. La URL será https://sarrerak.bizkaia.eus y, como hemos dicho, estará disponible a partir de mediados de octubre hasta principios de diciembre de 2021.
 Nuevo entorno de pruebas que, atendiendo a las sugerencias recibidas, funcionará con certificados de pruebas y estará disponible a partir de mediados de noviembre.
La información detallada de estos entornos se publicará en la web de Batuz (www.batuz.eus) y se notificará tanto a través del apartado de Novedades de dicha web como a través de un correo enviado desde este buzón.
Agur bat.

[keys]

Pero no dicen si estara operativo todo el libro 140/240 o solo la parte de TicketBAI

[iMia]

Empezado por iMia

Es que no se coge por ningún sitio...
Si ellos han recibido y leído mi request para saber que la factura ya existe, no puede nunca un bad request...
La comunicación ha ido bien a nivel de protocolo... por lo tanto es 200 no es 400...

Bueno, les he escrito exponiendo los motivos por los que no debería ser un error 400.

A ver qué contestan, por que cambiarlo,, no tengo esperanzas que lo cambien... ya van muy pillados en tiempo como para ponerse a cambiar algo que "les" funciona (aunque sin lógica)..

Pues me han contestado, que:

En relación al error “400 Bad Request” estamos revisando lo que nos comenta y procederemos a solventarlo para modificar su comportamiento.

En cuanto se encuentre disponible en el entorno de Pruebas, les informaremos personalmente dirigiéndonos a este correo desde el que nos escriben.

Sólo puedo decir que chapó por ellos...