Transcript Understanding Allocations

Understanding
Allocations
Brian Chizever
Cognos Corporation
Terminology
• Allocations
– General usage: to apportion among a group
– Cognos Finance: a set of specialized steps in the calculation
process
• Allocation Table
– The set of allocation rules for a specific submission
• An Allocation
– One step in the allocation process
• Allocation Line
– One rule in the allocation table
– This rule may perform one or more steps in the allocation
process
Allocation Levels
• Determines when the allocation is executed
– Level 1: Occur after submission rollups and currency
translations and before all other calculations
– Levels 2-8: Each allocation level forces another round of
Input Component and Rollup Component calculations.
– Level 9: Occur after all other calculations are completed.
No other calculations will occur after level 9 allocations.
– The minor (decimal) portion is used to order allocations
within a major level
Allocation Types
• There are six allocation types
– By Account: Use another account as a basis to determine the
percentage of the source value that is assigned to the target
– By Specific Proportion: Use a specified weight as a basis to
determine the percentage of the source value that is assigned to the
target
– Combine: Add the sum of all source values and assign that sum to
the target
– Distribute: Copy the source component/account value and assign
that value to the target account for each target component
– Duplicate: Copy the source account value and assign that value to
each target account within a component or set of components
– Reverse: Copy the source values, reverse the sign and assign that
new value to the target
By Account
• Used to assign a value to the target
component/account based on the value found in
another account in the target component
SA
TA
SA
SC
SA
TA
SA
TA
TA
By Specific Proportion
• Used to assign a value to the target
component/account based on weights specified
for in the Allocation Table
SA
TA
SA
SC
SA
wt2 %
TA
SA
TA
TA
Combine
• Sum several source values and assign the result
to the target.
SC
TA
SA
SC
SC
TA
SA
SA
TA
TA
SA
TC
Distribute
• Copies data from the source to the target(s)
SA
TA
SA
SC
SA
TA
SA
TA
TA
Duplicate
• Copies values from the source account to the
target account within multiple components.
SA
TA
SA
TA
SA
TA
Reverse
• Copies data from the source to the target and
reverses the sign
SC
SA
SA
TA
TA
Component Hierarchies
Demonstration 1 & 2
• Demonstration 1
– Allocate Rent By Account and Reverse in 2 lines
• Demonstration 2
– Allocate Rent By Account and Reverse in 1 line
– Allocate By Account & Allocate By Specific Proportion
• If some weights are negative and some positive, treat it as two
separate allocations
– Those targets with positive weights get the source amount allocated
– Those targets with negative weights get the reverse of the source
amount allocated
Demonstration 3 & 4
• Demonstration 3
– Same as demonstration 2 (Allocate Rent By Account and
Reverse in 1 line), but add a line for Postage and a line
for IT Expenses
• Demonstration 4
– Same as demonstration 3 but all in one line using
Allocation map
– Large performance improvement because number of file
reads are writes are greatly reduced
– Eases maintenance because component groups are
selected once instead of multiple times
Allocation Map
• If you have multiple allocation lines that only differ by
accounts, use an Allocation Map to merge the lines
• Faster performance
– Eliminating file reads and writes is the single biggest
performance gain you can get
• File Storage
– Each submission is a file
– Within each file, a record contains all accounts and periods for a single
component group
• Easier to maintain
– Only one line instead of multiple lines
– Ensures that multiple allocations use the same component set
Demonstration 5
• Demonstration 5
– Ease maintenance by using dependency
– If more children are added to the calculated item, the
allocation table doesn’t have to change
Set Dependency Levels
• Self
– Just use the selected item
• Input
– Replace the selected item with all the input items which roll
into it
– Has the effect of replacing one component group with many
component groups
– Eases maintenance by ensuring the allocation is based on the
current hierarchy
– Each input item uses the weight specified for the parent
– Rounding Error
• If set to “No”, each input is “No”
• If set to “Yes”, the first input is “Yes”, all others are “No”
Demonstration 6 & 7
• Demonstration 6
– Same as demonstration 5 but add three additional
lines for remaining hardware products
• Demonstration 7
– Same as demonstration 6 (allocating from multiple
target component groups), but merge into one line of
the allocation table
Multiple Source Component Groups
• Some allocation types use multiple source component groups
– Combine
– Duplicate
• Some allocation types use a single source component group
–
–
–
–
By Account
By Specific Proportion
Distribute
Reverse
• For those that use a single source component group, we allow the specification
of multiple sources
– This is treated the same as multiple lines in the table with each line using a single
source component group
– Merging lines by using multiple sources for these allocations may:
• ease maintenance
• have a slight performance improvement
• create more allocations than intended
*MATCH
• *MATCH means to use the same item for the
target as was specified in the source
• This is mostly used when specifying multiple
source component groups
Demonstration 8
• Demonstration 8
– Same as demonstration 7 (allocating from multiple
target component groups), but use hierarchy for
source
– Hierarchy makes maintenance easier
– Hierarchy makes it very easy to create a large
number of allocations
• Possibly without realizing it
Demonstration 9
• Demonstration 9
– Similar to demonstration 8 (allocating from multiple
target component groups), but use component library
for source
Libraries for Component Groups
• For each dimension, a library or single item is selected
– If no dimensions use a library, this is converted to a component group with
one row
• The library is loaded at the time the calculation is performed
– If a library cannot be found, the allocation is skipped and an appropriate
message is written to the log.
• When specifying libraries be aware of the path since the calculation may be started
from different machines
– The library may be either static or dynamic
• If dynamic, the hierarchy of the submission being calculated is used
– All items have a weight of one and dependency set to “Self”
• If multiple dimensions use a library, each item in each dimension is
paired with each item in the other dimension
– For example if dim1 has a library with 3 items and dim2 has a library with
2 items, there will be a total of 6 (2x3) component groups.
Performance
• Minimize file access
– Use Allocation Maps
– Be aware of “exploding” nature of hierarchies
• Executing allocations based on calculation flags
– In version 7.3 and earlier, all allocations were executed
– In version 7.3SP4 we added logic to skip allocations if the
data had not changed
• Must be run if any data changed
– Source or Target component group
– Source, Target, or Basis account
• Set flags manually iff the allocation table changes (similar to Currency
Translation and Submission Rollup Tables)
• Setting the Target Value to “Add” forces a lot of work to determine
which allocations can be skipped
Target Value Option
• Overwrite
– This is the normal action
– The new target value replaced any existing value
• Add
– The new target value is added to any existing value
– Mostly used to allocate multiple rules into the same
account
• Insert an allocation to ensure the initial value is zero
– Avoid if possible
• Interferes with the ability to skip allocations based on
calculation flags
Source Value Option
• Copy
– This is the normal action
– The source value is retained after the target is written
• Move
– The source value is set to zero after the target is
written
– Removes the need for a Reverse allocation
– Makes the calculation non-restartable
– Only use for intermediate values
Create Component Groups Option
• Yes, create component groups for allocation.
– Should (almost) always be used for these types:
• By Specific Proportion
– The sum of the values in the targets should equal the value in the source. This may not happen if you
don’t create new component groups
• Combine
– The created sum may be first value in the target component group
• Reverse
– The reversal may be the first value in the target component group
• No, ignore component groups that do not already exist in this submission.
– Mostly used for Distribute
• If you want a rate in multiple components, you may only input into one of them and use
Distribute to copy it to the other components
• If those other components have no other data, you don’t want to create them just for this
• This option is ignored for
– By Account
• If the target doesn’t exist, the basis is zero so the target would not receive a value anyway
– Duplicate
• If the target doesn’t exist, neither does the source so there is nothing to do
Compare Allocations
• Compare the allocation tables in two submissons
–
–
–
–
Lines in submission 1 but not in submission 2
Lines in submission 2 but not in submission 1
Lines in both submissions that match
Lines in both submissions that are different
• Option for how many differences the line has between the
two submissions before it’s considered a different row
• Option for which columns are used in the comparison
– For example, may not care if the comment is different
Cognos Finance,
moving forward.
Q &A