Name: Introducing Customer Services in the Base Commerce Module of SAP Commerce Cloud
Uploaded: 2023-8-21
Duration: 617 s
Description: This video gives a brief introduction to the default implementation support for the Customer Services in the Base Commerce Module of SAP Commerce Cloud, which includes the API introduction to the order cancel service, return service and the refund service.

Share feedback

<p><u><strong>Planned maintenance of Practice Systems</strong></u></p>

Planned maintenance of Practice Systems

Why create an SAP account?

Enhance your learning experience

SAP Learning

Choose your subscription

Manage your subscription

Live Sessions

Hands-on Practice

Certification

My Learning

Ready to start learning?

<div><div><div><div><div>This video gives a brief introduction to the default implementation support for the Customer Services in the Base Commerce Module of SAP Commerce Cloud, which includes the API introduction to the order cancel service, return service and the refund service.<br></div></div></div></div></div>

Introducing Customer Services in the Base Commerce Module of SAP Commerce Cloud

Hello, let’s talk about the Customer Services in the Base Commerce module.  If you check the documentation on help portal, you can see that the Base Commerce Module is the technical implementation which supports the order management of SAP Commerce Cloud.  The related features include the base store data structures, the customer review, the basic customer services, fraud detection, replenishment order, order history, order splitting, payment, basic stock and warehouse management, etc.  In this video, we’ll focus on the basic customer services in the Base Commerce Module, which is more API level implementation. But don’t confuse them with the Customer Service module or Assisted Service Module, which provides further end user functionalities.  Technically speaking, the customer services in the Base Commerce Module are implemented in the base commerce extension.  It includes the following 3 services:  Order Cancel Service, Return Service and Refund Service.  We’ll be more focusing on the order cancel service first, as this is typically customized or extended to fulfill individual project needs.  The order cancel service enables order cancellation, either by the customers themselves, or triggered by the customer support agents.  Out-of-the-box in the Backoffice administration cockpit, there is the order cancellation configuration which can be used to support different order cancellation scenarios,  such as to allow customers to cancel their orders or not, enable complete cancel after the order is shipped, whether partial order cancel, or order-entry cancel is supported Example given, I ordered item A and item B, but want to cancel item A and keep item B. Or I ordered 2 item A, but just want to keep one A and cancel the other A,  or enable order cancel after the order request has been sent to warehouses.  Let’s log into Backoffice and check the order cancellation configuration.  It’s under base commerce, order cancellation configuration.  You can see that the order cancellation is currently enabled.  We can also check it on the composable storefront, that the customer can see a button to cancel the selected order or order entries.  Now let’s disable the order cancellation and save the configuration.  I’ll refresh the order page now.  As you notice, the order cancellation button is no longer there, meaning that the order cancellation is now disabled as we configured so.  Let’s take a further look at the Order Cancel Service interface API.  It is the main service interface for cancelling orders, which can perform order-cancel-related functionality.  It has access to order cancel data model and configuration.  And it uses OrderCancelRequest to construct cancel requests.  But how does it really work?  When an order is to be canceled, an order cancel request is created and sent to the default implementation of the Order Cancel Service interface, namely the DefaultOrderCancelService.  In this service, a state mapping strategy takes the order cancel request as an input, and returns an Order Cancel Status as an output.  The order cancel status is further sent to a request executors map.  Depending on the order cancel status value, a pre-assigned request executor is chosen to handle the order cancel request accordingly.  For example, if the order is currently being processed, based on the state mapping strategy, the order cancel status pending or holding area is returned.  Then based on this value, the request executor 1 is chosen to handle the order cancellation.  Or if the order is being shipped to the customer, the state mapping strategy returns shipping, then the request executor 2 is chosen to handle the order cancellation.  As you may notice, the order cancel state mapping strategy plays an important role for choosing the assigned executor to handle the order cancel request.  Out of the box, this strategy relies on 2 objects to decide the order cancel state, namely the order status and the consignments.  In this table, you can observe how the default implementation is done.  For example, if the order status is cancelled, canceling or completed, or the status of all consignments are set to shipped, the order cancel status will be “cancel impossible”.  Or if the order status is not cancelled, canceling or completed, and the order was not yet split into consignments, the order cancel status will be “pending or holding area”.  Of course, the default implementation can be customized, and we’ll talk about it later.  Let’s come back to the order cancellation process, after the order cancel request is handled by the order cancel service and sent over to the backend ERP system, it’s not processed immediately, as SAP Commerce Cloud and the backend ERP are 2 independent systems.  After the order cancel is processed, a response message is sent back from the ERP system and used to construct an order cancel response object in SAP Commerce Cloud.  This order cancel response is then further handled by the order cancel callback service.  Out-of-the-box, the order cancel callback service interface is also implemented by the DefaultOrderCancelService.  It uses a similar structure to handle the order cancel response as the order cancel request.  First of all, a state mapping strategy takes the order cancel response as an input, and returns an Order Cancel Status as an output.  The order cancel status is further sent to a response executors map.  Depending on the order cancel status value, a pre-assigned response executor is chosen to handle the order cancel response accordingly.  For example, if the order is already being shipped to the customer, based on the state mapping strategy, the order cancel status “shipping” is returned.  Then based on this value, the response executor 1 is chosen to handle the order cancel response.  Let’s put these altogether and take a look at the implementation of the DefaultOrderCancelService.  As mentioned before, it implements both the Order Cancel Service interface and the order Cancel Callback Service interface.  It uses the state mapping strategy to deal with the order cancel request status and the response status.  It contains the request executors map to handle the order cancel request and the response executors map to handle the order cancel response.  In basecommerce-spring.xml, we can also observe the declaration of the spring bean, where the default mapping of the request executors map is defined, and the default mapping of the response executors map, as well as the state mapping strategy.  As we notice, there are different possibilities to customize the order cancellation process.  We can have a new service implementation of the order cancel service interface for completely custom handling of order cancel requests,  or a new implementation of the order cancel callback service interface for handling order cancel response.  We can define a new state mapping strategy to handle more complicated order cancellation situation but keep the current structure unchanged.  We can provide a new executor mapping or mappings for order cancel request or response.  Of course, we can keep the handling process unchanged, but override a certain request executor or response executor to change exactly that order cancel request or response handling.  Ok, now let’s take a quick look at the return service.  In SAP Commerce Cloud, a default scenario is implemented by the return service interface in basecommerce-spring.xml already, which supports the followings:  A customer can request a return authorization regarding a certain completed order in the self-service area.  The return authorization request is sent over to the order management module.  Once the return request is approved, the customer gets an email notification about the approval, while the return request information is sent over to the backend warehouse that will be waiting for the order item to arrive.  The customer can then send the item to the warehouse.  Once the warehouse finished checking the returned item, a refund or replacement can be triggered in the order management services module.  This entire scenario is demonstrated in the video of SAP Commerce Cloud Order Management Services Module, please have a check there.  The Return Service interface is the key interface for this scenario and consists of different methods to support the return functionality.  However, in real-life projects customization is needed to meet different project requirements.  Last but not least, the Refund Service interface is responsible to support the refund scenario with the following methods:  The createRefundOrderPreview method is used to clone the original order and create a preview of it for the refund.  The getRefunds method goes through the cloned order and the return request, fetch the entries that are to be refunded.  The first apply method with the list of the refund entries calculates the refund amount and relate it to the affected order.  Finally, in case the return is successful, the second apply method recalculates the original order and applied the refund based on the return request.  The default implementation can be observed in the DefaultRefundService.  But please note, this default implementation assumes unchanged promotions and prices, it looks at standard prices only and may cause incorrect calculations.  Therefore,it should only be used as an example for own customized work in real-life projects.  That’s it for a brief introduction to the customer services in the base commerce module. Thank you for watching.