You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

Diagram Sandbox

(warning) WIP --This is to explore and contrast different models

Gliffy Macro Error

An error occurred while rendering this diagram. Please contact your administrator.

  • Name: Raft ER 1

(warning) Need AZ at the assumption level since co and people can be in multiple worksets and models.
(question) Do we need detail Salary expense detail, in addition to roll up posted to GL

ACH: Yes - we need to the monthly salary by person, the % effort by CO for that person, and separately: the total loaded cost for that person

(warning) Multiple Assumption Sources for detail. (question) can this be pushed together

ACH: Potential Granularity Differences

(warning) Looks like the Common Forecast Assumptions are from a CO perspective.
(question) Do we need to create Common Assumptions from the Person view as well

Under discussion. The current belief is that Common Assumptions in some form should be available for a person. This makes interface model fairly complex though.

(question) How do the edge conditions of a workset get handled.
Example: CO A has a salary allocation for Tom, who also has an Allocation in CO B, but CO B isn't in the workset.

ACH:

1) Allocations outside of the workset will show as "Other" and will not be editable within the workset.

2) In our current plans there is a "Person" view that shows all of the CO allocation for a person in the workset. From this view all allocations are editable.   

Easiest would be to include all people and all COs, but the boundary may be ragged.

Gliffy Macro Error

An error occurred while rendering this diagram. Please contact your administrator.

  • Name: Raft ER 2

(warning) Assumes that there is a "Standard" or common Model

ACH: Correct
(question) How does the concept of Workset help - Limits the user view set available at any point in time. We are not limiting what they do with a set, but we want a quick way to limit the working set that they are calling. Secondary effects will ripple

across multiple COs/Worksets, but the plan is to limit how many direct COs and People we need to deal with from the Users's view side at any point in time. In <certain systems> there was an issue with simply loading the fully populated hierarchy. We want to prevent that from happening.

QUESTION - ACH: How do we handle Overhead Assumptions? As Financial Assumptions only?

  • No labels