Muchas gracias Irreo. Me hará falta la suerte.

Funcionó
 

Gracias Irreo, al fin funcionó.

Era el certificado. No era cierto que aceptara los .c12

Te debo una.

plantilla registro de soft
 

Hola a tod@s, alguien me puede ayudar con el tema del registro de soft en Alava???


Alguién que lo haya registrado me puede facilitar una plantilla o documento???


Gracias x anticipado


P.D.: Me gustaría contactar con gente que tenga funcionando aplicaciones en Alava. Mi software sólamente va a tener 2 instalaciones en 2 comercios. Estoy pillado de tiempo y necesito avanzar, x supuesto no quiero aprovecharme de nadie, si hay que llegar a una compensación económica (razonable) no sería un problema

Me alegro, ya te dije que andabas cerca ;)

Lo de aceptar PFX/P12 supongo te dirían porque el servidor sí los admite. Es posible que el código que habría que utilizar para el envío fuese diferente... esas "opts" admiten más parámetros, así que seguramente poniendo algún otro o cambiando algún valor, funcionará con P12, quiero pensar.

La memoria no tiene mucho misterio, es una descripción breve y concisa, sin necesidad de tecnicismos, de cada punto que exigen.

En mi caso ha quedado en un poco más de un folio... simplemente describe brevemente con tus palabras los puntos que piden:

Tipo de software (en la nube, etc..)
Proceso de encadenamiento (el sistema que usas para determinar el encadenamiento..)
Proceso de firma (qué tipo de certificado utilizas..)
Tipos de facturas o justificantes (formatos de facturas que emites...)
Ubicación código identificativo
Pantalla de verificación (cómo acceder, etc..)
Sistema de almacenamiento (cómo o dónde almacenas ficheros TBAI, etc.)

Básicamente, no es un manual para que alguien sepa cómo hacer un desarrollo. Se trata de describir un poco lo que tienes montado.

Buenos días.

Unas dudas respecto al Zuzendu. Según he leído, en principio las rectificaciones que se pueden hacer con el Zuzendu se pueden realizar también desde la aplicación web de “Consulta de facturas emitidas”. ¿Vosotros habéis desarrollado Zuzendu? Si lo habéis hecho ¿os deja modificar información que desde la web no permite? Por ejemplo, no sabemos cómo actuar para modificar un CIF o una dirección.

Muchas gracias.

Zuzendu no deja modificar casi nada. Casi lo único que se puede modificar son los tipos de iva. En el momento que intentas modificar un CIF o el importe de la factura te dice que no se puede realizar ese cambio.

Me estáis dejando descolocado :confused:

¿Zuzendu para rectificar facturas?

Hasta donde yo tenía entendido, cualquier cambio en una factura que haya sido aceptada se debe hacer mediante una nueva factura de tipo rectificativa.

Y Zuzendu, también hasta lo que entiendo, no es que "puedas" desarrollarlo... DEBES.

Según este fantástico esquema (para algo claro y bonito que hacen...), los reenvíos de facturas rechazadas por esquema o por algún otro error, van por Zuzendu (bien sea Subsanar, o Modificar):
https://www.gipuzkoa.eus/documents/2...0-576df4d5c345

Personalmente, no uso Zuzendu para nada más.... si una factura da un error, la envío a Zuzendu si así se requiere, y si quiero corregir un dato de la factura (dirección, etc.) es una nueva factura rectificativa.

¿O estamos hablando de cosas diferentes?

Saludos.

Pues eso, solo sirve para facturas que han dado error a la hora de presentar o hay alguna modificación que no tiene reflejo en la factura. Yo por lo menos no he hablado de rectificar nada.

OK, es que como hablabais de modificar direcciones o importes con Zuzendu, no me cuadraba.

Nosotros tuvimos el caso de un hotel donde metió el NIF de un cliente indicando Otro identificador. Vía Zuzendu no nos dejó cambiarlo y poner un NIF. Tras la pertinente consulta, nos dijeron:
En este caso, la identificación del cliente no la vais a poder cambiar mediante ZuzenduBAI. Hay que emitir factura rectificativa por sustitución declarando al cliente como nacional, usando la etiqueta NIF.

