IBM Cognos ICM · PDF fileIBM Cognos ICM Advanced Composer Concepts June 2013 This document contains confidential and proprietary information and is intended only for the person(s)

IBM Cognos ICM

Advanced Composer Concepts

June 2013

This document contains confidential and proprietary information and is intended only for the person(s) to whom it is transmitted by IBM. Any reproduction of this document, in whole or in part, or the disclosure of any of the information contained herein without the prior written consent of IBM is prohibited. IBM reserves any and all rights to the information contained in this document. No warranties of any kind are contained in this document, and IBM shall not be held liable for any damages howsoever caused by reliance on or use of the information contained in this document.

Copyright © 2013 IBM 2


TABLE OF CONTENTS

DOCUMENT CONTROL .............................................................................................................3

DOCUMENT OVERVIEW ...........................................................................................................4

PURPOSE ..................................................................................................................................4

DATE EFFECTIVE TABLE DESIGN ..........................................................................................4

JOINING DATE EFFECTIVE TABLES .......................................................................................5

JOINING TO A SINGLE DATE ........................................................................................................5

JOINING TO A PERIOD ................................................................................................................6

Cognos ICM 8.0.1 + ..............................................................................................................6

Time Table (Pre-Cognos ICM 8.0.1) .....................................................................................8

OTHER USES FOR THE TIME TABLE ....................................................................................10

USE CASE: RETURN RECORDS FOR THE LAST MONTH OF THE QUARTER ......................................10

USE CASE: ALLOCATING ANNUAL QUOTA TO PERIODS ................................................................12

USE CASE: PRORATING TIME BETWEEN TWO COMP PLANS IN A PERIOD .......................................13

THE PREV() FUNCTION ..........................................................................................................14

WHAT YOU NEED TO KNOW ABOUT PREV().................................................................................14

USE CASE: DRAW RECOVERY ..................................................................................................14

DRAW COMPONENT BY CALCULATION .......................................................................................15

BLENDED RATES ...................................................................................................................18

WHAT YOU NEED TO KNOW ABOUT BLENDED RATES ..................................................................18

WHEN TO USE BLENDED RATES................................................................................................18

HOW TO USE BLENDED RATES .................................................................................................20

DATESTRING TABLE ..............................................................................................................21

WHAT YOU NEED TO KNOW ABOUT THE “DATESTRING TABLE” ....................................................21

WHEN TO USE THE DATESTRING TABLE ....................................................................................22

THE DATESTRING TABLE BY CALCULATION ................................................................................23

INTRAMODEL IMPORT ...........................................................................................................24

ACCUMULATING PARTITIONS ..............................................................................................28

WHAT YOU NEED TO KNOW ABOUT ACCUMULATING DATA .........................................................28

WHEN TO USE ACCUMULATING PARTITIONS ..............................................................................30



DOCUMENT CONTROL

Issue Date Author Description of Changes

1 Feb 2012 Created 10 Feb 2012 A. Rupf Prev() 7 Mar 2012 J. Menezes Accumulating Partitions 9 Mar 2012 K. Rhamany Time Table and Effective Dates 15 Mar 2012 O. Mehrzad Outer Join and DateString 16 Mar 2012 A. Hawkins Intramodel Import 19 Mar 2012 J. King Blended Rates 26 Mar 2012 N. Bass Minor Edits 4 Jun 2013 E. Baldovino Reformatted, retitled, updated Date Effective

Tables, added Composer Connections



DOCUMENT OVERVIEW

PURPOSE

The purpose of this document is to outline advanced concepts when designing and building a

model in IBM Cognos ICM.

DATE EFFECTIVE TABLE DESIGN

Custom tables in Cognos ICM must be designed to capture how data may change over time.

This applies to any information that would be used to affect payout rules such as quotas, rates,

territory definitions, etc.

Payee information is the most common example of this data. A payee’s attributes such as their

title, comp plan and reporting manager must be stored in Cognos ICM so that they can be used

to calculate their compensation.

The core Payee table in Cognos ICM includes only one column in its primary key: PayeeID.

