Perfecto gracias

Facturas Recapitulativas
 

¿Facturas Recapitulativas? Son las que agrupan albaranes pero en Tbai no es necesario hacer referencia al albaran solo detallar las lineas.

Datos de Facturas Rectificativas
 

Buenos días;

En la parte de la factura rectificativa, existe un nodo "BaseRectificada" y "CuotaRectificada", por ejemplo:

-<ImporteRectificacionSustitutiva>
<BaseRectificada>24.04</BaseRectificada>
<CuotaRectificada>5.05</CuotaRectificada>
</ImporteRectificacionSustitutiva>


Quiero entender que la Base Rectificada es la Base NO Exenta de la factura inicial, la que se está rectificando... ¿Pero la Cuota Rectificada, se refiere al IVA de la factura sustituida, o a la cuota de IRPF de la misma?

Muchas gracias por vuestra ayuda.
Saludos

Hay cambios en el esquema de TicketBAI (campos no obligatorios), que llegan desde Guipuzcoa.
Por ahora, no es obligatorio cambiar nada.
A día de hoy sólo en pruebas, en breve dicen que los subirán a producción.

¿Habrán hablado con Álava y Viscaya?

Actualizo el mensaje 1 y el FTP.

Base de la rectificada y la suma de las cuotas de los impuestos de la rectificada con los recargos de equivalencia aplicados.
de IRPF no hay ninguna referencia en los esquemas.

Muchas gracias!
Saludos

Me acaba de llegar un mensaje desde Alava, con un nuevo esquema, que permite más decimales en algunos campos, tiene algún pais más, y un par de tipos de Iva nuevos.
No cambia la versión ni es obligatorio, a no ser que haga falta alguno de esos 'añadidos'.



------------------------------------------


Buenas,

Les mandamos este correo para informar que tenemos disponible una versión mejorada del esquema XSD de alta de TicketBAI en el ENTORNO DE PRUEBAS y PRODUCCION

El esquema mejorado contiene los siguientes cambios:

• Ampliación de los decimales de los campos de las líneas. Aquellos que facturen usando más de dos decimales podrán usar el nuevo esquema y enviar la información con la precisión necesaria. Pasan a tener 8 decimales los campos: Cantidad, Descuento e ImporteTotal de las líneas

<complexTypename="IDDetalleFacturaType">
<sequence>
<elementname="DescripcionDetalle"type="T:TextMax250Type"/>
<elementname="Cantidad"type="T:ImporteSgn12.8Type"/>
<elementname="ImporteUnitario"type="T:ImporteSgn12.8Type"/>
<elementname="Descuento"type="T:ImporteSgn12.8Type"minOccurs="0"/>
<elementname="ImporteTotal"type="T:ImporteSgn12.8Type"/>
</sequence>
</complexType>

· Nuevas claves de régimen de IVA 17 y 19. Para aquellos que necesiten facturar en los regímenes previstos en el Capítulo XI del Título IX (OSS e IOSS) o en el Régimen Especial de Agricultura, Ganadería y Pesca (REAGYP) ya están disponibles estas dos claves en el esquema mejorado.

<simpleTypename="IdOperacionesTrascendenciaTributariaType">
<restrictionbase="string">
…
<enumerationvalue="17">
<annotation>
<documentation>IX. tituluko XI. kapituluan aurreikusitako araubideren bati atxikitako eragiketa (OSS eta IOSS) - Operación acogida a alguno de los regímenes previstos en el Capítulo XI del Título IX (OSS e IOSS)</documentation>
</annotation>
</enumeration>
<enumerationvalue="19">
<annotation>
<documentation>Nekazaritza, abeltzaintza eta arrantzaren araubide berezian dauden jardueren eragiketak (NAAAB) - Operaciones de actividades incluidas en el Régimen Especial de Agricultura, Ganadería y Pesca (REAGYP)</documentation>
</annotation>
</enumeration>
…
</restriction>
</simpleType>


