How to configure same-day delivery in SAP ECC using Netweaver
(Part 1 of 6). Over the next six weeks I’m going to share with you a tried and tested method which you can then use to bring huge cost savings to your current SAP client.
You will see that this solution is adaptable, robust, and can be implemented at low cost. The example I provide will also open the door to solving similar problems. This will all be achieved by learning and applying an underestimated and undervalued standard SAP functionality.
After following this sequence of six blog posts, you’ll be desperate to start exploiting this free SAP tool to solve any complex problem you face.
I first became acquainted with this functionality only a few months ago. Even though I’ve saved my SAP clients a lot of money on multiple occasions, I would not label myself a guru. My road to discovery is ongoing, but I’m sure you can benefit from what I‘ve learned so far.
It all started with a post-it note that contained the following business requirement: “Determine the cut-off time for same-day delivery”.
The thought behind this request was to have a reliable delivery date printed on the order confirmation, assuming that delivery was possible under normal circumstances. Many companies would like to control this in their SAP system; however there is no standard SAP functionality available to configure this. This is mainly because the determination of the cut-off time for same-day delivery differs for each SAP client. Yes, the SAP system provides the parameters for making a decision, but automating decision making is a totally different story.
The post-it note remained on my desk for several days. I read and re-read it, wondering how I could solve this problem. Each time I dived into the SAP system to look for answers, I found nothing I could use.
The next hurdle was to explain my predicament to the business analyst. Of course, he had written the note and thought it would be a straightforward matter. He was expecting a straightforward response from me. So he was surprised when I explained my problem at the coffee machine.
A good moment to discuss the business requirement in a bit more detail.
The German manufacturing site in Frankfurt distributes the goods to all German customers. The delivery region as well as the delivery priority determines whether goods can be delivered on the same day. By default German customers need to provide their orders by midday. Those with priority service can wait until 2pm.
There are also deliveries to other distribution centres in other countries. These internal customers are open 24/7, so there is more flexibility in offering same day delivery. For example, supplying the Dutch store in Arnhem on the same day can be promised as long as the request is received before 6pm.
So far it’s not that complex, but each location across Europe then has its own specific differences. For example, some Italian customers prefer to select their own preferred transporter, arriving at the Italian distribution centre in Milan at 11am. And some British customers pick up the goods themselves at the Birmingham distribution centre at the end of the working day.
As always, that one-liner on a post-it note becomes a complex business requirement that needs to cater for many different scenarios.
Nonetheless, I still had to design a flexible, easy, affordable solution, and my deadline for the deliverable would not be moving.
What would you do next?
You’d probably take a blank piece of paper and note down all the details that you’d received so far. Then you’d try to figure out how SAP deals with similar requirements in order to avoid reinventing the wheel.
Thats what I did, but while I was staring at my notes, I saw a potential method that could allow me to move forward!
To be continued…
(Part 2 of 6) It started with a few words scribbled on a single post-it note: “determine the cut-off time for same-day delivery”.
But, as is often the way, there was a deceptive complexity behind this simple message.
So, next I decided to write down the parameters to determine this cut-off time on a blank piece of paper.
First up, as the route influences lead times you need to know the factors influencing standard SAP route determination. The shipping point represents the physical location from which you ship the goods. The destination country and transportation zone determines where the goods will arrive. The shipping condition identifies the service level, being standard or priority delivery or customer pick up.
In addition, the ordering customer can define their preferred forwarding agent. And then we need to know when the goods are collected at the shipping point.
I quickly discovered that only a selection of the parameters would influence the cut-off time. but at least it was obvious that the shipping point is always required.
When the customer picks up the goods, the ordering customer and shipping condition are required.
In the case of standard or priority delivery, you also need to know the destination country and transportation zone. And, finally, the ordering customer and forwarding agent can determine when the goods are ready for collection.
This enables me to list the combinations (in no particular order):
• Shipping point, ordering customer and shipping condition.
• Shipping point, destination country, destination transportation zone and shipping condition.
• Shipping point, ordering customer and forwarding agent.
The next logical step is to order them from “most specific” to “most generic”. This exercise produces the following result:
• Shipping point, ordering customer and forwarding agent.
• Shipping point, ordering customer and shipping condition.
• Shipping point, destination country, destination transportation zone and shipping condition.
So, if the customer is not using a specific forwarding agent to pick up the goods, then check whether they pick it up themselves before applying the standard rule based on the receiving address.
It occurred to me that this process is very similar to the SAP condition technique, using condition types, condition tables and access sequences.
The cut-off time for same-day delivery can be seen as a condition type.
Then, the three sets of parameters are the condition tables.
And the access sequence will determine the sequence in which you must address these condition tables.
What a great discovery! I started to believe, for the first time, that I had an opportunity to solve the puzzle.
But there was still a long way to go.
The condition technique supports pricing, output determination, material listings or exclusions, revenue account determination and much more. So, the concept is widely used throughout the system. It is flexible, but could become quite complex to configure. Still, it is the most logical method to adopt for re-determining the delivery date based on a cut-off time for same-day delivery.
The delivery date is influenced by the route. If you find that the order was received past the same-day delivery cut-off time, then you need to assign a new route to the order item. This route would require one extra day for transportation planning to ensure that the goods can be expected to leave the site the next day.
Therefore, you need a simple table to identify which route should be used for next-day delivery.
Job done? Not quite.
To be continued…
(Part 3 of 6) My SAP client wants to determine a reliable delivery date for an order confirmation. One vital factor is the cut-off time for same-day delivery.
If the order is received too late, the goods will only arrive the next day.
This means that you need to define the cut-off time for same-day delivery and compare this against the current local time. If the order is received too late, then re-determine a new route that ensures next-day delivery.
There is this theoretical opportunity to solve this puzzle by simulating the condition technique:
Just treat the cut-off time for same-day delivery as your condition type. Then three condition tables can be identified to handle various business cases:
• Shipping point, ordering customer and forwarding agent.
• Shipping point, ordering customer and shipping condition.
• Shipping point, destination country, destination transportation zone and shipping condition.
Finally, the access sequence will order these business cases from “most specific” to “most generic”.
Although the condition technique is a well-known methodology within SAP ECC, it is not available for reassigning a new route.
This fact suggests that you need to simulate the condition technique. And the only obvious method is to revert to code. But, that seems quite a time consuming and expensive way to solve a relatively simple problem. So, what do you do?
You start with building custom tables to match the condition tables. Then you need to arrange the sequence, which is best served by having another custom table to control this sequence. Finally, you need to simulate the condition technique through code.
All of this sounds fine, but there is something that worries me: The current business requirements are not written in stone. They could change at the last minute. So it makes sense to assume that requirements will change and often at the least opportune moment. Therefore code needs to be easily adaptable.
And, wait, there is another hurdle.
During my presentation explaining my progress, one of the end users made an interesting comment: At the moment they maintain the parameters in a spreadsheet. The worksheet has each parameter as a column, along with a column stating the cut-off time for same-day delivery.
In my example, you would have seven columns in total:
1. Shipping point
2. Destination country
3. Destination transportation zone
4. Shipping condition
5. Ordering customer
6. Forwarding agent
7. Cut-off time for same-day delivery
When using the condition technique, you need to split them into three different worksheets. One worksheet per condition table, because each parameter must have a value. So when you need to use different condition tables, then you lose the total overview.
You could feel their sense of disappointment. My suggestion was to build a report offering the same overview as their current spreadsheet. But that failed to enthuse them. And I could not blame them. When you are used to maintaining master data in a spreadsheet, then you prefer to keep that capability.
It was no surprise when I received the request to find an alternative. In other words, the end users want to keep their precious spreadsheet.
It seemed that I would have to start from scratch to satisfy their desires.
To be continued…
(Part 4 of 6) Just when I thought I found a solution to handle the cut-off time for same-day delivery, a spanner was thrown in the works.
The SAP condition technique methodology seemed perfect as a basis to code the solution.: Just interpret the cut-off time for same-day delivery as a condition type;
Have several condition tables to capture the various business scenarios to determine the cut-off time;
Finally, code the sequence in which these condition tables are accessed.
But I was not able to convince end users that this was a great solution. Their main concern related to the maintenance of the master data in these condition tables. The end users maintained a spreadsheet that contained all parameters within one worksheet. SAP requires that the parameters in the condition tables must have a value, forcing several worksheets without a capability to provide a clear total overview.
Back to the drawing board for me. But I did not want to get rid of the core concept of the condition technique.
As always, such a challenge can be resolved in many different ways. Whatever I decided to do, I needed to anticipate that business requirements change. New parameters can be introduced or a sequence changed. And normally this would happen as a last minute change request. Somehow the chosen path had to be easily maintainable for the support organisation.
So, I resorted to diving into a Google search. Certainly I am not the only one trying to resolve this puzzle. After an hour I stumbled on a post that referred to “hierarchical access.” Instantly, the new ideas started to flow.
In a nutshell, “hierarchical access” merges various condition tables, allowing some key parameters to be blank. Then, specific configuration can decide in which order this merged condition table wcan be read. This condition technique functionality used to be available for pricing but was removed due to a lawsuit, as it was deemed to infringe on patents owned by an American company.
How can I simulate “hierarchical access”?
First I created one table containing all parameters along with the result data field:
1. Shipping point
2. Destination country
3. Destination transportation zone
4. Shipping condition
5. Ordering customer
6. Forwarding agent
7. Cut-off time for same-day delivery
Then I was able to make three additional table indexes to simulate how to access the table:
• Shipping point, ordering customer and forwarding agent.
• Shipping point, ordering customer and shipping condition.
• Shipping point, destination country, destination transportation zone and shipping condition.
Just apply the rule that a field not listed in the index is expected to be blank when reading the data.
A separate custom table ordering the table indexes should be sufficient to control the access sequence.
Even though it sounded feasible, I couldn’t escape the thought that it could all become very messy. Therefore I decided to ask my colleague for her feedback. I was not ready for the casual comment she made that changed everything.
To be continued…
(Part 5 of 6) Over the past days, I must have spent well over 40 hours analysing and discussing the business requirement, originally written on a post-it note that is still on my screen. It reads: “determine the cut-off time for same-day delivery”.
There was some progress made, because I knew that I could solve this business requirement by simulating the condition technique with hierarchical access. This approach was the closest I could come to the current way of working to define the cut-off time for same-day delivery. Now the end users use a spreadsheet in which all parameters are listed, along with the desired cut-off time. These parameters are not always required, so some worksheet cells were blank. And a blank cell signals that any value would be acceptable as it doesn’t influence the decision.
The complexity kicks in when you want to identify which rows in the spreadsheet have preference over others. Any solution that I analysed ended up being too complicated for a support organisation to maintain.
To my great surprise my colleague was not fazed by my quest. When I provided my notes, she just looked at them for a minute and asked whether she could play with this for a while. Of course I did not mind at all as she seemed genuinely delighted to take on the challenge, leaving me with the thought she already has a perfect solution in mind.
Just three hours later she asked me to visit her desk.
And I could not believe my eyes.
She asked for a sales order and item reference that would trigger next-day delivery. I gave her the data and then she just entered that on the screen and executed a simulation, immediately showing the route I was expecting for next-day delivery. Needless to say, I was stunned.
Whatever example I provided next, every time the result was as expected. She had solved my problem within three hours!
She told me that this was a free NetWeaver tool that is available in any SAP ECC system.
Then she asked me what I noted as the estimate to implement my approach to build my solution without NetWeaver.
Well, I guessed it would take a few days to write the functional specification. After it was approved for development, then a technical specification needed to be made. Of course, several days of coding and unit testing would be necessary. It would take at least 10 days!
She smiled and then said that her effort had saved our client a lot of money.
It is safe to assume the cost to the company would be €1,000 per day to pay for everyone involved in the management, design and development. Already five days had been spent on my analysis and I estimated it would take another 10 days for realisation. And so the price tag was €15,000.
She was able to solve my business requirement within a few hours. The NetWeaver tool can be considered as configuration. With just one press of a button all the required code is generated. No developer was required, no technical specification needs to be written and we have already tested this configuration successfully.
So the potential saving via NetWeaver would be at least €10,000!
This was by far the best demo I have seen in a long time. And I was eager to know which NetWeaver tool solved my problem.
To be continued…
(Part 6 of 6) This has been quite a journey. It started with just one sentence, scribbled on a post-it note: “determine the cut-off time for same-day delivery”.
As always, the original business requirements are more complex than initially thought. But they can be solved by simulating hierarchical access for the condition technique. My colleague showed me how to configure this easily, using standard SAP.
She revealed that the “Business Rule Framework plus” (BRF+) was used to solve my problem. It is a free tool and available for any SAP client using NetWeaver 7.0 enhancement pack 1, or higher.BRF+ allows you to design rule-based decision making. It is highly structured, as if you are instructing a robot to carry out specific actions only under specific circumstances. It has an excellent simulation capability, making it easy to validate cause and effect. As soon as the decision making meets the business requirements, then BRF+ generates the required code.
BRF+ allows you to design rule-based decision making. It is highly structured, as if you are instructing a robot to carry out specific actions only under specific circumstances. It has an excellent simulation capability, making it easy to validate cause and effect. As soon as the decision making meets the business requirements, then BRF+ generates the required code.
Needless to say, BRF+ is a great tool for agile development and the lead time for implementing changes is greatly reduced. You design the decision making process while you are gathering the business requirements. You can use the simulation capability to get the business sign off. Then the developer only needs to find the correct spot to execute the BRF+ functionality.
Imagine you have a toolbox in your garage. Within this box you collect a wide range of tools available for use across a wide range of functions. BRF+ is designed in a similar way. The “toolbox” is called an application and the “tools” are object types. You call BRF+ by asking the application to allow the object types to perform a specific function.
These BRF+ functions can be called within ABAP code, but it is also accessible via service-oriented architecture (SOA).
BRF+ is clever enough to suggest the code required to call a BRF+ function. This makes it a simple cut and paste job for developers.
When you create a BRF+ application, you must then decide whether changes need to be transported through the system landscape, or if you need to import the BRF+ application in each individual system via XML. This distinction is important when you want to control decision making via spreadsheets. In my example, you have the ordering customer and forwarding agent as parameters to make decisions. These customer and vendor numbers differ in your development, test and production environment. So it is advisable to create two BRF+ applications. One application contains all the framework for decision making that needs to be transported through the system landscape, while the other application loads the spreadsheets into decision tables, using data valid for that specific system.
In other words, one application contains the configuration, while the other contains the master data.
BRF+ also has authorisation capabilities. When you use a BRF+ application to maintain master data, you are able group decision tables into catalogues. You can then authorise users to maintain the master data assigned to a specific catalogue.
Any information, warning or error messages can be stored in the SAP application log, making it easy to report any issues found during decision making.
I am sure you understand that I am only scratching the surface of BRF+ capabilities. But at least you know that this is a great tool to solve complex problems.
In these blog posts we show you how to control the moment until same day delivery is still possible. But, I have built more sophisticated and complex solutions as well. I am convinced that BRF+ will be able to solve any of your challenges. Here are just a few ways:
• You can design BRF+ to ascertain whether a sales order is accurate and complete.
• Any complex pricing rules can be handled easily with BRF+.
• It is possible to determine the next available Mother AirWay Bill number for a specific forwarding agent.
• Complex vendor evaluation can be designed to support the procurement process.
• Data validation rules can be designed to support data migration. These rules can also be re-used afterwards for data governance.
The list is as endless as your imagination.
It would be exciting to know what obstacles you face at the moment. Imagine how thrilling it would be if I was able to quickly find you a solution via BRF+…