Thus, this table can only have one record for every unique payee in the system. However, in

Cognos ICM, several aspects of the payee information can change over time and affect how a

payee’s compensation is calculated. This information should be stored in a date-effective table

such as the one below:

A few notes about date-effective tables in Cognos ICM:

• They must include a Start Date and End Date column

• In addition to what makes each row of data unique, the Start Date (but not the End Date)

must be included in the primary key. For example, the EffectivePayee table above has a



primary key of PayeeID and Start Date, which means that a payee should have one

record effective for a given time period.

• The person or system maintaining the data in this table should:

o Ensure that there are no records with overlapping dates for the same data. This

could cause duplications in calculation results

o Ensure that the End Date is always populated (this allows the calculations joins

to be simpler and perform better in queries).

Recommendation: use a consistent end date such as 1/1/3000 to denote

currently effective records.

o Ensure that when a new record is being entered, the old record is end-dated one

day before the start of the new record

JOINING DATE EFFECTIVE TABLES

When joining date-effective tables in calculations, data stores and report sources, it is essential

to restrict on both the Start Date and End Date of the table in order to avoid duplicated results.

JOINING TO A SINGLE DATE

It is best to restrict, or “wrap” the Start and End Dates of the table around a single date if it is

available. For example, if you are joining to a transaction table, then you can wrap around the

Transaction Date of each transaction.



JOINING TO A PERIOD

If a single date is not available, you will likely be joining to a time period such as a month or a

quarter. In this case, you will be comparing the Start and End date of the table with the start

and/or end of the period.

COGNOS ICM 8.0.1 +

In version 8.0.1 and above, you can access the Starting and Ending of a period partition by

double-clicking (or “drilling down”) on the partition.

Case 1: Return the record that is effective on the start or end of the period

In most cases, when joining to a time period, you will still want to ensure that one and only one

record in your date-effective table returns a matching record. For example, retrieving rates from



a rate table. This can be done by joining the Start and End dates of the table to either the start

or end of the period.

OR

Case 2: Return all the records that are valid at any time in the period

In some cases, you may want to return all the records that are effective at any time in the

period. For example, return all the managers that the payee reports to within a month. This can

be done by doing a cross comparison.

Case 3: Return the record that is effective for the entire period

In rare cases, you may only want to return the records that are effective for the entire period.



TIME TABLE (PRE-COGNOS ICM 8.0.1)

In versions prior to 8.0.1, the Starting and Ending of a period partition can only be accessed by

first joining to the Time table.

The Time table is the underlying table behind the calendar. When partitioning by any date field,

Cognos ICM will convert that date to a period. That partition does not directly provide the

information associated with that period (e.g. start, end, level) and you need to join to the Time

Table to get the information back.

Time Table Columns

Column Name Description TimeID Defines the Calendar ID (i.e. CAL, T001) Name The string name of periods set during calendar

configuration Level Calendar level (i.e. Months, Quarters, Years) Parent The level directly above a defined period Starting The start date of a period Ending The end date of a period

Essential Restrictions

When joining to the Time table to retrieve the start and end of a period, you must make sure to

restrict on TimeID, as there could be several calendars defined in the model. Then you can join

Time.Name to the time partition in your main source.



Once you have joined in Time, you can then join the date-effective table to the Starting and

Ending of the period through the Time table.



OTHER USES FOR THE TIME TABLE

USE CASE: RETURN RECORDS FOR THE LAST MONTH OF THE QUARTER

You are calculating everything by month but need to only produce results for the third month in

the quarter. In this scenario, you would join to Time, restricting the data set to the third month in

the quarter (where the end of the month equals the end of the quarter).

Step 1: Join to Time (alias Time Qtr).



Step 2: Restrict data to the third month in the quarter. *Assuming Time level Period=Months



Define Data

Source

Description Define Restrictions

1. QTD Accumulating Quotas by Period

Prior calculated results with Periods as one of the partition

Restrictions applicable to this source would occur in step 5 of the calculation wizard. For the purpose of this example, it is not necessary to highlight any restriction.