· Nuevas entradas en el listado de países. Se han añadido los siguientes países en el contenido CountryType2
· AX ISLAS ALAND
· BL SAN BARTOLOMÉ
· EH SAHARA OCCIDENTAL
· GF GUAYANA FRANCESA
· GP GUADALUPE
· MF SAN MARTÍN (FRANCIA)
· MQ MARTINICA
· RE REUNIÓN
· SJ SVALBARD Y JAN MAYEN




<enumerationvalue="AX"/>
<enumerationvalue="BL"/>
<enumerationvalue="EH"/>
<enumerationvalue="GF"/>
<enumerationvalue="GP"/>
<enumerationvalue="MF"/>
<enumerationvalue="MQ"/>
<enumerationvalue="RE"/>
<enumerationvalue="SJ"/>


Nota Importante: Este nuevo esquema de alta de ficheros TicketBAI mantiene la numeración de versión interna como 1.2. Es decir, no afecta a los que no necesiten de las mejoras incluidas en el mismo.
Si no necesita hacer uso de alguna de las mejoras incluidas en el esquema mejorado no es necesario que haga ningún cambio en su sistema.
Un saludo,

Parece que son los mismo que hace unos días enviaron desde Guipuzcoa.
Queda Vizcaya. A ver si se han puesto de acuerdo los 3...

Descuento en Factura
 

Buenos días;

Estoy teniendo problemas a la hora de expresar un descuento en una factura.

Imaginemos que la factura tiene 2 lineas, con su IVA:

Honorarios 60
Cantidad 2
IVA (%) 21%
Total Honorarios 60

Honorarios 50
Cantidad 1
IVA (%) 21%
Total Honorarios 50


Necesito hacer un descuento del 30% del total de los honorarios (170).

Desde Guipuzcoa me indican que "para hacer un descuento en una factura, hay que incluir una línea más de facturación, teniendo en cuenta que dicho descuento lleva IVA incluído".
En mi caso, el descuento solo es sobre el total de los honorarios, y una vez aplicado dicho descuento, ya se calcula el IVA del resultante.

Desconozco si deberían de ir los honorarios en negativo, o si entonces no se utiliza el nodo "Descuento" para nada, o por qué no se puede hacer un descuento por cada línea.

¿Podríais ayudarme con un ejemplo, cómo quedaría dicha línea de descuento que habría que incluir, y que la factura quede correctamente formada?

Muchas gracias de antemano

Un saludo

Perdón, donde pone Total Honorarios 60 debería poner Total Honorarios 120 (60 x 2)

Buenas Tardes, espero que te sirva, aunque te lo he puesto con tipo impositivo al 10% al 21% cambian las bases pero el resto igual es igual.:
En lass lineas de descuento no hay que indicar porcentajes solo importes

Muchísimas gracias. Me ha sido muy útil.
Un saludo

Rechazo de alta de facturas de Gipuzkoa en entorno de pruebas
 

Hola,

Llevamos un tiempo utilizando el servicio de pruebas https://tbai-prep.egoitza.gipuzkoa.e...nFacturas/alta para el envío de facturas de Gipuzkoa.
Normalmente, las facturas son aceptadas y obtenemos el código 00 de envío recibido correctamente.

Sin embargo, ayer (05-08-2022) y hoy (06-08-2022) estamos recibiendo el código 01 (Rechazado - ALTA PREP) con código de retorno de envío 007 (Certificado remitente no válido para emisor factura.)
El certificado que utilizamos para el envío es el mismo de siempre, expedido por FNMT, que sigue en vigor.

¿A alguien más le está ocurriendo?

Saludos

Yo acabo de probar y me suben perfectamente

Yo también acabo de probar a subir una ahora mismo y todo correcto (Guipuzcoa / Preproduccion).

Hola,

Gracias edari y Neftali.

Era un problema de que el certificado de envío y el certificado de firma eran diferentes.
Y, en el entorno de pruebas, no estaba dado de alta, como colaborador social, el certificado del enviante.
Ya está solucionado.

Muchas gracias, de nuevo.

Saludos

Problemas de envio mediante CURL
 

Estoy tratando de enviar mediante CURL un registro.

