For me the MRU angle would be recurrent tasks -
Which might be hard to encode into report / file names,
as another employee might need to run the report more or less often.

MRU is somewhat self-organizing,
abolishing the need to create a way
for every employee to tweak their own menus -
and with that the need to document and teach.
Perhaps add a paragraph on how to set # of MRU entries.

It cuts the "offered" reports from 100+ to amount every user needs for *his* tasks
and the time dimension is IMO also a usable order criterion for tasks last done/to do.

the smart ass answer of course would be:
picking a report *is* picking a file (couple),
so you should have no reason to vomit -
imagine it to be an Excel file with a dynamic query
giving new / current results for the period.

;-))

>Me, from a user POV, would vomit if a non-file menu behaves like that.
> I have a visual orientation and expect an entry on a certain

>A MRU for files like in an editor is fine so far, since the file is the data.
>>I think you should combine Dragan & Al:
>>first make it EASY for each user to identify / find specific report
>>- description table based in a grid,
>>- perhaps 2nd window or description field form
>>add Search option in Reports Menu
>>Build MRU Menu via tables
>>allow deletion in MRU Menu
>>
>>my 0.002 €
>>thomas