The format-logical control (FLC) service is aimed at reducing regulatory risks for repository reporting, including the number of potential errors in the parameters of transactions reported by clients to the Repository.
Connecting to the FLC service allows you to:
- Avoid or significantly reduce the number of errors in transmitted messages and, therefore, reduce data logging costs.
- Conduct regular monitoring of unclosed contracts in the Repository Register on time.
- Monitor regulatory deadlines for information provided to the Repository.
- Minimize the likelihood of providing false information and comply with the deadlines for providing information, thereby avoiding potential sanctions from the regulator (Part 4 of Article 15.18 of the Administrative Code).
Introductory part
Reception and verification of electronic reporting at the Pension Fund of Russia can be divided into five stages.
Each stage involves data processing using a separate program. In some Departments, the transfer of information from one program to another occurs automatically. In other Directorates (in particular, in most UPFR of Moscow and the Moscow region), inspectors transfer data manually. With any of the options, each stage of the audit has its own characteristics, which are very useful for an accountant to know about. We will tell you in detail about all the stages.
First stage: digital signature verification
Having received reports via telecommunication channels (TCC), inspectors, first of all, check the existence of an agreement concluded between the Fund Management and the policyholder, as well as the relevance of the electronic digital signature certificate (EDS).
If the verification program does not confirm that the certificate is current and the agreement has been concluded, the company will receive an error message: “The digital signature was affixed with a certificate for which there is no concluded agreement.” This usually happens to those who report under the TCS for the first time, as well as to those who have recently changed their certificate due to expiration, replacement of the manager, or for some other reason.
Let's say right away that there is no reason to worry. This error is caused by the peculiarities of the fund’s software, which begins to “recognize” the organization’s digital signature only after it receives the report signed by it for the first time. Within four days, the certificate will be identified and the policyholder will be notified that the report has been received. Even if this happens outside the reporting period, inspectors should not impose a fine. And the next time the Pension Fund “recognizes” the electronic signature without delay.
Second stage: format-logical control
Next, inspectors carry out the so-called format-logical control. Its purpose is to ensure that reports are created without violating established formats.
At this stage, Pension Fund employees carry out verification using the CheckXML and CheckXML-UFA programs. Accountants can also use these programs to ensure that reports are correct before submitting them. You can install verification programs yourself, but then you will have to constantly monitor whether an update has appeared. In some electronic document management systems and reporting programs (for example, in Kontur-Extern, which is an online system where updates are installed without user intervention), they are already included, and the update occurs automatically. By the way, until September 30, the web service built into Kontur-Extern will be available free of charge to everyone (see “Insureds can prepare and check reports in Kontur-Report PF for three months free of charge”).
Practice shows that most “format” errors identified at this stage are due to flaws in accounting programs. In this case, the accountant needs to contact the specialist who supports the program and agree on troubleshooting.
Another common cause of error is the incorrectly specified address of the organization or insured person. It can be avoided if you install the latest version of the Russian Address Classifier (KLADR). A number of electronic document management systems (in particular, the above-mentioned online system “Kontur-Extern”) already contain this classifier and maintain its relevance.
Checking the program for updates
If everything is in order with the document, the data is filled out correctly, there are no errors or inaccuracies, you need to check if there is a new version for your 1C-Reporting program. Outdated program modules may cause error 508. And after updating, you can continue working without fear of sending new reports. Before checking and installing a new version, it is recommended to make a copy of the existing one. Because you never know for sure how this might end for your software.
- Select the “Configuration” item in the open program;
- Hover your mouse over “Support”;
- A drop-down menu will appear to the right of it, where you need to select “Update configuration”;
- If this item is not active at the moment, click the “Open configuration” line in the “Configuration” window.
Next, you should select a function that will automatically check and install available versions of the program on your computer. The update can be downloaded separately onto any media. Then use the same configuration update parameters to specify the path to them. After updating, it is advisable to restart the program for the new settings to take effect.
Third stage: pre-basic check of reports
The essence of this stage is to conduct an express check of the reports and place them in temporary storage.
Express check is carried out using the Perso PC software package. It is installed in the Pension Fund Offices, and only fund employees have access to it. As for policyholders, they, unfortunately, do not have the opportunity to use this software for self-control.
Perso checks, among other things, the availability and numbers of packs, data on insured persons (full name and SNILS), verifies balances at the beginning of the billing period, payments indicated in the calculations, balances according to information before 2010, etc.
If no errors are found, the policyholder will be sent a receipt of information with the data of the inspector who conducted the inspection. If there are errors, the organization will receive a negative protocol.
Then, reports that have successfully passed the verification will be recorded in a special journal and transferred to temporary storage. There is a peculiarity here: the storage cannot contain two files with the same names. This often leads to consequences that are very unpleasant for the company. The fact is that if the policyholder assigns the same number to two different packs, then the file names of these packs will also be the same. Then the file that was transferred to the storage earlier will be completely erased by the file of the same name transferred later. As a result, incomplete information about the policyholder will remain in the Pension Fund database, and this will greatly complicate reconciliation.
You can prevent such an incident with the help of a little trick: throughout the year, assign batch numbers not in order, but so that the numbering of each reporting period has its own distinctive features. For example, packs for the first quarter should be numbered “101, 102, 103...”, packs for the first half of the year – “202, 203, 204...” and so on until the end of the year. This method is not a violation and avoids confusion.
Fourth stage: verification of transferred payments
This stage was introduced in 2010, when the Unified Social Tax was replaced by contributions, and companies and entrepreneurs became obligated to submit calculations for accrued and paid insurance premiums (forms RSV-1, RSV-2 and RV-3).
At this stage, the inspector selects the DAM form from the received package of information and loads it into the software and hardware complex called “Insurance Premium Administration” (abbreviated as PTK DIA). There, the details of the organization and the amount of transferred contributions are checked, after which the information is stored in a separate database (later from this database it will be transferred to the desk audit department).
Here, as at the previous stage, if there are no errors, the policyholder is sent a receipt for receiving information, and if errors are identified, a negative protocol is sent. Most often, an error is found in two cases: either the payment did not go through, or the accountant made a mistake when filling out the calculation.
When eliminating errors indicated in the negative protocol, one important rule must be followed: the corrected version of the DAM calculation must be issued as an adjustment with the corresponding serial number.
This is due to the fact that any calculations, even incorrect ones, are stored in the database. Consequently, the original version of the calculation is already there, and any correction is an adjustment.
Please note: for personalized accounting information (forms SZV-6-1, SZV-6-2, SZV-6-3, ADV-6-2, ADV-6-3, etc.) this rule does not apply. In other words, having eliminated the errors indicated in the negative protocol, the accountant must send to the fund not adjustments, but the source codes of these reports.
Other causes of error 508 FSS
To resolve error 508 when sending sick leave, check that the data you entered is correct. A computer program wants to tell us this in code. Numbers, calculations and additional information in the electronic form must also be verified. Some values in it may simply be missed, please pay attention to this. Incorrect recalculations of cash accrual amounts, days and other data may be indicated. Check that the injury rate is assigned correctly if necessary.
If you cannot solve the Logical Control problem for a long time, try creating a new report with recalculating the data and filling out the form again. The FSS website has a free program https://fss.ru/ru/fund/download/55818/ that allows you to automatically prepare calculations for the service. You can upload a report file in xml format into it and enter values. Then download the corrected version and submit it again as a report. It is possible to seek help from FSS support on the website.
Fifth stage: posting individual information to personal accounts
The last, fifth, stage is to distribute the data from the received and verified reports to the personal accounts of the insured persons and store them in a single electronic database. It is called the software and hardware complex of a personalized accounting system (abbreviated PTK SPU).
The process is as follows: first, the inspector downloads calculation data from the DIA software package, then - packs of individual information from the Perso temporary storage. At the same time, there is a comparison of accrued and paid contributions for each insured person and for the organization as a whole. Fund employees call this “information matching.” As a rule, docking takes a day or two.
If no errors are found, the amounts indicated in the individual information are transferred to the personal accounts of the insured persons. At the same time, inspectors do not send any messages or notifications to the organization, that is, the inspection is completed “by default.”
But sometimes docking reveals errors. Let's give an example: a woman got married and changed her last name. At the same time, at the previous stages of verification, the previous name was listed in the database, but at the time of posting to personal accounts, the new name was already listed. Then, at the fifth stage, the system will not be able to identify the insured person and will record an error.
In such a situation, inspectors must send a notice to the company to correct the discrepancies. The policyholder is required to make adjustments within two weeks. Otherwise, the fund has the right to independently eliminate discrepancies and report this to the organization. This is stated in paragraph 41 of the instructions on the procedure for maintaining individual records, approved by order of the Ministry of Health and Social Development of Russia dated December 14, 2009 No. 987n.
However, in practice, fund employees very rarely send notifications. Instead, they immediately begin making corrections on their own without the policyholder even realizing it. Naturally, when preparing reports for the next period, the organization does not take into account the adjustments made by the fund. When checking the next period, inspectors perceive this as an error, and the company receives a negative report. Not understanding what happened, accountants often suspect the special communications operator of changing the data in the reports. Unfortunately, it is almost impossible to prevent such a situation.
Proper data cleaning is one of the important conditions for their quality. For example, the data bank of the European Social Survey (https://www.europeansocialsurvey.org/) only accepts carefully cleaned data from participating countries. Array cleaning can be divided into technical and logical. Technical cleaning is used to: 1) check questions with multiple alternatives: control the maximum / minimum number of selected answer options (in case the number of categories that need to be selected is set precisely or limited to a certain number); 2) checking for questions of the same type whether the “None of the above” option is selected along with other answer options; 3) correct transitions after filter questions. Logical cleaning is more creative. If in the case of technical cleaning the researcher can be guided solely by the requirements for filling out the questionnaire, then in the logical cleaning he needs to use his imagination and knowledge in order to determine those configurations of answers that are contradictory in a logical sense. Finding such situations usually indicates data entry errors or falsification of questionnaires. First of all, the analyst needs to check that there are no duplicate questionnaires in the array, that is, entering one questionnaire two or more times. The simplest way is to construct a one-dimensional distribution based on a key attribute (usually a unique questionnaire number). If duplicates are found, you should make sure that the answers to the questions are also identical and delete the duplicate questionnaire. To check the identity of responses (not by key attribute, but by the content of all responses), you can use the following syntax: for (i in 1:nrow(takeData)) { check <- apply(takeData[,-70], 1, function(x ) identical(x,takeData[i,-70])) if (table(check)[“TRUE”] > 1) { shortlist <- c(shortlist, which(check == T)[which(check == T ) != i]) if (!i%in%shortlist) cat("string",takeData[i,"keyVar"],":", which(check == T)[which(check == T) ! = i], "\n") } }
First, we convert the array that requires verification into a “takeData” matrix and create an empty “shortlist” vector. Next, using the for() loop for each row of the matrix using the apply() function, we check its identity with all rows (including itself) of the same matrix, and write the results in the form of a logical vector “check”. In this case, “-70” indicates that it is necessary to exclude the variable with the seventieth index, which is the key feature (otherwise each observation will be unique). If the number of TRUE values exceeds one (that is, the contents of a line coincide not only with itself, but also with the contents of at least one other line), then the numbers of the corresponding lines are written to the “shortlist” vector, with the exception of the one that is currently being checked . And if the number of the current line is not in the “shortlist”, then using the cat() function the result is displayed, which is the number of the line currently being checked and those lines that duplicate it. If the answers to questions with the same numbers are not identical, then the input error was in the questionnaire number, and each questionnaire must be assigned a unique number. After this, you can proceed directly to data cleaning, during which the analyst formulates a number of logical conditions using software. The result of their verification will be a list with the numbers of questionnaires in which logical contradictions were found. When the researcher has paper questionnaires at his disposal, he can refer to them to understand whether relevant errors were made during the data entry process by the operator and, if necessary, correct them. You can also determine whether individual questionnaires stand out from others in terms of the number of errors. If the latter exist, they can be monitored by contacting the respondent. In addition, it is worth checking other questionnaires of the relevant interviewer. Let's look at examples of technical (examples 1 and 2) and logical (examples 3 and 4) cleaning. Example 1. A multiple-choice question about membership in public and political organizations cannot simultaneously contain an answer about membership in one or more organization(s) from the list and the answer option “I do not belong to any.” To check, you can use the following set of commands: finalUSind$b4_sum falserows_b4 0 & finalUSind$b4_14 == 1 wrong_b4 First, the total number of elections of public and political organizations for each respondent is found, which is recorded in the “b4_sum” variable. To do this, use the rowSums() function, which belongs to the category of functions (along with colSums(), rowMeans(), colMeans()) designed to aggregate information in the rows or columns of an array. Next, using two logical conditions corresponding to the conditions described above, a logical vector “falserows_b4” is created, in which the TRUE values correspond to those rows of the array in which a logical contradiction is detected, and FALSE to those in which it is not detected. After this, using the which() function, a vector “wrong_b4” is created, containing the numbers of only those lines in which a logical contradiction is detected. Finally, you can contact these numbers and check the corresponding profiles. Example 2. There are no filter questions in the “Ukrainian Society” monitoring. At the same time, if you need to check the correctness of transitions after filter questions, you should specify the appropriate conditions. Let us assume that a respondent who answers that he would not like to leave the locality in which he lives should not be asked a question about the possible direction of relocation. The essence of the commands is the same as in the previous case (similar for the third and fourth examples): falserows_i5 wrong_i5 Example 3. The number of people with whom the respondent lives in the same room should not be greater than the number of people with whom he lives in the same apartment ( home). falserows_k7 finalUSind$k6 wrong_k7 Example 4. If in the question about the type of employment o, then in the question about the amount of wages for the last month there should be a zero. false_l3 0 wrong_l3 The more variables are used in logical conditions, the higher the probability of finding an input error or identifying a falsified questionnaire. At the same time, it is worth keeping in mind that some conditions of logical purification cannot directly indicate an erroneous, incorrect answer. In the last example, the respondent could talk about his last personal income, and not about the income for the last month, or only in this month he became unemployed without any sources of income, and last month he had income. In addition, you should not get carried away with such “weak” conditions, such as, for example, “People with higher education cannot be completely dissatisfied with the level of their education” or “Ukrainians by nationality cannot practice Islam.” Although these are non-standard situations, they are quite probable. You should also adhere to reasonable limits in the number of logical conditions. The presence of a small amount of illogicality in the questionnaire is quite acceptable. There are situations when some value judgments at the beginning and at the end of the questionnaire may not coincide, which may indicate uncertainty in the respondent’s opinion on this issue. After implementing the syntax and receiving a list of identified errors, two options for further actions are possible: 1) accessing paper questionnaires by their number and checking the correctness of the entered data (that is, comparing the values in the array and the questionnaire), correcting the values as necessary; 2) working exclusively with a data array. The first option is more preferable, but then cleaning takes much longer. The second option is less time-consuming, but in this case the researcher has to decide to change the values in variables containing inconsistencies “at his own peril and risk.” At the end of this part of the article, we provide a syntax that structures all the work done before and brings the results into a more convenient format:
itogi <- list("error in b4" = wrong_b4, "error in i5" = wrong_i5, "error in k7" = wrong_k7, "error in l3" = wrong_l3) inorder <- names(sort(table(unlist(itogi) ),deccreasing = T)) rawresult <- list() for (i in inorder) { rawresult[ ] <- lapply(itogi, function(x) as.numeric(i) %in% x) } letsee <- lapply( rawresult, function(x) x)
First, an “itogi” list is created with the information about the gaps obtained in the previous four examples. Next, an “inorder” vector is created, in which the order of the questionnaires is fixed depending on the number of logical inconsistencies found in them (in descending order). After this, another “rawresult” list is created, in which, using a for() loop and the lapply() function, the presence or absence of a logical inconsistency in relation to each check is recorded for each questionnaire. Finally, a final “letsee” list is created, in which for each questionnaire only those results are retained that indicate the presence of logical inconsistencies. This final list can be used as a guide for identifying and processing questionnaires that meet the review criteria.
Tags: Technical data cleaning, Logical data cleaning, Input errors
blog comments powered by Disqus
Advice for those who have transferred registration to another Pension Fund Directorate
In conclusion, we note that a lot of problems when checking electronic reporting arise for policyholders who have changed their address, and with it the Pension Fund of the Russian Federation.
Often difficulties arise due to the fact that accountants mistakenly believe that the agreement on the exchange of electronic documents concluded with the “former” Department will be valid even after the transition to the “new” UPFR. In fact, when changing Management, the organization must enter into a new agreement - otherwise the Foundation will not accept electronic reports.
Another reason for the difficulties is that each Department has its own database for receiving information. And, unlike the SPU PTK, which is a single centralized system and stores information about all persons, the databases for receiving information contain only the data that was received in this particular Department. It turns out that if previously the organization reported to another UPFR, then at the new place of accounting there is no data on previous periods, and they will arrive with a great delay.
In this regard, we advise “newcomers” to submit their first reports not using the TKS, but on paper or a floppy disk. The explanation is simple: “paper” reports will require the personal participation of the inspector, who can be given verbal explanations. Whereas electronic verification systems will record an error without hesitation. Therefore, it is better for newly registered policyholders to get acquainted with the employees of the Department and draw their attention to their situation.
Control ratios
In addition to checking the declaration for “internal logic”, the VAT+ module checks whether the control ratios are met in the declaration.
If logical control is a check of data for one specific invoice, then control relationships are a reconciliation of data for certain sections of the declaration and between sections. Therefore, in order for the service to perform this check, you need to upload the entire VAT return to VAT+, including sections 1-7.
The current control ratios were approved by order of the Federal Tax Service dated October 29, 2014 No. ММВ-7-3/ [email protected] and are also given in the letter of the Federal Tax Service dated March 23, 2015 No. ГД-4-3/ [email protected]
VAT+ implements almost all the ratios that the Federal Tax Service checks when processing tax returns. Several control ratios, which are still under development, are available in Externa. For example, the service checks that:
- the calculated and restored VAT in sections 2–6 coincided with the final VAT payable in section 9;
- deductions in sections 3–6 did not exceed the amount in section 8;
- the amount of VAT to be deducted from all sheets of section 8 was equal to the total amount on the last page of the section, and the tax payable from all sheets of section 9 was equal to the total amount on the last page of the section;
- the tax agent reflected the deduction in section 8 with code 06 and provided the calculated VAT on the same invoice in section 9 with code 06.
If you have questions about filling out the declaration, in particular about control ratios and logical control, you can always ask our experts.