En la apliación hago y firmo el TicketBAI y luego hago el xml de la presentación.
Este fichero lo comprimo con 7zip en formato gz.
Luego creo un fichero BAT para ejecutar el envío:
El problema es que me está devolviendo el mensaje 415 Unsupported Media Type
He seguido este hilo y he visto y comparado las difrentes formas de enviar por CURL que hay en el mensaje que resume este tema.
He visto que hay algunos de ustedes que han enviado con éxito utilizando CURL estos registros.

¿Véis alguna cosa rara en cómo lo estoy haciendo yo?

Lo único que me resulta raro en la respuesta es
Content-Type: text/html;charset=ISO-8859-1
Pero yo genero en UTF8 y en la cabecera se menciona tipo gzip.


Por si sirve de algo, os dejo la captura completa de lo que devuelve CURL.

¿Has probado con este ContentType? (tercer parametro)

Parece que funcionó!!! MUCHAS GRACIAS!!!
La respuesta es:
Ahora seguiré mirando cómo sigue el intercambio, pues el mensaje de respuesta me dice que el tamaño no es válido.
No se si se refiere a:

• todo el mensaje
• La parte JSON de la cabecera.
• al campo <TicketBAI> que contiene el Ticket BAI comprimido y convertido a Base64
• algún campo dentro del Ticket BAI (aunque esto sí lo acepta)

Si alguien me puede enviar un fichero de presentación de un ticket BAI os lo agradecería, para poder comparar formato, tamaño, codificacion, etc.

Os dejo el BAT con el que estoy trabajando hasta ahora.

Te lo adjunto al mensaje

Gracias Germán,

Lo he comparado con lo que genero yo y son iguales, excepto la parte de la firma, donde la estructura es un poco diferente.
Como parece que lo aceptan, no voy a mirar eso mucho más.

De todos modos, me refería al envío del Libro de Registro.
Esto lo formo con una parte JSON en la cabecera
y luego un XML que contiene el TicketBAI comprimido y convertido a Base64 dentro del tag <FacturasEmitidas><FacturaEmitida><TicketBai>:

Duda sobre encadenamiento
 

Saludos a todos y gracias por vuestra ayuda.


La duda que no me ha quedado clara leyendo los post es si, tras enviar el fichero firmado, nos devuelve un mensaje de error.
1. Si el error es de datos, creo que el fichero se acepta y queda registrado. (¿y que hay que hacer en este caso?)

2. Si el error es por otra causa y es rechazado (error en el formato o la firma por ejemplo) ¿queda registrado y su signaturevalue es válida para la siguiente factura? Supongo que no, pero no me ha quedado claro que ocurre en este caso.


El proceso que voy a seguir para realizar los envios es este, por si a alguien le sirve de ayuda y por si veis que hay algo que corregir:
Primero creo el fichero XML desde la factura sin los datos de encadenamiento y luego los recupero con otro programa que hace lo siguiente:

1. Lee el fichero XML
2. Busca la ultima factura procesada
3. Guarda los datos de encadenamiento
4. Firma el fichero

5. Envía el fichero
6. Si el resultado es correcto
a. Actualiza la ultima factura

b. Imprimo o envío la factura
c. Muevo el fichero xml a otro directorio

Si el resultado es incorrecto
a. Borro el fichero XML
b. Notifico el error
7. Inicio el proceso con el siguiente fichero


Gestionar el encadenamiento desde la misma aplicación de facturación, en entornos con múltiples terminales era una pesadilla, por eso la idea de crear una cola y gestionarla con otra aplicación. No se si ya existe algo así


Muchas gracias a todos.

A esta pregunta (que les he realizado) me han contestado lo siguiente:

"Los cambios están consensuados entre las tres provincias. Sin embargo, de momento solo se han implementado en Gipuzkoa."

Osea, que podemos ir implementándolo para las 3 administraciones.

El problema que veo es que si tienes un error en el envío, borras el xml y estás "sacando" esa factura digamos del correcto encadenamiento. Si la borras, ¿cómo gestionas luego eso?. Aparte que si tienes que imprimir la factura (y necesitas el QR) cómo lo haces cpon esa factira cuyo envio ha fallado? Lo digo porque necesitas la firma para eso.