2. TimeQtr Stores the underlying information for a given period (i.e. start and end dates)

- TimeQtr.TimeID = “T001” - TimeQtr.Level = “Quarters” - TimeQtr.Ending = Periods.Ending

*This calculation is partition by T001/Periods/Periods.

Example 2 results:

Month Value Month 1 2500 Month 2 2500 Month 3 2500

USE CASE: ALLOCATING ANNUAL QUOTA TO PERIODS

Payees are assigned an annual quota and paid commissions based on year-to-date sales

against annual quota. To calculate year-to-date attainment on a periodic frequency; annual

quota is required to be assigned to every period in the year.

Month Value Month 3 2500



Calc: Assign annual quota to periods Description: This calculation will assign the annual quota for every period in the year. Sources: tblAnnualQuota, Time

{Where TimeID = “T001”, Time.Level = Periods, Time.Start <= tblAnnualQuota.EndDate, Time.Ending >=tblAnnualQuota.StartDate}

Formula: sum(tblAnnualQuota.QuotaAmount) Partitions: CreditedPayee, Time.Ending(T001/Periods/Periods)

tblAnnualQuota

… StartDate EndDate QuotaAmount 1/1/2013 12/31/2013 50,000

Calculation Results

… Periods Value 2013-01 January 50,000 2013-02 February 50,000 2013-03 March 50,000 2013-04 April 50,000 2013-05 May 50,000 2013-06 June 50,000 2013-07 July 50,000 2013-08 August 50,000 2013-09 September 50,000 2013-10 October 50,000 2013-11 November 50,000 2013-12 December 50,000

USE CASE: PRORATING TIME BETWEEN TWO COMP PLANS IN A PERIOD

Payee changes compensation plan in the middle of a period. Commissions are paid while payee

is effective in each compensation plan. You need to calculate the percentage of the payee was

effective in each compensation plan within that period.

Calc: Prorate time between two comp plans in a period Description: This calculation will return the percentage of time a payee is affective within a period. Sources: tblCompPlan, Time

{Where TimeID = “T001”, Time.Level = Periods, Time.Starting <= tblCompPlan.EndDate, Time.Ending >=tblCompPlan.StartDate}

Formula: sum{ [(tblCompPlan.EndDate – Time.Starting) + 1] / (Time.Ending – Time.Starting +1)}



Partitions: CreditedPayee, Time.Ending(T001/Periods/Periods)

THE PREV() FUNCTION

The Prev() function is a powerful command to use when you want to reference the previous

calculation result. In that sense, it is iterative. It is most commonly required when having to track

a balance from one period to the next. However, it can be used to calculate items other than

balances. The functionality of Prev is in no way similar/interchangeable to the Time Shift calc.

WHAT YOU NEED TO KNOW ABOUT PREV()

There are a few points to be aware of when using Prev():

• Do ensure that you have an accumulating partition in all calculations that utilize the

Prev() operator.

• Do Not sum Prev(), i.e. SUM(Prev()). The results are not predictable.

• Do assume that anytime you have to keep track of balances the Prev() operator will be

used

USE CASE: DRAW RECOVERY

While there are many instances when Prev() may be used (limited only by your imagination),

one of the most common scenario is Draw Recovery (aka Carry Forward Balance).

Often sales reps will be paid out a minimum monthly commission. There are times though that

the sales rep may not have earned enough commission in a given month to meet the minimum

payout. Consequently, future earnings will be used to cover the deficit.

Exhibit 1: Carry Forward Balance Calculation Stream using Prev()

The following table summarizes the output.

Payee Name Month Monthly

Sales Monthly

Minimum SOM

Balance EOM

Balance Commission

Joe Payee Month 1, 2012 500.00 500.00 0.00 0.00 500.00

Joe Payee Month 2, 2012 550.00 500.00 0.00 0.00 550.00

Joe Payee Month 3, 2012 450.00 500.00 0.00 50.00 500.00

Joe Payee Month 4, 2012 450.00 500.00 50.00 100.00 500.00

Joe Payee Month 5, 2012 450.00 500.00 100.00 150.00 500.00

