Good morning. Wanted to update you regarding this financial issue. I ran a Gridview report of the accounts in question and found a number of anomalies. First, the statistical units are the same for both 2018 and 2019. Secondly, the information included in the Gridview report do not match the posted transactions in the detailed listing. In talking to the client this morning, the completed year end procedures have been followed in previous years without any issues. It is only after 2019 year end that these problems occur.

BTW, it appears that the FYE 2018 data is corrupt. The data for FYE 2019 is correct and is consistent with the posted transactions.

Hi Lars,

To confirm, if the data for FY2018 does not have the correct values, then would it be fair to say that there is a problem with the data rather than the Financial Reports?

I recall you sent some data to Andrew, is that correct? Do you also have access to a backup of data where the FY2018 numbers are correct? Such as prior to creating the next fiscal year, or some other step that may have caused unexpected values to populate the FY2018 records? If in the end this problem has to do with the data, we'll need to be able to replicate what happened in order to prevent this better for the future.

Hi Support. I have confirmed that there is nothing wrong with the financial report. I compared the information using the SuperSpec90 and everything is consistent with the information included in the GridView report. I also compared the posted transactions for FYE 2019 and everything appears to fine. When the detailed transactions for FYE 2018, the information does not natch that on the GV report. As well, there is information in 2018 that is missing from the GV that are included in the posted transactions.

I have asked the client to provide a copy of the data prior to closing 2018. Once received, I'll upload it to you.

Thanks for your help on this issue.

Hi Lars,

You can import statistics into an account, and there is no data integrity checking on the numbers to my knowledge.

Hi Andrew. The units are being entered at the same time as the account details are entered. For example, labour costs are entered and then the hours are entered in the ManHrs field. The account is set up to accept statically units.

This issue does not relate to importing statistics. It is a result of entering the statistical units when entering a transaction.

Hi Lars,

You sent the data, and I can confirm that the stored Statistics for Fiscal Year 2018, in the 'Net Changes' data file, do not match the posted transactions for the Units saved there. Fiscal year 2019 Statistics are all correct. It looks like only the first 3 periods are matching, then periods 4 to 13 are all 0 for stats in 2018, different than what the posted transactions have for those accounts.

There is no problem in the Financial Reporter, as the drill-down can only show the values that are stored in the data. The problem is that incorrect values are on the FY2018 Net Changes records for the Statistics values.

Because periods 4 to 13 have 0.00 for statistics, it is unlikely that posting GL transactions overwrote these values by mistake. If this was an issue with posting batches updating the previous year by accident, I would expect to see future fiscal periods unchanged. I do see that for fiscal year 2019, there are values for periods 4 to 6, different than what are in year 2018. So something changed at the end of period 3 (closed year 2018?), or there is another explanation than posting.

This company data also has Export and Import Statistics templates defined. This does not prove that they used Import Statistics to accidentally update the 2018 values instead of the 2019 values, but it leads to the potential that this happened.

As I replied to you off-line, the solution is to create a GridView view to generate an Excel file with the correct statistical units for each of the 13 periods, then use Import Statistics to overwrite the wrong values. I sent you the View and Excel file that I created to fix the problem.