Teóricamente según TBAI, el software garante tiene que ser capaz de emitir una factura (firmarla e imprimir su QR) sin necesidad de conectarse con ellos (que era el principal problema que había al principio).

En mi caso, hemos desligado la generación, firmado e impresión de la factura del envío que va por un servicio de cola que únicamente se encarga de enviar las facturas que va generando el software y notifica posibles errores para luego poder solventarlos de manera manual, que es la única manera que hemos encontrado ya que automatizar algo es prácticamente imposible ...

Yo hago algo parecido: un programa crea el xml en una carpeta compartida en la red y luego otro programa gestiona la cola firmando, enviando el fichero y luego comunicando al programa de facturación el resultado.
La idea de borrar el xml es para eliminarlo de la lista de ficheros pendientes de firmar y enviar. Tras hacerlo, notifico a la factura que ha habido un error y que hay que volver a generar el fichero y, por tanto, no puede imprimirse. Después de borrar el fichero, el programa continúa con la cola. Esto te permite seguir trabajando y te asegura que el QR impreso siempre es correcto. Lo peor que puede pasar es que los servidores TBai no funcionen y los clientes se tengan que ir sin el tiquet o esperarse un rato.

La diferencia que veo con tu método es que se corre el riesgo de que el el fichero sea rechazado y no ingrese en su sistema. Estarías imprimiendo un QR que apunta a una URL inexistente y se estaría rompiendo el encadenamiento real.

Hola,

Creo que el procedimiento, como ya han indicado más de una vez los de TicketBAI, no es esperar a conseguir que el sistema informático de Hacienda Foral dé el visto bueno al XML firmado y enviado.
Se trata de:
- Recopilar los datos para emitir la factura (la factura no está emitida, realmente, hasta que no se ha obtenido el XML firmado)
- Crear el XML
- Firmarlo (ahora es cuando la factura está realmente emitida)
- Recopilar los datos de códigos TBAI y QR a partir de los datos del XML firmado
- Imprimir o enviar la factura al destinatario con los códigos TBAI y QR.
- Y, a continuación, enviar el XML firmado a Hacienda.

Que Hacienda dé por bueno o no el XML es independiente: la factura ya está emitida.
Si Hacienda da por bueno el XML recibido, genial.
Si Hacienda no lo da por bueno, dependiendo del tipo de código que retorne, habrá que hacer una u otra cosa. Pero la factura ya está emitida y va a misa.

Saludos

Ok. Pero la duda que tengo es para este caso:

Tenemos 3 facturas A,B,C.
Se genera el xml de A, obtenemos el qr y el signature value para introducirlo en B e imprimimos

Se genera el xml de B, obtenemos el qr y el signature value para introducirlo en C e imprimimos

Se genera el xml de C, obtenemos el qr y el signature value para introducirlo en ... e imprimimos


El proceso de validación en TBai nos rechaza el fichero de B y no se registra en TBai (no porque no le gusten los datos si no porque hay un error en la estructura, por ejemplo) cuando ya hemos impreso C y encadenado con signature value de B.
En este caso C estaría encadenando con un fichero que nunca se ha registrado en TBai y el impreso de B tendría un qr que no apuntaría a una url válida.

No se si esto es correcto así y hay una forma de corregirlo posteriormente pero pienso que habría que evitarlo, también para evitar posibles explotaciones maliciosas de este error.

Hola Ja Mon,

El encadenamiento de los XML de facturas es algo que tienes que hacer tú a medida que las vas emitiendo.
Es independiente de que Hacienda después, cuando se las envíes, considere que alguna de ellas no está correcta.
Tú las tienes encadenadas y eso es lo importante.

Puede ser que se te caiga la conexión a Internet, que los servicios de Hacienda Foral no funcionen o que la emisión sea en Bizkaia (normativa Batuz que puede admitir que las facturas se envíen varios meses después de su emisión).
Da igual: tú las tienes numeradas consecutivamente, firmadas y encadenadas.
Si después, cuando consigas enviarlas a Hacienda, te dice que alguna (o todas) tienen errores tienes diversas vías para corregir esos errores sin necesidad de volver a enviar.
(Por ejemplo, en Bizkaia, en el capítulo 1.2 del LROE. O en Gipuzkoa o Alava mediante el servicio Zuzendu).

