Spain

SII update

New checks have been implemented to consider the new validations from the Spanish Tax Authority (AEAT) effective since October 2019.

SII legal changes

On June 30, 2020, the Spanish Tax Authority published a document with the new validations for SII. The validations came into effect on January 4, 2021, and are intended to improve the quality of the information provided.

To comply with the legal requirements and to prevent the rejection of the SII file by the tax authority, LN now considers the new validations during these actions:

  • When the SII records are selected in the Select SII Transactions (lpesp2206m000) session
  • When SII transactions are manually changed in the SII Purchase and Sales Transactions (lpesp2106m000) session
  • When the XML is generated in the Generate XML Files (lpesp2208m000) session

If validation is not passed during any of these stages, you must correct the data before the file can be created.

The legal document also includes the introduction of a new SII book for Intracommunity Consignment Operations (LRVC). In LN, these consignment types are supported:

  • Consignment Owned: The administrative warehouse is replenished through a sales order or sales schedule transfer for which payment is set to Pay on Use. Customer consumptions are registered in the Inventory Consumptions (tdsls4140m000) session.
  • Consignment not Owned: The own warehouse is replenished through a purchase order or purchase schedule for which payment is set to Pay on Use. Consumptions can be triggered by any transaction, which results in a payable receipt or purchase order of type Payment.
Note: Both consignment types are not restricted to warehouses of type consignment owned or not owned.

If the localization parameter for Spain is selected in the Implemented Software Components (tccom0500m000) session for the financial company of the own warehouse, the replenishment and consumption transactions are published to the Localization (lp) package when the transaction happens. The own warehouse is the replenishment warehouse in case of consignment not owned, and the ship-from warehouse in case of consignment owned. In the Localization package, the data can be used to generate the required XML message.

The transactions are registered only if these conditions are met:

  • A VAT number has been registered for the sold-to and buy-from business partner.
  • The tax country of the sold-to and buy-from business partner are the same as the ship-to and ship-from country.
  • Goods move physically between Spain and another EU country.

Transactions are registered with a quantity in the inventory unit. The amount must be expressed in euros. In LN, the local currency of the own warehouse is used. Because this is a Spanish warehouse, this local currency must be euro. Conversion is done with the internal rate type (value in EUR from a Spanish company perspective).

If you use the old LN order types for consignment handling,that is, consignment replenishment, consignment invoicing, and consignment payment, the related SII consignment messages cannot be generated automatically in a consignment owned (sales) scenario. The messages cannot be generated for these reasons:

  • At the moment of replenishment, the sales amount is not known. The amount always is zero on the order line for orders of type consignment replenishment.
  • At the moment of consumption, the reference to the original replenishment is not known in LN. However, this reference is required to determine whether the consumption must be registered and to determine the original registration ID and transaction data, which are both elements of the message.

Using these specific order types is not blocked, but the replenishment and consumption message must be created manually. Therefore, we recommend that you do not use these specific consignment-related order types for consignment owned scenarios. Instead, use normal order types for which payment is set to Pay on Use. For this new type of consignment handling, the SII consignment messages are created automatically. This restriction does not apply to consignment not owned scenarios.

The SII ICT sales and purchase transactions can be verified in the SII for ICT Sales & Purchase Consignment (lpesp2136m000) session.

.

SII enhancements

A setup option has been added to identify the purchase invoices linked to an asset (Bien de Inversión). For a specified tax code, you can now select the Fixed Asset check box in the Exceptions by Tax Code (lpesp0102m000) session. When the tax code is used in a purchase invoice, the field is retrieved correctly in the SII Purchase & Sales Transaction Details (lpesp2116m000) session and the tag <sii: BienInversion> under <sii: DetalleIVA> is included when the XML file is generated.

The Blocked check box has been added to the Codes by Transaction Type (lpesp0101m000) session. This check box is used to automatically block a transaction before it is submitted to the Tax Authority. This to enable manual actions before submission. If the check box is selected, the transaction is selected by the Select SII Transactions (lpesp2206m000) session and included in the SII Transactions for Purchase (LRFR) & Sales (LRFE) (lpesp2606m000) session with the Blocked (lpesp206.bloc) check box selected.

Basque e-invoicing TBAI

For Infor customers who report to one of the Basque Tax Agencies, communication of TicketBAI invoice files is now available for LN. The communication uses the Infor Localization Services Platform (LSP) to generate the TicketBAI invoice xml file, sign it, generate the identifier and QR code, communicate it to the tax authorities, and return the outcome of the communication to LN.

LN setup
  • The localization for Spain must be activated in the Implemented Software Components (tccom0500m000) session.
  • The Electronic Invoicing parameter must be activated in the Spanish Parameters (lpesp0100m000) session.
  • Use External Invoicing System must be selected for the invoicing method in the Invoicing Methods (tcmcs0555m000) session.
LSP setup
In the Tax Reporting Translation Maintenance screen of LSP, specify the tax reporting translation for the tax codes that are used on the LN sales invoices. With this mapping, LSP can convert the LN tax codes that are received on the Invoice BOD to the standard codes used in TicketBAI. You must also specify, and specifically for non-domestic tax codes, whether the tax code relates to services.
Process
  1. After a billable line is composed in the Invoicing (cisli3600m000) session, the invoice can be submitted to the external system, through Actions on the Invoice tab. An invoice BOD is then sent to LSP.
  2. After receipt of the invoice BOD, LSP verifies whether a TicketBAI invoice xml can be created. LSP verifies whether it can map the tax code to one of the standard tax codes and whether the required information exists on the BOD. If the TicketBAI xml cannot be generated, this information is sent to LN, which changes the invoice status to Rejected by External System. In this situation, printing cannot proceed unless the error is corrected and the corrected BOD is resent to LSP.
  3. When LSP has managed to generate the TicketBAI invoice, it signs the invoice and generates the TicketBAI identifier and QR code, which are sent to LN where the invoice can be printed with these elements. Note that these input fields must be added to the invoice report using Report Designer so that they are visible on the printed invoice.
  4. After the QR code and TicketBAI identifier are forwarded to LN, LSP attempts to communicate the TIcketBAI xml to the tax agency. This does not affect the printing process, because printing can be performed already after signing the TicketBAI invoice xml in LSP. The outcome of the communication along with any error messages is displayed in the Electronic Invoice Information by Document (lpesp0111m000) session.
Limitations
These limitations apply to the process:
  • Credit notes without a linked original invoice are communicated as negative sales invoices to the tax agency and not as rectification invoices. This is because it is mandatory to identify the original invoice on the TicketBAI schema.
  • The TicketBAI field Clave for Regimen especial has a default value of 01 (General), except if the customer is outside the EU. In this case, the field is set to 02 (Export). Other special tax regimes are currently not supported.
  • To modify a TicketBAI invoice file that is signed but rejected by the Administration, a different webservice called Zuzendu must be used. This service is not yet supported.

Sales consignment in Modelo 349

Previously, the registration of intracommunity consignment operations via SII could be performed in the SII for ICT Sales & Purchase Consignment (lpesp2136m000) session.

Now, consignment operations are also included in the Modelo 349 output file if the Process Intracommunity Listing (tccom7270m000) session is run for declaration country Spain and option ASCII – Spain.

Note: Exporting consignment operations in Modelo 349 only occurs for SII consignment records with an operation type of 01 (Shipment), 02 (Substitution), or 07 (Replenishment Return), and a status of Accepted.

Accepted corrections specified for SII records are also considered on the output file. However, registration of corrections specifically related to Modelo 349 consignment operations is not supported.