Automatic approval for returns

Every product that is modified within a return is subject to an automatic approval process. With the appropriate level of security, manual approval can be issued, but for a typical return, automatic approval is easier. Automatic approval consists of a series of tests on the specified product and its relationship to the rest of the return, other returns, and the original order. For each unsuccessful test, a denial reason is logged against the return item. The reasons can be presented to a Customer Service Representative who can override the system evaluation and issue a manual approval.

The tests are broken down into a set of standard checks, which typically every store can use. This is the default implementation of these standard checks:

Is the item refundable?

In some cases, a store might not accept returns on all products. For example, for hygienic reasons, a clothing store may designate intimate apparel as nonrefundable. The CREDITABLE column of the STOREITEM table allows you to specify whether a product is refundable by default; that is, if CREDITABLE=N, then this product should not be refunded. You can edit the value of the CREDITABLE column using the Product notebook. During the standard checks portion of the auto-approval process, one of the following can occur:

  • If a product is marked non-creditable, then a corresponding deny reason is applied to the Return item.
  • If STOREITEM.CREDITABLE=Y, then the item can pass the auto approve check criteria.
  • If StoreItem.creditable=N, then the return merchandise authorization (RMA) goes into pending approval status (the auto approve check failed on this criterion). The administrators must approve this RMA manually. This is logged in the deny reason list.

Is the merchandise going to be returned?

During the checking process, the system validates whether the customer plans to return the return item. Typically a deny reason will be applied to a return item, if the customer does not intend to return all the components of the product. Depending on your business, a return does not always require the customer to physically return the unwanted product. For example, if a customer wants a refund for fresh produce from a grocery store, the store would probably not request the return of the produce to the store. This preference is controlled by the RETURNNOTDESIRED column of the STOREITEM table. You can edit the value of the RETURNNOTDESIRED column using the Product notebook. During the standard checks portion of the auto-approval process, one of the following can occur:

  • If a product is marked as return not desired, then no deny reason is applied even if the customer does not intend to return the merchandise. The components that the merchants does not want to have returned, will be flagged as such.
  • If STOREITEM.RETURNNOTDESIRED=N, then the item must be physically returned to the fulfillment center. In this case, if the customer returns the item to the store, then this RMAItem can pass the auto approve check. But if the customer does not return the item to the store, then the RMAItem will not pass the auto approve criteria (the auto approve check failed on this criterion). The administrators must manually approve this RMA. This is logged in the deny reason list.
  • If STOREITEM.RETURNNOTDESIRED=Y, then the item does not have to be returned to fulfillment center. In this case, whether the customer returns the item to the store or not, the RMAItem passes the auto approve criteria. You must check the STOREITEM.RETURNNOTDESIRED and RMAITEMCMP.SHOULDRECEIVE.
  • If RMAITEMCMP.SHOULDRECEIVE=S or RMAITEMCMP.SHOULDRECEIVE=Y, then this RMAItem can pass the auto approve criteria. If RMAITEMCMP.SHOULDRECEIVE=N, then this RMAItem does not pass the auto approve check and is logged in the deny reasons list.

    Note: If static kits are part of the order, then all the components are checked for the RMAItem of the static kit.

Would approving this return item mean that the customer is approved for more than was shipped?

If WebSphere Commerce's fulfillment functionality was in use when the order was fulfilled, then this check will confirm whether the return item will put the total quantity approved over the quantity shipped. This could be true if products have been misattributed to order items during the returns process, by either accident or fraud. If fulfillment functionality was not in use at the time the order was fulfilled, then the default implementation always logs a deny reason on this check.

Would approving this return item mean that the customer is approved for a total refund greater than the amount paid for the originating order?

If WebSphere Commerce's payment capture functionality was in use when the order was fulfilled, then this check confirms whether this return item will make the total refund greater than the amount that was paid. This could be true if products have been misattributed to order items during the returns process, by either accident or fraud. If payment capture functionality was not in use at the time the originating order was fulfilled, then the default implementation always logs a deny reason on this check.

Policy extensions for standard checks

Automatic approval is checked using the AutoApproveReturnItemPolicyCmd task command. The default implementation of this command enforces a period after the ship date within which returns will be accepted. If there is no ReturnApproval policy referenced in the trading agreement, then a NOPOLICY deny reason is applied to the return items that are covered by that trading agreement.