Understanding the Order Approval Process

At its most basic level, the order approval process consists of the following phases:

  1. During checkout, the application determines if an order requires approval.

  2. If the order requires approval, then an approver approves or rejects the order.

  3. The application determines if the approval process for the order is complete.

  4. If the approval process for the order is complete, then the order proceeds through checkout.

The following properties of an Order object (class atg.b2bcommerce.order.B2BOrderImpl) support the order approval process and maintain historical approval data for an order as it moves through these phases.

Property Name

Property Type

Description

authorizedApproverIds

List

The list of profile IDs of the users who are authorized to approve the given order.

approvalSystemMessages

List

The list of system messages that the application attaches to the order. These messages indicate what conditions triggered an approval being required, such as “order limit exceeded.” They are defined by the processors in the checkRequiresApproval pipeline chain.

approverIds

List

The list of one or more profile IDs of the users who have approved or rejected the order.

approverMessages

List

The list of messages the approvers attach to the order.

The ApprovalFormHandler form handler enables an approver to add comments when he or she approves or rejects an order. These comments are added to this property.

The following diagram illustrates the business logic that drives the order approval process and briefly indicates which components move an order from one step in the process to the next. The complete order approval process is subsequently explained in detail.

In this diagram, a customer has just submitted an order for checkout, and, consequently, the processOrder() method has executed the processOrder pipeline chain. processOrder’s first processor, executeValidateForCheckoutChain, has validated the order. processOrder’s second processor, executeApproveOrderChain, begins the order approval process by executing the approveOrder chain. The first processor in the approveOrder chain is verifyApproval.

As is briefly illustrated in the preceding diagram, the order approval process is as follows:

  1. approveOrder’s first processor, verifyApproval, checks whether the order already is approved.

  2. approveOrder’s second processor, runCheckRequiresApprovalChain, executes a separate pipeline chain named checkRequiresApproval. checkRequiresApproval determines whether approval is needed for the order and reports back to approveOrder.

    Note:The default implementation of the checkRequiresApproval chain checks the approvalRequired property in the customer’s profile. If the approvalRequired property is true, then approval is required for the customer. An error is then added to the PipelineResult object, which tells the system that an approval is required, and the reason that approval is required is stored in the errorMessages property of the Order. This reason for approval is later added to the order’s approvalSystemMessages property by the approveOrder chain’s addApprovalSystemMessagesToOrder processor. If the approvalRequired property is false, then approval isn’t required for the customer.

    You can edit the checkRequiresApproval chain to create specific requirements for whether an approval is required for a given customer. For example, you might want to include a processor that checks the total amount of the customer’s order against an order limit specified in the customer’s profile. If the order amount exceeds the specified limit, then approval for the customer’s order would be required. Similarly, you might want to include a processor that checks the manufacturers of the items in the customer’s order against a list of preferred suppliers specified in the customer’s profile. If a manufacturer isn’t in the list of preferred suppliers, then approval for the customer’s order would be required.

  3. If approval for the order is needed, an approver then approves or rejects the order and submits this decision in a form using the ApprovalFormHandler form handler. The form’s “Approve” and “Reject” submit buttons call the handleApproveOrder method or the handleRejectOrder method, respectively.

    Note:The orderApproved and orderRejected pipeline chains are the same with the exception of the value of approvalStatus property of the ApprovalUpdate message that is sent. You can edit these chains to add or remove functionality to meet your application’s needs.

  4. The ApprovalCompleteService, located in Nucleus at /atg/commerce/approval/ApprovalCompleteService, is configured to listen for the ApprovalUpdate messages sent by the orderApproved and orderRejected chains to the /Approval/ApprovalUpdate JMS message queue. When ApprovalCompleteService receives a message, it executes the checkApprovalComplete pipeline chain. checkApprovalComplete determines whether the approval process for the order is complete. By default, checkApprovalComplete’s second processor, approvalCompleteAnalyzer, checks whether at least one person has approved or rejected the order. If so, then the approval process for the order is considered to be complete.

    Note:As previously mentioned, the default implementation of the approvalCompleteAnalyzer processor merely checks whether at least one person has approved or rejected the order. If so, then the approval process for the order is considered completed. You can change the implementation of approvalCompleteAnalyzer in order to change the requirements for completion of the approval process.

For detailed information about the pipeline chains and processors mentioned in this section, refer to the Pipeline Chains in the Order Approval Process section in this chapter.

 
loading table of contents...