Introduction

In a B2B scenario orders may need to be approved by certain users of a customer before they are placed. The order approval workflow can be very simple or very complex or could be handled by an external system. To ensure that the order approval is flexible enough, an Order Approval Service is implemented using the Approval Service interfaces from the standard Intershop 7.

References

• Concept - Approval Managed Service
• Cookbook - B2B Order Approval

Workflow

The following diagram shows a bird's eye view of the approval workflow.

Implementation

The implementation of the service is based on the order approval workflow of the previous version of the B2B Extension Module and supports approval rules as before (see the cookbook for more details).

Currently a generic REST approval callback is not part of the standard implementation. A callback has to be implemented separately when integrating with an external approval system.

Dependencies

Classes

The following diagram describes the main classes used by the ICM approval service implementation. For more information on the approval service itself see Concept - Approval Managed Service.

• ApprovalRequiredRule - A rule that can determine whether approval is needed for a given buyer and requisition. For example a rule could say approval is needed if the requisition total is greater than the buyer's budget. In general the rules should perform simple checks.
• ApprovalRequiredRuleProvider - A provider for ApprovalRequiredRule instances.

• ApprovalStepBO - A unit that needs to be approved by a single approver. Multiple steps can be associated with the same requisition. In general each step of the same requisition should require approval by a different set of users (e.g., any of the users with the permission to approve orders, the manager of a cost center, etc.). Different ApprovalRequiredRule instances could require different approval steps. Once all applicable approval steps for a requisition are set to approved then the requisition is considered as approved and order creation process could start. If any of the approval steps for a requisition is set to Rejected then the entire requisition is considered to be refused. In case the same user is responsible for more than one approval step of requisition he could set the approval decision for all steps in one action(Approve or Reject).
• BusinessObjectApprovalStepExtension - Manages the approval steps. It is aware of which steps need to be created for a requisition based on the ApprovalRequiredRule instances.
• EligibleApproverPredicate - A predicate that can be used to determine whether a user is eligible to approve an approval step. For example a predicate could check whether the user has the permission to approve orders. The predicate is used internally by the default implementation of the approval step BO.

Components

The ApprovalRequiredRule and EligibleApproverPredicate are available as contract components and can be used to add new rules or trigger the creation of new steps. For more details see Cookbook - B2B Order Approval.

The following rules are available and wired out of the box:

• BudgetThresholdApprovalRule - requires approval if the requisition total exceeds the buyer's budget. Applicable for one time purchase baskets, but not for baskets automatically created from approved subscription.
• SingleOrderThresholdApprovalRule - requires approval if the requisition total exceeds the buyer's limit for a single order. Applicable for one time purchase baskets, but not for baskets automatically created from approved subscription.
• CostCenterApprovalRule - requires approval if the requisition is assigned to a cost center. In case the buyer is assigned as buyer for at least one cost center then a cost center must be selected and it is assigned to the basket. Once the basket has cost center assigned it require approval, unless it is automatically created from approved subscription.
• SubscriptionApprovalRule - requires approval if the requisition is a subscription. Once the subscription is approved then all subsequent baskets created from it are also considered as automatically approved.
  

The following predicates are available and wired out of the box:

• ApprovalPermissionEligibleApproverPredicate - users with the permission to approve orders can approve a step. This is set as default. Steps are created using this predicate when a rule doesn't have a specific assignment.
• CostCenterEligibleApproverPredicate - the manager of the cost center to which the requisition is assigned. A step using this predicate is created if approval is required by the CostCenterApprovalRule.

Basket State Changes

The following diagram illustrates possible basket state changed related to the approval process:

• BASKET_OPEN - Basket is open for every kind of manipulation, like add products, warranties and coupons, remove line items.
  Furthermore a basket being in this state is ready for checkout.
• BASKET_ORDERED - Checkout of basket has been successfully finished.

One time purchase requisitions has basket type REQUISITION(10). Subscriptions has basket type RECURRINGBASKET(11). Before to start the Checkout process it is possible to switch basket type from REQUISITION to RECURRINGBASKET and vise versa.