Joe Payee Month 6, 2012 500.00 500.00 150.00 150.00 500.00



Joe Payee Month 7, 2012 700.00 500.00 150.00 0.00 550.00

Joe Payee Month 8, 2012 600.00 500.00 0.00 0.00 600.00

Joe Payee Month 9, 2012 450.00 500.00 0.00 50.00 500.00

Joe Payee Month 10, 2012 700.00 500.00 50.00 0.00 650.00

Joe Payee Month 11, 2012 500.00 500.00 0.00 0.00 500.00

Joe Payee Month 12, 2012 600.00 500.00 0.00 0.00 600.00

Table 1: Summary of Carry Forward Balance results

DRAW COMPONENT BY CALCULATION

The Base Model1 incorporates the above draw logic. This should help save time when

implementing a solution involving draws.

The Draw component generates 3 important values for display on reports:

• Draw Payment or Recovery Amount;

• Draw Balance SOM (start of month); and

• Draw Balance EOM (end of month).

The following chart shows a calculation stream that uses the Prev() operator.

1 The Base Model is a pre-configured model developed by Cognos ICM Lab Services that can be used as

a starting point for Cognos ICM implementations.



Calculation Logic Details

Calc: COM002 Balance EOM

Calc: COM001 Total Commission Prior to Clawback

Page 1: Calc Info

Name: COM001 Total Commission Prior to Clawback

ID: 1225

Description: This is a sample commisison prior to any clawbacks occurring that outputs payee, period and value.

Page 2: Define Data Sources

Source: ABC001 Sample Input Calculation

Page 3: Define Formula

sum(ABC001 Sample Input Calculation.Value)

Page 4: Define Partitions

[ABC001 Sample Input Calculation].[PayeeID]

[ABC001 Sample Input Calculation].[Months]

T001/Months/Months

Page 5: Define Restrictions



Page 1: Calc Info

Name: COM002 Balance EOM

ID: 1226

Description: This calculates the balance at the end of the month.


Source: COM001 Total Commission Prior to Clawback


MIN(0, (PREV() + COM001 Total Commission Prior to Clawback.Value))


[COM001 Total Commission Prior to Clawback].[PayeeID]

[COM001 Total Commission Prior to Clawback].[Months]

T001/Months/All Time


Calc: COM003 Balance SOM

Page 1: Calc Info

Name: COM003 Balance SOM

ID: 1227

Description: This is a time shift of previous month's balance to the start of the following month.


Source: COM002 Balance EOM




Calc: COM004 Net Commission Payment

Page 1: Calc Info

Name: COM004 Net Commission Payment

ID: 1228



BLENDED RATES

WHAT YOU NEED TO KNOW ABOUT BLENDED RATES

A Blended rate is simply the rate assigned to an aggregated summation of Revenue or Sales,

whose value crosses one or more thresholds as defined by a Rates table.

The 2 Approaches to Calculating Tier based Rates:

1. Retroactive Rates (the alternative to blended rates): Once a new tier is achieved

the rate applies to all prior sales

2. Blended Rates: Once a new tier is achieved the rate only applies to the portion

of sales that falls within that tier. The actual “blending” of the rates is

accomplished by taking the weighted average of rates achieved.

WHEN TO USE BLENDED RATES

The use of Blended rates is driven by business requirements.

Description: This is the net commission payment after all clawbacks, adjustments and commissions earned have been processed.


Source: COM001 Total Commission Prior to Clawback

Add Columns for: [COM003 Balance SOM]

[COM003 Balance SOM].[PayeeID] = COM001 Total Commission Prior to Clawback.PayeeID

AND

[COM003 Balance SOM].[Months] = COM001 Total Commission Prior to Clawback.Months


MAX(0,(COM001 Total Commission Prior to Clawback.Value+COM003 Balance SOM.Value))


[COM001 Total Commission Prior to Clawback].[PayeeID]

[COM001 Total Commission Prior to Clawback].[Months]

T001/Months/Months




Use Case – Obtaining a payout rate based on Attainment values

Min Rev Attainment Max Rev Attainment Rate

