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.
Respuesta
Cuando se envía un archivo, los sistemas de las autoridades tributarias realizan automáticamente varias validaciones, y los resultados de estas verificaciones se incluyen en la respuesta.
El estado ideal del registro es REGISTERED. SIGN ES ayuda a reducir los rechazos al garantizar que los archivos XML estén bien estructurados y que los datos estén formateados correctamente mediante sus procesos de validación.
Sin embargo, si el estado de registro de la factura aparece como REQUIERES_CORRECTION, puede ser necesario volver a enviar el fichero, siempre que las normativas de facturación españolas no exijan emitir una factura rectificativa.
Reenvío de facturas emitidas
SIGN ES permite el reenvío de facturas con estado de registro REGISTERED, REQUIERES_CORRECTION y REQUIERES_INSPECTION a través de facturas REMEDY a Zuzendu en los siguientes casos:
- los ficheros de alta han sido rechazados
- los ficheros de alta han sido aceptados con errores pero NO requieren una factura rectificativa por ley
- ficheros aceptados por TicketBAI, cuando el contribuyente necesita modificar información que no requiere la emisión de una factura rectificativa por ley
Si el error se debe a que el contribuyente no ha registrado el certificado del dispositivo en Álava o ha excedido el período de aceptación de 30 días en Guipúzcoa, el contribuyente debe registrar o aceptar el certificado del dispositivo, según corresponda, lo antes posible.
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.
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 los subcapítulos 1.1 y 1.2. 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 o porque falta información importante.
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
El reenvío a través del subcapítulo 1.2 es posible si:
- el subcapítulo 1.1 fue rechazado, y no es posible re-enviar a través del 1.1
- si la factura ya ha sido corregida y reenviada mediante el subcapítulo 1.2. También es posible subsanar nuevamente la factura ya subsanada, si la factura de tipo
REMEDYesté en el estadoREGISTERED
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.