on 10-29-2015 8:23 PM
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
The setting on the query/infoprovider level does not affect the initial variable screen selection - that is limited to the InfoObject setting. The infoObjects in question are set to Only Posted Values for Navigation or Only values in Infoprovider..tried both.
See this comment in my original thread:
"I am specifically referring to BEx variables and the initial Variable screen which is presented to BEx users or BOBJ clients using BEx Variables upon query execution. I understand that variables are defined globally, so the "Selection of Filter Values for Query Execution" settings do not apply here from the query settings, but they would apply in once the report is run and Filters settings are accessed - correct me if I am wrong. What happens is that the Variable screen variables take upon the setting in the InfoObject itself - as designed. My particular infoobjects are set to "Only Posted Values for Navigation" and also have tried with "Only Values in InfoProvider". "
I found this here: http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/20ecb78c-374a-2d10-c6af-f024f19b7...
"2. For variables input help, the query execution setting in RSD1 only initiated. Settings done in infoprovider specific properties and query designer will have no impact on variable input help. Because variables are global not restricted to any particular query"
Unless I am misunderstanding how it works!
Hi Thomas
You are exactly right and you have a valid point here. Though you could ignore this and go ahead with your work, I appreciate your effort to get to the bottom of it.
I have read your question when you posted in originally and was eagerly waiting to see some interesting replies which I didn't see so far
Coming to your question, I have checked many variable inputs in our project to see what difference it makes. To my surprise all the info-objects had this '#' which I haven't noticed as a big thing. But there are few info-objects which doesn't have this '#' as well.
You might also feel the same if you check the F4 for all available variables in all of your reports.
One fact that disturbed me is that the characteristics which doesn't have '#' in F4. I started analysing the background of it. Whenever an info-object doesn't have '#' in F4, that is not being used in many infocubes/DSOs. Even when it is used, it has a valid rule assigned which means, it will definitely have a value assigned it it. It never holds '#' in any info-providers.
On the other hand,the info-objects which has '#' in F4 is being used in many infoproviders and one or other has blank values in them. I am sure this is not a complete solution for your question, but I am just trying to let you know what I experienced, so that you could get a valid point from this
I am still confused about the point that this doesn't happen in a DSO based query. Lets wait for others to comment on this.
Thanks for your efforts!
Regards
Karthik
Thanks for your reply and your research - looks like you are seeing exactly the same thing as me! For InfoObjects that don't show #, check if their Texts are being shown...then they would show up on the list as "Not assigned" and may be further down in the list of values (noticed that on my end also).
But you may be right...if you have an infoobject that has been populated in all transaction data (regardingless of infoprovider - would have been across the board where this infoobject was used) it may not have a 0 sid value and possibly wouldn't show up. This is a very rare case, as not all characteristic values are mandatory across the board...so I would consider this an exception.
I still think the variable screen has an issue with the # value and I'm almost certain it has to do with a coding error along side the 0 dimension row in InfoCubes.
Dear Thomas,
It looks like there is blank row in your Master Data duw to which it is appearing in variable screen.
Delete the blank row in MD and it won't show the #.
Hope this will be helpfull.
Thanks & Regards,
Amit
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Master data will always have a 0 sid entry also, and a blank row is created because the value may be blank in transaction data in other places.
This is not only happening for master data though, its across the broad on all characteristics - master data bearing and non master data bearing also. So I do not think that its the blank row in master data.
User | Count |
---|---|
91 | |
10 | |
10 | |
9 | |
9 | |
7 | |
6 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.