Pero, en cualquier caso, la emisión de la factura (y su encadenamiento) y la obtención de los códigos TBAI y QR son temas de tu aplicación de facturación e independientes del posterior envío y aceptación (o no) por parte de Hacienda.

Para corregir los errores, después, ya hay otras vías, pero la factura emitida firmada y encadenada es cosa tuya y no se debe poder borrar ni alterar en ningún caso (Nueva Ley General Tributaria Antifraude)

Saludos

Aunque no ingrese en su sistema (caso de que el xml sea rechazado como indicas) ese XML se corresponde con una factura perfectamente válida ya emitida por el software y como dice @sistel, eso va a misa. Para solventar el problema luego se tendría que realizar un Zuzendu de subsanación en el caso de Guipuzcua y Alava con lo que el QR de esa factura ya emitida y que tendría en poder el cliente, empezaría a funcionar correctamente porque la factura ya estaría "dada de alta" por asi decirlo, en su sistema.

Deberías de diseñar el sistema para que fuese autónomo de manera que si hubiese un problema de conexión (los servidores de IZEMPE se caen o están "en mantenimiento", o la conexión a inet se va por avería), el software pueda seguir emitiendo facturas con encadenamiento, QR e identificador tbai. Eso fue una de las cosas que más me costó entender en un principio ...

Intuitivamente, me cuesta aceptar entregarle al cliente información potencialmente erronea que pueda suponer un conflicto para el vendedor pero si hacienda no le va a "buscar las cosquillas" pues lo haré así.
Muchas gracias, sistel y trumbold, por la ayuda.

Hola a todos,

No sé si esto ha sido respondido, pero pregunto

Cuando generamos el .xml, hay alguna forma de saber si es valido o no antes de mandarlo, a nivel de sintaxis y a nivel de informacion.
Si fuera erroneo intentaría rehacerlo y no generar la cadena de .xml erroneo + envio + error en pantalla + llamada del usuario + .xml de anulacion
Lo digo porque sobre todo al principio puedo generar algunos .xml erroneos y claro eso conllevara problemas y quizas anulaciones


Gracias de antemano

Hola xamminf,