0 100,000 1% 100,000 150,000 1.5%

For example, if the aggregated value of Sales for a Payee is 125,000, and the Rate tiers were

structured at 0.1% from 0 – 100,000, and 1.5% from 100,000 to 150,00, the Rates would be

assigned as being 1% for the first 100,000, and 1.5% for the final 25,000. The Blended Rate

would be approximately 1.1%.

There are 3 scenarios which will occur with a blended rate and need to be

considered in the formula

1. The amount measured all falls within a single tier

2. The amount measured starts in one tier and ends in the next tier

a) The amount that attributed to the starting tier needs to be calculated to

the tier maximum

b) The amount that attributed to the secondary tier needs to be calculated

from the tier minimum.

3. The amount measured starts in one tier, fully crosses another and then

ends in a 3rd tier (or higher)

a) Calculation is a combination of scenario 1 & 2



HOW TO USE BLENDED RATES

Logic:

1. Create a table which holds the tier min, max and payout – a typical Rates table

2. Create a calculation to calculate the YTD Accumulation after sale

3. Create a calculation to calculate the YTD Accumulation prior to sale

• It is important to determine if the Accumulation after the sale is > or < the

accumulation before the sale. Both conditions will be handled in the formula

below.

4. Create a calculation to calculate the Blended Rate

Typical Blended Rate calculation formula:

If (Attain After > Attain Before,

SUM (

MIN(Tier Max - Tier Min, Tier Max - Attain Before, Attain After - Tier Min, Attain

After - Attain Before)

/ (Attain After - Attain Before)

* Rate)

,

SUM (

MIN(Tier Max - Tier Min, Tier Max - Attain After, Attain Before - Tier Min, Attain

Before - Attain After)

/ (Attain Before - Attain After)

* Rate)

)

5. Create a calculation to multiply the blended rate by the total deal amount to

determine payout

Sample results when determining Blended Rates.



Rate Table Structure

Tier Min Tier Max rate

0 100,000 0.1

100000 150000 0.15

Attainment Results

Starting Attain Ending Attain Results

20,000 40,000 1 row; 20000 * 0.1

40,000 120,000

2 rows returned;

(100000 - 40000) * 0.1

(120000 - 100000) * 0.15 or a blended

rate of:

80000 * 0.1125

DATESTRING TABLE

WHAT YOU NEED TO KNOW ABOUT THE “DATESTRING TABLE”

Although you can partition by a date field in your Cognos ICM calculations, you lose the actual

date information because Cognos ICM partitions by a Calendar period as opposed to an actual

date. For example, if you partition by your SalesDate of 03/18/2012 and select

T001/Months/Months, the partition becomes 2012, Month 03 (assuming a fiscal year of January

1 to December 31).

However, there are many situations where you actually need the partition by date. A good

example is the requirement to tally sales by day – how much was sold by each person by day?

How can you achieve this in Cognos ICM?

In order to partition by a date, we need to first convert the date into a string (text field) which can

be used to partition. This can simply be done by mapping a date field to the DateString table.

The DateString table, which is included in the Base Model, has many columns, but the primary

columns are the Date and DateString columns. The Date column is the date in a date-type

column, and the DateString column is the date in a text-type column. Simply map your date

field to the Date column of the DateString table, and partition your calculation’s result by the

DateString column.



WHEN TO USE THE DATESTRING TABLE

There are many uses for the DateString table and these are best understood by examining the

common kinds of columns in this table:

Column Name Description and Utility

DateString To convert a date-type field to a text-type field for partitioning requirements.

In format of yyyy/mm/dd – this is important because it allows you to sort accurately by

date.

DayString The day number as a text-type field for partitioning requirements.

MonthString The month number as a text-type field for partitioning requirements.

YearString The Year number as a text-type field for partitioning requirements.

DateValue The day number as a numeric-type field for calculation requirements.

MonthValue The month number as a numeric-type field for calculation requirements.

QuarterValue The quarter number as a numeric-type field for calculation requirements.

YearValue The year number as a numeric-type field for calculation requirements.

