I'm running a client's Ledger data under Ledger 9.3 (180422). The problem is that the current month statistics is also shown under the previous year statistic. According to the client, this started happening after they rolled over to FYE 2019 and prior to this, the reports were correct. when looking at the transaction details, they are the same for each period in each of the current and prior period.

Also, period 4 shows transactions but the sub-total is not showing in the detailed listing, nor does the balance for period 4 show on the financial statement for the current period.

The parameters for the previous year's period formula is =ADGET("GLDATA.{1}UM",$B123) and for the current period is =ADGET("GLDATA.UM",$B123). I'm not sure that there is any error here, but am suspecting a problem with the transaction file. DIC completed with no errors.

Hi Tech Support Team - It appears that "UM" and "{1}UM" are pulling the same data. Trying to get the Current Period for Last Year units.

Hi Lars,

Reports are only as good as the underlying data. Maybe the numbers are the same in the data for this year and last year, correctly or incorrectly.

Use GridView to look at the Ledger dictionary and the Account Net Changes table. The Statistics fields for each of the 12/13 periods are stored here, with each year in separate records. If the numbers are the same here, they will also be the same on financial reports.

Statistics can be exported and imported, if some numbers are wrong, and you know what the correct numbers should be.

When a New Year is created in Adagio Ledger, there is an option to carry over Budgets and Forecasts from the Current Year. Statistics are not carried over, and I confirmed that this is working.

I printed out the detailed listing for the accounts / dept in question, and the totals do not match those is the financial statements. These are Statistical Units that are entered during data entry. All I need is to find the code that pulls the selected period last year. As mentioned above, the "UM" and {1}UM are pulling the same data that is the same as the current period this year.

Hi Lars,

Can you try using the formula GLAMT() rather than ADGET()?

Or perhaps ZIP up the data and the statement and send it to me?

Thanks

Hi Andrew. Didn't make any difference to the result. When you take a look at the data, check out account 990010 on the statement for prior year Man Hours. In the detailed listing the units for 990010-71 FYE 2018 shows 534 units.
Thanks for checking this out.

Hi Lars,

With sample data, I created a financial statement that had both UM and {1}UM as columns on a SmartSheet. Account 4000 has statistical units for years 2008, 2007 and 2006, so this is good to test with. For account 4000-100 and year 2008, period 10, I can correctly see a value of 21.00 for the UM formula, and 16.00 for the {1}UM value. Same if I collapse the SmartSheet and consolidate all departments for account 4000. So in these examples, {1}UM is not reporting the same value as UM.

I presume you have sent data and the spec to Andrew, based on your comments.

Yes I have. Definitely something wrong with the code.

Which statement?

Hi Andrew. See PM.

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.