ReportNet Data Source 2

[datawrangler]

So, we are just getting started with ReporNet. The data warehouse guy has plugged in all of our data using Framework Manager. It is now up to me to design the reports. Here's the issue I am having. I need to do a simple financial report. Budget vs. Actual. Problem is, all of these transactions Budget, Acutal, Voids... are all in one field called currency. There is a way to break these out using another field called transaction type. Which means I will have to run two queries to get my main measurable data in the report so that I can run calculations. I've taken ReportNet1.1. and of all the sample data I've seen, the different currency transactions are broken out into separate fields.. drag in the Actual, drag in the budget and do my calculations. He says that's silly. Am I nuts here? Does one need to run a query each time you want to bring in a field of information. Suggestions? Am I crazy? I am the one who builds our Models and if users are going to have to do this themselves, they will need to see the measures in separate field... the way it is in the model. thanks!

 

[plevey]

Your 'data warehouse guy'should create new query items for each type of value in FM. In other words add a new query item which is the value field with record type selection to only include the correct transaction types, one for Actual, one for Budget and so on.
Good luck


If fishing was easy it would be called catching

 

[Draoued]

or you can create the fields by yourself in Framework manager by adding Calculated fields.
Budget field =
if ( Transaction= 'Budget' )
then Currency
else Null
end if

Actual field =
if ( Transaction= 'Actual' )
then Currency
else Null
end if

Void field =
if ( Transaction= 'Void' )
then Currency
else Null
end if

 

[datawrangler]

Thanks for your posts. I was looking for an opinion, and it seems you agree. He sort of refuses to do it in FM and says that I (or the user) can just do it with a query in the ReportNet report itself. I am of the opinion that if it is not intuitive for me, it will not be intuitive to other users. For some reason, the FM portion of this project is his job, and mine is to work with what he gives me. He could do it in FM, but won't. I just needed to know whether or not I was being silly for asking him to do this. Or for even bringing up that this was not a very useful structure.

Thanks!

 

[datawrangler]

Ok, so this fellow is still saying that it should be done in the report. He says the sample data I am looking at of Revenue and Sales Target are actually calculated columns in ReportNet not Framework manager. Any suggestions on how I can convince him to break this out? Does anyone know of any kind of sample data or white papers that might explain why it is not an efficient use of a Cognos Product to lump all currencies (Budget, Actual etc) into one field called currency?

 

[plevey]

Your are quite correct. Standard business calculations should be held in FM so that ALL users have the same and therefore avoid errors. If for some reason the calculation should change then you have it in only one place and you don't have to go to each report to check and amend the calculation.

If fishing was easy it would be called catching

 

[KingCrab]

It has nothing to do with efficiency. There are several ways to do any one thing in RN, RS, and FM.

Doing it in FM may benefit more then one report writer but doing it in a report is still a feasible option if there is only one report writer wanting this field or for a proof of concept. Doing it in a report as a proof of concept can give this "fellow" a better idea of exactly what fields you want to add and how they are needing to be calculated for you.

I would argue that saying, "it is not an efficient use of cognos" is not the way to convince someone who knows Cognos to add something to a package, especially when it is not absolutely needed.

 

[datawrangler]

Thanks for all of your valuable posts. However, in our case, there will be multiple users. Our programmer did not take the ReportNet course, so perhaps this is where our miscommunication comes into play. Please continue posting if you'd like. This is a great learning experience for me.