Management Reporter P13 Issue

(0) Share

Report

Posted on by Ian Grieve

22,784

I'm having a problem with Management Reporter 2012 RU4 and P13.

The report in question is one which consolidates several companies into one using a reporting tree. When the report is generated I get an error stating "Period 13 for fiscal year 2013 is not valid for company XXXXXX. No data will be returned for this company."

Three of eight companies work but the rest do not. I have checked the fiscal calendars and all of the companies have the same calendars (P13 is the last day of the fiscal year).

I've created a new report and tree and get exactly the same errors.

*This post is locked for comments

I have the same question (0)

All responses (15)

Answers (1)

Ian Grieve 22,784 on at

Like (0)

Report

As an addemdum, if I change the report name and starting unit both to one of the companies that fails to work and generate the report, it generates correctly with fgures.

Was this reply helpful? Yes No
cgust on at

Like (0)

Report

Please consider updating to the latest release, which is RU6. Thanks

Was this reply helpful? Yes No
Ian Grieve 22,784 on at

Like (0)

Report

I did a trial upgrade on my test system the other day and the RU6 web viewer didn't work so I can't roll it out to a client until I've had a chance to find out why.

Was this reply helpful? Yes No
Verified answer

Ian Grieve 22,784 on at

Like (0)

Report

The problem was caused by all periods for the Financial series being closed for the Open Year (last year has not been closed yet). It turns out at least one Financial series period must be open for Management Reporter to be able to access data.

Was this reply helpful? Yes No
Frank Hamelly | MVP... 46,625 Super User 2025 Season 2 on at

Like (0)

Report

Just as an FYI, the behavior Ian describes was present in FRx also.

Was this reply helpful? Yes No
Beat Bucher GP Gee... 28,058 Moderator on at

Like (0)

Report

Char,

We ran into a little different situation, though the error message is exactly the same as Ian described in his post from last year... Being on the CU8 (and tested with CU9) doesn't change anything... The reality is that we opened a new FY 2015 for all our companies by using the Rockton Software Toolbox with the Open/Close Periods tool. This function allows also to generate the next FY in the system for all companies.. On a normal basis, this works fine, but this year was a bit special as we to split 2014 in two FY and thus had one FY with 5 periods and the rest of 2014 with only 8 periods. When we asked the system to open 2015, it initially created only 8 periods for each company, which of course was wrong, but apparently based on the current FY schema... Long story short, when trying to run a consolidated report from within MR 2012, no data gets returned, despite the fact that we corrected in GP for each company the FY periods from 8 to 12 and validated all the dates...

When running the conso report for Period 12 in 2015, we get the warning for each company that the Fiscal period 12 doesn't exist... but when running the report for Period 8, everything is coming out right... so it looks like that MR is checked somewhere else the number of periods rather than using the tables SY40100 / SY40101 from each companies..

Do you have any suggestion where to look for it ? I did for one small company that we had only 3 FY's setup to wipe out 2015 with the PSTL (in fact it wipe all the FY's in the system !!! ) and set them up again... When doing so, the consolidated report ran for 12 periods and returned data for this company only... proof that it checks the amount of periods elsewhere in the system... I've scanned thru about 20 tables in GP that hold a PERIODID field, and none of them was suspicious of holding only 8 periods for 2015.

Any hint would be really appreciated, as I don't want to go thru all the period & FY setup again for all the companies.. some of them have up to 14 years of history.

Was this reply helpful? Yes No
Suggested answer

April Olson on at

Like (0)

Report

When running consolidated reports in Management Reporter, the company you have selected in the Report Definition is very important. The company defined in the report definition is what company is used as the base calendar. If its set to @Any then its either the company in the reporting tree definition or the default company. That company's calendar and base year and period are the basis for the consolidation. So, if that company has a FY2015 Period 12, depending on the settings of the report definition, it will look for FY2015 Period 1 in every company. Again it depends on the settings in the report definition under Settings > Other > Additional Options>Consolidate companies with different fiscal year ends. In this case, if every company didn't have a FY2015 Period 12 you would receive errors. If you are using a consolidation by period end date then it should just match the date, not the period number. Also, with make sure a one period is open in the new year. These are a few things to check.

Was this reply helpful? Yes No
Beat Bucher GP Gee... 28,058 Moderator on at

Like (0)

Report

Thanks April,

I've checked all that already and the companies defined in the reporting tree all have FY 2015 open and 12 periods defined (checked the tables SY40100/101), and BTW, when each company is selected individually (instead of @ANY), then the report returns the correct numbers in each company... so why does the consolidated output keep saying that period 12 is invalid for company XYZ and this for each company except one, and it's not even the single one that gets data returned in the consolidated report (with @ANY)...

What strikes me is that our current FY 2014 has only 8 periods ranging from May to December, but 2015 has 12 periods... Also when running the 2015 base year up to period 8, I don't get any errors and the report runs just fine for @ANY... but soon as I go 1 period further, it fails... strange !

it's like MR uses the BASE YEAR 2015, but looks for the periods in 2014... bug ?

I've checked all the definitions (reporting tree, columns) and none of them show anything different from the 2014, from which I did a copy for each elements, since I didn't wanted to scrap the working 2014 reports. I also made sure that at least one period was opened for 2015 in the Financial series after reading Ian's post, but that didn't helped neither...

Was this reply helpful? Yes No
Suggested answer

Beat Bucher GP Gee... 28,058 Moderator on at

Like (0)

Report

Hi April,

Ok... after spending almost the entire day on trying all kinds of settings, went back to the roots and was replicating the exact same setup on my TEST bed system, that hosted the last version (CU9) of MR 2012... the more I digged into this, the more I suspected that MR has a bug when it comes to select the BASE year and BASE period in the system...

Despite selecting 2015 as the BASE year to run our Budget consolidated reports for next year, the system keeps warning about invalid periods for 9-12(no matter which one you tried to run past 8)... Since our current FY 2014 has only 8 periods, I started to think about a scenario where I would alter the SY40101 table and change the NUMOFPER from 8 to 12... That didn't helped, but then I went thru a couple of companies and re-calculated the periods for FY 2014 to extend them from 8 to 12 periods... and oh voilà... all of a sudden they started to show up..

After completing all the companies to extend 2014 to 12 periods (adding 4 fake periods for the 4 last days of this year), I was able to run my Consolidated Budget report for FY 2015.

I think you should look into opening a bug report for this, since this is really not the expected behavior or MR when selecting a BASE year & period to run a report.

Thanks and have a great time.

Hope to see you in St-Louis this fall,

Was this reply helpful? Yes No
Suggested answer

Beat Bucher GP Gee... 28,058 Moderator on at

Like (0)

Report

Hi Ian,

Here's an update about this story.. I got the information today thru our partner that this problem is already registered at Microsoft under the bug #1603128 and is supposed to be fixed with the next CU10 release (it should have been with CU9, but apparently didn't made the cut)...

Don't know how long they know about this, but definitely could have been replying here about this :-(

Was this reply helpful? Yes No