Respecto al fichero de Zuzendu, hemos optado por el camino del medio: volvemos a generar el XML de la factura a corregir y antes de su envío sacamos un editor donde poder verificar que se haya generado bien o, en su defecto, corregirlo manualmente (lógicamente lo haríamos nosotros conectándonos al cliente).

Mensaje publicado por error :p

Borrar please, gracias.

Verificar QR
 

Buenos días
¿Cómo puedo verificar que el código QR generado es correcto?
¿Si pongo esa URL en un navegador me tiene que mostrar algo?

Gracias

Pues si, te debe mostrar la factura, que para eso es.

Puedes probar con esta, por ejemplo:
https://batuz.eus/QRTBAI/?id=TBAI-A9...&i=1.98&cr=047
O esta de Álava:
https://pruebas-ticketbai.araba.eus/...&i=2.42&cr=089

Buenos días,
En el envío de una de las factura me ha dado el siguiente aviso:
El motivo es porque es de un cliente extranjero el cual no teníamos informado el código postal y lo enviamos vacío. Entonces, para subsanar el error intento modificarlo mediante la web, pero el campo código postal no permite cambiarlo. ¿Cómo debería proceder en este caso? Muchas gracias.

Es una corrección que se refleja en la factura, por lo que tienes que hacer una factura rectificativa.

Por cierto me surge una duda con este tipo de rectificaciones...


Siguiendo con el mismo ejemplo del compañero de no haber rellenado el código postal...


Cual sería la secuencia?


1) Se mete la factura con el error, sin código postal
2) Se genera una rectificativa (abono) con el mismo error sin código postal?
3) Se corrige el cliente completando correctamente los datos
4) Se sube la nueva factura ya corregida en positivo


Gracias de antemano

Imagno que no es necesario que el la rectificativa cometas el mismo error.
Valdrá tanto si lo cometes como si no.

No "creo" (no lo aseguro 100%) que comprueben que la rectificativa y la original tengan el mismo Código Postal (no parece un dato identificativo importante).

Para modificar o corregir datos en prácticamente cualquier factura, se puede emite una factura rectificativa por sustitución. No hace falta anular nada.

Por ejemplo quieres modificar o corregir algo de la factura H-200: emites una nueva factura R-13 con los datos correctos, indicando que sustituye a la H-200.

En la propia factura rectificativa ya estás indicando en el XML cuál es el importe rectificado, así qua ya se está "anulando" la factura anterior.

En el caso que dices, si la factura se ha aceptado pero con el error de código postal, emites una nueva rectificativa por sustitución, exactamente como debería haber sido la anterior, y listo.

Si se va a cambiar un importe, se puede usar una rectificativa por diferencias.

Por ejemplo tienes la factura H-200 por importe de 1200€, pero debía haber sido de 1000€, emites una nueva factura, R-13, por un total de -200€

De esta forma el importe computado son 1200 - 200 = 1000€

Pero podrías usar una sustitutiva perfectamente, indicando 1000€ simplemente con los datos correctos, sin negativos ni nada.

De todas formas esto es solo para facturas que estén aceptadas, con o sin errores.

Lógicamente si la factura ha sido rechazada, se deberá reenviar de nuevo ya sea a Alta o Zuzendu según el caso.

Gracias a los dos

error dipu alava
 

Buenos días

Nos están dando una serie de errores de repente el 998 y 008, en la dipu de alava no se si alguno sabe algo.

Nos acaba de llamar un cliente de Alava que les esta pasando lo mismo. Parece que tienen algún problema.

Hola chic@s,
bueno, lo primero desearos unas felices y fiestas y todo eso, y el deseo de un año nuevo mejor que este, que ha sido malo de cojones.
Me suena que una de las diputaciones puso una herramienta para validar el fichero xml del Ticket Bai, y que mostraba los errores y todo eso.
¿Alguien sabe donde estaba? o lo he soñado
Gracias de antemano y lo dicho, felices fiestas.

Video tutorial de Danysoft para el envío de un XML a Bizkaia usando componentes REST
 

Envío de Factura Electrónica a TicketBAI con el uso de API REST en Delphi
https://www.youtube.com/watch?v=P0wmgqoxeXo

Por si a alguien le sirve.

Qué bien viven los funcionarios de la Hacienda Alavesa


A día de hoy no saben recoger el nuevo iva de la lecha con 0%


Y del recargo de equivalencia del aceite (0,625%) ni intentarlo :eek::eek::eek:




