b2b2dot0’s View on SAP’s Shipping Information

Written May 18th, 2009 by
Categories: CEO's Blog
1 Comment »
VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Architecturally, our rule of thumb is that all business rules are
handled by SAP.  But like every rule worth it's name it has it's
exceptions. One of the bigger, if not biggest one, is our handling of
SAP's shipping information, or what we call the "Shipping View".

SAP's availability check of ordered items, with their requested
quantities and delivery dates, produces linked schedule lines.  These
schedule lines are copied later into delivery items. This copying is
not straight-forward and there can be differences in quantity and
dates, because the availability situation may have changed in between
order and delivery creation.

Let's look at an example:
On Apr 1 customer Jack
places an order for 100 hammers for Apr 5. The system confirms him 50
for Apr 5 and another 50 for Apr 20. If everything goes as
expected, this is the situation in SAP on Apr 5:

SAP order 123

order item 10: 100 PC for Apr 5


schedule lines for item 10:

Del.date    Qty

Apr 5       50


Apr 20      50

SAP delivery 456

delivery item 10: 50 PC for Apr 5

If you're used to SAP it's usually no problem to navigate back and
forth between these different documents. But it's definitely not
something you'd want to present to your customers. His main perspective
is to know about the ship status: did it ship already, or is it still
scheduled ? Or, worst of all cases, is it still pending when it should
have already shipped?

We therefore decided to combine
schedule lines and delivery items into a combined view that we call the
"Shipping View". Let's look at at the above example:
In the shipping view we display this on Apr 1:

Ship Status   Del.date   Qty

scheduled     4/5/2009    50


scheduled     4/20/2009   50

As part of the availability check, SAP did it's date determination
(based on your configuration): transit time is 2 days and 1 day is
required for picking. This means that on Apr 2 a delivery gets
created. Some clients let their customers know about this, others
don't. It all depends on the reliability of your shipping process, but
we recommend to be conservative and only change the status once it gets
shipped, because that's what your customers mostly care about.

So on Apr 2 it still looks like this:

Ship Status   Del.date   Qty

scheduled     4/5/2009    50


scheduled     4/20/2009   50

But we internally switch to the data from the delivery, assuming that
it is more reliable than the schedule line which got created a day
before.

On Apr 3 towards the evening this will be displayed:

Ship Status   Del.date   Qty   Del.Nr

shipped       4/5/2009    50   80123456


scheduled     4/20/2009   50

This was easy I hope. But it probably dawned on you that it is only
easy as long as the world is perfect. So let me explain some of our
exception handling.
Our main guiding principles are:
1. Don't display anything which is obviously wrong.
2. In case of inconsistencies between schedule lines and delivery
items, always rely on the delivery item, because it was created more
recently.

If the delivery is blocked for some reason and doesn't get shipped, we
display the status scheduled until Apr 5, assuming that you still have
a fighting chance to get it to your customer. But to display this on
Apr 6:

Ship Status   Del.date   Qty

scheduled     4/5/2009    50


scheduled     4/20/2009   50

would be an insult to Jack's intelligence.
We therefore display this:

Ship Status   Del.date   Qty

scheduled     4/20/2009   50


pending                   50

It's the best we can do based on the information in SAP.

The same applies to scheduled order items which weren't copied into deliveries. This will be displayed until Apr 20:

Ship Status   Del.date   Qty   Del.Nr

shipped       4/5/2009    50   80123456


scheduled     4/20/2009   50

but starting on Apr 21, we display this:

Ship Status   Del.date   Qty   Del.Nr

shipped       4/5/2009    50   80123456


pending                   50

This case happens less frequent because a lot of companies use a nightly rescheduling job, which ensures current dates.

This summarizes our basic approach. The logic works for most clients,
but there are so many different possibilities imaginable that there
probably still are additional scenarios that we will need to handle. 
But the good news is: it covers most cases already. And if you find
something that isn't displayed according to the listed rules or if you
think the rules should be different (e.g. you may want to switch to
"pending" if the goods issue date is in the past, not the delivery
date, or you may think that it is better to say "delivery delayed"
instead of "pending"), just tell us (and provide us an example) and
we'll see what we can do.

Adrian