WeekIncrValue The incremental week number as a numeric-type field for calculation requirements. For

example, this is used where you need to calculate the number of weeks between two

particular dates.

MonthIncrValue The incremental month number as a numeric-type field for calculation requirements.

For example, this is used where you need to calculate the number of weeks between

two particular dates.

DateBy8DigitsString To convert dates of the type yyyymmdd (8 digits) into a date format that is recognizable

by Cognos ICM.

DateBy6DigitsString To convert dates of the type yymmdd (6 digits) into a date format that is recognizable

by Cognos ICM.

DayOfWeek Monday, Tuesday, Wednesday, etc... The day of the week for partitioning or reporting

requirements.

DayOfWeekValue Monday = 1, Tuesday = 2, Wednesday = 3, etc... The day number of the week as a

numeric-type field for calculation requirements.

BusinessDay 1 for every business day, 0 for every non-business day. Often used to count the number

of business days between any two dates.

NbrOfWeekValue The day number as a numeric-type field for calculation requirements.

CurMonthStartDate The starting date of the month that this record falls within.



CurMonthEndDate The ending date of the month that this record falls within.

When constructing such a table, you must ensure that it abides the Fiscal periodicity of your

client. For example, the Splits table in the Base Model is based on the Jan01-Dec31 fiscal year.

If your client’s fiscal year is Apr01-Mar31, then the values in columns such as MonthString and

MonthValue may be misleading.

THE DATESTRING TABLE BY CALCULATION

Let’s assume we have a Revenue table as follows:

tsdRevenues

SalesRep SalesDate Product Revenue

TBoxter 110426 Radio 259

TBoxter 110427 TV 4567


TBoxter 110429 Radio 827

TBoxter 110430 Modem 231

TBoxter 110501 Grill 875

TBoxter 110502 Modem 123

TBoxter 110503 Grill 875



Your client requires you to report on Month-to-date (MTD) earnings by day. How is this achieved

in Cognos ICM?

Calc1: Daily QTD Revenues by Payee Description: This calculation will use the DateString table to map the date to a Cognos ICM

recognizable date, and also partition by a date for calculation purposes. Sources: tsdRevenues, DateString

{Where DateString.DateBy6DigitsString = tsdRevenues.SalesDate}



Formula: sum(tsdRevenues.Revenue) Partitions: tsdRevenues.SalesPerson, DateString.Date (T001/Months/Months)

Accumulating on DateString.DateString Calc1 Result:

PayeeID DateString Month Revenue

TBoxter `2011/04/26 2011, Month 04 259

TBoxter `2011/04/27 2011, Month 04 4826

TBoxter `2011/04/28 2011, Month 04 8254

TBoxter `2011/04/29 2011, Month 04 9081

TBoxter `2011/04/30 2011, Month 04 9312

TBoxter `2011/05/01 2011, Month 05 875

TBoxter `2011/05/02 2011, Month 05 998

TBoxter `2011/05/03 2011, Month 05 1873

TBoxter `2011/05/04 2011, Month 05 3801

TBoxter `2011/05/05 2011, Month 05 13082

INTRAMODEL IMPORT

The Intramodel Import (a.k.a. the “Hawkins Hack”) is essentially an import of data into Cognos

ICM based on data that already exists within the model itself. In doing this, it allows for a few

features not normally available, but comes with a few risks. What it can be used for is this:

1. Transform/modify data in existing tables, using SQL queries

2. Copy entire tables within Cognos ICM

3. Import to usable tables, data that is normally un-accessible

How it’s Done

You will need to select the ‘import’ wizard.



Within the wizard, select .

Choose the Database Driver that applies (SQL Server in this example). Then choose the

appropriate DB and supply the credentials.

You will now be able to make a query based on the data residing within your model.



Finally, map the fields appropriately and complete.

This is, simply put, the Hawkins Hack. Some of the uses of this will be detailed below, with

some mention of the usability and what you should avoid so as not to cause model failure.

Uses

A. Table Copies

The safest use of the Hawkins Hack is to use it simply for data copies.

