Application classes peoplesoft pdf

Start here to find all of the latest resources for Oracle's PeopleSoft PeopleTools products, features, customers, and more. Documentation Updates See Documentation Updates for a cumulative list of updates to the online help and PeopleBooks through August 02, Documentation Updates See Documentation Updates for a cumulative list of updates to the online help and PeopleBooks through March 2, Documentation Updates See Documentation Updates for a cumulative list of updates to the online help and PeopleBooks through October 12, Older Releases Older Releases.

An architect might in fact have several blue prints detailing where electrical will be placed and wires run. Conversely another blue print might show where piping will run. Keep in mind the blue print is NOT the house it is only a representation of the house an Application Class is similar. There are a few things that need to happen before we have a house:.

In some respect a simple application class can appear on the surface to be similar to a function. Skip to content house blueprint. PeopleCode Create Function. End - Function ;. This example illustrates the fields and controls on the Select a Content Reference page. Select to make hidden content references available for assignment. Click to expand the folder and display child folders and links. Click to collapse the folder and hide all children.

Click a content reference link to select that content reference to which related content will be assigned. After selecting a content reference, continue by configuring PeopleCode programs and events.

Use the Configure Event Mapping page to map application class PeopleCode to component level, page level, and component record level events. This example illustrates the fields and controls on the Configure Event Mapping page. Select the unrestricted prompt only when the item for which you are searching is not found on a page definition that is explicitly included in the component definition. This allows an unrestricted search of all matching definitions within the system.

Searching for secondary pages invoked by the main page or by a subpage at any level within the component. Note: If you return to this configuration, the unrestricted prompt check box is no longer selected. However, the actual configurations are retained.

Using this process, the different end users can approve or deny requests, monitor transaction statuses, and audit approvals. Many PeopleSoft transactions have a top-level record known as a header with keys that uniquely identify a single transaction in an application. Then, these transactions typically have children records line-level records of this header record. This check is possible because the system correlates the application header keys with the approval process instance keys.

When you need to track an approval status at a lower level within a transaction, an analyst can configure the approval process so that different line-items in the same request follow different routes. In such cases, the workflow approval engine splits the workflow into constituent line items, and enables analysts to configure the approval process so that different line items in the same request follow different routes.

These lines of the workflow are still part of the same request, however, and should be tracked as such. You can deny some lines of the requisition and approve others, making line-level approvals independent for each line. For example, a requisition can contain multiple lines, and you might want to use special approvers for certain catalog items, such as software or hardware.

You can add specialized approvers to approve requisitions that are in their area of expertise. An approval workflow might have mixed header and line-level approval routings. For example, department managers might exercise budgetary control over the request as a whole, while commodity approvers still examine only those line-items which fall within their expertise.

Final approval requires both types of approvers to sign off on the requisition. When a request is approved, the engine notifies the application, which then takes source end actions:. An approval of one transaction often leads to the creation of another transaction, or triggers another business process. The approval workflow engine supports this trigger by providing a call-back mechanism for event notification.

For example, when a requisition is approved, it can be sourced—an action follows final approval, which is the end action. Use line-level approvals to make it possible for an action to be taken on different line items upon their approval, without waiting for the approval of other line items in the requisition. You can source line items as soon as they are approved. This action is possible only if line-level approval routings are at the end of the process and require no further review.

In this case, the application can act on the individual lines as they get approved. The approval workflow engine notifies the application of significant approval-related events. After an approval process is defined, validated, and made active, the system can submit a transaction for approval.

Each PeopleSoft application typically has a top-level database record that distinguishes one transaction from the next. These top-level records are called header records. When a transaction is submitted for approval, the approval workflow engine combines the approval process definition with the header record instance and line records, if line level approval is configured, to create a unique approval process instance. This approval process instance is routed from approver to approver, as configured in the approval process definition.

Approvals use two levels of processing: header and line. Business analysts set up the approval process definition that determines the flow of the approval at both levels. The approval process consists of:. A stage is one part of an approval process that can contain multiple parallel paths but must be at the same header or line record level. The system executes stages in sequence where one must complete before the next one begins. A stage can be at either a header level or at a line level.

Stages at a line level make it possible for approvers to sign off separately on individual line items for a single transaction. The workflow engine sees each header and each line as individual pieces. A line is a child of the header. A header stage acts on the unique header while a line stage acts on each line. A stage consists of one or more paths. A path contains a sequence of steps. Within a stage, paths execute in parallel.

