AP_APPROVAL_Services

AP_APPROVAL

Step 1: Workflow Triggered

• The workflow is started when there is an “ACCEPT” event on the BT20.OHBirMaster table (likely a new or updated AP batch/transaction).

• The workflow model named AP Approval begins execution.

Step 2: Initial Start Node

• The workflow technically starts at a “Start” activity. This is mostly a placeholder; no processing happens here.

Step 3: Creator Approval Task (A33: Transaction Approval)

• The system assigns the first task to the creator (person who initiated the AP transaction) to approve the transaction.

• The creator receives the task in their workflow inbox or approval list.

• If the creator rejects the transaction, a Rejection Handler (NotAccepted) sends a rejection notification, logs the reason, and the workflow ends.

• If the creator approves the transaction, the workflow proceeds to the next step.

Step 4: Insert/Update Records (A39: Main Processing Logic)

• The workflow attempts to set the required approval information in the database.

The process here is:

1. Check if the batch is busy:

   • The workflow checks the “Post Status” of the batch in ohh_batch_mstr.oh_post_state.

   • If status is "EX" (e.g., in use or locked by another process), the workflow waits and retries—counted by PendingCount.

   • This retry process happens up to 10 times by design.

   • Each failed attempt increases PendingCount.

2. If batch is available:

   • Workflow sets the necessary approval flags & inserts approval detail records.

   • Updates are made to oh_ref_id_mstr (reference identifiers) and oh_bir_mstr (batch master) tables, marking the approval as completed.

   • If records are updated without error:

     • ApprovalStatus is set to GOOD.

     • Workflow prepares to send an approval confirmation.

3. If still failing after 10 attempts:

   • The workflow sends a notification to the final approver (usually an AP manager or admin), informing them the batch is “stuck” and needs manual attention.

   • The workflow ends (or enters a holding state, as per configuration).

Step 5: Notifications and Transitions

• When successfully approved:

  • The system sends an email confirmation to the creator (and/or final approver), stating the invoice has been approved.

  • The workflow then finishes.

• If retries are exhausted (PendingCount >= 10):

  • An email notification about the error ("Stuck batch") is sent to the final approver.

  • The workflow ends.

• If something else fails or errors are encountered:

  • The workflow transitions to an Error Handler, which sends an error email (with logs) to the creator for further review/correction.

• If the transaction does not follow a valid path (not accepted, system logic error, etc.):

  • The workflow enters the NoTransition handler, which sends a "No Transition" notification about the path problem and ends.

Step 6: Workflow Ends

• After a successful process, a rejection, a manual/corrective action, or an unrecoverable error, the workflow proceeds to the End node.

• The workflow instance now ends—no further automated steps occur on this transaction.

Summary Table: Workflow Pathways