| # Process Description (Imperative) |
|
|
| This file contains the imperative process description - the typical way the process flows and the standard sequence of activities. |
|
|
| --- |
|
|
| ## BPMN PROCESS DESCRIPTION |
|
|
| Below is a business-oriented textual interpretation of the BPMN model. The diagram represents a **purchase-to-pay / procurement exception-handling process** with strong integration to an **SRM (Supplier Relationship Management)** system and an **execution system**. It appears to manage the lifecycle of a purchasing document and its related downstream objects: **purchase requisition, purchase order, goods receipt, service entry sheet, invoice receipt, invoice clearing, and corrective actions** when data or process states change. |
|
|
| --- |
|
|
| ## 1. Process Overview |
|
|
| This process is about **creating, transmitting, updating, and correcting procurement documents and related financial/logistical records**. It covers the end-to-end handling of a purchasing transaction, including: |
|
|
| - Creation and release of purchase requisitions and purchase orders |
| - Transmission of documents to an execution system |
| - Recording of confirmations, receipts, and invoices |
| - Handling of changes to order data such as quantity, price, currency, payment terms, delivery indicators, and storage location |
| - Managing exceptions such as blocked items, cancellations, deletions, reactivations, and failed transfers |
| - Synchronizing statuses back in the SRM system |
|
|
| In practical terms, this is not a simple linear purchasing process. It is a **highly branched orchestration model** that supports many possible business states and correction paths. The model is designed to ensure that if a procurement document changes after downstream processing has already occurred, the related dependent records are updated, reversed, or reprocessed accordingly. |
|
|
| --- |
|
|
| ## 2. Main Activities |
|
|
| The model contains 44 activities. The most important ones can be grouped by business function. |
|
|
| ### A. SRM Status and Lifecycle Activities |
|
|
| These tasks reflect system status updates in the SRM environment: |
|
|
| - **SRM: Created** – indicates the transaction or document has been created in SRM |
| - **SRM: Ordered** – indicates the order has been placed |
| - **SRM: Complete** – indicates the transaction is completed from the SRM perspective |
| - **SRM: Awaiting Approval** – indicates a pending approval state |
| - **SRM: Held** – indicates the transaction is on hold |
| - **SRM: Incomplete** – indicates required data is missing or the document is not ready |
| - **SRM: In Transfer to Execution Syst.** – indicates the document is being transferred to the downstream execution system |
| - **SRM: Transfer Failed (E.Sys.)** – indicates a failed transfer to the execution system |
| - **SRM: Change was Transmitted** – indicates a change has been successfully sent |
| - **SRM: Document Completed** – indicates the document lifecycle is complete |
| - **SRM: Deleted** – indicates the document has been deleted |
| - **SRM: Transaction Completed** – final SRM completion state |
|
|
| These activities are mostly system-state markers rather than manual business work. |
|
|
| ### B. Procurement Creation and Release |
|
|
| - **Create Purchase Requisition Item** – creates a requisition line item |
| - **Release Purchase Requisition** – approves or releases the requisition for further processing |
| - **Create Purchase Order Item** – creates the purchase order line item |
| - **Release Purchase Order** – authorizes the purchase order for execution |
| - **Change Approval for Purchase Order** – modifies approval status after changes |
|
|
| These are core procurement control steps. |
|
|
| ### C. Logistics and Fulfillment Records |
|
|
| - **Record Goods Receipt** – confirms physical receipt of goods |
| - **Cancel Goods Receipt** – reverses a goods receipt |
| - **Record Service Entry Sheet** – confirms service delivery |
| - **Cancel Invoice Receipt** – reverses an invoice receipt |
| - **Record Invoice Receipt** – records the receipt of an invoice |
| - **Clear Invoice** – settles or clears the invoice financially |
| - **Vendor creates invoice** – vendor submits an invoice |
| - **Vendor creates debit memo** – vendor issues a debit memo |
| - **Receive Order Confirmation** – receives confirmation from the vendor |
|
|
| These tasks show that the process spans both operational and financial control points. |
|
|
| ### D. Change and Correction Activities |
|
|
| The model contains many corrective actions, which is a major feature of the process: |
|
|
| - **Change Quantity** |
| - **Change Price** |
| - **Change Currency** |
| - **Change Payment Term** |
| - **Change Delivery Indicator** |
| - **Change Storage Location** |
| - **Change Rejection Indicator** |
| - **Change Final Invoice Indicator** |
| - **Remove Payment Block** |
| - **Set Payment Block** |
| - **Block Purchase Order Item** |
| - **Reactivate Purchase Order Item** |
| - **Delete Purchase Order Item** |
| - **Cancel Subsequent Invoice** |
| - **Record Subsequent Invoice** |
| - **Update Order Confirmation** |
|
|
| These activities are used when the original purchasing data changes after downstream documents or confirmations already exist. The process ensures that dependent records are either updated or reversed as needed. |
|
|
| --- |
|
|
| ## 3. Process Flow |
|
|
| Because the model is highly branched, the best way to understand it is as a **lifecycle with multiple exception and correction paths** rather than a single straight sequence. |
|
|
| ### Step 1: Start and Initial System Handling |
|
|
| The process begins at the **start event**. Immediately, the flow splits into parallel paths, indicating that multiple initial actions or state preparations may occur at the same time. |
|
|
| From there, the process can enter SRM status handling and document processing activities. The model includes early states such as: |
|
|
| - **SRM: Created** |
| - **SRM: Ordered** |
| - **SRM: Awaiting Approval** |
| - **SRM: Held** |
| - **SRM: Incomplete** |
|
|
| This suggests the transaction may move through creation and approval-related states before being fully processed. |
|
|
| ### Step 2: Requisition and Purchase Order Processing |
|
|
| A central path creates and releases the procurement documents: |
|
|
| 1. **Create Purchase Requisition Item** |
| 2. **Release Purchase Requisition** |
| 3. **Create Purchase Order Item** |
| 4. **Release Purchase Order** |
|
|
| These steps establish the purchasing commitment and prepare the order for execution. |
|
|
| ### Step 3: Transfer to Execution System |
|
|
| The model includes a transfer path: |
|
|
| - **SRM: In Transfer to Execution Syst.** |
| - **SRM: Transfer Failed (E.Sys.)** if the transfer does not succeed |
| - **SRM: Change was Transmitted** if a change is successfully sent |
|
|
| This indicates that the SRM document is interfaced with another operational system, likely for fulfillment or ERP execution. |
|
|
| ### Step 4: Vendor Confirmation and Fulfillment |
|
|
| After order creation/release, the model supports downstream vendor and fulfillment events: |
|
|
| - **Receive Order Confirmation** |
| - **Record Goods Receipt** |
| - **Record Service Entry Sheet** |
| - **Record Invoice Receipt** |
| - **Vendor creates invoice** |
| - **Vendor creates debit memo** |
| - **Clear Invoice** |
|
|
| These represent the standard purchase-to-pay progression: |
| - Order confirmation |
| - Receipt of goods or services |
| - Invoice receipt |
| - Invoice settlement |
|
|
| ### Step 5: Change Handling and Reprocessing |
|
|
| A very large portion of the process is devoted to handling changes after the transaction has already progressed. The model supports changes to: |
|
|
| - Quantity |
| - Price |
| - Currency |
| - Payment terms |
| - Delivery indicator |
| - Storage location |
| - Rejection indicator |
| - Final invoice indicator |
|
|
| When one of these changes occurs, the process branches into different correction paths. Depending on the state of the document, the model may: |
|
|
| - Update the purchase order |
| - Change approval status |
| - Block or reactivate an item |
| - Delete an item |
| - Cancel or re-record receipts |
| - Cancel or record subsequent invoices |
| - Remove or set payment blocks |
| - Update order confirmations |
|
|
| This means the process is designed to keep all related records consistent when the source document changes. |
|
|
| ### Step 6: Completion and Closure |
|
|
| Eventually, the SRM lifecycle reaches terminal states such as: |
|
|
| - **SRM: Complete** |
| - **SRM: Document Completed** |
| - **SRM: Transaction Completed** |
| - **SRM: Deleted** |
|
|
| The process ends at the **end event** after all applicable branches have been resolved and the transaction is fully closed. |
|
|
| --- |
|
|
| ## 4. Decision Points |
|
|
| The model contains many gateways, and they play a critical role in controlling the process logic. |
|
|
| ### Exclusive Gateways |
|
|
| Most gateways are **exclusive gateways**, which means only one path is taken based on the current business condition. |
|
|
| These gateways are used for decisions such as: |
|
|
| - Whether a document is approved, held, incomplete, or deleted |
| - Whether a transfer succeeded or failed |
| - Whether an item should be blocked, reactivated, or deleted |
| - Whether a receipt or invoice should be canceled or retained |
| - Whether a change affects quantity, price, currency, or other attributes |
| - Whether a correction should lead to one downstream action or another |
|
|
| In business terms, these gateways represent **if/then decisions** based on document state, approval status, or the type of change. |
|
|
| ### Parallel Gateways |
|
|
| The model also uses many **parallel gateways**, which split or join work that can occur simultaneously. |
|
|
| These are used when: |
| - Multiple document updates must happen in parallel |
| - Several dependent objects must be synchronized at the same time |
| - Multiple correction actions need to be completed before the process can continue |
|
|
| For example, after a change to a purchase order, the model may branch into separate paths for: |
| - Updating confirmations |
| - Adjusting receipts |
| - Changing invoice-related data |
| - Modifying payment or approval status |
|
|
| ### Converging Gateways |
|
|
| Many gateways are converging, meaning they wait for one or more incoming paths before continuing. This ensures that: |
| - All required updates are completed |
| - Parallel corrections are synchronized |
| - The process only proceeds once the document is consistent again |
|
|
| ### Business Meaning of the Branching Logic |
|
|
| Overall, the gateway structure shows a process that is highly dependent on **document state management**. The model does not assume a single happy path. Instead, it supports: |
|
|
| - Normal processing |
| - Approval and release |
| - Transfer errors |
| - Partial completion |
| - Post-order changes |
| - Reversals |
| - Reprocessing |
|
|
| This is typical of enterprise procurement environments where documents must remain aligned across SRM, ERP, logistics, and finance. |
|
|
| --- |
|
|
| ## 5. Start and End Conditions |
|
|
| ### Start |
|
|
| The process begins with a **start event** labeled **"start"**. |
| From there, the flow immediately enters a parallel split, indicating that the process may initialize multiple workstreams at once. |
|
|
| ### End |
|
|
| The process ends with a single **end event** labeled **"end"**. |
| However, the path to that end is not direct. Before completion, the process must pass through final SRM completion states and consolidate any outstanding branches. |
|
|
| In practical terms, the process ends only after: |
| - All relevant procurement and financial activities are completed |
| - Any required changes or reversals are processed |
| - The SRM transaction reaches a final closed state |
|
|
| --- |
|
|
| ## Concise Business Interpretation |
|
|
| This BPMN model describes a **complex procurement transaction lifecycle** with integrated handling of: |
| - Requisitions |
| - Purchase orders |
| - Vendor confirmations |
| - Goods/services receipts |
| - Invoices and debit memos |
| - Approval and transfer statuses |
| - Extensive post-processing corrections |
|
|
| It is best understood as a **purchase-to-pay process with exception management and document synchronization across systems**. |
|
|
| --- |
|
|
| *Note: This is the typical flow description. The agent has autonomy to guide execution according to this description, as long as all actions conform to the normative constraints specified in process-constraints.md.* |