Path entry criteria determines whether or not a path executes for a given transaction or transaction line. A step represents one or more approvers or reviewers. Steps within a path execute in sequence. Separate criteria for each step determines whether or not that step executes. Each step can also have a set of reviewers. Reviewers are notified about transactions that are pending approval by email, through the Worklist, or both.

However, the workflow proceeds without waiting for reviewers to act. The system notifies approvers by using email, Worklist, or both, of pending approval steps, which can require one, all, or a fixed number of approvers. You can specify approvers by roles, queries, fixed lists, or by using custom application classes. Once the required number of approvers have approved a step, the approval workflow advances to the next step. If the workflow has no further steps, it advances to the next stage.

While the configuration may require multiple approvers to approve a step before it advances, any single approver can deny a step. The moment an approver denies a step, the transaction stops moving forward in the approval process. If the transaction is at a line level, other lines will continue to move forward. If the denial is at a header level, the approval process terminates, and the entire transaction is denied.

However, PeopleSoft Expenses allows processing to continue. This diagram illustrates how the approval process uses stages, paths, and steps for routing approvals:. Using a combination of features, you can create rules for different types of approvals. This section discusses:. During the approval process, approvers can add other approvers or reviewers to the current or a later stage of the approval process. For example, if a buyer wants input from an inventory analyst, she can add the analyst as an approver.

This action is called ad hoc approval, and it only applies to the approval instance in which the addition occurs and does not affect the underlying process definition used for other requests. You can add ad hoc approvers once the requisition is submitted.

If you have an ad hoc approver user list defined in the transaction registry, only the users within that list can be added as an ad hoc approver or reviewer. Ad hoc reviewers are users that an approver or requester would like to review a transaction. Ad hoc reviewers are notified and provided with a link in a Worklist entry or email to the transaction, if the process is so configured.

A requester can also be an approver. If requesters approve their own transactions, it's called self-approval. A check box setting enables self-approval. However, you can establish criteria that helps control the requester's approval authority. For example, you can place a limit on the dollar amount for the requester so that if the transaction is over that amount, the requester is not used as an approver. If self-approval is not enabled, then the requester can't serve as an approver.

If the requester appears as an approver for any step, they are blocked from acting. If, because of this, the number of approvers that are available to act drops below the minimum, then an error is generated. The process is then routed to the administrator. If self-approval is enabled, then the self-approval criteria must be specified.

Then, if the requester appears as an approver, the criteria is evaluated. If the criteria are met, then the requester's approval is assumed and the minimum approvers for that step decrements by one. When a requester is an approver, you can configure the path to skip the steps in that path prior to the requester's step. Route to requester is a feature that informs the system that an approval should be sent to a requester under certain circumstances:.

If self-approval is set up, the criteria to trigger self-approval is not met, and route to requester is not selected, then the requester can't be included as part of the approval path. If route to requester is selected and self-approval criteria is not met, then the requester is included as part of the approval path and the system notifies them of the pending approval.

For example, if a vice president orders items on behalf of a direct report at the supervisor level, the system will send a notification to the supervisor for whom the order was made. The supervisor remains part of the approval process. When skip prior to requester is enabled, the system begins the approval flow at whatever step in which the requester is an acknowledged approver. For example, if a vice president orders supplies for herself, the system skips application approval steps leading up to the step for which the vice president is an acknowledged approver.

For example, if the approver approves line one and the line appears again as a required approval for the specific approver, the approval is remembered for the line. This approval does not pertain to any other line, but header approvals do imply line approval for this feature. Alternate Approvers. Alternate workflow approvers are users who are assigned to receive emails and Worklist notifications for the primary approver when the primary approver is not available.

When you identify an alternate approver, you enter a date range during which you want the alternate to fill in. The system determines if the alternate is in place for the date range.

Alternate users are defined in the User Profile. Push back takes a currently pending step out of pending status and requeues the previous step to its approvers. Push back is only possible within a path, therefore, the first step of a path cannot push back. Requesters can add comments to transactions, and approvers can associate their comments with the approval process rather than the request transaction directly.

