Hola,

Me puse en contacto telefónico con TicketBAI de Álava para ver si ellos iban a coordinar los cambios con Gipuzkoa para no tener que disponer de distinto software para una y otra provincia.
No sabían nada del tema y me dijeron que no tenían previsto hacer ningún cambio, pero que mejor les preguntase por escrito a través del formulario.

Les pregunté, vía formulario, y me acaban de responder:
"Les escribimos en relación a su consulta número 00027147, para indicarle que efectivamente en Araba también se van a introducir modificaciones en las especificaciones técnicas en las mismas fechas."

Con Bizkaia no he hecho la consulta (miedo me da a la vista de que siempre son diferentes en todo)

Saludos

Hola,

Acabo de enviar la consulta a Bizkaia, en cuanto me contesten os cuento.

Saludos

Esto me han contestado:

Todas las novedades referentes a Batuz se publican en la web batuz.eus/es/novedades. En cuanto a la regulación de especificaciones normativas y técnicas sobre el software garante y la llevanza del LROE se publicó el 13 de julio de 2023 la ORDEN FORAL 274/2023, la cual entra en vigor el 1 de enero del 2024.

También puede consultar el documento Versionado del esquema TicketBAI disponible en el apartado TicketBAI de la documentación técnica de la web: Documentación técnica - BATUZ - Bizkaia.eus

Hola,

Lo que me han contestado a mí:

"Todas las novedades referentes a Batuz se publican en la web https://www.batuz.eus/es/novedades. En cuanto a la regulación de especificaciones normativas y técnicas sobre el software garante y la llevanza del LROE se publicó el 13 de julio de 2023 la ORDEN FORAL 274/2023, la cual entra en vigor el 1 de enero del 2024.

También puede consultar el documento Versionado del esquema TicketBAI disponible en el apartado TicketBAI de la documentación técnica de la web: Documentación técnica - BATUZ - Bizkaia.eus"

Parece que no se rompen mucho los cuernos.
Con el copia+pega les vale para todo...les digas lo que les digas.

Saludos

Pues siendo asi, sólo significa que las especificaciones técnicas se diferencia aún más de lo que ya lo eran y ese parece que será el camino.
Tiene rubiales que un país más pequeño que Tejas tenga seis agencias recaudadoras y no tengan redaños a ponerse de acuerdo y unificar especificaciones

Por si es de utilidad
 

Buenos días, esto es un no parar :confused::confused:.....

He subido a los entornos de pruebas de Guipuzkoa y Araba ficheros con el esquema modificado solo para probar el Descuento y el Importe Total con 8 decimales :



<IDDetalleFactura>
<DescripcionDetalle>994/15 CACHE POR LIME SPIRIT</DescripcionDetalle>
<Cantidad>10.00</Cantidad>
<ImporteUnitario>8.01652867</ImporteUnitario>
<Descuento>1.72355374</Descuento>
<ImporteTotal>94.91173296</ImporteTotal>
</IDDetalleFactura>

Y lo han aceptado, otra cosa será el entorno real que no se yo .....

Salud y paciencia

Tengo el mismo problema ¿Como lo solucionaste?
Gracias

Hola,

¿Alguien envía ya, en real, a algunas Haciendas Forales, con los 8 decimales, y puede confirmar cómo le responden?
Gracias

Saludos

Hola,

TicketBAI de Álava ya ha publicado en su web los nuevos cambios de estructura de los XML:
https://web.araba.eus/documents/1050...vo+esquema.pdf

Y también el tema del cambio de versión del protocolo TLS autorizado:
https://web.araba.eus/documents/1050...C3%B3n+TLS.pdf

Saludos

Hola buenas.

Me han contestado desde Gipuzkoa que haga las pruebas en xmlvalidation.com, es la web que ellos recomiendan para hacer las pruebas, y estos son los errores:

Click on to jump to the error. In the document, you can point at with your mouse to see the error message.
Errors in the XML document:
80: 123 cvc-complex-type.2.4.d: Invalid content was found starting with element 'ds:Signature'. No child element is expected at this point.

Errors in file ticketBaiV1-2-1.xsd:
4: 133 schema_reference.4: Failed to read schema document '....xmldsig-core-schema.xsd', because 1) could not find the document; 2) the document could not be read; 3) the root element of the document is not <xsd:schema>.
13: 34 src-resolve: Cannot resolve the name 'ds:Signature' to a(n) 'element declaration' component.


