Envío de Ficheros XML
El cumplimiento de la obligación TicketBAI contempla la creación de dos tipos de ficheros XML:
Fichero de Alta: fichero XML creado cuando se emite una nueva factura.
Fichero de Anulación: fichero XML creado cuando se cancela una factura. Por ejemplo, en el caso de transacciones que no se llevaron a cabo.
TicketBAI requiere que los ficheros se envíen a la Hacienda Foral que corresponda en función de la dirección fiscal del contribuyente que emite las facturas.
Araba y Gipuzkoa
SIGN ES realiza este envío automáticamente en Álava y Guipúzcoa. La información de facturación emitida por SIGN ES sirve de cara al libro de facturas expedidas del SII (Suministro Inmediato de Información) para aquellos contribuyentes que están obligados a su cumplimiento. Sin embargo, si se requiere más información contemplada por el SII - referencia externa, importe percibido por transmisiones de inmuebles sujetas a IVA, entre otros - entonces deberá enviarse a través del servicio adicional OSATU, no contemplado dentro de las especificaciones de TicketBAI. (Ver requisitos del servicio OSATU)
El proceso de envío de los archivos TicketBAI se lleva a cabo en el componente de firma de SIGN ES API. El componente de firma sincroniza el estado de los ficheros TicketBAI desde el servidor de SIGN ES hacia el servidor de la Hacienda Foral. Esta sincronización en implementada acorde al modelo de petición/respuesta provisto por las Autoridades Tributarias Españolas.
Vizcaya
Envío de facturas con SIGN ES
El envío se realiza mediante un certificado de dispositivo que debe ser registrado en DFB/BFA por el contribuyente. Esto debe hacerse antes de que el dispositivo comience a generar facturas en nombre del contribuyente.
Al enviar las facturas en tiempo real, garantizamos el cumplimiento de los plazos establecidos por BATUZ.
EMPRESAS: SIGN ES realiza el envío automático de facturas TicketBAI dentro del subcapítulo 1.1 del LROE - Facturas emitidas con software garante (Modelo 240). Este envío se realiza en tiempo real.
PARTICULARES: Una vez que se proporcione el código de actividad SIGN ES realiza el envío de facturas TicketBAI dentro del subcapítulo 1.1 del LROE - Ingresos con facturas emitidas con software garante (Modelo 140).
Idealmente, el activity_code
(código de actividad) debería proporcionarse en el momento de crear la factura. Esto permite la transmisión en tiempo real de la factura a las autoridades fiscales. De lo contrario, la factura permanecerá en estado STORED (ALMACENADA) y será enviada a las autoridades fiscales solo después de que la factura haya sido actualizada con el código de actividad.
Por favor, verifica que el código de actividad sea válido en Bizkaia, de lo contrario, la factura será rechazada por la autoridad fiscal.
Para particulares, existen dos campos adicionales opcionales: income_tax_amount
y pay_collect
que junto con el activity_code
forman un conjunto agrupado de datos. Si estos no se completan pero se proporciona el código de actividad, automáticamente serán marcados como 'No' por defecto.
Si la base imponible del IVA es diferente de los ingresos del IRPF, el contribuyente necesitará completar el campo income_tax_amount
. Para orientación sobre cómo calcular esto, puedes referirte a nuestro artículo ¿Cómo calcular el Importe Ingreso IRPF de una factura?
El campo pay_collect
es un indicador que especifica si el contribuyente ha optado por el criterio de cobros y pagos.
El código de actividad puede introducirse una sola vez, ya sea durante la creación de la factura o al actualizarla, y no puede modificarse posteriormente. Esto también se aplica a los campos de income_tax_amount
y pay_collect
, una vez que los envías con el código de actividad. Esto asegura que estos datos, una vez ingresados, permanezcan consistentes e inalterables.
El campo vat_withholding
en nuestra API podría aplicarse tanto a particulares como a empresas, específicamente a transacciones B2B que incluyen facturas completas y sus correcciones. Este campo se dirige a un escenario específico del sistema tributario que involucra a autónomos que, al emitir facturas a empresas u otros autónomos, están obligados a retener una parte del IRPF (impuesto sobre la renta de las personas físicas) sobre sus ingresos. En este sistema, es el comprador, no el vendedor, quien remite directamente una parte del impuesto a la autoridad.
Respuesta
Al recibir una solicitud, los sistemas de la Hacienda Foral de Vizcaya llevan a cabo procesos de validación automáticos. Los resultados de estas validaciones se reflejan en la respuesta de SIGN ES, similar a otras provincias.
Idealmente, el estado de registro debería ser REGISTERED
. SIGN ES ayuda a minimizar casos de rechazo al asegurar la estructura de los archivos XML y el formato correcto de los datos requeridos.
Sin embargo, si la factura requiera inspección (REQUIRES_INSPECTION
), los archivos deben ser reenviados a la Hacienda Foral de Vizcaya, siempre que no sea necesario emitir una factura rectificativa acorde al reglamento de facturación. Según el caso, esto se realiza a través del subcapítulo 1.1, dedicado a facturas emitidas con software garante, o el subcapítulo 1.2, dedicado a facturas emitidas sin software garante.
Reenvío de facturas emitidas
SIGN ES habilita el reenvío de facturas en el estado de registro REGISTERED
, REQUIRES_CORRECTION
y REQUIRES_INSPECTION
a través de facturas de tipo REMEDY
(subsanación) mediante el subcapítulo 1.1. El reenvío de facturas en los estados de registro PENDING
y STORED
no está permitido. Estas facturas se encuentran pendientes de envío por parte de SIGN ES o almacenadas debido a que no requieren transmisión a la autoridad tributaria.
El reenvío a través del subcapítulo 1.1 es posible si:
- el error se debe a datos incorrectos introducidos en los campos del bloque
annotations
- el certificado del dispositivo no fue registrado o fue registrado incorrectamente por el contribuyente al momento de enviar la factura
Si una factura necesita ser reenviada a través del subcapítulo 1.2, el contribuyente debe introducir los datos de la factura manualmente en la plataforma Batuz. Actualmente, estamos trabajando para habilitar el reenvío de facturas a través del subcapítulo 1.2, así que mantente atento a las próximas actualizaciones.
Entorno de pruebas
El Entorno de Pruebas en Vizcaya requiere un NIF específico, un número de IVA y un certificado de dispositivo para evitar errores de rechazo. En fiskaly, hemos solicitado formalmente y obtenido esta información de las autoridades. Estos detalles específicos reemplazarán automáticamente los datos de prueba proporcionados durante la creación de archivos XML, ÚNICAMENTE EN EL ENTORNO DE PRUEBAS. De esta manera, garantizamos un flujo de pruebas sin inconvenientes y con efectivas respuestas de transmisión.
SIGN ES API lleva a cabo validaciones que evitan el rechazo de los ficheros XML al enviarlos a la Hacienda Foral.