The approval workflow monitor provides a mechanism for associating comments with a particular approval process instance, which is tied to a particular application transaction. Approvers can view comments added by another approver, but they cannot change previous comments. This section details the steps to implement and use approval workflow.

It describes tasks that application developers, business analysts, and end users perform in conjunction with approval workflow. Application developers register information with the approval workflow engine by using the Register Transactions page. Application developers create a record and table in which to store cross-reference information and set up notification templates for events.

This definition determines the pending approval workflow process and tells an application which transaction is being approved or denied.

Functional business analysts define the approval process definition for an application transaction. Essentially, analysts determine the approval transaction registry entry on which the process definition is to be based and then define the details of the process.

The approval process definition includes definitions of stages, paths, steps, and criteria. This action launches the approval process. The approval workflow engine reads the approval process definition and queues the transaction for approvers. The system queues an approval task to an approver or reviewer using email notification, Worklist entry, or both.

When an error or violation of criteria or rules occurs during the approval process, the system notifies the administrator, who interacts to resolve the issue. The error conditions for static steps are no approvers or not enough approvers at a step. Business analysts use this page to define an approval definition process. The process is made up of stages and their paths and steps.

The approval steps that you place on the approval path represent the approval levels that are required for a transaction.

Use alternate hierarchies, such as commodity approvers procurement and financial approvals expenses and so on. Use staged tracks, such as first receiving commodity approval and afterward receiving financial approval. Two different approvers for each step, where both approvers at a step must approve the request for it to advance to the next step.

See Understanding the Approval Transaction Registry. Enter any identification code that provides meaning to you. This identifier is used as a search field on the Monitor Approvals page. Click to access the Criteria Definition page, where you can define user and field criteria along with monetary and application class criteria for this stage. This criteria is used to determine which Definition ID is to be used to process the Approval.

See Defining Definition Criteria. This criteria can be evaluated by applications to highlight conditions of a transaction to be approved. For example, a one-time shipping address used only on this requisition. See Defining Alert Criteria. Click this link to view what a workflow instance would look like if it were running. Click this link to access a graphical tool, which enables you to view each stage, path, and step of the approval process.

When you are viewing the graphic tool in the Approval Process Builder page, if you elect to make changes the system will return you to the standard Approval Process Definition page.

Indicates the date on which this approval process became effective and ready for system use. This value applies to approval processes for a particular approval process ID and definition ID, and it includes PeopleSoft functionality associated with effective-dated entities. For instance, if multiple approval processes are active with the approval process ID, definition ID, and effective-date specification, then the system uses the latest active effective-dated process.

Select the user list role used by workflow to route the transaction to all users filling that role in case of an error during approval processing. Active: Indicates the approval process is available for use. Inactive: Indicates the approval process is not available for use. A transaction that has started with a specific definition continues using that definition, even if the status is Inactive.

Select to sort the definitions in the order that the Definition Criteria should be evaluated. The Definition with the highest priority and that matches the definition criteria is used to process the transaction. Priority 1 is the highest. Multiple Definition ID's can have the same priority. Select to indicate that the system should use this process definition as the default when no other definition ID matches the criteria entered.

Select to allow each line to continue to the next step of the approval process, with out waiting for other lines within the transaction to complete. This setting applies to approval processes that have a line-level stage at the end of the process.

The system supports line-by-line sourcing only when the last stage is at the line level. This setting assumes that the line-level stage is the last stage of the approval process. The next time this approval process is presented to the approver, the system automatically applies the approver's selections. The automatic application of steps in the process is left in place until you clear the User Auto Approval check box. This setting applies to the specific line or header the approver had previously approved in this process only.

A header approval implies line approvals for all lines. Route to Requestor works in conjunction with the self-approval flag. If the approver failed to meet the self-approval criteria, the approval could still be routed if this check box is selected.

If the check box is not selected and the approver fails to meet the self-approval criteria, then the system routes the approval to the administrator. Enter the sequence in which you want this stage of the approval acted upon. You can also enter a description for the stage in the Description field.

A stage is a logical grouping within a process such as commodity or fiscal approval. You can define a single stage or use multiple stages, in which case the stages execute in strict sequence. Before the second stage starts, the first stage must end. Each stage must be either at the header level or at the line level. This is the additional constraint on header- versus line-level approval configurations.

A header-level stage acts on the single header. A line-level stage acts simultaneously on all the lines under the header.