1. You have made a table with incorrect data types, and populated it. You had imported

data from several files to get to this point, so to save yourself some time, you can import

the data directly from the table you’ve already made and filled, into the new table.

B. Data Transformations

Probably the most useful thing to do while employing this import methodology is to perform

data transformations. Here are some examples of what you can use this for.

1. An email address isn’t supplied by the source systems, but the company has a standard

email format based on the first and last name. You can use SQL to perform string

manipulation and populate the Email Field.

2. You need to fix an entire transaction table due to an error that existed in the client

source data. Once again, if the error was consistent and can be uniquely defined by



other existing data, then it’s a simple matter of creating the appropriate SQL query to

solve the problem.

Example

The model contains payees whose email addresses were not populated by the source data.

Email addresses are of the format <PayeeID>@IBM.com. Given this, you can import data

against the model itself, and create a query that will update the email addresses if there isn’t

already an email address in existence.

The query entered here was

Select *, PayeeID + '@Cognos ICM.com' as email2 from Payee where Email = '' or Email is Null

C. Importing Results



ACCUMULATING PARTITIONS

WHAT YOU NEED TO KNOW ABOUT ACCUMULATING DATA

In a Calculation, partitions define how the calculated result will be presented.

3 Scenarios:

1) No accumulation: The result for each row is independent. In the figure below, the

“Calculation” and the “Accumulate” are the same. This means that there is no

accumulation and the results (value) for each row is independent.

2) Accumulating Periods Partition: In the Figure below, the “Calculation” and the

“Accumulate” are different. This means that there is an accumulation by year and each

row result (value) will add to the previous until the year changes or any one of the other

partition changes.

Note: this will create a result for every period in your calendar



3) Accumulating Partitions Option: This option allows the user to select which columns

to accumulate by. In Figure 4, the Accumulating Partition is selected, which means that

Cognos ICM will accumulate until there is a change in years or any column mentioned in

the Upper Window (PayeeID and AttributeID). The columns in the Lower Window

(DateString and OpportunityID) will not reset the accumulation. See Table 2 for results.

Note: this does

Upper Window = if partition changes, accumulation resets to zero

Lower Window = if partition changes, accumulation value continues

Use Case: Running YTD total revenue at a Transactional Level, accumulated in order of

Date, then TransactionID.



PayeeID AttributeID DateString TransactionID Period Value 1234 License YTD

Credit Actuals 01/20/2012 Opp-1234 Jan 2012 2000

1234 License YTD Credit Actuals

01/23/2012 Opp-5678 Jan 2012 3000


01/27/2012 Opp-9012 Jan 2012 4500


01/27/2012 Opp-3456 Jan 2012 500

*Note, when DateString and TransactionID changes, value accumulates, when PayeeID

changes, value starts back from zero.

WHEN TO USE ACCUMULATING PARTITIONS

Accumulating partitions are used when you want to accumulate on something other than just the

period. For example, if you need to track YTD revenue accumulating by transaction,

accumulation partitions will enable you to do so.

Accumulating Partitioning

is checked.

Upper Window

Lower Window



COMPONENT CONNECTIONS

In Composer, outbound connections are used to expose data contained within a component so

that it can be used by sibling or parent components. Conversely, inbound connections are used

to bring data into a component from sibling or parent components.

Cognos ICM does not limit the number of connections that can be created. However, a high

number of connections will result in a model that is difficult to understand and maintain.

In some cases, there will be a need to connect calculation results to existing “placeholder”

connections. This can be done provided the following conditions are true:

• The Calculation has the same set of partitions as the disconnected connection.

• If a time partition is used, the level (e.g. Periods) and calendar (e.g. T001) are the same

Cognos ICM also allows connections to be made from tables. However, this is not

recommended as it tends to add clutter and complexity to the model. Rather, if a table needs to

be used outside of its component, it can be designated as a Global table. This will allow it to be

used throughout Composer without the need to create connections.

Documents

IBM Cognos ICM · PDF fileIBM Cognos ICM Advanced Composer Concepts June 2013 This document contains confidential and proprietary information and is intended only for the person(s)