docs/process-description.md

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.