Skip to end of metadata
Go to start of metadata

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

Compare with Current View Page History

« Previous Version 15 Next »

We built Financial Approval version 1.0 through Spring 2013. I completed it with help from Fruition, worked out bugs, and finally put it in test in summer 2013. Shortly after, it was demo-ed with focus groups, and various people pointed out oversights and flaws.

In late August 2013, we completed a spec for version 2.0. Backeberg is converting the paper-based specs to a technical spec for Fruition to work on.

Data needed to make decisions

We need a data mapping such that we can readily determine appropriate approvers for each active Organization at Yale. Organizations have six-digit codes, a name, as well as:

  • Operations Manager (sometimes)
  • Lead Admin (almost always)
  • BOLT Team Member (even more often)
  • BOLT Team Leader (always)

History

On Financial Approval version 1.0, we needed to reorganize our data loaders, and we added data dips that get us Operations Manager (where avaiable) and Lead Admin data for the Organizations. This works great and is well tested since Spring 2013

New feed

We need a new data feed for BOLT Team Member. Met with Nancy Scanlon and Igor B. in early Sept. Confirmed that this data only lives in the data warehouse. I need a feed on "yugl organization dm cur v" and the fields inside there are:

  • CD six-digit ORG number
  • Senior Director (bolt member)

New feed requirement

R1026 is the number in HPQC.

Request for access to Hyperion / Brio / DWH

Backeberg confirmed we can leverage the existing level of access already used for pulling similar information from DWH. However, a problem is that Senior Director is represented as a Real Name, and there are no other identifying characteristics for that user. This is a problem because Real Name is terribly ambiguous in most cases, and especially at Yale with a user table with 200k members. Need to bug Nancy Scanlon or somebody at DBAs to discern about how we possibly handle revising the DWH to have a UPI for the Senior Director in the DWH pull.

Need to enhance DWH / HOP source

Met with Soren week of Sept. 12, 2013. Learned that the upstream data source in HOP1 also does not have a unique identifier for SENIOR_DIRECTOR. As such, it will take a long time to get the data properly situated. Meanwhile, it would be worthwhile to move on without that data.

R1026

On R1026, I built the data loader for SENIOR_DIRECTOR as-is, with the imperfect data because I need to move on. I built a special hack to translate the Joe data into Joseph data. I tried to have Nancy Scanlon fix this, but it's not something she controls; she just receives it from upstream.

So we have a long-term bug we just seeded, which is that if we end up with SENIOR_DIRECTORs with common names, we will not be able to set them appropriately.

R1020

I sent the spec to fruition in three phases

Phase one

R1020: Financial Approval Workflow, v. 2.0, No PTAEO mode

We have a new spec for Financial Approval Workflow.

I would like us to:

  • copy the existing Financial Approval Workflow. Name the new one "Financial Approval v2, No PTAEO"

The old Financial Approval Workflow had a single mode, with operation based upon Opened By and Requested For.

The new Financial Approval Workflow has three modes, with operation based upon Opened By and Requested For,
or on a single PTAEO,
or on two PTAEOs.

As such, we need to build three workflows, each more complicated than the previous one.

Once we get this copied, we need more changes:

  • add two fall-through modes. See later comments.
  • when we finish this one we will move on to the one PTAEO version
  • when we finish the one PTAEO version we will move on to the two PTAEO version

I've attached a revised version of the attachment. The UC versions are revised. Please ignore the earlier versions of these blocks:

I've now created the data. See UC108 for the condition we are modeling here. And see UC109 for the algorithm for determining the primary approver.

The OpsMgr and LeadAdmin were already used in Financial Approval rev 1.

The Bolt Member is a new field, now in the Org table. The field is:

u_cmn_organization.u_bolt_member

START admin is a new field, and we are going to statically define it directly in the approval workflow. The sys_id for the START admin is:
09bea76ad8d46c007ac0638b5167dcc6

which is Nancy Scanlon.

This block is revised, please ignore earlier version.

The general idea of financial approval version 1.0 is sound. But the phase where we choose an approver is more complex, and the way we fall through to a secondary approver after three days will also need to be more complex:

1) start with trying to assign OpsMgr as primary approver. Start the three day counter. Then execute UC105. We always want to escalate. If the ORG has a Null value for LeadAdmin, instead assign Bolt Member. If null value for Bolt Member, assign START admin.

