Tabular “completeness” validations in UK and Gibraltar returns
FIX PENDING NEXT APPLICATION UPDATE
Description: This issue ONLY affects users in UK and Gibraltar. Further, note that the actual Return Setup process is NOT affected by this issue i.e. the rules for generating the QRTs in the workbook within Return Setup process is correct. However, the validations within Tabular that check for QRTs incorrectly included or not included (when comparing to the Company Setup profile) is not working correctly in relation to some QRTs (being those which were changed in the 2.8 taxonomy). The issue is that this Tabular validation is applying the rules based on an EU insurer profile and hence producing incorrect results e.g. it is not expecting QRTs like S.17.02 (this has been retired in the 2.8 EIOPA taxonomy) and instead would expect S.17.03 (the replacement for S.17.02 in the 2.8 EIOPA taxonomy)
Workaround: Note that given the actual Return Setup process is NOT affected by this issue in most cases these validation results can just be ignored.
Versions: 9.0.0.0, 9.0.1.0, 9.0.2.0, 9.0.3.0
S.30.03 C0245 formula
FIXED IN 9.0.0.5
Description: Due to an error in the formula it always produces a #VALUE result
Workaround: Remove the interaction formulas from this column and enter correct value. Also ignore the associated validation: SIIS_S3003C0245c
Versions: 9.0.0.3
EIOPA_V2.8.0_V.1 fails for non-mandatory LEI code fields
FIXED IN 9.0.0.5
Description: Due to a technical error this validation incorrectly fails for a small number of cases with blank identifier codes but this field is not mandatory and so an empty value is allowed e.g. S.06.02.04.01 and S.08.01.04.01 C0020 and C0030
Workaround: Ignore the associated validation results
Versions: 9.0.0.3
P.04.05.21 C0010 R0021, R0022, R0031, R0032, R0041, R0042, R0051, R0052 formula incorrectly bring in values relating to “Direct” business
FIXED IN 9.0.0.5
Description: These Tabular formulas should bring in data relating to accepted reinsurance business but instead bring in data relating to direct business. Note that the other columns in this QRT (eg Top countries 1 to 5) are correct.
Workaround: Remove the interaction formulas from these affected datapoints and enter correct value
Versions: 9.0.0.3
S(E).01.01 R0775 is not populated when QRT excluded
FIX PENDING NEXT DATA UPDATE
Description: Tabular normally populates the S(E).01.01 sheet automatically (during create/edit return process) but due to a data error R0775 in S(E).01.01 annual returns it is left empty when the QRT is not included (instead of showing “Not reported due to ….”). XBRL validations detects that one or more rows in S(E).01.0 is empty and flags a Blocking validation error (but because it is testing every row within one validation it is not clear from the validation result which row(s) are empty). The relevant xbrl validation codes areBV1251 in an annual solo (without ECB Add-ons) and BV1263 in an annual solo with ECB Add-ons.
Workaround: Enter the appropriate option from the S(E).01.01 R0775 dropdown
Versions: 9.0.0.3
QRT_Population validation is showing incorrect results in some special cases
FIXED in 8.0.0.0
Description: This validation says you need to add a specific QRT due to some rules being changed, but in some special cases, this might not be true. Due to the nature of the bug, we can’t list all the cases but one known issue is for S.26.05 for a life firm with health slt business. You can easily check if the validation is actually correct or not using edit return. Go into edit return and in the QRTSelection tab check the status of the QRT from the VL, in the above case you would not have S.26.05 so that means the Validation is false. If it was marked as included (and an tag of added) that means the validation is correct and you should indeed add the QRT.
Workaround: Just ignore the validation
Versions: 7.0.0.0
Auto generation of N.IE.13 data includes numbers from last period as well
FIXED in 4.1.0.2
Description: The auto-generate NST.13 feature can include SE.06.02 data records relating to the previous quarter’s return. This is due to an invalid condition within the feature SQL that should filter out all SE.06.02 data within the Tabular database except that for the current return, but does not in all cases.
For example, running the auto-generate NST.13 feature for the Q1 2019 return; the error meant that Tabular would load into the current return’s NST.13 sheet the transformed SE.06.02 records from the Q1 2019 AND the Q4 2018 return – resulting in NST.13 containing incorrect data (essentially double-counting the SE.06.02 data sets from current and previous returns for all asset IDs found in both returns). Note the same problem affects the validations.
Workaround: None
Versions: 4.1.0.1
UK NST.07 (N.UK.07.01.Y0) R1000 reconciliation with s.05.01
FIXED IN 4.1.0.1 DATA UPDATE
Description: Based on the BoE LOG guidance (https://www.bankofengland.co.uk/-/media/boe/files/prudential-regulation/regulatory-reporting/insurance/nsts/ns07-log-file-31-12-18.pdf?la=en&hash=4635B083B45CA36C8FC6D26B5D870BC0E86F2DE0) the formula (and accompanying cross-QRT Tabular formula) in N.UK.07.01.Y0 C0010 R1000 is linking to S.05.01 R0550 (+R1900 where available)
We think this is a mistake in the BoE guidance and will contact the BoE to inform. The formula will be updated in the next Tabular update to reference R0500 + R1800
Workaround: None
Versions: 4.1.0.0
EV55 validation gives invalid result
FIXED IN 4.1.0.1 DATA UPDATE
Description: EV55 validation gives invalid result incorrectly checking that E.03 and/or S.17.02 amounts specified by country are EQUAL to 90% of S.17.01 (total) instead of being greater than or equal to the S.17.01 (total)
Workaround: None
Versions: 4.0.0.0
Return Setup includes S.04.01 when ‘Company > Business undertaken outside home country’ is not selected
FIXED IN 4.1.0.1 DATA UPDATE
Description: S.04.01 sheets should only be included in the return where ‘Company > Business undertaken outside home country’. However, due to a setup error Tabular is including S.04.01 sheets in the annual return even when this option is not selected
Workaround: Set S.04.01 worksheets to ‘not include override’ in QRT Selection screen (note this can be done in edit return also)
Versions: 4.0.0.0
*BV779 validation with severity ‘Blocking’ instead of ‘Non-Blocking’ *
FIXED IN 4.1.0.1 DATA UPDATE
Description: The wrong severity has been assigned to this validation. Please read the result as ‘Non-Blocking’ instead of ‘Blocking’. For example, there are cases where CIC 8 where S(E).06.02 C0110 is required and in these cases this EIOPA validation should flag a ‘Non-Blocking’ validation for users to confirm C0110 has been filled appropriately.
Workaround: For now you can just ignore this validations where not applicable
Versions: 4.0.0.0
BV1014 validations do not detect where S.08.01 C0150, C0160, C0170, C0180, C0210, C0220 are 0
FIXED IN 4.1.0.1 DATA UPDATE
Description: These fields should be >=0 according to the xbrl Non-Blocking validation, however Tabular only flags when they are <0 i.e. if their value is 0 the validation should flag an error but doesn’t
Workaround: None
Versions: 4.0.0.0
BV993 validations give invalid result for valid S.08.01 CIC
FIXED IN 4.1.0.1 DATA UPDATE
Description: The S.06.02 valid CIC list has incorrectly been used for validating appropriate CIC usage in S.08.01
Workaround: For now you can just ignore this validations
Versions: 4.0.0.0
Workbook shows that it is being used by another person but noone else have it opened at the moment
FIX PENDING
Description: This is usually just a consequence from workbook being corrupted or just showing some message that goes behind the main window, but is locking the workbook so it is shown as read only.
Workaround: You can try few things. Open the workbook not by double clicking on it, but by opening Excel first and then File-> Open. This changes the order of opening events, so can help in the scenario. You can also just click to open the workbook in read only mode. Then usually you will see what is the actual problem leading to this message. If it is workbook corruption – check this article for how to resolve. When the underlying issue is fixed – it should stop showing this message.
Versions: 3.0.0.0 and above
Facts with integer values – xbrl ri facts are reported with 1 decimal digit instead of 4
FIXED in 4.0.0.0
Description: The xbrl documents are vague on the number of decimal digits required for ri facts and we implemented with 1. At some point some regulators started to require them to be with 4 decimal digits.
Workaround: none
Versions: 3.0.0.0 and above
Workbook is corrupted and needs recovery
FIX PENDING
Description: It is not directly related to Tabular but more the combination of big workbooks with a lot of sheets, lots of named ranges and mostly external workbook links. It happens mostly to clients using links to Siimplify workbook.
Workaround: Usually just clicking repair for the workbook will be enough. Note the repaired workbook is up to date and it is not reverting some of your data changes that you made last. More info you can find in this article.
Versions: 3.0.0.0 and above
Using edit links menu to change the source of a link throw error
FIX PENDING
Description: In some cases when a user uses the Tabular integrated edit links and try to change the source of a linked workbook an error will show stopping or the process (you might need to forcefully close excel as it shows error for every formula).
Workaround: User can delete and add again the links manually if they are not that much. If they are a lot – user can export the sheets with the links to Excel and then modify the links in the export using the Excel edit links and then Import this file into the workbook using the preserve user formula option. You can also contact support so they can help by unprotecting your workbook and using the default excel edit links.
Versions: 3.0.0.0 and above
Importing wrong values into Z named ranges in some QRTs
FIX PENDING
Description: The Z named ranges are usually filled in from return setup and locked and you can’t edit them in Tabular. However due to a gap in import you can import a value over them and when this value is incorrect it breaks the XBRL export as this fields expect a specific value to generate the proper XBRL dimension.
Workaround: Either make sure you never manually change this fields in your import file(excel file etc..) or you can run edit return without changing any value in the return setup and this process will overwrite the Z values with the correct ones.
Versions: All
Dates exported to Malta NST workbooks are sometimes not correct if you use windows culture with different format than dd/mm/yyyy
FIXED in 3.0.0.6 DB version
Description: Dates exported to Malta NST workbooks(both quarterly and Annual) are sometimes not correct if you use windows culture with different format than dd/mm/yyyy. As we apply some conversions to this dates, for specific dates it is not converted correctly so you might end up with misplaced dates/months or no date at all.
Workaround: Change dates manually in the generated file
Versions: All
S.29.04 .01 for QRT was not being generated for Life companies
FIXED in 3.0.0.5 DB version
Description: For non-life insurers with non-life annuities exposures, the S.29.04 QRT for life business was not being included automatically in annual returns
Workaround: Add S.29.04.01.ALI via the ‘Add multicopy’ QRT in QRT selection
Versions: 3.0.0.0 to 3.0.0.4
S.29.04 Non-life annuities values incorrectly brought into S.29.03 Non-life column
FIXED in 3.0.0.4 DB version
Description: For non-life insurers with non-life annuities exposures, the formulas in S.29.03 reconciling with S.29.04 were not correctly allocating the non-life annuities S.29.04 QRT into the S.29.03 life column.
Workaround: Remove the Tabular interaction formulas and correct
Versions: 3.0.0.0 to 3.0.0.3
Roll forward feature doesn’t populate the H.HV sheet
FIXED in 3.0.3.0 application version
Description: Roll forward sometimes fails to extract the data from the referenced return and fill the H.HV sheet. This might be caused by having PrintAreas NamedRanges in it or having hidden formulas(present in some Malta NSTs)
Workaround: You can get around the issue by running the macro from this link the referenced return and then repeating the process (you can run Tools->Refresh H.HV helper sheet)
Versions: 3.0.0.0 to 3.0.2.0
UK NST data points not populated from Tabular return
FIX PENDING – Next Application Release
Description: Due to the protection levels in this workbook is not possible to populate all NSTs. The following are not populated or only partially populated:
NS.08
NS.09 C0090 and C0100
NS.11 is pre-set to populate up to 3 instances of NS.11. If you have more than 3 combinations of accident year/underwriting year, line of business and currency to be reported please contact our support team who can configure to support additional instances. Note NS.11 r0310 – r0370 (inflation rates) are not populated
Workaround: You can get around the issue by manually entering these values into the applicable cells in the PRA workbook generated by Tabular
Versions: All
Tools – Apply non ECB Transformation fails as it doesn’t export properly S.02.02, S.05.02
FIXED in 3.0.0.0 application version
Description: When have empty columns in S.02.02 or S.05.02 – Tabular tries to export the 0s that are in the formulas in this columns and because there is no currency selected Xbrl creation for this fact fails. Not this is handled in normal XBRL export but not for the Non ECB Transfomation.
Workaround: On the affected sheet select all the subtotals for the non used columns, select Subtotals > Selected Cell > Delete formulas. This will remove the formulas in this columns and then you should manually delete all the 0s in this fields. Then export will work.
Versions: R.2.2.6.0 and below
S.26.01, S.26.05, S.29.04 subtotal in sheet formula is hardcoded to 0
FIXED in 2.2.1.8 DB version
Description: There are some cases where the Tabular return workbook incorrectly has the subtotal formula removed in the sheet, instead the cell is set to 0 value (no formula in the cell).
Workaround: On the affected sheet, select Subtotals > Selected QRT > Replace formulas. This will reload the correct formulas
Versions: R.2.2.1.7 and below
S.21.03.01.AS is not generated when Assistance lob selected for euro currency
FIXED in 2.2.1.8 DB version
Description: When in Return Setup is selected Assistance LOB for euro currency or Non Material — the corresponding S.21.03.01 QRT is not generated.
Workaround: Ask SolvencyIISolutions support team for a custom upgrade file, to fix for you.
Versions: R.2.2.1.7 and below
Invalid formulas in S/SR.26.01 and S/SR.26.03/04 in pre-R2.2.1.2 DB created returns
FIXED in version 2.2.1.2DB version
Description: Problem is that although this formulas are fixed in latest data(2.2.1.2), due to a technical limitation they are not directly corrected into this templates. The affected fields and cases are:
SR/S.26.01 c0080 r0100, S/SR.26.03/04 c0080 r0400 -Gross SCR figure for interest rate risk and lapse risk respectively
Correction to take into account the scenario used to derive the net SCR figure and utilise this scenario from the gross figures
SR.26.01 c0080 r0100, c0060 r0420, SR.26.03/04 c0060 r0400 Net SCR figure for interest rate risk, credit derivative risk and lapse risk respectively
Correction to include the impact on the firm as a whole for each of the bidirectional scenarios and to use within each RFF SR. QRT the applicable scenario
Workaround: Go in this sheets and do a Subtotals -> Selected QRT -> Replace Formulas from the ribbon and the same with Interactions -> Selected QRT -> Replace Formulas. This will replace the formulas with the correct ones.
Versions: R2.2.0.0 and R2.2.1.1 DB
Slow performance when exporting group of sheets to Excel
Fixed in version 3.0.3.0
Description: You can get slow performance if exporting number of sheets to Excel. The performance decrease the more sheets are selected and especially if they are multicopies or with a lot of interactions.
Workaround: If you export to Excel the whole workbook the performance will be much faster as checks if interactions are broken is not performed.
Versions: 2.2.3.0
Validation error when don’t complete primary key fields (e.g. reinsurer code, broker code) in list QRTs
FIXED in version 2.2.3.0
Description: You can get validation error when don’t complete primary key fields (e.g. reinsurer code, broker code) in list like S.31.01.01.02
Workaround: If this is a subtable of a QRT e.g. S.31.01.01.02 but S.31.01.01.01 is completed then this validation can be ignored and the S.31.01.01.02 table can be left empty
Versions: 2.2.0.0
Some formulas not right when language setting of excel is not English
FIXED in version 2.2.3.0
Description: Few complex array formulas in S(E).02.01 might not work as expected when language setting of Excel is not set to English. If you notice such issue contact support so they can explain and provide workaround
Workaround: For workaround contact support
Versions: 2.2.1.0
Annual MFSA NST export is not working
FIXED in version 2.2.3.0
Description: Although the option is added to the ribbon under Export it is not working at the moment.
Workaround: No workaround
Versions: 2.2.1.0
EV35 and EV38 validations give invalid result when you have SE.01.01.16 and E.01.01.16 both in the return
FIXED in version 2.2.1.0
Description: When have E.01.01.16 an SE.01.01.16 in same return — they get mixed up and you are getting the wrong result in EV35 and EV38 validations. They show DataError as Actual Value.
Workaround: For now you can just ignore this validations which will not affect your filling in any way.
Versions: 2.2.0.0
LEI code type and code not properly exported to XBRL from S.01.02.01
FIXED in version 2.0.2.2
Description: Our XBRL engine should do the combination of S.02.01 R0030 and R0020 for you but the call to the code that does this was dropped accidentally as part of the reworking of the XBRL engine to account for large datasets in 2.0.2.1. This is why Tabular validation passes for you when you have the LEI code without the LEI prefix in R0020 but fails when you add it because the validations think the XBRL will then be LEI/LEI/[LEIcode].
Workaround: You can get around the issue by entering the LEI prefix directly in R0020 – although of course Tabular will give a validation error
Versions: 2.0.2.1
Validations for S.25.01.01.SF fails with “Cannot convert type ‘System.DBNull’ to ‘bool’ “
FIXED in version 2.0.1.0
Description: The workbook contains an invalid NamedRange for the specified QRT and it causes the Completeness validations to give error
Workaround: You can get around the issue by removing the PrintArea named range from the list of NamedRanges in the workbook
Versions: 2.0.0.0
Vendor tag was added to the instance generator and this was not accepted by CBoI
FIXED in version 2.0.2.0
Description: When create an XBRL file at the top there is Instance generator tag which we exported like that:
< ?instance-generator id=“Tabular” version=“2.0.1.0” vendor=“Solvency II Solutions Ltd” creationdate=“2016-04-05 11:52:17” ? >
This was causing an error at the CBoI test window. The error is “Declaration of software vendor is missing or incomplete in the instance document “
Workaround: You can get around the issue by removing vendor part of the Tag, so resulting string becomes:
< ?instance-generator id=“Tabular” version=“2.0.1.0” creationdate=“2016-04-05T11:52:17” ? >
Versions: 2.0.0.0, 2.0.1.0
Import breaks Array formulas in S.02.01
FIXED in version 2.0.4.0
Description: After importing data to the S.02.01.01 array formulas are broken. Array formulas are marked as : {=C0030_R0040+ etc…}
After the import the {} are removed so this becomes normal formula and give completely different result.
Workaround: You can get around the issue by using the replace interactions option from the Ribbon. Interactions -> Selected QRT -> Replace formulas
Versions: 2.0.0.0, 2.0.1.0, 2.0.2.0, 2.0.2.1, 2.0.2.2
XBRL incorrectly exports code type as NONE instead of None
FIXED in version 2.0.2.0
Description: Our XBRL engine was exporting NONE value for issuer/counterparty/group code type fields (usually in lists like S.06.02, S.08.01 etc…) and this was not passing the validations on regulator portals as its case sensitive.
Workaround: You can get around the issue by finding and replacing the NONE values in the XBRL file with None
Versions: 2.0.0.0, 2.0.1.0
Feedback
Post your comment on this topic.