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

[YellowStone]

Empezado por Noe277

Esto es un problema de ellos habrá que decirles, el caso es que creo que esta en el redondo.
1 x 1,446 también da error pero 1, 44 lo hace bien. 1,45 también hace mal el problema es como redondean.

El problema está en pedir que la etiqueta <ImporteTotal> venga con el impuesto incluido y luego seguramente validan que la suma de los "importes totales" sea igual al importe de la factura, y eso es un error (creo que por parte de ellos, Álava en este caso, porque la misma factura con los mismos importes Guipúzcoa la da por válida). No se puede sacar el IVA por cada línea de la factura, porque el IVA se debe calcular sobre el importe final de la factura, y no línea a línea, porque por los redondeos va a descuadrar si o si en muchos casos. ¿Qué hacemos? ¿Metemos una línea de detalle con el posible descuadre del centimillo?

[thinkows]

Empezado por YellowStone

El problema está en pedir que la etiqueta <ImporteTotal> venga con el impuesto incluido y luego seguramente validan que la suma de los "importes totales" sea igual al importe de la factura, y eso es un error (creo que por parte de ellos, Álava en este caso, porque la misma factura con los mismos importes Guipúzcoa la da por válida). No se puede sacar el IVA por cada línea de la factura, porque el IVA se debe calcular sobre el importe final de la factura, y no línea a línea, porque por los redondeos va a descuadrar si o si en muchos casos. ¿Qué hacemos? ¿Metemos una línea de detalle con el posible descuadre del centimillo?

Yo lo consulté y esto me respondieon :

Buenos días Jordi


Hemos revisado el contenido de su fichero y los importes son correctos.

El error se está dando en las líneas en las que el importe es menor de 1 euro. Al trabajar con importes pequeños y despreciar los decimales se ha provocado esta situación.

Vamos a solucionarlo en breve.

Cuando lo hayamos solucionado se lo comunicaremos.

Gracias por su colaboración

Un saludo

[edari]

Estoy mirando el resto de ficheros del LROE y se me caen los pantalones abajo


modelo 240.



altas Facturas recibidas
altas Intracomunitarias
altas Cobros

altas Pagos
altas Importes superiores a 6000 euros


(y creo que no me afectan más)


Entiendo que estos ficheros no hay que hacer transformarlos en base64 si no que se generan directamente, se comprimen y se suben (en mi caso con el curl) desde ya la gestión contable de nuestros programas.



En el zip de ejemplos que tiene Batuz no veo ejemplos de estos. Están en algún otro sitio?






Gracias

[keys]

Empezado por edari

Estoy mirando el resto de ficheros del LROE y se me caen los pantalones abajo


modelo 240.



altas Facturas recibidas
altas Intracomunitarias
altas Cobros

altas Pagos
altas Importes superiores a 6000 euros


(y creo que no me afectan más)


Entiendo que estos ficheros no hay que hacer transformarlos en base64 si no que se generan directamente, se comprimen y se suben (en mi caso con el curl) desde ya la gestión contable de nuestros programas.



En el zip de ejemplos que tiene Batuz no veo ejemplos de estos. Están en algún otro sitio?






Gracias

Se envían como tu dices, no hay ejemplos. Yo solo he encontrado de emitidas.

[josevalle]

Empezado por edari

Estoy mirando el resto de ficheros del LROE y se me caen los pantalones abajo


modelo 240.

altas Facturas recibidas
altas Intracomunitarias
altas Cobros

altas Pagos
altas Importes superiores a 6000 euros


(y creo que no me afectan más)

Entiendo que estos ficheros no hay que hacer transformarlos en base64 si no que se generan directamente, se comprimen y se suben (en mi caso con el curl) desde ya la gestión contable de nuestros programas.

En el zip de ejemplos que tiene Batuz no veo ejemplos de estos. Están en algún otro sitio?

Gracias

Hola!:

