...
El caso de que el destinatario de la operación no sujeto a normativa foral en el IS o IRPF emita la factura en nombre y por cuenta del obligado tributario sujeto a Batuz es un supuesto de exoneración del cumplimiento de TicketBAI. Es decir, el destinatario no tiene que cumplir con TicketBAI en la emisión de dicha factura. No obstante, el obligado tributario sujeto a Batuz, su representante o un tercero autorizado debe informar de dicha operación en el subcapítulo 1.2 del LROE.
Si el destinatario de la operación sí que está sujeto a normativa foral en el IRPF o en el IS, deberá cumplir los requisitos TicketBAI en la emisión de la factura, indicando una “D” en el campo “Factura emitida por el destinatario
de la operación” y encadenándola con las otras facturas emitidas en nombre de ese NIF en su sistema. Esta factura contendrá un QR y el identificativo TicketBAI. Posteriormente, la anotación correspondiente a esa factura deberá remitirse al LROE del obligado tributario, mediante el subcapítulo 1.1. La remisión la podrá hacer el obligado tributario, su representante o un tercero.
7. Cómo ejecutar la transaccion FB01 correctamente con la instrucción CALL TRANSACTION” para que los documentos contables se generen correctamente junto con los registros TicketBAI.
En el caso en el que se utilice un programa Z para crear facturas y en este programa se haga un CALL TRANSACTION a alguna de las transacciones estándar de creación de facturas como puede ser la fb01, el proceso TBAI no podrá realizar su flujo de forma correcta a no ser que se haga el call transaction con un parámetro especial. Debido a que en el flujo de TBAI se realiza un commit work para actualizar las tablas de base de datos, esto hace que se interrumpa el procesamiento lógico del call transaction y tras el commit se devuelva el control al programa que inicio el call transaction, dejado código del flujo de TBAI sin ejecutar.
Un ejemplo de llamada sería la siguiente:
| Bloque de código |
|---|
DATA : l_s_options TYPE ctu_params.
l_s_options-racommit = 'X'.
CALL TRANSACTION 'FB01' USING bdc_tab MESSAGES INTO t_messtab OPTIONS FROM l_s_options. |
De esta forma, con la opción racommit indicamos que no se va a interrumpir el procesamiento lógico del call transaction cuando se encuentre un commit work y así pueda ejecutarse completamente el flujo de TBAI.
8. Creación de altas negativas desde transacción FB08
En el estándar de producto, actualmente cualquier factura que se cree desde la transacción FB08 se está generando como una anulación porque se chequea que el campo stblg esté relleno
Se da el caso de que algunos clientes no generan anulaciones, sino que generan altas negativas desde esta transacción.
Si es el caso, se deberá comentar la parte del código adjunta para que omita esta validación. De esta manera se creará un alta siempre que la CREAN tenga configuración para ello.
...
9. Anulación y rectificación de facturas enviadas al SII anteriores a la entrada en vigor de BATUZ
No podrán enviarse rectificaciones o anulaciones de facturas anteriores a la entrada en vigor de BATUZ.
Las facturas de alta declaradas en el SII que necesiten ser anuladas o rectificadas, deberán remitirse a través del SII y no de BATUZ.
Para ello será necesario generar una excepción en las tablas de excepción de creación de registros TBAI y LROE para que no se generen entradas anteriores a la fecha de entrada en producción.
De esta manera, los registros no entrarán en los monitores de BATUZ y las anulaciones y rectificativas correspondientes a las altas anteriores a esta fecha entrarán en el monitor del SII para poder declararlas a través del sistema original de envío.
En el caso de que su empresa no aplique al SII, al generar estas excepciones, se controlará que si la factura de alta es anterior a la fecha de la excepción, la rectificativa o la anulación directamente no se genere.
Por ejemplo, si una empresa entra en producción en el servicio de BATUZ en fecha 01.01.2022 generará las excepciones siguientes:
Excepción tabla TBAI
...
Excepción tabla LROE
...
10. ¿Se informan los suplidos de las facturas de servicios en el XML?
Los suplidos no es un campo que haya que informar en el XML. El suplido es un pago por cuenta del cliente a un tercero y por tanto no forma parte del ImporteTotalFactura ni de la Base Imponible.
En el caso en el que, en una factura, por ejemplo, además de los honorarios de un profesional se documentase un suplido, el importe del suplido no formaría parte de la base imponible del IVA pero estas facturas deben cumplir igualmente los requisitos TicketBAI.
En este caso, cuando los suplidos vayan encuadrados en una factura por prestación de servicios, se podrá disponer de un campo para los suplidos después del Importe Total Factura, donde deberá informarse de los suplidos que contenga la factura. En cambio, si únicamente se quisiera documentar un suplido, se trataría de una operación en la que no se documenta ninguna entrega de bienes ni prestación de servicios, ya que en estos casos el empresario actuaría como mero intermediario, satisfaciendo sumas de dinero del cliente a un tercero por mandato expreso.
En este último caso, no habría obligación de expedir factura de acuerdo con lo dispuesto en el Reglamento de facturación, pudiéndose documentar la operación en un recibo u otro justificante. Por tanto, un documento en el que solo se informe de un suplido quedaría fuera del ámbito de aplicación de TicketBAI.
11. Facturas emitidas con descuento
El “Descuento” en factura es un campo opcional en las facturas emitidas. Este campo deberá informarse con el importe total del descuento.
El producto TicketBAI no mapea este campo con los campos de SAP por lo que si un cliente desea informarlo deberá gestionarse desde proyecto.
Adicionalmente, es posible que, la base imponible de las posiciones de dicho documento no se estén informando de forma correcta. Esto ocurre cuando al descuento se le aplica un iva repercutido y este aparece con saldo debe en la factura.
Para este caso de forma excepcional deberá modificarse el mapeo del campo “BaseImponible” de bseg- hwbas a bset-hwbas:
...
El cambio a realizar deberá ser:
Sustituir lv_base_imponible = -hwbas por lv_base_imponible = ls_bset-hwbas
12. Error al enviar XML “El XML no cumple el esquema”.
Cuando enviamos a la agencia tributaria un XML con algún campo obligatorio vacío nos devuelve el siguiente error que es muy poco interpretable:
”El XML no cumple el esquema.[Linea:1 Columna:663310] Error:cvc-enumeration-valid: Value '' is not facet-valid with respect to enumeration '[1, 2, 3, 4]'. It must be a value from the enumeration.”
Este error lo que dice es que si el XML fuese una única fila el error está justo en la columna 663310. Esto si el XML es muy grande porque incluye muchas facturas, por ejemplo un lote con 50 facturas, se puede hacer un poco tedioso buscar que campo vacío es el que falla.
En este ejemplo una pista es los valores [1, 2, 3, 4] ya que el error te esta diciendo que esperaba esos valores. Si conocemos mas o menos que valores llevan ciertos campos del XML podemos deducir que campo es el vacío.
En este ejemplo el campo vacío es SituacionInmueble , pero puede ser que no sea el único campo que espera esos valores.
...