2) if null OpsMgr, set primary as LeadAdmin. Start the three day counter. Then execute UC105. We always want to escalate. If the ORG has a Null value for Bolt Member, then set START admin as secondary.

3) if null LeadAdmin, set Bolt member as primary. Start the three day counter. Then execute UC105. We always want to escalate. The only secondary we can escalate to is START Admin.

I think you're going to need to overhaul the section of the approvals to accomplish this.

Phase two

R1020: Financial Approval Workflow, v. 2.0, One PTAEO mode

do FRU0015862 first, before this one.

I would like us to:

  • copy the "Financial Approval v2, No PTAEO", name the new one "Financial Approval v2, One PTAEO"

The new Financial Approval Workflow has three modes, with operation based upon Opened By and Requested For,
or on a single PTAEO,
or on two PTAEOs.

As such, we need to build three workflows, each more complicated than the previous one.

Once we get this copied, we need more changes:

  • We are calculating the approvers for the ORG based on the value set in the PTAEO, rather than the requested_for field.
  • when we finish the one PTAEO version we will move on to the two PTAEO version

See UC105 and UC106. We're going to build a simpler version of those in this phase.

We need to revise the logic that selects the ORG from which to choose approvers.

Instead of going off the Opened_by field, we are going off the ORG code in the PTAEO.

We need to check for the existence of both the recurring PTAEO, and the initial PTAEO. Only one of them should exist in this scenario, and the other should probably not even be present.

Once we find the ORG code, dig for the sys_ids for the Lead_Admin and Ops_Mgr. Are those the same as the Opened_by And / OR the Requested_for?

If so, approval.

Else, move on to use the same logic trail for picking a primary and secondary approver as in the NO PTAEO mode of Financial Approval version 2.0.

Please ignore the earlier version of this block.

Phase three

R1020: Financial Approval Workflow, v. 2.0, Two PTAEO mode

do FRU0015882 first before you start this one.

I would like us to:

  • copy the "Financial Approval v2, One PTAEO", name the new one "Financial Approval v2, Two PTAEOs"

Once we get this copied, we need more changes:

We have two PTAEOs, so we need to basically copy the logic hunk that does the breakdown for assigning primary and secondary approver, and do a second set in parallel.

At the top before we do the parallel branches, we first need to compare the TWO ptaeos. Are they the same?

If so, then revert to ONE ptaeo mode, and execute the ONE ptaeo version of the workflow.

If not, then there's no way we can have the approval granted automatically, because we require approval from a representative of EACH ORG.

Then fall through to the branches. We need two approvals, one from each ORG to be able to grant approval. If only one comes through, and then the second approval does not come through, we should cancel the request when the two rounds of three days expires.

Let me know if this is not clear. See attachment.

Phase four

Notifications. These are stored in an Excel document.

do FRU0015883 first, this is extra scope after that.

We need to review notifications. The notifications are not explicit on the first round of flowcharts.

They are instead embedded in the Excel document.

The notifications themselves are not included here.

I will invent them as we need them. There contents will say:

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

This will force us to come up with the final version of the text when people complain about getting those notifications :-p

Some of these scenarios already exist and contain existing notifications; there's nothing to do there.

In other cases we will need to invent new notifications from whole cloth, using the fake latin above.

I updated the fruition portal with a pdf-ified version of the Word document that Christine sent around.

Follow-up

There is still more to do here

Fix SPEC.

The spec is incorrect as of early September. We always need to escalate when going for a secondary approver. We only do not escalate if the primary approver was the START admininstrator.

Revise Visio.

The Visio that concerns escalation is incorrect, and needs to always escalate.

Revise Word spec.

Anytime the text spec talks about secondary approvers it needs to be rewritten to mention that we are always escalating on secondary approvers.

Questions

TWO PTAEO case, where ORGS are different.

TWO PTAEO case, where ORGS are different, but approvers are the same. As written, the SPEC says that if there are two separate ORG codes given in the two-PTAEO workflow, there should be two approvals sought, one from each ORG, and the workflow cannot move forward unless both approvals are granted.

However, many ORGs have the same set of approvers. I think we should revise the SPEC such that we merge the TWO PTAEO case to the ONE PTAEO case if and when the approvers for the separate ORGs are the same, not ONLY when the ORG codes are the same. In fact, the approvers will be the same when the ORG codes are the same, so we use this specific case as the general case.

Notifications

We have multiple places where the spec calls for notification. Some of those happen automatically, and some will have to be generated for the first time.

  • No labels