Aunque he visto 3 mensajes con ejemplos de uso de curl ninguno me funciona, me da error en el certificado. ¿Puedes publicar ejemplos de como utilizas curl?. Muchas gracias.

[oscarperez-1980]

Pero el envío de eso no es obligatorio, no?

[josevalle]

Empezado por oscarperez-1980

Pero el envío de eso no es obligatorio, no?

Yo uso xbase++ y tengo un programa del año 1985. Lo pude adaptar al sii usando curl gracias a un mensaje en el foro de Velneo. Y ahora pretendo hacer lo mismo. He probado con certificado de persona física usando el ejemplo de este foro, no se como probar con el certificado de equipo. Seguiré probando y, consciente de mis limitados conocimientos, es esperando que alguien publique otro ejemplo con curl.

[oscarperez-1980]

A ver si alguien de aquí pone algún ejemplo...

[josevalle]

Empezado por josevalle

Hola!:

Aunque he visto 3 mensajes con ejemplos de uso de curl ninguno me funciona, me da error en el certificado. ¿Puedes publicar ejemplos de como utilizas curl?. Muchas gracias.

Hola, lo estaba probando con la versión de Curl que viene con W10. Ahora he bajado de la web y con los mismos certificados funcionan perfectamente.

[edari]

De vuelta por aquí tras un impas
Me estoy empezando a meter con el tema del Zuzendu (Alava) y tengo algunas dudas
Sabéis si hay por algún sitio ejemplo de los xml (subsansar, modificar y anulación)? Lo de tirar del XSD para "sacar" el fichero nunca se me dió bien...
Los ficheros Zuzendu de Alava y Guipúzcoa son iguales? Tiene pinta de que sí pero quiero estar seguro
Cuando tenga preparar los ficheros para subirlos sería con un "curl" más o menos configurado como lo hacemos para subir las facturas?

¿Qué diferencia hay entre el fichero anular una factura desde el Zuzendu de anulación (-<T:SubsanacionAnulacionTicketBAI xmlns:T="urn:ticketbai:zuzendu-baja">) y anularla desde el xml de anulación que ofrecía el propio Ticket bai (<T:AnulaTicketBai xmlns:T="urn:ticketbai:anulacion">)?



Gracias de nuevo

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

Empezado por edari

¿Qué diferencia hay entre el fichero anular una factura desde el Zuzendu de anulación (-<T:SubsanacionAnulacionTicketBAI xmlns:T="urn:ticketbai:zuzendu-baja">) y anularla desde el xml de anulación que ofrecía el propio Ticket bai (<T:AnulaTicketBai xmlns:T="urn:ticketbai:anulacion">)?

Diría que uno es anular un Alta de factura (desde TBAI), y el otro anular una Subsanación (desde Zuzendu).
(Es lo que me dice la lógica, si no es así comentadlo)

[thinkows]

Empezado por edari

De vuelta por aquí tras un impas
Me estoy empezando a meter con el tema del Zuzendu (Alava) y tengo algunas dudas
Sabéis si hay por algún sitio ejemplo de los xml (subsansar, modificar y anulación)? Lo de tirar del XSD para "sacar" el fichero nunca se me dió bien...
Los ficheros Zuzendu de Alava y Guipúzcoa son iguales? Tiene pinta de que sí pero quiero estar seguro
Cuando tenga preparar los ficheros para subirlos sería con un "curl" más o menos configurado como lo hacemos para subir las facturas?

¿Qué diferencia hay entre el fichero anular una factura desde el Zuzendu de anulación (-<T:SubsanacionAnulacionTicketBAI xmlns:T="urn:ticketbai:zuzendu-baja">) y anularla desde el xml de anulación que ofrecía el propio Ticket bai (<T:AnulaTicketBai xmlns:T="urn:ticketbai:anulacion">)?



Gracias de nuevo

Hola, te adjunto en el zip ejemplos de cada tipo, yo he enviado a Guipuzkoa y Alava sin problemas.
Un Saludo