Es la primera vez que veo esto, el xml está firmado con autofirma y no habido problemas en ser entregado para Bizkaia.

Saludos.

Hola.

Ya está arreglado este detalle, cuando el país de la empresa emisora no es el mismo que el cliente destinatario, entonces carga este nodo con el tipo correcto, 02 para Europa sí tiene IVA Intracomunitario y 04 para el resto.

Saludos.

Buenos días,

Yo ya envío en producción con 8 decimales a todas y todo correcto.

Saludos

OK. Gracias.

Saludos

Gracias.
Ya está añadido el link al primer mensaje del foro.

Buenas

Alguien envia registros al LROE de BATIZ de los capítulos 3 y sucesivos (Bienes de inversión, etc)?

No se si es obligatorio el envío por parte de las aplicaciones, porque son temas muy "contables" y se podría incluso causar problemas fiscales

Por ejemplo, el capitulo 3 del 240, bienes de inversión se debe enviar las "regularizaciones" en los años siguientes a la compra.
Esto parece ser que esta en la normativa foral, pero tiene tela desde el punto de vista fiscal y contable

¿Omitis directamente este tipo de cosas?

Todo depende de lo que quieres que haga tu proprama y lo que quieran tus clientes, nosotros en nuestro caso generamos todos los capítulos de todos los libros del 140/240.

Indicarte que en el 240 el capitulo de bienes de inversión sólo es para las empresas que están en prorrata, y lo que tienen que enviar es la regularización de la prorrata de los bienes de inversión comprados ese año.

Y si tienes razón es un lio desde el punto de vista fiscal y contable.

Un Saludo.

Nosotros sí lo hacemos porque nuestros clientes lo necesitan, pero no hay que implementarlos todos si no es necesario.

Pasar las ventas y compras es normal, porque se tiene todo el control

Pero lo bienes de inversión, por ejemplo, se aplica solo sobre la "prorrata" entre bienes deducibles y no deducibles

¿ Esta información se pregunta al usuario del programa?

Si hay un algún error se puede crear un problema fiscal, porque afecta a lo que se puede o no deducir

En nuestro caso, eso lo rellena el usuario.

Buenos días a tod@s,
¿Podeis enviar a los servidores de pruebas de Bizkaia?
Desde hoy me esta dando error 12175 - Error de seguridad

Yo acabo de probar y me envía bien. Un Saludo

Jodo, pues que será? me sigue dando error, en los servidores de pruebas, pero en los de producción no.

Gracias keys por responder.

Problemas Pruebas Bizkaia
 