Fantástico v\||/v\||/v\||/v\||/

Buenos días y Feliz Año a tod@s...

Estoy haciendo pruebas de envío con el IVA 0% y con el nuevo IVA al 5% con RE 0,625%.

En principio puedo enviar (Gipuzkoa) facturas con IVA 5% + RE 0,625.

En cambio, si envío facturas con el IVA = 0%, como "No Exenta / Sujeta", me la rechaza:

002 Rechazado - ALTA PREP Fichero no cumple el esquema XSD. Detalle del error: cvc-complex-type.2.4.b: The content of element 'DetalleNoExenta' is not complete. One of '{DesgloseIVA}' is expected.

Si la envío como "E1: exenta por el artículo.......", o con E6, etc. ocurre lo mismo. Misma respuesta.

Había entendido que, al menos Gipuzkoa, ya admitía el envío del IVA 0% sin necesidad de enviarla como "Exenta".

Parece que el problema está en mi aplicación, que al detectar un IVA=0% automáticamente añadía al XML la sección <NoSujeta> , cuando sí que está Sujeta.

Envío ejemplos de cómo lo tengo hecho actualmente para que funcione. Si alguien puede corroborar que esté correcto creo que nos haría un favor a todos:

Ejemplo 1: Factura Exenta de IVA:

Ejemplo 2: Factura normal, con IVA:

Ejemplo 3: Factura con Recargo Equiv. Clave Rég. IVA = 51

Aquí acabo de darme cuenta de que el Rec. Equiv. se esta enviando con solo 2 decimales, así que tendré que corregirlo:

Me devuelve mogollón de avisos, pero se envía:

Codigo 5021: Si ClaveRegimenIVAOpTranscendencia igual a 51, el TipoRecargoEquivalencia no debe venir informado
Codigo 5022: Si ClaveRegimenIVAOpTranscendencia igual a 51, la CuotaRecargoEquivalencia no debe venir informada
Codigo 5023: Si ClaveRegimenIVAOpTranscendencia igual a 51, en bloque Sujeta y No Exenta, en al menos una OperaciónEnRecargoDeEquivalenciaORégimenSimplificado tiene que ser S


Ejemplo 4: Factura con IVA = 0%, pero No Exenta

Y te funciona el iva de la leche?



Porque yo no consigo

Si no me equivoco, la leche pasa a tener el 0% (baja del 4% al 0%), por lo que es el último ejemplo que puse: factura normal, sujeta, no exenta, pero con IVA = 0.

Eso sí, yo solo lo he probado en Gipuzkoa. No he probado aún con Araba o Bizkaia.

Así lo tengo yo y nada en Alava

Lo único que veo raro es que en TipoImpositivo parece haber un espacio en blanco después del cero. No creo que sea eso, pero por si acaso.

Tal vez es que simplemente Álava no ha aceptado aún enviar facturas sujetas a IVA pero con IVA cero. Creo que hace unos días leí que solo Gipuzkoa lo había hecho.

Hoy si tengo un hueco pruebo a hacer envíos y te confirmo.

Lo he cambiado pero eso no es porque sigue fallando buien ajustaod. Lo he dejado bien porque se coló en mis últimas pruebas para intentar encontrar la manera de que subieran bien


Ha llamado un cliente mío a Hacienda Alavesa y le han dicho textualemnte que



"He llamado a diputación foral , departamento de hacienda , y me han dicho que hasta que nuestro software subsane el problema de IVA 0 pongamos esas facturas en operaciones exentas por otras causas , nº 6 ."


Soy yo el tikismikis o están desviando la culpa de una manera acojonante?



También me han dicho que hay 15 días para subsanarlo.

Claro claro, dile tu a tus clientes que se acuerden de elegir en el desplegable la opción nº 6, o bien modifica tu aplicación para que, solo a Álava, las envíe todas con ese código, pero solo hasta que ellos lo arreglen. Y cuando lo hagan, a sacar otra actualización para que deje de hacerlo así y lo haga "asá".

Lo que me contestan al hilo del tema del 0,625


Nuevo recargo de equivalencia de 0,625 (asociado al tipo impositivo del 5%):
Servicio rest de recepción de ficheros Ticketbai de DFA:

• El esquema TicketBAI, no admite 3 decimales para el tipo de recargo de equivalencia. Dicho esquema es común a las 3 Haciendas vascas y hay que ponerse de acuerdo entre todos.

Mientras que dicho esquema no se modifique, la única opción es poner 0.62 o 0.63 y calcular correctamente la “cuota de recargo de equivalencia” aplicando el 0.625.

• El servicio rest dará un aviso indicando que el tipo de recargo de equivalencia es incorrecto. Se modificará lo antes posible, para que deje de darse dicho aviso.

Aplicación FakturAraba:

• Se adaptará lo antes posible. De momento, no es posible indicar recargo de equivalencia del 0.625.

Pobrecillos

En Gipuzkoa nos han respondido que ya han adaptado el esquema para admitir el porcentaje de recargo con tres decimales pero que no lo han publicado aun, y que si validamos el fichero XML antes de su envío, "lo que es muy recomendable" (sic), debemos modificar el esquema a mano para permitir el tercer decimal.

Pues yo me niego a hacer nada. El problema lo tienen ellos. Yo no voy a estar haciendo una modificación ahora para luego hacer otra dentro de X días. Que le den explicaciones ellos a los contribuyentes, no yo.
Yo tardé un día en hacer el cambio de los decimales. Ellos llevan ya más de una semana.

Lo que faltaba, tener que redondear a dos decimales y recalcular el total para que coincida.

Hola,

La pasada semana, les envié consulta a TicketBAI de Álava.
Les preguntaba cómo hacer con los productos del 5% y del 0%, así como el tema del nuevo recargo de equivalencia de 3 decimales.

Por el momento, para resolver el tema, procesaba los productos que han pasado al 0% de IVA en la sección de "Exenta" con causa "E6" (otras causas).

Me acaban de llamar de TicketBAI de Álava para contestarme:

- Que que ya tienen resuelto, en las 3 Haciendas Forales, el tema de los productos del 0%.
Que admiten el tipo de IVA "0.00" en el "TipoImpositivo" dentro de la sección "NoExenta"
Que debo cambiar el sistema que estaba usando, temporalmente, de anotar esas bases del 0% en la sección "Exenta"

- Que el tipo del 5% ya es aceptado desde hace tiempo, cuando se aplicó a las empresas eléctricas
(Efectivamente, con el 5% no he tenido ningún problema)

- Que el tema del nuevo RE de 3 decimales, estará resuelto en breve y avisarán.
Que de momento, emplee sólo los 2 primeros decimales.
(Lo que ya estaba haciendo)
Y que aunque avisen que ya está, la publicación llevará más tiempo.

Saludos

Confirmado que Álava admite ya el iva al 0%


Echo para atrás la mañana de trabajo de ayer..


Le mando la factura del coste a Pedro Sánchez y Urkullu.

Pues nosotros llevamos varios días esperando que nos contesten a otra problemática:

Cuando se hacen facturas rectificativas por rápeles, hay que identificar la primera y la última factura a la que corresponden los rápeles. Tenemos un cliente en Álava que tiene que hacer este tipo de facturas para sus clientes, el problema es que al identificar esas facturas (la primera y la última a incluir en el rappel), resulta que alguna de ellas pertenece a un periodo en que nuestro cliente no estaba obligado a presentar las facturas en Ticketbai (nuestro cliente empezó el 1 de diciembre, como casi todos) y el sistema no admite la factura porque no encuentra dicha/s factura/s.

¿Cómo decirles que sólo pueden comprobar facturas si pertenecen desde la fecha de obligatoriedad en adelante?

v\||/

Buenos días,
nosotros para el Tipo Impositivo 0 estamos enviando desde el 1 de Enero el desglose de IVA como si se tratara de cualquier otro tipo.
Hasta que en Guipúzcoa aplicaron y estabilizaron sus cambios tuvimos una serie de facturas recibidas correctamente pero con avisos. Desde que lo detectamos no hemos dejado de llamar a la hacienda para que nos digan exactamente que tenemos que hacer con esas facturas (si ignoramos los avisos, las mandamos por Zuzendu...) y lo más increíble de todo es que con cada persona de la hacienda que hemos hablado nos ha dicho una cosa distinta :mad:
Hemos intentado que nos den una respuesta por escrito y se niegan a hacerlo, supongo que para no pillarse las manos...

¿Alguna persona más con este problema?