[espinete]

Hola a todos/as...

Por fin he podido generar, firmar, enviar, (consultar) y anular facturas a las tres delegaciones. El problema que me encuentro ahora es con Bizkaia, que permite enviar varias facturas en el mismo envío, en lugar de una a una como Gipuzkoa y Araba.

Si envío varias facturas de golpe en el mismo envío/fichero... ¿cómo obtengo el Nº, serie y firma de la factura anterior si aún no he recibido respuesta hasta que se envíen todas?

Lo explico mejor...

En un mismo fichero, envío 100 facturas de golpe. Si en "SignatureValueFirmaFacturaAnterior", etc. debo poner la firma de la factura anterior, nº, serie... que se haya enviado correctamente... ¿cómo sé si ésta efectivamente se envió correctamente, si aún no he obtenido la respuesta de este envío masivo?

Obviamente puedo incluir ese dato, y el nº, serie, etc. de la factura anterior independientemente de que ésta se haya enviado correctamente o no, y esperar al resultado final y actuar en consecuencia (marcándolas como "no enviadas").
Pero claro, desde que falle un envío (por ejemplo, cuando vaya por la 25), las otras 75 darán todas error. No veo lógico hacerlo así.

Otra opción es enviarlas de una en una y listo, como con Gipuzkoa y Araba, pero no sé si será una opción elegante teniendo en cuenta que han habilitado el envío masivo por algún motivo, no?

Espero haberme explicado bien. Sin duda creo que el envío "de una en una" permite controlar más los envíos, ya que puedes incluso hacer comprobaciones antes de enviar, etc.

¿Cómo lo hacéis vosotros?

[adolphsys]

Empezado por espinete

Hola a todos/as...

Por fin he podido generar, firmar, enviar, (consultar) y anular facturas a las tres delegaciones. El problema que me encuentro ahora es con Bizkaia, que permite enviar varias facturas en el mismo envío, en lugar de una a una como Gipuzkoa y Araba.

Si envío varias facturas de golpe en el mismo envío/fichero... ¿cómo obtengo el Nº, serie y firma de la factura anterior si aún no he recibido respuesta hasta que se envíen todas?

Lo explico mejor...

En un mismo fichero, envío 100 facturas de golpe. Si en "SignatureValueFirmaFacturaAnterior", etc. debo poner la firma de la factura anterior, nº, serie... que se haya enviado correctamente... ¿cómo sé si ésta efectivamente se envió correctamente, si aún no he obtenido la respuesta de este envío masivo?

Obviamente puedo incluir ese dato, y el nº, serie, etc. de la factura anterior independientemente de que ésta se haya enviado correctamente o no, y esperar al resultado final y actuar en consecuencia (marcándolas como "no enviadas").
Pero claro, desde que falle un envío (por ejemplo, cuando vaya por la 25), las otras 75 darán todas error. No veo lógico hacerlo así.

Otra opción es enviarlas de una en una y listo, como con Gipuzkoa y Araba, pero no sé si será una opción elegante teniendo en cuenta que han habilitado el envío masivo por algún motivo, no?

Espero haberme explicado bien. Sin duda creo que el envío "de una en una" permite controlar más los envíos, ya que puedes incluso hacer comprobaciones antes de enviar, etc.

¿Cómo lo hacéis vosotros?

Hola, el proceso de encadenamiento de las facturas se hace en la emisión (facturación propiamente dicha), no en el envío.

[espinete]

Empezado por adolphsys

Hola, el proceso de encadenamiento de las facturas se hace en la emisión (facturación propiamente dicha), no en el envío.

Es decir, que cuando genere el XML de la factura, incluyo los datos de la factura anterior independientemente de que ésta se haya enviado correctamente o no?
Y ya luego, cuando obtenga la respuesta del envío masivo, las marco como "erróneas"?

Habrá que hacerlo así, pero sigo prefiriendo el envío "una a una".

