Corevist’s Belt and Suspenders Approach to Duplicate Order Prevention

How do you prevent duplicate orders?

In SAP B2B eCommerce, user experience (UX) is tantamount. From first login, through catalog search, adding items to the cart, all the way to checkout, the user needs a friction-free experience. We constantly strive to remove friction points and optimize our software for performance. It’s a proactive approach to UX–and being proactive is one of our core values.

To start the process of UX performance optimization, we first pinpoint the source of potential issues. We can proudly say that performance or lag issues don’t originate within the Corevist app. Our software is built with lean, efficient code, and it works. Really well.

On rare occasions, we do encounter lag issues–from our client’s SAP system, which we can’t control. Because SAP is an enterprise-class system, there may be times of day (or month) when it runs a little slow. For example, Finance might be closing the books for the month, or Sales might be swamped with quote requests after the release of a new product.

We occasionally see these lag issues with clients who haven’t migrated to SAP HANA. We encourage our clients to migrate to HANA, which will eliminate a lot of these performance issues at peak SAP use times.

These issues originate outside the Corevist app, but they can affect it. That’s why we constantly monitor the performance of our clients’ SAP systems. We let our clients know when performance lags so we can proactively prevent issues.

The problem: SAP lag occasionally leads to web timeout

A handful of times, we’ve seen SAP lag lead to the placement of duplicate orders. While this is an extremely rare case, we find it unacceptable. It stops now. It isn’t the fault of the Corevist app, but we have taken steps to address it so that it never happens again to any of our clients. Those duplicate orders drive up expenses–not to mention the impact on customer satisfaction. They lead to return shipping costs, restocking costs, and lost orders due to inventory unavailability. Duplicate orders also require communication with the client and a plan for addressing the situation, both of which create personnel expenses.

While other issues like network connectivity can cause duplicate orders to occur, the performance of the SAP system is the driving factor in duplicate order placement.

How it happens

The user submits an order with a large number of items. Internal factors of SAP, like database tuning, lack of machine resources or inefficient ABAP code, can cause delays in processing every item in the order. In these cases, a “timeout” may occur on the web application. The user gets a generic connectivity-related error message and thinks their order hasn’t been placed. Consequently, the user places the same order again.

But the order was placed.

In the meantime, while the user was trying to place the same order again, SAP continued its processing and has finished the original order in the background. The order was created, but the user doesn’t know it. Due to their misguided second attempt, the user has created a duplicate order without even realizing it.

It’s important to emphasize that this is an extremely rare occurrence. We can count the number of duplicate orders we’ve seen on one hand. But we wanted to eliminate all possibility of this happening again. Here’s how we did it.

The solution: 2-step, automated duplicate order check

To solve this issue, we built a new duplicate order check into the Corevist app. It operates in two stages: on the Rails (web application) side, and on the SAP side.

This feature will be turned off by default in the release, since it requires some work on the SAP side to turn it on fully. However, we wanted to explain this feature to our clients. If you would like to turn it on, just let us know.

Let’s look at the details. We like to think of this as a Belt and Suspenders approach to duplicate order checking. One check is at the cart level, and the second is in SAP.

Step 1: The Rails (web application) side

In our latest quarterly release, the Corevist web application performs the first duplicate order check in the process. This feature is turned off by default in the new release. It’s easily turned on for clients who need it. This feature can detect duplicate orders that happen for a number of reasons, such as:

  • Timeout
  • SAP Communication Interruption
  • End User Interruption [Refresh / navigation]

Here’s how it works.

The Corevist application already maintains the status of a logged in user’s shopping cart. When the user walks away, logs out, or otherwise stops working on the cart, their progress is saved for the next time they visit the site. In addition to that, we’ve added the step of saving the cart status between the time you are ready to submit it to SAP and when SAP sends back a successful response. You might think of this as a “temporary saved state.”

Our first level of duplicate order check occurs here. We check all new order attempts against any saved carts that might be in a temporary saved state. Any time that temporary saved state still exists, it is checked against any current activity looking for duplication at the web level. If the check comes back positive, we ask the user if they are sure they want to proceed. This level of checking saves time by not requiring a round-trip message to SAP to prevent a possible duplicate.

In order to perform this level of duplicate order check on the cart, we’ve designed a one-time hash or checksum that serializes all the data in the cart for evaluation. This feature looks for duplicate order attributes such as SKUs, quantity, and PO number. If it finds duplicates, it submits a warning message to the user. This catches duplicate orders that would occur due to clicking the “submit order” button more than once.

Step 2: The SAP side

For orders which have passed the web-side duplication check and have been sent to SAP for creation, an additional check is performed in the SAP system. This is meant to catch potential duplicate orders caused by a break in the link between an original request to create an order and a success or failure message back from SAP. SAP may have indeed created the original order, but the user was never informed, so they attempted to recreate the same order.

As with the saved cart check, the SAP check examines data such as PO number, number of items, material number, and quantity. If all those criteria match a previous order exactly, we warn the user with a message. “We already have an order number, 12345, that has that exact same attributes as the one you’re placing now. You may be creating a duplicate order. Are you sure you want to proceed?”

We set this to manual approval because some “duplicate” orders may be intentional—the user may realize that they needed to order double the quantity of what they already ordered. For that reason, the user can bypass this check manually, in case they really do need both orders.

Of course, the vast majority of cases will be unintentional duplicates caused by SAP lag. If the user didn’t intend to place a duplicate, they can go look at the order number that comes back in the warning. They may find out that the order was already posted to SAP while the web application showed a web timeout.

The duplicate order check governs a certain period of time, which is configurable. For one client, we’ve set that time to 1 hour. If you submit a duplicate order within one hour of submitting the original order, you’ll get the warning message. If an hour or more has elapsed, you won’t get the warning message.

We can adjust that setting to any period of time, based on the business case confronting the client.

The Takeaway

In an ideal world, every SAP system would work at a reliable speed that doesn’t conflict with web timeouts. However, we know SAP, and we know that isn’t always realistic, especially given network connectivity issues and very large orders. Our goal was to create a solution that doesn’t disrupt your SAP system, but also prevents the placement of duplicate orders. We’re thrilled to launch this new feature in our Q2 release. Again, it will be turned off by default, but is easily turned on if you believe it would benefit your business. If you have any questions, please don’t hesitate to contact us.

Subscribe to our blog

About Author

Nathan Leach

Nathan serves as a Senior Implementation Consultant, project manager, and account manager. He began his career as an SAP® technical consultant in 1995, and specializes in custom development, system integration, technical architecture and design, and project management.