|
Oracle Workflow Developer's Guide Release 2.6.3.5 Part Number B12161-02 |
|
|
|
|
|
||
| Previous | Next | Contents | Index | Glossary |
Note: Some Oracle Applications products use the Account Generator feature to dynamically create accounting flexfield combinations. The Account Generator has generic predefined workflow functions that each Oracle Application product uses in its own predefined Account Generator process. The Account Generator processes for each product are not listed in this section, but are documented in more detail in each respective product's User's Guide. A general discussion of the Account Generator feature is also available in the Oracle Applications Flexfields Guide.
User Define Exception Workflow Process - In this process, a user-defined custom exception is run and generates a number of results (exceptions). For each generated exception, a notification is sent to the recipient of the exception. The workflow is called for each generated exception. The recipients and subject of the notification can be specified in the Custom Exceptions recipients page.
Supply/Demand Mismatch Process - This process is the Supply Chain Event Manager Exceptions notification workflow.
Oracle Collaborative Planning VMI Replenishment Process - This process is the workflow for the VMI replenishment engine.
Start ASCP Engine Process - This process facilitates the automation of launching an ASCP plan after receiving an order forecast or supply commit from Oracle Collaborative Planning.
DP Receive Forecast Process - This process facilitates receiving forecasts from Oracle Demand Planning into Oracle Collaborative Planning.
Publish Order Forecast Process - This process facilitates the automatic launch of the Publish Order Forecast program from the Planner Workbench.
Publish Supply Commit Process - This process facilitates the automatic launch of the Publish Supply Commit program from the Planner Workbench.
Start Receive Supplier Capacity Process - This process facilitates the automatic start of the Receive Supplier Capacity program when a supply commit is loaded into Oracle Advanced Supply Chain Planning.
Start SCEM Engine Process - This process facilitates the automatic launch of the supply chain event manager when an order forecast or supply commit is loaded into Oracle Collaborative Planning.
The Demand Planning processing cycle is made up of the following five stages, which correspond to processes:
The Demand Planning Administrator may choose to run a master workflow process called ODP Master that manages all five stages together by running a concurrent request to launch and manage this master process. This concurrent request is called "Demand Planning Engine Master Workflow Process."
JTF Calendar Workflows - Tracks and routes calendar requests to the Calendar Administrator for new group and public calendar approvals and to Group Calendar Administrators for existing group calendar subscription approvals. The process also sends invitations for appointment invitees and attendees.
JTF Task Reminder - Picks up appointment reminders for scheduled appointments. For example, if the user selects "15 minutes Before" from the Remind Me drop-down list while creating an appointment, then that user receives a workflow notification 15 minutes prior to the start of the scheduled meeting.
Escalation Manager
Reactive Escalation Notification Workflow - Sends notifications to inform the escalation owner, the owner's manager, and optionally any customer or employee identified in the escalation document when an escalation document is created, or when certain document attributes such as status, level, owner, and target date are updated.
Business Rule Monitor
Business Rule Monitor Main Process - This process services the Business Rule Monitor looping workflow, which in turn checks all the active business rules and identifies whether any rule has been violated.
Business Rule Monitor Task Process - This process is used only when the Business Rule Monitor Main Process identifies a violated business rule that is related to a Task object. The Business Rule Monitor Task process services the subsequent activities based on the workflow information identified for the rule. For example, if the Escalate a Task (notification only) workflow is selected for a business rule, then a workflow notification will be sent to the person identified in the workflow attributes window.
Business Rule Monitor Service Request Process - This process is similar to the Business Rule Monitor Task process, except that it is used only when the Business Rule Monitor Main Process identifies a violated business rule that is related to a Service Request object.
Business Rule Monitor Defect Process - This process is similar to the Business Rule Monitor Task process, except that it is used only when the Business Rule Monitor Main Process identifies a violated business rule that is related to a Defect object.
Task Manager
Workflow - Task Manager - Task Manager uses the Workflow - Task Manager process to send notifications to inform personnel when tasks are created or changed.
Task Manager supports sending notifications to groups or teams. If a task is assigned to a group or team, then the workflow process will send a separate workflow notification to each member of the group, rather than sending only one notification to the e-mail address listed for the group.
Notifications can be sent either automatically for both the HTML and Forms versions of Task Manager, or manually for the Forms version only.
JTF Task Reminder - Picks up appointment reminders for scheduled appointments. For example, if the user selects "15 minutes Before" from the Remind Me drop-down list while creating an appointment, then that user receives a workflow notification 15 minutes prior to the start of the scheduled meeting.
Service Request Actions and Dispatch Process - Routes a service request action to individuals in the organization for resolution and in addition, notify with instructions, appropriate service personnel who need to be dispatched to a field site. Customize the process to manage, transfer or escalate dispatch requests.
Field Service Dispatch Process - Inserts or updates service request data into the interface table and sends a notification to the field service engineer with dispatch information. This process is used by Oracle Mobile Field Service.
Electronics Renewals Workflow - This workflow is launched when an extended warranty contract qualifies for the electronic renewals process. It first derives the template set, QA checks the contract, generates a quote (draft contract) letter with associated cover, emails the letter, and updates the renewal status. When the user logs in through self service renewals, if they accept the contract quotation and decide to pay the contract amount using a PO, the workflow sends a notification to the contract administrator. Depending on the administrator's response, it sets the contract to the appropriate status.
Installed Base Transactions Notification Workflow - If the system profile 'OKS: Enable Install Base Integration Messages' is set to 'Yes', this workflow will send notifications to the user identified in the system profile 'OKS: User name to Send Install Base Messages' during certain transactions. These include when a new item instance is created, when it is terminated, when it is transferred to a new owner, when it is replaced or returned, or when the quantity of items instances are split.
CE Exception Report Transmission Notification Process - This workflow sends a transmission status e-mail notification to the designated user defined in the Bank Transmission Details window. This workflow process is initiated when you submit the Retrieve Payment Exceptions program to transmit payment exceptions reports from your bank to your local directory.
Process XML Bank Statement Workflow - This workflow begins once the import process is launched. Notifications are sent to the designated Cash Manager to say whether or not the import process was launched successfully and whether or not the import process was a success.
Delinquency Current Status Notice - This workflow sends notifications about the status of a delinquency to the agent and the agent's manager when the status changes. For example, when the delinquency is closed (that is, when it is considered "current") or when a new status such as Bankruptcy or Write-Off is created for a delinquency, a notification is sent to describe the change in status.
Collection Delinquent Credit Hold - A collector can request that a credit hold be placed on a customer by checking the corresponding check box on the Delinquency tab. A notification is then sent to the appropriate manager to review and approve or deny the request. Routing to the appropriate manager for approval is done through the reporting hierarchies as defined by Oracle Resource Manager. After the request is approved, the Approval check box on the Delinquency tab is checked so collectors can confirm that their requests have been approved. The actual setting of a credit hold is a manual process, however.
Collection Delinquent Service Hold - A collector can request that a service hold be placed on a customer by checking the corresponding check box on the Delinquency tab. A notification is then sent to the appropriate manager to review and approve or deny the request. Routing to the appropriate manager for approval is done through the reporting hierarchies as defined by Oracle Resource Manager. After the request is approved, the Approval check box on the Delinquency tab is checked so collectors can confirm that their requests have been approved.
Notify a Third Party for Repossession - When a specialist assigns a third party organization to repossess an asset, an e-mail notification is sent to that organization with the details about the asset or assets, repossession, and other information. The specialist assigns the third party through the HTML interface.
Delinquency Status Approval - A collector can recommend that various strategies or statuses should be initiated for a delinquency: repossession, write off or litigation. (Bankruptcy is handled separately.) However, these statuses require review and approval by a manager before the corresponding strategy is initiated. The Delinquency Status Approval workflow is initiated when a collector clicks the New button on the Delinquency tab, selects a new status, enters the details to start the process, and saves the new status. The workflow routes the request according to the resource's hierarchy as defined by the system.
Delinquency Asset Workflow - A specialist can request that an asset valuation be provided for the assets related to a delinquent case. This workflow sends a notification to the appropriate manager to review the request, obtain the information and forward it back to the specialist. The request is initiated on the asset selection window from the Delinquency tab and write off window.
Strategy Fulfillment Mailer - As part of a strategy, a request may be made to the 1-to-1 Fulfillment Server to send e-mail documentation such as a dunning notice, a dunning reminder, copies of delinquent invoices, and so on, to the delinquent party. This workflow manages this request.
Strategy Custom Workflow - If customers want to implement a custom work item as part of strategy in order to use a different implementation from the seeded workflows, they can customize the custom strategy workflow. The custom strategy work item workflow is an example of what parameters are expected to be identified in a custom workflow and what must be identified after the work item is completed.
Collection Strategy Workflow - A strategy is a series of collections work items grouped together to create a collections plan. Each work item may have a workflow as part of the completion process. The Collection Strategy workflow is the main workflow process that drives the completion of all the workflows that are tied to the collections work items for each strategy.
AutoAllocations Process - When you generate step-down AutoAllocations, the workflow process initiates the AutoAllocation process and validates and generates the Mass Allocation and Recurring Journal batches that are defined in the AutoAllocation. The workflow process also determines whether journal approval is required for each generated journal batch, submits the batches to the appropriate users for approval if required, and notifies the appropriate users of the approval results. If an error occurs during the AutoAllocation process, the designated user or users can choose to roll back the AutoAllocation process, which reverses any posted journals.
Global Intercompany System - The Global Intercompany System (formerly CENTRA) is an enhanced feature for Release 11i, and has been backported to Release 11. It provides an environment for multiple companies to exchange intercompany transactions. The workflow process notifies the receiver company when a sender company initiates an intercompany transaction and requires approval from the receiver, or when the sender company recalls or reverses an intercompany transaction. The workflow process notifies the sender company when a receiver company approves or rejects an intercompany transaction that the sender had initiated. In addition, a threshold amount can be set to limit the volume of notifications. The workflow process is initiated when the sender submits, recalls, or reverses an intercompany transaction, or when the receiver rejects or accepts an intercompany transaction.
Global Consolidation System Cross Instance Data Transfer - You can automate the Global Consolidation System to consolidate data from remote subsidiary ledger database instances to a central consolidation database instance and optionally use workflow notifications to notify users of the cross instance consolidation status. Each notification provides the user with consolidation transfer details including source database name, mapping rule, set of books, group IDs, and concurrent request ID. When a user chooses to automatically run Journal Import or AutoPost on the central consolidation database, the workflow notification cites the status of success or failure of the concurrent request. If the Journal Import or AutoPost process fails, the workflow notification recommends reviewing the request log on the central consolidation database for further details.
The workflow process is initiated at the following points:
Notifications are sent to approvers and the workflow process waits for the response from each approver before proceeding to the next approver in the hierarchical proposal approval map.
The proposal is approved if all approvers approve the proposal. The proposal is rejected if any approvers reject it. The person submitting the proposal for approval is notified of the approval status at every stage during the approval process.
Notify Approval Subprocess - The Notify Approval Subprocess is initiated during the Proposal Approval Process when the next approver in the hierarchical approval map is selected.
The Notify Approval Subprocess notifies the approver that a proposal is pending for approval. The approver can approve or reject the proposal.
If the approver fails to approve or reject the proposal within a given time frame, the approver receives periodic reminders. Organizations can set the timeout, which defines the time frame in which the reminders are sent. By default, the timeout is not set.
Notify Proposal Members Process - The Notify Proposal Members Process sends notifications to personnel on the proposal.
Credit Cards Workflow - The Credit Cards Workflow process consists of independent workflow processes and notifications that perform various activities. The Credit Cards Workflow process contains the following processes:
The following procurement card workflow processes enable your self-service employees to verify and approve procurement card transactions.
AP Procurement Card Employee Verification Workflow Process - The AP Procurement Card Employee Verification Workflow process notifies and confirms procurement card transactions with card holders. This workflow process is initiated when you submit the Distribute Employee Card Transaction Verifications program from Oracle Payables. The process notifies an employee of transactions charged to the employee's procurement card, and optionally requires the employee's manual verification.
AP Procurement Card Manager Approval Transaction Process - The AP Procurement Card Manager Approval Transaction workflow process notifies and confirms verified procurement card transactions with a card holder's manager. This workflow process is initiated when you submit the Distribute Manager Card Transactions Approvals program from Oracle Payables. The AP Procurement Card Employee Verification Workflow process must first complete for transactions before the manager workflow process is used. The process notifies managers, and optionally requires their manual approval, of procurement card transactions incurred by employees.
The Effort Report Notification workflow process includes the following subprocesses:
Notification is sent to approvers of the effort report. When the effort report is approved, the effort report is sent to a supervisor for certification. The creator of the effort report can monitor the status of the effort report.
Distribution Adjustment Approval Notification Process - Workflow functionality in Labor Distribution automatically routes distribution adjustments approval notifications throughout the organization and delivers electronic notifications to users regarding distribution adjustments that require their attention or processes that are completed. The process is initiated when a distribution batch is submitted.
AP Open Interface Import Process - This workflow automates verification and validation of data in the Payables Open Interface invoice tables. For example, this process can be modified to validate all accounting code combinations in the Payables Open Interface invoice tables. Notification of any invalid code combinations can be sent to a specified user for correction. Optionally the process can be set up to override any invalid code combinations with a designated default value. You can use Oracle Workflow to include additional workflow rules that meet the specific requirements of a business. Once an invoice has passed this process it is ready to be imported into the Oracle Payables application tables. To initiate the Open Interface Import process, submit Payables Open Interface Workflow from the Submit Requests window.
Invoice Approval Workflow - This workflow routes invoices to designated individuals for approval. This workflow uses the approval rules that you define in Oracle Approvals Management (OAM) to determine if an invoice requires approval. If the invoice requires approval, the workflow sequentially asks each approver on the approval list to approve the invoice online. For example, you can define a rule so invoices over $100,000 require CFO approval and then CEO approval.
Process Payment Message Workflow - This workflow creates the XML payment message and sends it to your bank. It then sends notifications to the user who formatted the payment. This workflow also manages the confirmation of payment batches that generate XML payments.
Receive Payment Instruction Error Workflow - If you use the XML payment feature and if you set up Oracle XML Gateway to receive the Show Payment Instruction Error message, then when your bank sends you this message, the Receive Payment Instruction Error workflow sends the appropriate user a notification that includes the payment instruction errors.
Receive Payment Advice Message Workflow - If you use the XML payment feature and if you set up Oracle XML Gateway to receive the Show Payment Advice XML message, then when your bank sends you this message, the Receive Payment Advice workflow sends a notification that includes the payment advice to the appropriate user.
For more information about related workflows in Oracle Internet Expenses, including expense reports and procurement cards, see Oracle Internet Expenses.
Submit Worksheet Workflow Process - The Submit Worksheet Workflow Process submits worksheets. Based on user-defined parameters, the process performs constraint validations, worksheet operations, copying, and merging. The process moves worksheets from one budget stage to the next and routes the worksheets through an approval process for required approvals. The process also freezes and unfreezes worksheets. Notifications are sent to users who initiate a process and to approvers.
The process is initiated at the following points:
Submit Budget Revisions Workflow Process - The Submit Budget Revisions Workflow Process submits budget revisions. Based on user-defined parameters, the process performs constraint validations and other budget revision operations. The Submit Budget Revisions process routes budget revisions through an approval process and updates the status and baseline values for budget revisions. The process also performs funds reservation and posts revisions to General Ledger. The process freezes and unfreezes budget revisions. Notifications are sent to users who initiate a process and to approvers.
The process is initiated at the following points:
EXP Approval - The Exchange Protocol Approval process is initiated when a transmission unit is transmitted. The process sends requests for transmission unit authorization to the appropriate approvers, based on the approval profile. The dialog units that are contained within the transmission unit will be processed based on the approvers' responses.
Contract Commitment Approval Workflow Process - The Contract Commitment Approval Workflow is initiated when a contract commitment is submitted for approval. The process automatically routes the document to the appropriate approver, based on the approval hierarchy setup. The approver can approve or reject the document. If budgetary control is enabled, funds are checked and reserved when the approver approves the document. The person who submitted the document for approval is notified of the approval status at every stage during the approval process.
Dossier Approval Process - This process is initiated when a dossier maintenance transaction is sent into approval. The process sends notifications requesting approval of the dossier maintenance funds transfers to the appropriate approvers, based on the approval hierarchy attached to the dossier type. Based on the approvers' responses, encumbrance journals will be reversed and actual journal entries created to complete the funds transfer.
You initiate the Credit Memo Request workflow from iReceivables. iReceivables is a web-based, self-service application that enables registered users to access their Receivables account information using a standard web browser. When an iReceivables user chooses the Dispute a Bill function, Receivables places the specified amount in dispute and initiates the Credit Memo Request process to route the request for approval.
Document Transfer Message Workflow - This workflow creates an XML invoice document and sends it to your customer. This workflow consists of two item types.
AR Credit Management Application Process Workflow - This workflow manages the collection and analysis of account or prospect credit data, as well as the making and implementation of credit decisions.
The workflow is started when a credit request is generated, either by a credit event, such as an order hold, or by the submission of a credit application. The workflow first tries to automatically complete the credit review process. If, for any reason, a failure occurs in the workflow functions, then the workflow routes the credit analysis to the appropriate credit analyst for action.
If an organization requires that credit recommendations be reviewed and approved by other personnel, then the workflow routes the recommendations through an approval hierarchy.
Address Change - This workflow is triggered when subscribed from an Oracle Trading Community Architecture business event. A notification provides old and new values for an updated address record. Use an Oracle Trading Community Architecture business event for creation or update of a Party Site and Location to route the Address Change workflow notification to a designated person. A notification is sent to the system administrator by default.
Admission Enforce Single Response Notification - When an offer response is recorded, the Offer Response Status business event is raised. The Admission Enforce Single Response Notification is sent when the offer response status is Accepted and the admission period category is set for single response. The workflow notification is sent to all applications instances for the person that is using an admission period category that is set for single response. This workflow is triggered when the Offer Response Status Change business event is raised and you are enforcing single response.
Admission Offer Response Status Change Notification - When an offer response is recorded, the Offer Response Status business event is raised. The Admission Offer Response Status Change workflow notification is sent every time the offer response status changes for an application instance. This workflow is triggered when the Offer Response Status Change business event is raised.
Admissions Requirements - This workflow notifies applicants that there are additional documents or missing items that are needed to complete the application. This workflow is triggered by running the Admission Requirements concurrent process.
Attendance Submission Notification - This workflow notifies the lead instructor of a unit section that attendance for the unit section is submitted. This workflow is triggered from the Review Attendance self service screen.
Change Grade Request - This workflow notifies the user who initiated a change of grade request and seeks resolution of the change of grade request for final and early final grading periods from the lead instructor of the unit section. It is triggered from the Review Change of Grade self service screen for final and early final periods.
Confirmation of Registration - This workflow is triggered when the Confirmation of Registration business event is raised. This workflow notifies the student, the student's supervisors, and an administrator of the registration of the student for the research candidacy.
Corrections Not Initiated by School - This workflow is triggered by the ISIR Import Process concurrent process. It notifies users when an ISIR correction record is received which the school did not initiate.
DLPNA - This workflow is triggered by the Promissory Note Acknowledgement Process concurrent process, which is part of the request set Direct Loan > Upload Promissory Note Acknowledgement. It is triggered if a Loan's promissory note is rejected by the external processing agency.
Exceed Workload - This workflow allows you to notify staff members when they exceed the expected workload. This workflow is triggered when staff members exceed the expected workload.
Generate New User - This workflow is triggered when a user attempts the new user registration in self service. Self service administrative users can approve or reject the creation of a person.
Grade Submission Notification - This workflow notifies the lead instructor of a unit section that final grades for the unit are submitted. Institutions are allowed to only customize the SELECT_APPROVER process of the Grade Submission and Change of Grade workflows to satisfy their specific needs. The remaining steps of the workflow must remain unchanged. This workflow is triggered from the Review Enter Grade self service screen.
IGS Degree Audit - This workflow delivers the XML document to the trading partner taking advantage of Oracle XML Gateway Callback functionality. The Callback feature allows the messaging system (Oracle Transport Agent) to report the message delivery status back to the workflow process that initiated the message creation. If the delivery fails, a notification is sent to the System Administrator defined in Oracle XML Gateway.
Incomplete Applications - This workflow sends both an e-mail message to the applicant and a notification accessible in the Applicant Home page. An applicant may have multiple incomplete applications. One e-mail message is sent for every time the workflow is initiated by the concurrent manager request, regardless of the number of incomplete applications the applicant may have. The workflow process may be initiated multiple times within a single period. This workflow is triggered by running the Incomplete Applications concurrent process for applicants with incomplete self-service applications.
Inform Instructor about Assessment Item Grades Release to Student - This workflow is triggered by a business event.
Inform Instructor That Unit Section Grades Have Been Submitted - This workflow is triggered by a business event.
Key Program Change - This workflow is triggered when the oracle.apps.igs.en.prog.keyprim event is raised. This workflow notifies an administrator when a student's key program changes.
Milestone - This workflow is triggered when the Milestone business event is raised. This workflow notifies the student, the active student's supervisors, and an administrator of additions and changes to milestone information for the research candidacy.
Milestone Notification - This workflow is triggered when the Milestone Notification business event is raised. This workflow notifies the student, the active student's supervisors, and an administrator of additions and changes to milestone notification information for the research candidacy.
Notify Advisor About Advising Group - This workflow notifies each advisor when he or she gets assigned to or removed from an advising group. It is triggered when an advisor gets assigned to or removed from an advising group.
Notify Evaluators About Unevaluated Applications - This workflow allows administrative users to notify application reviewers about applications that are complete and are ready for review.
Notify Student About Advising Group - This workflow notifies each student when he or she gets assigned to or removed from an advising group. It is triggered when a student gets assigned to or removed from an advising group.
Notify Student About Being Placed on an Advising Hold - This workflow notifies each student when he or she has been put on an advising hold for an advising group. It is triggered when a student has been put on an advising hold for a particular advising group.
OSS: Change in Supervisor Attribute - This workflow is triggered when a supervisor is assigned to a research candidacy or when certain attributes of the candidacy's supervision change. These attributes are the Person Number, Start Date, End Date, Supervised%, Supervisor Type, Organizational Unit, or Replaced Person Number. This workflow notifies students and administrators of supervisors.
OSS: Check Overdue Submission - This workflow is triggered when a submission is overdue (the students goes beyond the maximum submission date without submitting the work and the status of the thesis is still Pending). It notifies students and administrators of an overdue submission date.
OSS: Missing Academic Record Transcript Production - This workflow notifies the student when an administrator manually updates the details of a completion date of a missing academic records transcript. It is triggered when an administrator manually updates the details of a completion date of a missing academic records transcript.
OSS: Notify About Missing Academic Record - This workflow notifies the administrator about the missing academic records when a transcript request is placed by a student or by an administrator. It is triggered when a transcript request by a student or administrator indicates missing academic records.
OSS: Notify Admin About Transcript Production - This workflow notifies the administrator about the production of the transcript.
OSS: Notify Program Transfer Details - This workflow is triggered when a program transfer is committed (when the transfer itself is committed, whether or not the units or unit sections are transferred as part of the program transfer). It notifies students and administrators of program transfer changes. This workflow is not triggered if unit attempts or unit set attempts are transferred later in a separate transaction.
OSS: Notify Student About Intermission - This workflow is triggered when an intermission is committed or when an intermission that requires approval is committed or committed and approved. It notifies students and administrators of the intermission and intermission changes.
OSS: Notify Student About Transcript Production - This workflow notifies the individual student who placed an order about the production of the transcript. It is triggered when the system prints the academic records order placed by the student.
OSS: Notify Student for Program Discontinuation - This workflow is triggered when a program attempt is discontinued. The discontinuation can occur as the result of Discontinuation in Enrollment, as the result of transferring from a secondary program to a new primary program, or as the result of a progression outcome from progression. It notifies students and administrators of program discontinuation.
OSS: Notify Student Program Offering - This workflow is triggered when a program offering option is changed. This occurs when an administrator commits the change for a program offering option. For example, the administrator could use the Program Change button on the Student Enrollments window to change and commit the change of a program offering option. It notifies students and administrators of changes to program offering options.
OSS: Notify Students About Transcript Hold - This workflow notifies the student about a transcript hold when a transcript is requested by an administrator for a student who has a transcript hold. It is triggered when a transcript is requested by an administrator for a student who has a transcript hold.
OSS: Research Topic Modification - This workflow is triggered when a research topic is entered, changed, or approved. It notifies students and administrators of changes to research topics.
OSS: Thesis Topic Creation - This workflow is triggered when a thesis topic or title is entered, changed, or approved. This occurs when an administrator enters or changes the information for the thesis topic or title and saves the changes. It notifies students and administrators of changes to thesis topics.
Outcome Status - A workflow notification is sent to users alerting them to a change in the outcome status. This workflow is triggered when the outcome status is changed and saved
Post Admission Requirements - This workflow allows administrative users to notify applicants of the additional documents or missing items that are required by the institution even after the admission application process is complete. This workflow is triggered by running the Send Notifications for Admission and Post Admission Requirements concurrent process.
Receive Error - This workflow is triggered if there is an error in the receipt of a reply from the degree audit trading partner.
Receive Reply - This workflow is triggered on receipt of a reply from the degree audit trading partner.
Residency Event - This workflow is triggered by the oracle.apps.igs.pe.residency_change business event. A workflow notification is sent to the system administrator by default.
Saved Transcript - This workflow is triggered by a business event.
Set or Release External Hold - Third party software or an external system raises an Oracle Student System designated business event in Oracle Workflow in order to insert or update a hold type into Oracle Student System. This workflow is triggered by third party software to apply or release an external hold.
Student Employment Notification - This workflow is triggered by the Student Employment Upload Payroll Information concurrent process and payroll details of the Student Work Award Progress window. It notifies users if the amount resulting from the subtraction of the amount of a student's work study award from the student's gross pay is within the threshold level.
Submit Request - This workflow is triggered by the Submit button on the Review Request self-service page to signal Oracle XML Gateway to begin processing the outbound request.
Thesis Exam - This workflow is triggered when the Thesis Exam business event is raised. This workflow notifies the student, the student's supervisors, and an administrator when the thesis has been submitted or resubmitted for the research candidacy.
Thesis Result - This workflow is triggered when the Thesis Result business event is raised. This workflow notifies the student, the student's supervisors, and an administrator of a change in the thesis result for the research candidacy.
Transcript Change Validation - When a new transcript is created in Admission, this workflow validates advanced standing records to check if the existing advanced standing still applies for the student. If not, then the advanced standing records are deleted or updated and a notification is sent to the staff member.
GHR Position Description Process - Enables the routing of the Position Description form for data entry, signature, review and classification. Based on the agency's practices, the user can route the Position Description form to an individual, groupbox, or routing list within the routing group. As the Position Description form is routed, the system maintains a history of actions. By referring to the history, users can learn what action was taken, by whom, and on what date.
GHR Within Grade Increase Process - Enables the automatic processing of Within Grade Increase(WGI) actions without any manual intervention. The default WGI process automatically notifies the Personnel Office of the WGI approval and requires no response. WGI process can be configured during implementation in many ways based on the agency's practices.
The HR Task Flow item type provides you with an alternative to using forms to set up and maintain your task flows. By integrating with Oracle Workflow, you can use the graphical Oracle Workflow Builder to help you design and diagram the sequence of your windows.
Appraisals Processes - The appraisals workflows enable both managers and non-managers to use the appraisals functionality. Managers can create appraisals for their direct reports and generate notifications of the appraisal to the appraisee and any other appraisers. When a standard or 360-Degree appraisal has completed, the workflow can automatically trigger an update to the appraisee's competency profile. The workflow also generates a Performance Review event. SSHR includes the following appraisals workflows:
Change Extra Information Types/Change Special Information Types - These processes provide navigation for Extra Information and Special Information pages connecting to review, confirmation and approval processes. You can include the Extra information and Special information functions in other workflows to capture additional information if required.
Check Salary Basis Change in Mid-Pay Period - This process enables a SSHR manager to change the salary basis for a direct report during a pay period. The workflow generates a notification for the Payroll Contact who can then approve or reject the change.
Compensation Distribution - This process enables an SSHR manager to assign a one-time or recurring award to an employee or worker. Non-manager users can use this workflow to set up voluntary contributions.
Employee Review Process - This process enables a user to search for an existing review or create a new review. When the review is created, the workflow initiates the approval process.
Events and Bookings Processes - These processes generate notifications for users in the following situations:
Leave of Absence Processes - The Leave of Absence processes enable a user to enter, create, update, and confirm a leave of absence. The processes are:
New Employee Registration Processes - These processes combine to enable a new employee to register and enter personal and other information using SSHR. The new user can also create a new user name and password for SSHR. The processes include:
Personal and Professional Information - SSHR includes workflows to enable users of SSHR (managers and non-managers) to enter, update, and delete personal and professional information. Users can currently enter, update, and delete information in the following areas:
Release Information for Transfer - This process enables a SSHR user to use the Release Employee Information function to share information about themselves with another user, often a manager, who would not usually have access to their records. Similarly, a manager can use this function to share information about one of their employees or workers with a second manager.
Return for Correction Process - This workflow process enables a SSHR user to return a transaction to the initiator for correction. This process is introduced in SSHR version 5 and controls notifications if they are returned for correction.
Self-Service HR Standard Error Process - This workflow process is triggered if a system error occurs. The workflow generates a notification to the SSHR Administrator to inform them of the system error.
Tax Processes
OKL CS Transfer Assumption Request - The workflow is used for Transfer and Assumption Requests to notify the Contract Administrator after receiving necessary approvals: 1. Received Customer Approval? 2. Received Vendor Approval? 3. Notify Credit Departments. 4. Notify Collections for Approval. 5. Notify administrator to restructure contract. The workflow is initiated from the Requests tab.
OKL CS Billing Correction Request - The workflow is used for Billing Correction Requests to notify the Contract Administrator to approve billing correction requests. The workflow is initiated from the Transactions tab.
OKL CS Billing Refund Request - The workflow is used for Billing Refund Requests to notify the Contract Administrator to approve billing refund requests. The workflow is initiated from the Account tab.
OKL CS Convert Interest Type - The workflow is used to convert Interest Requests to notify the Contract Administrator of changes in the interest type from Lease Center. The workflow is initiated from the Structure tab.
OKL CS Contract Lease Renewal - The workflow is used for Renewal Quotes to notify the Contract Administrator to approve contract lease renewals: 1. Notification for Lease Renewal; 2. Notification for Lease Renewal Rejection. The workflow is initiated from the Requests tab.
OKL Stream Generation - Outbound - The workflow is used to initiate the outbound XML Pricing Engine transaction for Stream Generation: 1. Receive raised Business Event to send the outbound XML document; 2. Call XML Gateway API to check for validity of the generated XML document; 3. Report error, if applicable; 4. Call XML Gateway API to send the document to the Pricing Engine server. The workflow is initiated from the Stream Generation Process.
OKL Stream Generation - Inbound - The workflow is used to manage the inbound XML Pricing Engine transaction for Stream Generation: 1. Capture the Business Event for inbound XML message; 2. Process the streams returned by the Pricing Engine server. The workflow is a continuation of the Stream Generation Process.
OKL - INS Gather Third Party Insurance Information - The workflow creates a task to gather third-party information when a customer fails to provide insurance proof by the due date and the lessor cannot sell insurance. The workflow is initiated from the insurance placement process.
OKL Account Generator - You can use this workflow to generate account combinations instead of the seeded sources. The workflow is initiated from the Accounting Engine.
OKL - AM: Approve Contract Portfolio - The workflow routes a contract portfolio for approval. The workflow is initiated from Contract Portfolio.
OKL - AM: Notify Contract Portfolio Execution - The workflow notifies the Remarketer (Assignment Group) contract portfolio execution. The workflow is initiated from Contract Portfolio.
OKL - AM: Approve Restructure - The workflow routes a restructure for approval. The workflow is initiated from Restructure Quote.
OKL - AM: Shipping Instructions - The workflow is used to notify the lessee of shipping instructions for an asset. The workflow is initiated from Communicate Quote.
OKL - AM: Notify Internal Transport Department - The workflow is used to notify the internal transport department of the shipping details for an asset when the lessee accepts the transport management option. The workflow is initiated from Communicate Quote.
OKL - AM: Send Quote - The workflow is used to notify the requestor of an Asset Quote. The workflow is initiated from Communicate Quote.
OKL - AM: Repurchase Acceptance - The workflow informs users of the acceptance of a Repurchase Quote. The workflow is initiated from Quote Acceptance.
OKL - AM: Termination Quote Acceptance - The workflow informs users of the acceptance of a Termination Quote (Pre-Proceeds Termination Quote, Post-Proceeds Termination Quote). The workflow is initiated from Quote Acceptance.
OKL - AM: Restructure Quote Acceptance - The workflow informs users of the acceptance of a Restructure Quote. The workflow is initiated from Quote Acceptance.
OKL - AM: Notify Remarketer - The workflow informs the remarketing team of a new asset assignment. The workflow is initiated from Asset Return.
OKL - AM: Notify Collections - The workflow informs the collections agent of updates on returns in the case of a Repossessed Asset. The workflow is initiated from Asset Return.
OKL - AM: Notify Repossession Agent - The workflow informs the external repossession agent of a new repossession request. The workflow is initiated from Asset Return.
OKL - AM: Asset Repair - The workflow routes asset repair requests for approval. The workflow is initiated from Asset Condition.
OKL - AM: Request Title Return - The workflow requests the third party titleholder to return the title on expiration of the contract. The workflow is initiated from Remarketing.
OKL - AM: Remarketing Order Cycle - The workflow defines the order cycle in Order Management for remarketed assets. The workflow is initiated from Remarketing.
Credit Application Request - The workflow notifies the Lease Credit Approver to approve the recommendation. The workflow is initiated from Credit Management's recommendation business event.
Lease Funding Approval - The workflow is used to obtain approvals required for funding request approval. The workflow is initiated from the Funding Request submit button.
Lease Contract Booking Approval - The workflow is used to obtain approvals required for contract booking and activation. The workflow is initiated from the Approval button in Authoring.
OKL - AM: Notify Internal Transport Department - The workflow notifies the Transport Department when the lessee accepts the transport management option. The workflow is initiated from the shipping instruction.
OKL - AM: Notify Manual Termination Quote Request - The workflow notifies the representative of a manual termination quoting request. The workflow is initiated from the manual termination quote.
OKL - AM: AM Service Contract Integration - The workflow initiates Service Contract Integration. The workflow is initiated from the asset return.
OKL: Customer Service Principal Paydown - The workflow is used to send notifications about Principal Paydown, with a notification for Contract Rebook after paydown. The workflow is initiated from the Request tab.
OKL - SS: Request Termination Quote - Sends a notification to the Lease Center Agent that a quote has been requested. The workflow is initiated in Customer Self Service when a user creates a termination quote.
OKL - SS: Make a Payment - Sends a notification to the Lease Center Agent that a payment was made. The workflow is initiated in Customer Self Service when a user makes a payment.
OKL - SS: Request Repurchase Quote - The workflow creates a repurchase quote for the contract and sends out a notification for approval. The workflow is initiated in Customer Self Service when a user creates a repurchase quote.
OKL - SS: Cancel Insurance - Sends a notification to the Lease Center Agent that a policy has been cancelled. The workflow is initiated in Customer Self Service when a user cancels an insurance policy.
OKL - SS: Update Serial Number - The workflow sends out an approval notification and updates the serial number of the asset if approved, and sends a notification to requestor, whether the workflow is approved or declined. The workflow is initiated in Customer Self Service when a user requests a serial number update.
OKL - SS: Update Asset Location - The workflow sends out an approval notification and updates the location of the asset if approved, and sends a notification to requestor, whether the workflow is approved or declined. The workflow is initiated in Customer Self Service when a user requests an asset location update.
OKL - SS: Request Billing Change - The workflow sends out an approval notification and updates billing information of the contract if approved, and sends a notification to requestor, whether the workflow is approved or declined. The workflow is initiated in Customer Self Service when a user requests a billing change.
OKL - SS: Submit Third Party Insurance - If the insurance company does not already exist, the workflow sends out a notification to create a new party. The workflow creates an insurance policy once the notified user inputs the new party ID into the notification. The workflow is initiated in Customer Self Service when a user submits information on a new provider or when a user submits insurance policy details.
OKL - SS: Request For Invoice Format Change - The workflow sends out an approval notification and updates the invoice format if approved. The workflow sends a notification back to the user with the approval decision. The workflow is initiated in Customer Self Service when a user requests an invoice format change.
OKL - SS: Claim Notification - Sends a notification to the Lease Center Agent that a claim has been created. The workflow is initiated in Customer Self Service when a user submits a new insurance policy claim.
OKL - SS: Asset Return -The workflow notifies another user (the role selected in a setup step) to create a new asset return request. The workflow is initiated in Customer Self Service when a user submits a request for asset return.
OKL - SS: Request Renewal Quote - The workflow notifies the Lease Center Agent that a new renewal quote has been created. The workflow is initiated in Customer Self Service when a user creates a renewal quote.
OKL: Collections Approve Refund - The workflow is used to approve a vendor refund. The workflow is initiated from the Request Details.
OKL: Collections Approve Cure Request - The workflow is used to approve a Cure Request. The workflow is initiated when a user accepts a lease quote payment plan.
OKL - SO: Quote Acceptance - The workflow notifies another user that the quote payment plan has been accepted.
OKL - SO: Payment Plan Approval - The workflow routes the payment plan for approval. The workflow is initiated when the user submits a payment plan for approval.
If this process is enabled, work requests are created with a status of Awaiting Work Order (approved). Otherwise, work requests are created with a status of Open.
Material Shortage Message - Sends a notification to planners every time a receipt transaction is done for an item with material shortages. The workflow notification will be initiated from a concurrent program that checks all material transactions that have been marked by the transaction manager.
Sales Order Batch Reservations - The Sales Order Batch Reservations workflow sends notifications to the Customer Service Representative for changes in the production warehouse, quantity, completion date of the batch, and batch status.
OPM Product Development
Product Development Status Approval Workflow - When you activate the Product Development Status Approval Workflow, formulas, routings, recipes, validity rules, and operations require a series of approvals that result in reassigning their statuses through a predefined approval process. The workflow presents each approver with an electronic notification so action can be taken online. Laboratory Approval is optional in this workflow.
If the workflow is enabled, then formulas, routings, recipes, validity rules, and operations use the following statuses:
If the status is Approved for General Use, then you can use formulas, routings, recipes, validity rules, and operations in production batches and cost rollups.
OPM Quality Management
Sample Creation Notification - Sends a notification to draw a physical sample as required by the associated sampling plan for the specification and specification validity rule in effect. This workflow can be triggered by an inventory quantity increase, receiving transaction, batch step release, or lot expiration or retest. The notification lists the sampling plan information and includes a link to the Samples window, where information about the sampling event is populated.
Testing Notification - Sends a notification to prompt you to perform a test and enter its result against a particular sample. This workflow is initiated by the creation of a sample that is already associated to a specification or selection of the result action for retesting a certain test. Each tester for a given sample in process receives a notification for the expected test result.
Sample Disposition Notification - Prompts for assignment of the final disposition for a sample once testing has completed. The sample disposition can be changed to accepted, accepted with variance, or rejected when all tests (if required by the associated specification) have recorded results that have been evaluated and finalized.
Composite Results Notification - Asks you whether to composite the results across a set of samples within the same sampling event. This workflow is initiated when testing of all the samples in a sampling event (based on the number of samples required by the sampling plan) is complete and each sample has a final sample disposition. The notification provides a link to the Composite Results window, where information about the sampling event is populated.
Sample Group Disposition Notification - Notifies you that the sampling event requires a final disposition, based on the number of samples required by the sampling plan. This workflow is launched when all the samples within a sampling event have a final disposition of accept, accept with variance, reject, or cancel.
Spec Status Change Approval Notification - The Spec Status Change Approval Notification workflow notifies the contact person when the specification status has changed. The workflow is activated for processing the status change. Typically, workflow approval is activated for status changes to Approved for Lab Use and Approved for General Use. The other statuses can be processed without requiring workflow approval.
Spec Customer Validity Rule Status Change Approval - The Spec Customer Validity Rule Status Change Approval Notification workflow notifies the contact person when the customer specification validity rule status has changed. The workflow is activated for processing the status change. Typically, workflow approval is activated for status changes to Approved for Lab Use and Approved for General Use. The other statuses can be processed without requiring workflow approval.
Spec Inventory Validity Rule Status Change Approval - The Spec Inventory Validity Rule Status Change Approval Notification workflow notifies the contact person when the inventory specification validity rule status has changed. The workflow is activated for processing the status change. Typically, workflow approval is activated for status changes to Approved for Lab Use and Approved for General Use. The other statuses can be processed without requiring workflow approval.
Spec Supplier Validity Rule Status Change Approval - The Spec Supplier Validity Rule Status Change Approval Notification workflow notifies the contact person when the supplier specification validity rule status has changed. The workflow is activated for processing the status change. Typically, workflow approval is activated for status changes to Approved for Lab Use and Approved for General Use. The other statuses can be processed without requiring workflow approval.
Spec WIP Validity Rule Status Change Approval - The Spec WIP Validity Rule Status Change Approval Notification workflow notifies the contact person when the WIP specification validity rule status has changed. The workflow is activated for processing the status change. Typically, workflow approval is activated for status changes to Approved for Lab Use and Approved for General Use. The other statuses can be processed without requiring workflow approval.
Spec Monitoring Validity Rule Status Change Approval - The Spec Monitoring Validity Rule Status Change Approval Notification workflow notifies the contact person when the monitoring specification validity rule status has changed. The workflow is activated for processing the status change. Typically, workflow approval is activated for status changes to Approved for Lab Use and Approved for General Use. The other statuses can be processed without requiring workflow approval.
Sample Group Rejection Notification - The Sample Group Rejection Notification workflow notifies the contact person that either a monitoring sample group or a stability study time point sample group is rejected.
Stability Study Change Status Notification - The Stability Study Change Status Notification workflow notifies the study owner of status changes in the stability study. The process of changing status from New to a status of Completed involves a series of workflow notifications. Oracle E-Records operates with this workflow to enforce the stability study status control business rules. The cancellation of a stability study is also controlled by the workflow.
Stability Study Lot/Sublot Sample Notification - When the stability study is approved, and specific lots or sublots of the item to be tested exist, then the Stability Study Lot/Sublot Sample Notification workflow notifies the stability study contact person to obtain samples for all required material sources. In the notification, the contact person is designated to draw and store the specified samples, and to update the sample records accordingly.
Stability Study Batch Creation Notification - When the stability study is approved, and specific lots or sublots of the item to be tested do not exist, then the Stability Study Batch Creation Notification workflow notifies the stability study contact person to request that a batch be created for the study.
Stability Study Testing - The Stability Study Testing workflow is a master workflow that governs the Stability Study Time Point Scheduling Notification workflow, and the Stability Study Late Time Point Scheduling Notification workflow. This workflow runs as a background process to monitor for any time point test that requires a workflow notification, or a late workflow notification. The workflow raises the appropriate event for either scheduled or late time point tests.
If the stability study is canceled or the scheduled time point testing date changes, then a workflow API manages the situation. The sample group disposition is changed from a status of Retained to a status of Pending, and the sample pull dates are updated.
Stability Study Time Point Scheduling Notification - The Stability Study Time Point Scheduling Notification workflow notifies you to pull samples for time point testing. The notification considers the required leadtime, and it requests you to change the disposition of a time point sample from Retained to Pending. When the sample disposition is changed to Pending, tests are scheduled. If the test is not performed within the grace period, then the OPM Quality Stability Study Testing master workflow raises a separate event that indicates the test is overdue.
Stability Study Late Time Point Scheduling Notification - The Stability Study Late Time Point Scheduling Notification workflow notifies you that a test is overdue. The notification considers the required grace period, and uses the OPM Quality Stability Study Testing master workflow to raise a separate event to indicate the test is late.
Quality UOM Conversion Notification - The Quality UOM Conversion Notification workflow notifies the contact person that a new or revised lot-specific UOM conversion is recommended based on quality results. A link to the Item Lot/Sublot Standard Conversion window in the OPM Inventory Control application is provided. This link does not operate unless a lot number is assigned on the quality sample.
OPM Inventory
Lot Expiry/Retest Workflow - Sends a notification to a user at a defined number of days in advance of lot expiration and retest dates. Without this workflow the expiration or retesting of a lot is not visible to the user without a query for the expiration and retest information. The Lot Expiry/Retest Workflow gives the approver this visibility by notifying the approver the defined number of days in advance of the expiration and retest date.
Item Activation E-Record - Sends notifications to approve newly created items before changing their status to an approved inventory status. The workflow is initiated from the Approve Item from the OPM Item Master window. The workflow notifies the individual who needs to approve the item's creation and calls for e-signatures using Oracle E-Records. The item becomes active if it is approved. The item remains inactive if it is not approved. Item properties cannot be modified if the workflow approval is pending for an item.
Oracle E-Records
Oracle E-Records Individual Approval Notification - For all deferred e-signatures, the requestor receives a notification after each initiated e-signature of the event.
Oracle E-Records E-Signature Reminder Notification - Signers can receive reminder notifications that there are e-records awaiting their e-signatures.
Oracle E-Records Timeout Notification - An e-record requestor is notified when an e-record event times out when an e-signature is not received in the allotted period of time.
Oracle E-Records Rejection Notification - All signers and the requestor receive notifications when a rejection signature is entered for an associated e-record event.
Oracle E-Records Stylesheet Upload Notification - When all approvals have been captured for a new or updated E-Record style sheet file, the style sheet is automatically uploaded to the style sheet repository. A notification is sent to the requestor.
Oracle E-Records File Approval - Uploaded files can be routed for approval and e-signatures. This event is initiated from the Oracle E-Records File Upload window by clicking the Send for Approval button.
Oracle E-Records Transaction Configuration Variable Create/Update - The settings for Oracle E-Record transaction defaults are defined and set here. Enabling these events requires that e-Records and e-Signatures are captured before updates are saved. The new or updated data is not committed to the database unless all of the required signatures are obtained while the E-Signature window displays.
Oracle E-Records Rule Configuration Variable Create/Update - The settings for Oracle E-Record transaction rules are defined and set here. Enabling these events requires that e-records and e-signatures are captured before updates are saved. The new or updated data is not committed to the database unless all of the required signatures are obtained while the E-Signature window displays.
Contract Project Definition Process - This process is part of the Project Manufacturing Project Definition process navigator flow. This process guides users through all the necessary sequence of steps for setting up a Contract-type project for use in Oracle Project Manufacturing.
Critical Defect - Notifies the owner that they have recently been assigned a critical defect.
Change Order Notification Process - Sends a change order notification from certain application forms. The recipient and message content are set dynamically when you select a responsibility and provide content. Uses the item type OM Change Order (OECHORD).
COGS Process - Generates a cost of goods sold account using the item type Generate Cost of Goods Sold Account (OECOGS).
Negotiation Header Processes - Oracle Order Management supports the negotation phase of a sales order (that is, quotes) or blanket sales agreement. The item type for Negotiation is OM Negotiation Header (OENH). It includes steps such as submit draft, optional internal approval, customer acceptance, and complete negotation. If the transaction is a quote, at the end of the negotiation flow, the OM Order Header flow will be started; while if the transaction is a blanket sales agreement, at the end of the negotiation flow, the OM Blanket Header flow will be started.
Blanket Header Process - Oracle Order Management supports Blanket Sales Agreements through the workflow item type OM Blanket Header (OEBH). It includes steps such as submit draft (if the Blanket has no negotiation phase), expiration date handling and reminders, terminate blanket, and close blanket.
Order Import Process - Oracle Order Management supports the creation and modification of sales orders through the Order Import workflow. When an inbound XML message is received, the Order Import workflow is triggered and, depending on the setup, order import is either run synchronously or deferred for an asynchronous run. This workflow process subscribes to the event oracle.apps.ont.oi.po_inbound.create and its item type is OM Order Import (OEOI). It includes steps such as raising an event to trigger the OAG CONFIRM BOD XML message, interface table data population, raising integration events, and conditional execution of order import.
Send Acknowledgment Process - Oracle Order Management supports the generation of the ACKNOWLEDGE PO and CONFIRM BOD XML message. Both messages conform to the Open Applications Group (OAG) standard. The CONFIRM BOD notifies the buyer that an inbound document has been received and the ACKNOWLEDGE PO conveys to the buyer the results of order import. The CONFIRM BOD and ACKNOWLEDGE PO utilize different processes in the same workflow. These processes subscribe to the events oracle.apps.ont.oi.cbod_out.confirm and oracle.apps.ont.oi.po_ack.create, respectively. The item type for the workflow is OM Send Acknowledgment (OEOA). The two processes include steps such as raising integration events, generation of the deliverable data, and document transmission.
Show Sales Order Process - Oracle Order Management supports the generation of the SHOW SO and CHANGE SO XML messages. Both messages conform to the Open Applications Group (OAG) standard. SHOW SO contains status information concerning the current state of an order and CHANGE SO is used to notify the buyer of changes to his or her order. Both messages utilize the same process in the Show Sales Order workflow. The workflow process subscribes to the event oracle.apps.ont.oi.show_so.create and the item type is OM Show Sales Order (OESO). The value of a particular parameter in the consumed event determines which message will be generated. The flow includes steps such as checking trading partner setup, raising integration events, generation of the deliverable data, and document transmission.
Open Interface Tracking Process - Oracle Order Management supports the tracking of XML, EDI, and generic order import transactions through the Open Interface Tracking workflow. This workflow process subscribes to the integration event oracle.apps.ont.oi.xml_int.status and retrieves information from those events for use in the Open Interface Tracking UI. The item type for this workflow is OM Open Interface Tracking (OEEM).
EDI Workflow Process - Oracle Order Management supports the derivation and generation of EDI acknowledgment data through the OM EDI Workflow (OEXWFEDI) item type. This workflow process subscribes to the event oracle.apps.ont.oi.edi_ack_values.create and populates Oracle Order Management's acknowledgment tables with the data necessary to generate the outbound EDI messages (POAO and POCAO).
Receipt Confirmation Process - Sends receipt notifications to requestors, informing them that they should have received their order. This process is also known as the PO Confirm Receipt workflow.
Requisition Approval Process - Submits a requisition created from Web Requisitions to the appropriate managers for approval and updates the status of the requisition.
Supplier Self-Service Registration Approval Process - Oracle iSupplier Portal allows a guest to log on and register as a supplier contact for a company. This process routes a notification to the appropriate account approver to verify and approve the registration. If the approver approves the registration, the Supplier Web User account is activated. If the account approver rejects the registration, the account is deactivated.
Procurement Workflow - The Procurement Workflow is a lights-out, hands-off transaction processing system that is truly flexible and extensible to all members of your supply chain. It is one of the key enablers in the shift towards more strategic sourcing and procurement activities. It consists of the Document Approval, Automatic Document Creation, Change Orders, Account Generation, Send Notifications, Price/Sales Catalog Notification, and Receipt Confirmation (used only by Self-Service Purchasing) workflow processes.
Document Approval Process - Performs all approval related activities in Oracle Purchasing. These include, but are not limited to, document submission, approval, forwarding, approval notifications, and rejection. This includes the PO Approval workflow process for approving purchase orders and the PO Requisition Approval workflow process for approving requisitions.
Automatic Document Creation Process - Automatically creates standard purchase orders or releases against blanket agreements using approved purchase requisition lines, if the requisition lines have the required sourcing information. This process is also known as the PO Create Documents workflow.
Change Orders Process - Allows you to control which changes require a manual reapproval and which will be automatically reapproved. All reapproved documents, either manual or automatic, will result in the document revision being incremented. This process is part of the PO Approval workflow.
Send Notifications Process - Looks for documents that are incomplete, rejected, or in need of reapproval, and sends notifications regarding the document's status to the appropriate people. This is also known as the PO Send Notifications for Purchasing Documents workflow.
Price/Sales Catalog Notification Process - Sends a notification to the buyer when the price/sales catalog information sent through the Purchasing Documents Open Interface includes price increases that exceed a price tolerance that you set. This process is also known as the PO Catalog Price Tolerance Exceeded Notifications workflow.
Project Approval and Status Change Process - Routes a project and notifies appropriate users of any project status change. For example, you can submit the project for approval, or notify appropriate people upon project closure. You select which workflow to use for the appropriate status change, as well as determining the person(s) to route the project to.
Apply Team Template - Handles the task of applying a team template to a project.
Assignment Approval Workflow - This process manages approvals for resource assignments. It is launched when an assignment is created for a resource and is submitted for approval. When the assignment is approved or rejected, FYI notifications are sent to the resource, the resource manager, the staffing manager, and the project manager.
Candidate Notification Process - This notification process is launched when a candidate is nominated or withdrawn for a requirement. The process notifies the resource, the manager of the resource, and their staffing manager of the nomination.
HR Related Updates Workflow - Synchronizes Oracle HRMS data with Project Resource Management data.
Mass Assignment Approval - Handles the routing of approvals for mass assignments.
Mass Assignment Transaction Workflow - Handles the creation of assignments when a mass assignment request is submitted.
Overcommitment Notification Process - Notifies users when assignments cause overcommitments.
Budget Integration Workflow - When a project is set up to use bottom-up integration, the project budget baseline process launches this deferred workflow. This workflow process performs the following tasks:
Translation Approval Workflow - Sends notifications to designated approvers when a content item is waiting for translation approval. After the content item is approved, translators are notified, so that they can translate the content item into different languages.
Notifications Related to Orders
Order Confirmation Normal - Confirms a normal order. This notification is initiated when a user places an order in a web specialty store.
Order Confirmation - Next Steps for Faxed Orders - Explains the remaining steps for order submission. This notification is initiated when a user places an order and chooses to fax a credit card or purchase order as payment.
Orders Not Booked Notification - Announces that an order has not been booked to the system administrator. This notification is initiated when a user's order is not booked.
Cancel Order - Confirms a cancelled order. This notification is initiated when a user cancels an order using the web specialty store.
Notifications Related to Shared Shopping Carts
Share Cart Confirmation Notification - Confirms a shared cart event and explains how to access the shared cart to the Shared cart owner and recipients. This notification is initiated when a user shares a cart with other users.
Change Access Level - Notifies users about access level changes. This notification is initiated when a Shared cart owner changes the access level of the recipient.
Remove Cart Access for Recipient - Notifies users about the shared cart status. This notification is initiated when a Shared cart recipient ends working on a shared cart.
Stop Sharing - Notifies users that a shared cart has been un-shared by the owner. This notification is initiated when a Shared cart owner stops sharing a shared cart.
Notifications Related to Sales Assistance
Sales Assistance Request - To Sales Representatives - Describes a request for sales assistance to a sales agent. This notification is initiated when a user requests sales assistance during the checkout flow.
Sales Assistance Request - Sends a confirmation to users who requested sales assistance. This notification is initiated when user requests sales assistance during checkout flow.
Notifications Related to Users and Registration
User Registration - Welcomes a newly registered user. This notification is initiated when a user registers in a specialty store, or a B2B user is registered by the B2B Primary User.
Forget Login - Sends email to a user with his or her username and password. This notification is initiated when a registered user requests login information.
Notification Events Related to Contracts
Contract Negotiations Request - Disapproval - Announces rejection of a contract terms change request. This notification is initiated when the Contract administrator rejects a user's request for changes in contract terms.
Contract Negotiations Request - To Sales Representatives - Describes a request for changes to contract terms. This notification is initiated when a user requests changes in contract terms.
Contract Negotiations Request - Approval - Announces approval of a contract terms change request. This notification is initiated when the Contract administrator approves a user's request for changes in contract terms.
Contract Negotiations Request - Cancellation - Announces cancellation of contract negotiations. This notification is initiated when the Contract administrator cancels a contract that was created when a user requested changes in contract terms.
Contract Negotiations Request - To Users - Acknowledges a request for changes to contract terms. This notification is initiated when a user requests changes in contract terms.
Notification Events Related to Reports
Reports - iStore Historical Summary - Contains the information from the Store Order Summary Data Out Bin specified in the Store Administration UI. This notification is initiated when iStore Reports concurrent programs refresh the report data.
Reports - iStore Top Orders - Contains daily Top Orders from the Top Orders Bin specified in the Store Administration UI. This notification is initiated when iStore Reports concurrent programs refresh the report data.
Marketing Generic Approval Workflow - This process gets initiated when a user submits Root Budgets, Claims, and Price Lists for approval to make them Active or Complete.
Schedule Execution - This process gets initiated when a campaign activity is set to Available or Active, which means that it needs to be executed. This could happen as a part of schedule's manual activation by the user, or as a part of any automated schedule execution activity such as triggers or repeating schedules. This process updates the schedule's status to Active if needed, and then performs any seeded execution functionality based on the schedule's channel.
Marketing Triggers - This process gets initiated when a Marketing trigger's next run time has been reached. This could be either the original start time of the trigger, or a scheduled time for the trigger repetition, if the trigger repeats at a specific interval. This process verifies, for non date based triggers, if the condition for the trigger is satisfied. If it is, then some actions need to be performed, which is done by some of the subflows. The types of actions that can be performed are execution of associated schedules, generation and execution of associated schedules that need to repeat through this trigger, sending out notifications, and plugged-in custom logic. Also, if the trigger repeats, then the next run date/time for it is calculated and scheduled.
| Previous | Next | Contents | Index | Glossary |
