Enhanced Special scheme code setup
This hotfix provides an additional flexibility of Special scheme codes setup.
Sales tax group and Item sales tax group fields are added on the Additional fields setup in Electronic messages functionality:
These two fields can be filled or left blank independently. The current algorithm of searching Special scheme code for the register consists of 3 stages:
- Searching among records with Account code = Table for the particular customer/vendor.
- In case record not found on the first stage, searching is performed among records with Account code = Group of the customer or vendor.
- 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:
- 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
|
- 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
|
- 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
|
- 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 diverse types of Vat rate 0.00%.
Considering that in Spain, there are different cases 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 generation the reports to get "ImportePorArticulos7_14_Otros", "ImporteTAIReglasLocalizacion" tags filled in correctly.
Algorithm of adding Intra-community invoices
This hotfix provides new algorithm of identifying Electronic messages items of type "peracionesIntracomunitarias" according to the combination of the following criteria:
- Marked Intra-community parameter in Sales tax group (Tax > Sales tax > Sales tax group) for the sales tax transaction.
- Counteragent's primary address country is identified as "EU" in Foreign trade parameters > Country/region properties (Tax > Setup > Foreign trade > Foreign trade parameters).
- A counterparty should be included into SII intracommunity setup (Tax > Setup > Electronic messages > Message item additional fields, select TipoOperacion field).
Make sure you did correct setup of parameter for SIIGenerateItems executable class for TipoOperacion Additional field. To do so, open Tax > Setup > Electronic messages > Executable class settings, select SIIGenerateItems, click Parameters on Action pane and setup for "Intra-community operation ID" TipoOperacion value.
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 with manually updated values for Tax identificatory and Tax identificatory type, the following Additional fields were added to the SII processing:
Additional field name
|
Additional field description
|
Parameter name in SIIPartyAttributesEvaluation
|
ID
|
RegistrationID
|
Registration number
|
IDType
|
CounterpartyIDType
|
Tax ID type
|
CodigoPais
|
ISO code
|
Party ISO code
|
To evaluate values of these Additional fields, a SIIPartyAttributesEvaluation executable class introduced in scope of "Collections in cash" report hotfix, was included into the SII Electronic reporting processing.
Make sure you did correct setup of parameter for SIIPartyAttributesEvaluation executable class for Additional fields. To do so, open Tax > Setup > Electronic messages > Executable class settings, select SIIPartyAttributesEvaluation, click Parameters on Action pane and check parameter as per the table below.
Parameters description:
Parameter name in SIIPartyAttributesEvaluation
|
Field description
|
Registration number
|
Tax exempt number of the counteragent identified from the Counteragent's register information. If it is a EU counteragent, an ISO code is added as a 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 of these Additional fields 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).
NumSerieFacturaEmisorResumenFin tag filling is supported for summarized invoices
The hotfix provides an update for SIIGenerateItems executable class to support calculation of NumSerieFactura (Summary reference) Additional field. For customers invoice, it collects the value from the last ticket (receipt ID) related to the invoice in the reporting from the retail module or fill in with the invoice document number (this means that the invoice is not a summarized invoice). If the value in NumSerieFactura Additional field differs from the one in the Document number of the message item, then the invoice will be reported as summarized (<NumSerieFacturaEmisorResumenFin> will be printed). The NumSerieFactura Additional field's value can be updated manually if needed. Make sure if you are going to report an invoice as a summarized invoice TipoFactura field's value should be updated to "F4".
SIIGenerateItems executable class updated to cover the whole logic of evaluation of TipoFactura Additional field
This hotfix provides an update of SIIGenerateItems executable class to calculate value for TipoFactura Additional field. Value for <TipoFactura> tag in the reporting will be printed as it is predefined in TipoFactura Additional field value, no other calculation will be done on format generation. TipoFactura Additional field value is still available for manual update on Message items.
SIIGenerateItems executable class updated to support setup of parameters
This hotfix provides an update of SIIGenerateItems executable class to support setup of parameters to identify Additional field names to be updated during message items population in the Message items table: TipoFactura, TipoComunicacion, ClaveRegimenEspecialOTrascendencia, NumSerieFactura. See Setup part of this document to find more detail about values to be set up for these parameters.
SII Electronic message processing setup update
SII Electronic message processing setup updated to support evaluation of Additional field for a counteragent identification: ID, IDType, CodigoPais. See Setup part of this document to find more detail about values to be set up for these parameters.