También tengo problemas con dos entornos de prueba diferentes parece que da problemas con los certificados de pruebas ...?? :(:(

Gracias, ya me estaba volviendo loco...

Con algunos certificados de prueba funciona y con otros no.

Gracias keys.

Yo acabo de subir una ahora mismo (12:42) sin problemas:
https://batuz.eus/QRTBAI/?id=TBAI-A9...icated=false#/

UPDATE: Vale, veo que ya voy tarde... :o:o

Gracias Neftali, si, a mi ahora también me envía, seria un error puntual, pero como justo me ha pasado cuando estaba integrando la versión 1.2.2, pues me he asustado.
Gracias a todos.

Hola a todos,
Vuelvo con la turra, ya lo siento, pero, podéis enviar a pruebas de Bizkaia?
Hoy me da error de política de firma.
Este es el error:
"La firma no cumple los requisitos de la política de firma TicketBAI.(EPES: S ALGORITMO: rsa-sha512:4096 POLITICA: N CERTIFICADO_ADMITIDO: S"

Es que ya desconfío, con el historial que tienen, ya no sé si soy yo que he cambiado algo, o son sus servidores.


EDITO
Ya he encontrado el por qué da error, si usar la politica de firma 1.1 me da error, en cambio, si pongo la 1.0, va bien.
Os dejo como lo tengo por si se os ocurre algo....

//Version 1.1
//SIG_POLICY_ID_BIZKAIA = 'https://www.batuz.eus/fitxategiak/batuz/ticketbai/sinadura_elektronikoaren_zehaztapenak_especificaciones_de_la_firma_electronica_v1_1.pdf';
//SIG_POLICY_HASH_BIZKAIA = '2B66DA218D1F93C8DB90F1E47DF9391790B8E8EE55BB30F01F6D5D028BE3551B';
//SIG_POLICY_HASH_ALGORITHM_BIZKAIA = 'SHA256';
//SIG_POLICY_URI_BIZKAIA = 'https://www.batuz.eus/fitxategiak/batuz/ticketbai/sinadura_elektronikoaren_zehaztapenak_especificaciones_de_la_firma_electronica_v1_1.pdf';

//Version 1.0
SIG_POLICY_ID_BIZKAIA = 'https://www.batuz.eus/fitxategiak/batuz/ticketbai/sinadura_elektronikoaren_zehaztapenak_especificaciones_de_la_firma_electronica_v1_0.pdf';
SIG_POLICY_HASH_BIZKAIA = '42ECE7F7CC773CC6D21F06D4CDA8F97F928EA621F4BBC6EF9B06DB6CD90EF44B';
SIG_POLICY_HASH_ALGORITHM_BIZKAIA = 'SHA256';
SIG_POLICY_URI_BIZKAIA = 'https://www.batuz.eus/fitxategiak/batuz/ticketbai/sinadura_elektronikoaren_zehaztapenak_especificaciones_de_la_firma_electronica_v1_0.pdf';

Noticias TicketBAI Álava
 

Hola,

Hay nuevos avisos en la web de TicketBAi de Álava:
https://web.araba.eus/es/hacienda/ti...nt/id/13558642

Sin comentarios (ni risas)

Saludos

Sobre todo que no se estresen. :D

Hola de nuevo,



Una pregunta que me suena haber leído por aquí que sí se puede hacer pero no lo encuentro...


Se puede modificar en una factura ya subida a TB datos del estilo del número del vendedor para pagar sus comisiones p.e.... es decir datos que no afectan para nada ni al detalle de la factura ni a datos de cabecera ni a bases imponibles?


Gracias

Hola. Para eso tienes el servicio Zuzendu, pero son muy pocas las cosas que se pueden modificar.

Yo me refiero a datos que ni siquiera afectan a Zuzendu campos del estilo vendedor, su número de pedido...

Esos campos son datos que no afectan al fichero de TBAI, por lo tanto se pueden modificar. Se puede modificar todo lo que no afecte al fichero xml enviado a hacienda.

Gracias keys

Si.
Todo lo que no afecte a la generación del XML de ticketBAI puedes modificarlo.
Nosotros lo que hacemos es generar un nuevo XML (algo similar) y compararlo con el original (sin tener en cuenta fechas y alguna cosa más). Si ningún dato ha cambiado, grabas sin hacer nada más.

EDITO: Lo mismo que ha dicho keys, vamos...

Buenas,

Por si te sirve, te cuento mi experiencia. Yo tenía un sistema para controlar, según qué error daba la factura, enviar a Zuzendu-Subsanar (Z-S) o Zuzendu-Modificar (Z-M).

Un día tuvimos un problema con una factura, que enviamosa Z-M cuando debió haberse enviado a Z-S (o al revés, no recuerdo), y quedó en una especie de limbo.

Hablé por teléfono con un informático de TicketBAI, y básicamente me vino a decir que Z-M es un servicio con el que hay que tener cuidado porque tienes que tener muy claro que no estás modificando nada que sea visible en la factura (líneas, importes, NIF...).

Me dijo que para ir a lo seguro es mejor enviar una rectificativa por sustitución.

En resumen, cambié mi sistema para que:

- Factura aceptada con errores --> Nueva factura rectificativa por sustitución, me da igual qué le pase.
- Factura rechazada: Zuzendu-Subsanar.

Un saludo.

Ayuda - documento memoria de software garante
 

Buenas!

Estoy trabajando en una empresa que está en el proceso de solicitar ser software garante mediante el envío de la memoria.
He visto por el hilo que varios de vosotros habéis pasado por este proceso, por lo que creo que este es el mejor lugar donde buscar algo de ayuda.

Dado que es algo a lo que nunca nos hemos enfrentado estamos buscando a alguien que nos pueda ayudar.
Tenemos un borrador escrito y queremos asegurarnos que no nos dejamos ningún punto, y así asegurar lo máximo posible que será "aprobado" sin problemas.

- Idealmente habiendo participado activamente anteriormente en la redacción de una memoria para software garante.

Obviamente sería remunerado.

Podéis poneros en contacto conmigo a este email: [email protected]

Muchas gracias!

En todo caso puedes poner la oferta en nuestro foro "¿Quiéres trabajar?"