Sí. Puedes usar un verificador para comprobar que el XML cumple el esquema XSD de TicketBAI.
Yo programo en PHP y para verificar los XML creados utilizo la función DOMDocument::schemaValidate (https://www.php.net/manual/es/domdoc...schemavalidate)
Supongo que todos los lenguajes tendrán alguna función similar.

Pero ojo, la verificación deberías hacerla no sólo antes de enviar el XML a Hacienda, sino antes de emitir realmente la factura.
Los pasos que yo hago son:
- Recabar y comprobar todos los datos que compondrán la factura.
- Recabar los datos necesarios de la factura anterior para el encadenamiento.
- Creación del XML
- Firma del XML
- Verificación del XML frente al esquema XSD de TicketBAI

Si pasa la verificación, obtengo los códigos TBAI y QR y doy por emitida la factura.

Si no pasa la verificación, no puedo emitir esa factura (ni me molesto, en ese caso, en obtener los códigos TBAI yQR).

Hasta que no pasa la verificación no doy como utilizado el número de factura que le había asignado provisionalmente: la factura no está aún emitida.

El tema del envío a Hacienda es algo posterior (y sólo una vez emitida la factura)

Saludos

Sistel muchas gracias por tu detallada informacion

Hola, de nuevo.

Expongo la problemática y una solución, a ver si estoy en lo correcto y si alguien más se ha encontrado con esto y le sirve de ayuda.



En entornos multipuesto, varios usuarios var a querer obtener la última factura emitida al mismo tiempo:

a.Ultima factura firmada es 1
b.Equipo PC1 crea factura 2 y su xml, busca ultima factura (1) y firma
c.Mientras tiene lugar el proceso b. los equipos PC2, PC3, PC4 crean sus facturas (3,4,5) y sus xml y buscan la ultima factura.
d.Si b. no ha acabado (por el motivo que sea) todos encontrarán que la ultima factura sigue siendo 1 y todos querran incluirla en el encadenamiento.


Si se pudiesen firmar los xml en el servidor, no sería problema: se crea un cola y ya se procesará allí. Pero en las faq (8.10) indica que es el equipo emisor de la factura el que tiene que realizar la firma.

Para solucionarlo estoy creando este flujo de trabajo, a ver que os parece.


a.Equipo PC1 crea XML en una carpeta del servidor
b.El servidor busca la última factura firmada.
c.El servidor agrega el encadenamiento al fichero XML
d.El servidor comunica a Equipo PC1 que ya puede firmar
e.Equipo PC1 firma y lo comunica al servidor

f.El servidor envia el fichero y continua con el siguiente XML de su lista.
g.Equipo PC1 ya puede imprimir, exportar o enviar por correo electrónico.



Creo que también podría "obligar" al usuario a tener una serie en cada equipo (faq 14.1) pero los clientes, habitualmente, quieren poder imprimir facturas correlativas desde cualquier puesto de trabajo.

Otra duda sobre algo que, supongo, estará permitido. He enviado la consulta a hacienda pero la respuesta me ha dejado dudas.



En multipuesto y con una misma serie el fichero xml, su firma y envio de la factura 1000 puede ser posterior al envio de la factura 1001 debido a que la 1000 es una factura que está siendo revisada, o se ha dejado a medias en el almuerzo o la comida, etc. y la 1001 es una operación rápida de un cliente que está en el mostrador.


¿Supone algún problema?
Gracias.

Hola Ja Mon,

El procedimiento que propones puede crear un cuello de botella si el PC tarda mucho en firmar.

Y sí que está admitida la firma en servidor.
Lee las especificaciones de firma de TicketBAI. Hay tres modalidades admitidas:
- Arquitecturas con firma en cliente
- Arquitecturas con firma en servidor
- Arquitecturas con posibilidad de firma en cliente y en servidor

Firmar en servidor te permite tener un único certificado digital y aislar el tema de la firma de los problemas que pueda tener un PC.

Saludos

Hola Ja Mon,

No debe retrasarse la firma y envío en ningún caso.
(El envío sólo podría retrasarse en Bizkaia que se envía mediante LROE)

Yo considero que la emisión de la factura tiene lugar en el momento que se firma crea y firma el XML y debe llevar esa fecha y hora.
No se puede crear un XML y firmar más adelante.
Se trata de que todas las facturas sean consecutivas, con fecha y hora de la emisión y con envío inmediato.

Saludos

Ok. Creo que es una confusión con los términos. En 8.10 dice


Sí, si bien la firma del fichero XML TicketBAI se deberá realizar en el dispositivo en elque se genere la factura, el envío a la Administración podrá hacerlo tanto el propio
dispositivo de facturación como otro dispositivo diferente,por ejemplo, un servidor
centralqueenvíe losficheros devariosdispositivos defacturación


¿debo entender que el dispositivo en elque se genere la factura es el equipo donde se genera el xml, no el equipo donde está abierta la factura e inicia todo el proceso?

La duda que tengo no es el momento de firma y envio, sino si, al haber varios usuarios creando facturas simultaneamente, se pueden firmar y enviar por orden de solicitud o tiene que ser por orden de numeración. Es decir, un usuario acaba la factura 100, crea el xml y lo quiere firmar y enviar; pero hay otro usuario que está revisando la factura 99 antes de firmarla y otro la 98 que ha salido a almorzar, por ejemplo, y no lo las firmarán hasta pasado un tiempo. ¿Supone un problema enviar antes la 100 que la 99 y 98? Es que esto ocurre muy a menudo

Hola Ja Mon,

Yo así lo entiendo.
Para mí la emisión de la factura es el momento en que creo el XML y lo firmo (en el mismo equipo) con la fecha y hora de ese momento.
Después ya extraigo el código TBAI y código QR para meterlos en el documento-factura y envío a Hacienda Foral.

Saludos