![]() |
Cita:
Ya lo han demostrado en varias ocasiones. Cita:
https://servicios.izenpe.com/ticketbai/ Cita:
(poco más que el resto del mundo lo estaba haciendo mal, menos ellos :D:D:D) |
Cita:
Te recomiendo que te consigas un certificado digital FNMT de persona física. https://www.sede.fnmt.gob.es/certifi...icado-software Es rápido, gratuito, dura 4 años y tiene muchos más usos. Saludos |
Hola,
Tengo dudas sobre la posición del código TBAI y el código QR en el documento de la factura. Les consulté a Batuz sobre si el código TBAI y el código QR podían estar por encima del número de página que figura en el pie de página de la factura. Me contestaron que sí. Ahora estoy a la espera de que me contesten sobre si pueden estar por encima del texto de cumplimiento de la LOPD, que también está en el pie de página. Y ahora me surge la duda de si (en una factura en orientación vertical) podrían estar el código TBAI y el código QR abajo a la derecha, en lugar de en el centro (como se ve en el ejemplo de la normativa). Y si podría haber algún texto a la izquierda del código QR (por ejemplo el cuadro típico de totales de bases, tipos de IVA , cuotas de IVA y totales) ¿Alguien puede aportar algo sobre este tema del posicionamiento? Gracias anticipadas. Saludos |
Cita:
De echo en la memoria del Software Garante les puse: 5. Ubicación del código TBAI y código QR Las facturas se imprimen en formato vertical. El Identificativo TBAI y el código QR estará ubicado en la parte inferior derecha de la factura utilizando 2 líneas para la impresión del código TBAI. Y nos han concedido dicho software garante, por lo que no creo que tengas más problema. Saludos |
Muchas gracias por las respuestas, creo que seguiré vuestro consejo e intentaré conseguir ese maldito certificado...
Pd: Me gusta esa 13/14 en la que los ingenieros de hacienda dicen que el mundo está equivocado para no arreglar su código, es el equivalente a "La pelota es mía me la llevo a casa". (El concepto me hace mucha gracia). Un saludo señores y que la fuerza nos acompañe a todos. |
Hola, alguien más esta teniendo problemas hoy con el Batuz?
Otros días he podido enviar facturas y consultas, pero hoy no me deja. Cuando le envío datos, el curl se queda en bucle enviando. Saludos |
Cita:
|
Nosotros estamos igual.
|
Cita:
Ahora en serio, entre que tardan en responder una semana en responder, caídas de su servicio, falta de información, etc, etc, etc..... de verdad que quieren empezar para el 1 de enero del 2022? |
Cita:
Gracias por la información. Si alguien más puede aportar más información acerca del posicionamiento de los códigos TBAI y QR en la factura, se agradecerá. Saludos |
Cambios en el servicio?
Buenas
La semana pasada no tenía problemas a la hora de hacer los envíos, eran inmediatos, ahora al hacer el post se queda un buen rato pensando como sie stuviera esperando la respuesta hasta que da un timeout. Lo curioso es que consulto la operación con el código TBAI y está subida a la web. Sabéis si tiene que ver con el corte que anunciaron el 17 de junio? Gracias |
Batuz me ha contestato esto:
![]() |
Neftali se me ha adelantado, me han respondido exactamente lo mismo, aun así ya que estoy lo dejo publicado:
PREGUNTA: "Buenos días tengan ustedes, me imagino que se habrán dado cuenta de que el servidor de pruebas no responde desde ayer, ¿Serían tan amables de decirnos cuándo podremos retomar el desarrollo? Varios programadores completamente ajenos a nuestro equipo también están experimentando este problema así que podemos descartar que el error sea nuestro. Espero su respuesta." RESPUESTA: "Kaixo, Estamos teniendo problemas con la validación de los certificados desde ayer. Esperamos solucionarlo lo antes posible. Perdonad por las molestias causadas. Agur bat." En cualquier caso me toca la moral que nos devuelvan respuestas automáticas y protocolarias. |
Buenos días, me quiero empezar a meter ya con las facturas recibidas y la verdad que no hay mucha documentación.
En las facturas emitidas se pone esta línea al inicio, sabéis que línea hay que poner en las facturas recibidas? <?xml version="1.0" encoding="UTF-8" standalone="no"?><lrpjfecsgap:LROEPJ240FacturasEmitidasConSGAltaPeticion xmlns:lrpjfecsgap="https://www.batuz.eus/fitxategiak/batuz/LROE/esquemas/LROE_PJ_240_1_1_FacturasEmitidas_ConSG_AltaPeticion_V1_0_2.xsd"> El esquema xsd creo que es este "LROE_PJ_240_2_FacturasRecibidas_AltaModifPeticion_V1_0_1.xsd" Gracias |
Me acaban de escribir que ya podemos volver a trabajar con BATUZ.
"Kaixo, Parece que el sistema se ha restablecido y la validación de los certificados vuelve a funcionar correctamente. Agur bat." |
Yo cada vez que entro al foro y leo cosas nuevas, me deprimo, te lo juro.
Vamos a ver una cosa... Primero, Bizkaia va por su cuenta y crea una API engorrosa, con no sé ni cuantos "esquemas" diferentes (facturas emitidas con software garante, sin software garante, ingresos, gastos, intracomunitarios, anulación, modificación......) que encima hay que integrar por separado. Luego, que si se crea primero la factura con no sé ni cuántos requisitos, preparar el envío, que si comprimirlo en ZIP con otros requisitos más, etc. Luego Gipuzkoa y Araba solo tienen "enviar factura" y "anular factura" (pa qué más). En nuestra empresa hemos implementado en nuestro software la factura electrónica de varios países (México, Costa Rica, Guatemala, Colombia...), así como el SII y FacturaE en España. Ninguna de las facturas electrónicas de esos países requieren tanta tontería, y no solo eso: ninguna exige enviar también las "facturas recibidas", los gastos, etc. ni diferencian los ingresos, facturas con software garante y SIN software garante, etc. ¿Alguien me explica qué es un "Ingreso con factura SIN software garante"? ¿Acaso el software garante tiene que permitir enviar facturas que NO se hayan registrado en el propio software? ¿O es que lo estoy entendiendo mal? Lo siento. He venido a desahogarme un poco. Solo espero que esta gente esté preparada para que el 1 de Enero de 2022, miles y miles de empresas de todo el País Vasco envíen millones de facturas de golpe y no surjan problemas que no han previsto. |
Cita:
Pues sí que es cierto que tiene bastante complejidad técnica el sistema Batuz (TicketBAI + LROE) de Bizkaia. Aunque, en parte, se justifica porque es un sistema más ambicioso (en el tema de la persecución del fraude fiscal) que el de Gipuzkoa, por ejemplo. Hay que tener en cuenta que mediante ese sistema, las empresas de Bizkaia ya no harán: - Declaraciones de IVA - Declaraciones de operaciones con terceros - Transferencias por SII - Impuesto sobre Sociedades. Hacienda Foral de Bizkaia enviará borradores de esos impuestos que sólo habrá que aceptar o modificar (aportando en ese caso documentación justificativa) Eso permitirá a las empresas deshacerse de una buena parte de las operaciones que se derivan a las asesorías fiscales. Y, en consecuencia los costes de asesoría deberían bajar y, por contra, aumentar los de las aplicaciones informáticas que desarrollamos nosotros y que les permiten realizar, cómodamente, todas esas operaciones del LROE. En el caso que señalas de "Ingresos de facturas emitidas sin software garante", aparte de algunos tipos de facturas raras, también cubre el poder declarar las facturas que hayan sido rechazadas por TicketBAI por errores técnicos (por ejemplo, error en la firma digital) y que ya no pueden modificarse una vez emitidas. Eso sí, creo que los profesionales del sector informático que desarrollamos estas nuevas funciones (ahorro, para las empresas, en gastos de asesorías fiscales) deberíamos ser más valorados por este nuevo trabajo. Saludos y ¡Ánimo!, que ya verás como salimos adelante de esta también. |
Cita:
Creo que ya lo ha explicado [Sistel]; La opción de "sin SG" viene a ser algo así como una puerta de escape a todas las facturas que no se pueden codificar (por diferentes errores/problemas) por el caso normal (con SG). Digamos que el 95% o el 98% de las facturas son "normales" y luego hay un porcentaje pequeño que son especiales, de determinados sectores o (como han dicho) que por lo que sea dan error. Para eso se ha inventado el caso de "sin Software Garante". Personalmente lo veo demasiado complejo, pero... Eso sí, no os quiero desanimar, pero cuando lleguéis al tema de efectivo (percibido de más de 6000€) ya veréis... Hay una forma de hacerlo fácil y luego la que han implementado ellos. :(:mad::D (no se si reir o llorar...) NOTA: Lo siento por el "spoiler", pero también tenía ganas de desahogarme... |
Creo que unos días habrá novedades en Bizkaia, y no puedo decir mas. :cool:
|
Cita:
|
Cita:
Nos dejas en ascuas. ¿No puedes adelantar algo? :o En caso contrario, no sé si podré pegar ojo el fín de semana :) Opciones: 1- Las Diputaciones Forales informan que todo era una broma (y piden disculpas por si alguien se lo tomó en serio) 2- Los servicios informáticos de las Diputaciones Forales se han hecho el harakiri grupal (FIFO o LIFO). 3- Se pospone un año más la implantación de TicketBAI (y cerveza para todos) Saludos y buen finde |
Bueno vale.
Tengo el palpito :D que en Bizkaia van a retrasar batuz. No TicketBAI, solo el nuevo 140/240. |
Cita:
Cita:
https://www.batuz.eus/es/preguntas-f...cacheLevelPage También comentar, por si a alguien le interesa, por esta situación que les pregunté, ya que los clientes de mi software de facturación (tpv + gestión taller), la mayoría llevan el tema contable e impuestos a través de la gestoría o bien la empresas que tienen dpto. contabilidad, estos ya tiene su propio programa contable+fiscal, ya que el mío no está enfocado a esa tipo de gestión. Pregunta: Está permitido lo siguiente: - El software de facturación o tpv generaría el fichero XML TicketBAI cada vez que se emita una factura. - En el plazo que corresponda hacer el envío: desde un software contable tercero (distinto al software de facturación) se importarían todos estos ficheros XML TickeTBAI generados. Desde este software contable se crearía el modelo 140/240 con los TicketBAI y se realizaría el envío a la Hacienda Foral de Bizkaia. Es decir, el poder usar 2 software de fabricantes distintos. Uno para realizar las facturas y otro para la confección y envío del modelo 140/240. Ambos serían softwares registrados en el TicketBAI. Respuesta: La operativa que plantea es correcta. No hay ningún problema en que sea un software el que genere el fichero XML y la factura TicketBAI y que la información se envíe a Hacienda desde otro software diferente. Esta operativa está contemplada en las siguientes preguntas frecuentes publicadas en la web www.batuz.eus: 14 - ¿Se pueden enviar los ficheros TicketBAI desde un dispositivo distinto al que ha generado la factura? 166 - ¿Es posible usar diferentes softwares para cumplir con las obligaciones Batuz? No obstante, el software que se tiene que registrar en el registro de Software Garante TicketBAI es aquel que genera y firma el fichero XML e introduce el QR y el identificativo en la factura. Es decir, el software de gestión que planteáis en la consulta solo enviaría la información a Hacienda y por tanto no tiene que registrarse en el citado registro. faqs: https://www.batuz.eus/es/preguntas-f...cacheLevelPage |
Cita:
![]() |
Cita:
¿Qué significa eso? Que la parte de generar el TicketBAI, con el código QR, etc. sí llegará a tiempo, pero los envíos del LROE no? ¿O a qué te refieres con el nuevo 140/240? |
Cita:
De todas formas como he dicho es un palpito:cool: lo tiene que confirmar hacienda o no. Un saludo. |
De echo, si miras no tienen ejemplos para las facturas recibidas. El otro día les pregunte y me dijeron más o menos que era lo que había
|
Me acaban de responder desde Batuz:
Mi pregunta: Cita:
Cita:
|
Sobre los epígrafes del LROE 140
Buenos días, estoy de acuerdo con el tema de los epígrafes que comenta Galaxian.
Veo que nadie ha dicho nada sobre este post.:( ¿Como lo haceis los otros cuando hay múltiples epígrafes? Muchas gracias! Saludos Cita:
|
Cita:
El modelo 140 (LROE para autónomos) no es nuevo. Lleva existiendo muchos años. Y siempre ha incluído la información del epígrafe de actividad de cada operación. Ahora el único cambio consiste en enviarlo por el nuevo sistema. Pero la información es, prácticamente, la misma. Si el autónomo sólo tiene un epígrafe de actividad ¡¡¡ genial !!! Si no, debe separar las facturas (ficheros XML Ticketbai firmados) por cada uno de los epígrafes de actividad. Pero nada nuevo. Saludos |
epígrafes
Muchas gracias por la respuesta Sistel.
Y si hace una venta con artículos de varios epígrafes? tiene que hacerle dos facturas? Mi otra duda es sobre las facturas de compras (facturas recibidas) donde veo que también se tiene que informar el epígrafe, cuando recibes una factura de un proveedor, que yo sepa no pone en ningún sitio el epígrafe de la actividad del proveedor o de los artículos / servicios que te ha prestado:eek: Menudo lio Muchas gracias Cita:
|
Cita:
Para los autónomos todo es siempre más difícil, más caro y más arriesgado. (Por eso a mis clientes siempre les he convencido que se pasen a Sociedad Limitada) Lo de los epígrafes está pensado para cuando un autónomo tiene varias actividades diferentes. Ejemplo: el autónomo tiene un bar y también se dedica a trabajar como fontanero. Lo lógico es que, tanto las facturas emitidas, como las recibidas sean de uno de los dos negocios. Por supuesto, que puede ser que reciba una factura de un gasto que es achacable a sus dos negocios (por ejemplo, factura de sus asesoría) En este caso podría pedir a la asesoría que le emita esa factura repartida en dos diferentes (cosa que probablemente la asesoría le diga que nanay). En ese caso, creo recordar (hace mucho que no tengo ya ningún cliente autónomo) que en el modelo 140 podía repercutir parte de esa factura en cada uno de sus epígrafes . Pero es más complicado. Lo mejor: cada factura a la carpeta de uno u otro negocio. Saludos |
dudas Registro
Cita:
Buenas, Realmente las facturas tienen que ir a un epígrafe, van por actividad no puedes mezclar cosas . Si vendes libros y fabricas/vendes bombillas no puedes mezclar en una factura los libros con las bombillas. En compras tu decides a que actividad le imputas el gasto. Por otro lado alguien me puede decir una vez registrado el software en una hacienda cuanto tiempo tardan en pasarse los datos entre ellas. No me detecta como software garante en Guipúzcoa pero estoy registrada en Bizkaia. |
Muchas gracias Sistel y Noe277 por las respuestas.
Sobre el tema del registro como software garante que comenta Noe277 estamos igual, hace casi un mes que nos registramos, aparecemos en una lista pero no en otra. Además no nos han facilitado la licenciaTicketBAI. Envié un correo a las dos agencias que registran comentando el tema y de momento solo me ha contestado una (en la que no estamos registrados) y dicen: Cita:
Por cierto como habeis obtenido la licencia ticketBAI? os han enviado un correo o algo? Muchas gracias!:) |
Cita:
Si no entras al expediente no ves si as tenido notificaciones. Un saludo. |
dudas Registro
Me han contestado de Gipuzkoa.
Cita:
|
Licencia
Buenos días, nos hemos dado de alta en el registro hoy mismo en Gipuzkoa y nos han comentado que la licencia se corresponde con el número de registro (es licencia de producción, pero se puede emplear en el entorno de pruebas), nos han comentado que el registro en las demás haciendas forales es automático y que tarda cierto tiempo, sin precisar cuanto...
|
Parámetro Content-Lenght
Hola, soy nuevo en el foro y estoy haciendo un envío LROE240 con dos facturas al servidor de pruebas y me devuelve INCORRECTO con el error
"Error al descomprimir el fichero.Not in GZIP format". Me he puesto en contacto con ellos vía email y me dicen que el valor del parámetro Content-Length no coincide con el valor del tamaño del fichero que se envía. El tamaño del fichero gzip es de 12840 bytes, pero si pongo ese valor se queda pensando y no termina nunca. Si no pongo dicho parámetro ( Content-Lenght ) me indican que reciben un tamaño de 26 y no tengo ni idea de donde sale ese valor. A ver si alguien puede darme un poco de luz con respecto al valor de ese parámetro y al mensaje de error. Por cierto estoy usando curl desde línea de comandos. |
Cita:
|
Hola y bienvenido a este foro.
Cita:
Será más fácil si indicas el commando que estás utilizando para el envío; Así alguien que haya utilizado CURL te puede ayudar. Por lo que parece, o no estás enviando el archivo correctamente o no cuadra con la longitud que indicas. De todas formas, esto es una suposición. |
| La franja horaria es GMT +2. Ahora son las 19:23:24. |
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