Enhanced Special scheme code setup
To work with SII register, Special scheme codes should be setup for both Customers and Vendors. To do so, open General Ledger > Setup > Sales tax > Spain > SII Customer special scheme code or General Ledger > Setup > Sales tax > Spain > SII Vendor special scheme code respectively.
Two fields are added on the Special scheme codes table and form to make this setup more flexible:
Unique index was accordingly extended by adding these two new fields. These two fields are always enabled, and can be filled or left blank independently. The current algorithm of searching Special scheme code for the register consists of 3 stages:
1. Searching among records with Account code = Table for the particular customer/vendor.
2. In case record not found on the first stage, searching is performed among records with Account code = Group of the customer or vendor.
3. In case record not found on the second stage, searching is performed among records with Account code = All.
Searching on each stage valid dates of records are taken into account, and records which are valid on the register date should be selected only.
With adding two new fields, the whole algorithm remained the same (it still contains 3 main stages), but searching on each stage changed. When trying to search for the special scheme code for the register on each of the above-mentioned stages, now sales tax group and item sales tax group are taken into account. In order to get sales tax group and item sales tax group for the invoice, the first tax transaction is selected related to the current customer/vendor/project invoice. After that sales tax group and item sales tax group are passed as parameters to the method of searching special scheme codes.
Actually, searching by Sales tax group and Item sales tax group can also be divided into 4 sub-stages (they are all implemented for each of the above-mentioned 3 stages, until a suitable record will be found):
- First, we are trying to find a record which has Sales tax group and Item sales tax group not empty and equal to the values passed as parameters.
- If we can't find such record, we are trying to find a record having Sales tax group equal to the Sales tax group passed as a parameter and empty (empty means "any") Item sales tax group.
- If we can't find such record, we are trying to find a record having Sales tax group empty and Item sales tax group equal to the Item sales tax group passed as a parameter.
- Finally, if we can't find such record, we are trying to find a record having both Sales tax group and Item sales tax group empty.
Here are some examples. Let's say, we have invoice for the Customer = Cust001. The invoice has 1 line with 1 tax transaction having Sales tax group = TG and Item sales tax group = TIG. And we have the following setting of special scheme codes:
1. In this case, special scheme code 04 will be found for the invoice. Actually all 4 records meet the condition, but the 4th is selected because it corresponds to the invoice most fully.
Special scheme code
|
Account code
|
Account/group number
|
Sales tax group
|
Item sales tax group
|
01
|
Table
|
Cust001
|
|
|
02
|
Table
|
Cust001
|
TG
|
|
03
|
Table
|
Cust001
|
|
TIG
|
04
|
Table
|
Cust001
|
TG
|
TIG
|
2. In this case, special scheme code 02 will be found for the invoice, because it corresponds to the invoice most fully, and Sales tax group equality has priority over Item sales tax group equality.
Special scheme code
|
Account code
|
Account/group number
|
Sales tax group
|
Item sales tax group
|
01
|
Table
|
Cust001
|
|
|
02
|
Table
|
Cust001
|
TG
|
|
03
|
Table
|
Cust001
|
|
TIG
|
3. In this case, special scheme code 03 will be found for the invoice, because it corresponds to the invoice most fully.
Special scheme code
|
Account code
|
Account/group number
|
Sales tax group
|
Item sales tax group
|
01
|
Table
|
Cust001
|
|
|
03
|
Table
|
Cust001
|
|
TIG
|
4. In this case, special scheme code 01 will be found for the invoice, because it is the only one which meets the conditions.
Special scheme code
|
Account code
|
Account/group number
|
Sales tax group
|
Item sales tax group
|
01
|
Table
|
Cust001
|
|
|
03
|
Table
|
Cust001
|
|
SomeOtherTIG
|
So, schematically algorithm on each stage looks like this:
Sales tax code parameter to identify different types of Vat rate 0.00%
Considering that in Spain there are different case when Sales tax codes with 0.00% rate are used and there was no option to differ the following cases:
- ImporteTAI ReglasLocalizacion – to reflect transactions with other Spanish areas that do not have VAT but some internal indirect tax different than VAT (for example Canary Island, Ceuta and Melilla).
- ImportePor Articulos7_ 14_Otros – to reflect some other specific transactions.
There was shared a Type of tax field on Sales tax code table:
The Type of tax field may have different values but the followings should be used for Sales tax codes amounts on which should be reflected on corresponding tags:
Tag
|
Type of tax value
|
ImportePorArticulos7_14_Otros
|
VAT 0%
|
ImporteTAIReglasLocalizacion
|
Other
|
NOTE! Please update your setup of Sales tax codes before generating the reports to get "ImportePorArticulos7_14_Otros", "ImporteTAIReglasLocalizacion" tags filled in correctly.
Algorithm of adding Intra-community invoices
Previously the algorithm of Intra-community invoices identifying added all the invoices which have at least one Sales tax transaction with marked "Intra-community" check box into SII register. As in Spain "Intra-community" check box is used not only for Intra-community operations, the SII register was unnecessary filled in with extra invoices that should not be sent to SII system as Intra-community invoice.
To reduce a number of unnecessary intra-community invoices in the SII register, the algorithm was changed. To identify an invoice as intra-community, the following setup should be used: on Organization administration > Setup > Foreign trade > Foreign trade parameters form open Country/region properties tab and set up Country/region type = "EU".
Thus, only invoices with counteragents whose primary address ISO code set up as Country/region type = "EU" will be added to the SII register as Intra-community invoice.
IdOtro tag with code "07"
Sometimes when a Spanish counteragent’s tax exempt number (NIF) cannot be found in SII system’s data base an invoice cannot be accepted by SII system. At the same time, a Customer's invoice with unregistered in SII system's data base counteragent can be sent to the SII system identifying Tax exempt number of a counteragent in <IdOtro> tag with <IdType> = "07". In this case, such invoice will be Accepted with errors by SII system.
To support possibility of sending Customers invoices in this way, Tax registration tab was added on SII register form:
The Tax registration tab includes the following fields:
Field name
|
Field description
|
Registration number
|
Tax exempt number of the counteragent identified from the Counteragent's register information. If it is an EU counteragent, an ISO code added as prefix.
Can be manually updated if needed.
|
Tax ID type
|
This field can be filled in with a value from Registration IDs table or is empty is the Registration number is NIF.
Can be manually updated if needed.
|
Party ISO code
|
This field should be filled in by default with ISO code from the counteragent's primary address.
Can be manually updated if needed.
|
Values from the Tax registration tab will be used on XML report generating.
NumSerieFacturaEmisor tag - invoice number
Initially, SII register Export function generated XML report filling in the NUmSerieFacturaEmisor tag according to the official documentation:
Using as "No Serie" a combination of TableID and RecordID. Such invoice identification let invoices to be accepted by SII system but they cannot be further processed in SII system. Because for this purpose, an invoice should not have any prefix but should be registered with the invoice number only.
To let invoice be processed in the SII system, the export XML generation algorithm was updated to fill in NUmSerieFacturaEmisor tag with invoice number.
The scheme of a response from the Authority includes the following information about each of the previously included invoices:
Taking into account that <NIF> tag in the response includes the ISO code in case of all non-Spanish countries the information form the Authority response can uniquely identify an invoice in AX for all EU and Spanish companies.
Import XML parsing was updated basing on four parameters: Invoice register type, Invoice number, Invoices date, Tax exempt number (NIF).