[keys]

Yo creo que el problema del qr de alava es que estamos calculando mal el CRC. Mirando su ejemplo

https://pruebas-ticketbai.araba.eus/...2537.70&cr=017

Yo no consigo que me de 017. No se sobre que lo estan aplicando.

[keys]

Quizas tenga algo que ver esto de la barra. Lo estoy probando pero no me sale el mismo crc.

URL de acceso a la aplicación web de lectura del QR, específica para cada Administración tributaria:
o Araba/Álava: https://ticketbai.araba.eus/TBAI/QRTBAI (sin “/” para el cálculo del CRC).
o Bizkaia: https://batuz.eus/QRTBAI/ (con “/” al final para el cálculo del CRC).
o Gipuzkoa: https://tbai.egoitza.gipuzkoa.eus/qr/ (con “/” al final para el cálculo del CRC).

[hago_preguntas]

Empezado por keys

Yo creo que el problema del qr de alava es que estamos calculando mal el CRC. Mirando su ejemplo


Yo no consigo que me de 017. No se sobre que lo estan aplicando.

¿De donde has sacado el ejemplo?

A mí me sale crc=036, calculado sobre el enlace que has puesto quitando &crc=017

[adolphsys]

Empezado por espinete

Es decir, que cuando genere el XML de la factura, incluyo los datos de la factura anterior independientemente de que ésta se haya enviado correctamente o no?
Y ya luego, cuando obtenga la respuesta del envío masivo, las marco como "erróneas"?

Habrá que hacerlo así, pero sigo prefiriendo el envío "una a una".

Eso es, ya sabes que al cliente final hay que permitirle seguir facturando haya enviado o no la factura a Hacienda.

A Vizcaya puedes enviar un bloque por ejemplo de 10 facturas, e igual aceptan seis, y cuatro se rechazan, así que tienes que examinar el XML de respuesta y leer el estado de cada factura de forma individualizada.

[unomasmas]

Empezado por espinete

Hola a todos/as...

Por fin he podido generar, firmar, enviar, (consultar) y anular facturas a las tres delegaciones. El problema que me encuentro ahora es con Bizkaia, que permite enviar varias facturas en el mismo envío, en lugar de una a una como Gipuzkoa y Araba.

Si envío varias facturas de golpe en el mismo envío/fichero... ¿cómo obtengo el Nº, serie y firma de la factura anterior si aún no he recibido respuesta hasta que se envíen todas?

Lo explico mejor...

En un mismo fichero, envío 100 facturas de golpe. Si en "SignatureValueFirmaFacturaAnterior", etc. debo poner la firma de la factura anterior, nº, serie... que se haya enviado correctamente... ¿cómo sé si ésta efectivamente se envió correctamente, si aún no he obtenido la respuesta de este envío masivo?

Obviamente puedo incluir ese dato, y el nº, serie, etc. de la factura anterior independientemente de que ésta se haya enviado correctamente o no, y esperar al resultado final y actuar en consecuencia (marcándolas como "no enviadas").
Pero claro, desde que falle un envío (por ejemplo, cuando vaya por la 25), las otras 75 darán todas error. No veo lógico hacerlo así.

Otra opción es enviarlas de una en una y listo, como con Gipuzkoa y Araba, pero no sé si será una opción elegante teniendo en cuenta que han habilitado el envío masivo por algún motivo, no?

Espero haberme explicado bien. Sin duda creo que el envío "de una en una" permite controlar más los envíos, ya que puedes incluso hacer comprobaciones antes de enviar, etc.

¿Cómo lo hacéis vosotros?

Una cosa es la generación de la factura (del XML firmado y con QR generado) y otra el envío. Son procesos independientes. Puedes (debes) firmar el XML y generar su correspondiente código QR antes de imprimir (de hecho, lo necesitas para imprimirlo en la factura). Una vez generada puede enviarse inmediatamente o quedarse ahí y enviarla después junto con otras...