Limited Support for Time characteristics 0FISCPER/0CALMONTH/0CALQUARTER

Question

The time characteristics 0FISCPER/0CALMONTH/0CALQUARTER are converted into Character type value in Universe which results in following problems on switching to Webi based reporting from current SAP BI front end tools.
Problem 1: Sorting does not work correctly using the Key Value or Description as both are being treated as Character values. While setting up the Custom sort sounds like a workaround, the sort list has to be generated for all possible months/quarter/year combination that will be seen in the reports. Not a good solution when business analysts has to build their own reports from Universe.
Problem 2: Using range selections (E.g. between, greater than, less than etc) in Universe conditions/prompts does not yield correct results due to the same fact that all values are treated as characters. Possible workaround is use this kind of conditions in BI query variables directly. But, this does reduce the flexibility of selections a lot, especially when users are used to simple ways of making range selections in BEx.
Problem 3: keying in the prompt values for these characteristics/dimensions (both Key and text) is very cumbersome due to format issues. E.g. 1/2010 is no more recognized as valid fiscal period. You have to enter key value as K4/001/2010 or Text value JAN 2010 or January 2010 (based on text selected in query/infoobject). Only way of simplifying user input is to use LOVs and let users always select from LOVs. But, the users lose ability to simply key in values.
Problem 4: The default LOVs generated for Fiscal period takes values from the master data and hence might show all available fiscal periods including special periods 00,13 thru 16 etc. even though they may not be relevant to the underlying report (e.g. a Sales report). This can confuse users who are not used to seeing these periods before. Possible workaround is to apply filters on LOV using condition and in some cases this should fix the problem.
While some of the workaround for above problems sound acceptable (3 & 4), the others are not in my opinion(unless there is a better workaround anyone else have). My question is to experts from SAP is, can we expect better support for these objects in future Service packs? If not, then perhaps we need to move away from using this objects in reporting and use 0FISCPER3, 0CALMONTH2, 0CALQUART1 in combination with 0FISCYEAR/0CALYEAR to overcome above issues.
Though  this can mean  (1) good amount of backend changes to include these Infoobjects in underlying Infoproviders, if there are not present already (2) User training to explain them to use these new time char fields instead of the ones they are already used to.
I'm fairly new to BO and might have overseen somethings. I have already searched the BO forum related to this topic and did not find any satisfactory answers. Any input on this is greatly appreciated.
Thanks & Regards,
Sree

Answer 1

The issue is that these InfoObjects are not Data Type DATS in BI, they are NUMC and PERI7. Only InfoObjects of type DATS will be converted to Date format in the BO universe.
Workarounds:
- instead of using these time characteristics to filter results, consider using transaction dates, such as posting date.
- create a customer InfoObject ZFISCPER which is a transformation of 0FISCPER to DATS data type.
- create a custom variable in the WEBI reports which looks at the key for 0CALMONTH and only considers the first 2 characters which should identify the month (e.g. 01 = January, etc.). You can then sort on this and it avoids the year concatenation issue (e.g. JAN 2008, JAN 2009, JAN 2010).