How do you create a great user experience in your web channel—while also honoring your existing order-to-cash processes in SAP?

This is the challenge which Corevist products solve with prebuilt, configurable integration. And while we accommodate all standard SAP processes, some manufacturers have developed unique workflows in SAP that require creativity to translate into an eCommerce user experience.

We recently encountered this with a client who wanted to break out single orders from the Corevist Platform into multiple sales orders in SAP when line items had different RDDs (requested delivery dates).

Here’s how we tackled this challenge in collaboration with our client.

Problem #1: Line items with different RDDs require separate sales orders

Our client has an internal process which insists on this. If you order 10 products, and 3 are available in 30 days while the rest are available in 90 days, the internal process requires two separate sales orders representing a transaction which the customer sees as “one order.”

These separate sales orders all have the same PO number, but there is no master document representing all the broken-out sales orders (more on that below).

This process is deeply integrated to our client’s business. It’s set in stone, and they can’t change it without massive consequences.

Problem #2: Corevist wants to post 1 “master record” for the order in SAP

Our client’s process presents a challenge for the Corevist Platform. Our solution wants to place a single order in SAP which corresponds 1:1 with the customer’s order placement action on the web. This is the best possible data flow, since a single master SAP document representing the customer’s single web order affords the highest level of integration simplicity, strength, and verifiable integrity.  

This is critical to customer experience. If a customer calls in or faxes over a list of SKUs to order, they believe they’re placing a single order (even if Customer Service is breaking up that order behind the scenes). Yet because the line items must be broken up by RDD, there is no master document in SAP which corresponds with what the customer experienced as “placing an order.”

This introduces risk to the customer relationship. If the customer encounters a problem with the order, CSRs (Customer Service reps) have to look across multiple documents to see if they’re taking the entire order into account. But they can’t be sure they’ve covered everything until they’ve communicated with the customer several times. At scale, that’s expensive—and because it’s a manual process, it introduces a higher risk of errors.

Proposed solutions

Our client had a few ideas on how to deal with the problem:

1. Make the customer place separate orders for separate RDDs

This solution would satisfy the internal requirement, but it would put all the work on the customer. It also risked creating a frustrating customer experience. Users don’t have to place separate orders on Amazon, so why should they have to do it in Corevist?

We advised our client that this wasn’t an ideal solution.

2. Split up the order in the backend of the Corevist Platform

This solution would solve the customer experience problem by allowing the user to create only one cart. But this solution wouldn’t eliminate the problem of having no “master record” in SAP corresponding to that single order. 

SAP would still log multiple sales orders corresponding to that single order placement action, and SAP would have no way to tie these sales orders together. A CSR would have to put in manual work to figure out which sales orders were associated with that single order placement action.

We advised our client that this wasn’t ideal, either.  

Our solution: Let Corevist write a Quote to SAP… 

…then a downstream process to automatically split to separate sales orders using create with reference.

To solve the problems of both customer experience and internal documentation, we had to think outside the box.

What if we tweaked Corevist so it created a quote in SAP rather than a sales order?

That quote isn’t executable, but it’s still a single document—a single “master record” for the action which the customer took in placing an order. And the quote could have a single PO number associated with it, which would fulfill customers’ expectations of seeing a single PO associated with their order placement action.

In SAP, our client could write “create with reference” logic which would automatically break up the line items with different RDDs into separate sales orders. That way, our client would have a single document in SAP that corresponds 1:1 with the user’s order placement action in Corevist.

This solution wasn’t complicated, either. It’s standard SAP functionality using the function module that allows “Create with reference.” Our client’s IT team simply had to feed that function module with logic that says, “Put these line items in their own sales order. Put the rest of the line items in a different sales order.” 

The quote will automatically break out into separate sales orders, based on this custom logic. And it will bring over the original PO number from the quote to each separate sales order.

The impact: Great customer experience + total data integrity

On the front end, our client’s user experience is aligned with the universal expectations of web users. The customer gets to place a single order, just as they can on Amazon, regardless of how the line items will be handled behind the scenes. Same as before, the customer will see one PO number associated with all downstream orders in Corevist.

On the back end, our client gets a unique sales order in SAP for each RDD—yet they also have a single master document (the quote which Corevist placed in SAP) corresponding to the order placement action (a feature that will come in handy if customers claim their downstream order doesn’t correspond with the original order they placed in the cart.). 

What’s more, CSRs can see status for each line item and/or separate sales order using document flow in SAP. They can easily pull up that initial quote in SAP and find out what’s been shipped, partially shipped, invoiced, and so on. This provides a comprehensive view of the complex status of the customer’s “single order.” It’s a giant leap forward for our client’s Customer Service team (and for their customer experience).