| Mockup |
|---|
| add_create_person |
|---|
| add_create_person |
|---|
| Version | 1 |
|---|
| Name | add_create_person |
|---|
|
| Gliffy Diagram |
|---|
| size | L |
|---|
| name | dtree scenarios PII |
|---|
|
...
WIP --This is to explore and contrast different models
Need AZ at the assumption level since co and people can be in multiple worksets and models.
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
Multiple Assumption Sources for detail. can this be pushed together
ACH: Potential Granularity Differences
Looks like the Common Forecast Assumptions are from a CO perspective.
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.
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.
| Gliffy Diagram |
|---|
| size | L |
|---|
| name | RAFT_PII_Comment |
|---|
|
| Gliffy Diagram |
|---|
| size | L |
|---|
| name | RAFT PII Authorizations |
|---|
|
...
Assumes that there is a "Standard" or common Model
ACH: Correct
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.
...