How to Understand SAP’s Comments on the Issue with GR Processing Time

Executive Summary

  • SAP has provided support comments on the problem with the GR Processing Time not being respected.
  • We cover the issue with our view.

Introduction to the Issue of GR Processing Time

There is an issue with how SAP does not respect the GR Processing Time. In this article, you will read about our analysis of SAP’s recommendation on this issue.

Our References for This Article

If you want to see our references for this article and other related Brightwork articles, see this link.

Notice of Lack of Financial Bias: We have no financial ties to SAP or any other entity mentioned in this article.

  • This is published by a research entity, not some lowbrow entity that is part of the SAP ecosystem. 
  • Second, no one paid for this article to be written, and it is not pretending to inform you while being rigged to sell you software or consulting services. Unlike nearly every other article you will find from Google on this topic, it has had no input from any company's marketing or sales department. As you are reading this article, consider how rare this is. The vast majority of information on the Internet on SAP is provided by SAP, which is filled with false claims and sleazy consulting companies and SAP consultants who will tell any lie for personal benefit. Furthermore, SAP pays off all IT analysts -- who have the same concern for accuracy as SAP. Not one of these entities will disclose their pro-SAP financial bias to their readers. 

SAP’s View on the Issue

SAP proposes the following calculation for why the dates work out the way they do:

Start Date and Start Time is 14.10.2011 00:00:00

14.10.2011 00:00:00 + 100 Hrs = End Time and End Time is 18.10.2011 04:00:01

Here end date and available date are the same in the detailed view of the planning
book, whereas it should not be.

  • End date should be 17.10.2011 04:00.00
  • The available date should be 18.10.2011 04.00.01

The end date of the order contains all activities related to transport, which are GI, Transport, and GR, which add up to 100 hours in total in your case.

“So if the order starts on 14.10.2011, the end date is 18.10.2011 04:00:00 and that is the way it should work.” – SAP Support

SAP’s View on the GR Processing Date and the Transportation Bucket Offset

“The GR plays no role for the availability date.” – SAP Support

“To influence the availability date of the order in the bucket you have to use the bucket offset, when using the SNP-optimization. Depending on the bucket offset, you can shift the availability date until the end of the current bucket.” – SAP Support

My Comments

Contrary to SAP’s comment, the GR Processing Time does enter into the calculation for the availability time when the system works as designed.

Reasons for This Conclusion

There are several reasons for this conclusion. These include the following reasons.

SAP’s Help Documentation States that it Does. Its Definition of the GR Processing Time is:

The time between the delivery or the production of a product and its availability in stock. This time is used, for example, as handling time or time for quality checks, and is added to the transportation duration or the production time of a product. – SAP Help

In the Documentation, SAP Provides an Example of the Math:

Transportation duration/production time: 3 days, Goods Receipt Processing Time 1 day. 3 days + 1 day = 4 days, therefore the product is available on the fifth day. – SAP Help

We have Previous Screenshots and Extracts that Show that Previously the GR Processing Time did Adjust the Availability Day

There is a logical problem with this response. The concept of having both a GI and GR Processing Time is that they are assigned to the product location. This allows the GI and GR Processing time to be adjusted independently of the Transportation Lane. Without this, every product shipping on a Transportation Lane would have to have the same GR and GI time, as they would have to be assigned one way or another to the Transportation Lane and not to the product location.

Alternate Solution

Another solution would be to keep the Bucket Offset at its present value but lengthen the Transportation Duration on the Transportation Lane.

transportation-lane-1

A more flexible and lower-risk way of adjusting recognizing the GR Processing Time rather than changing the Bucket Offset is to add the GR Processing Time into the Transportation Duration.

It will certainly work and brings none of the testing issues and complexity required for changing the Bucket Offset. However, it limits all products on Transportation Lanes to only one GR Processing Time (although it is true that CCR does have many similar GR Processing Times). It is not a very good solution but appears superior to what SAP is recommending.

Examples of GR Processing Not Being Respected

gr-processing-test

Quotations from SAP Help on how the GR Processing Time Works:

When creating a planned order, you can instruct the system to take the goods receipt processing time into account during scheduling (that is, the goods receipt processing time you defined in the product master for the product being planned). The goods receipt processing time is added to the end time of the activity on the last line resource. This then gives the end time (availability date) of the planned order. – https://help.sap.com/saphelp_em70/helpdata/en/ff/adcf3d2691f30fe10000000a114084/content.htm

As noted above, the use of GR Processing Time for Planned Orders can be set (to be used or not used) in the Maintain Global SNP Settings screen. As can be seen below, the use of GR Processing Time for Planned Orders is activated.

global-snp-settings

However, there is not a similar setting for Purchase Req.

It is also documented that a BADI can disable the calculation of GR Processing Time. However, it is not a very relevant line of inquiry; this would only be important if that BADI had been, in fact, implemented.

“It affects the availability. If you order with delivery date May 10, and you have 3 days GR processing time (for quality control and putaway) then the material will becomes available on May 13.” – https://help.sap.com/saphelp_scm50/helpdata/en/82/5f517f0c174fb0b482c0a7190552fd/content.htm

(This quote is not from SAP but a comment on the SAP Developer Network site.)

Previous Screen Shot Example of the GR Processing Time Being Considered by SNP

The GR Processing Time is currently enabled in SNP. This can be enabled or disabled in the SNP Global Settings. Although according to the SAP documentation, GR Processing Time cannot be disabled for STOs.

This shows a clear one day difference between the Delivery Date and the Availability Date. This screenshot is from the past. Currently, the system shows no difference between the Delivery Date and the Availability Date, as can be seen from the screenshot below.

SAP Recommendation

Please be informed that the bucket offset from the transportation lane overrules the bucket offset from the optimization profile, so you should adjust the bucket offset in the lane in the means of transport. Currently it is ‘1’. That means, all orders with an end date inside a day will be available on the same date. If you maintain it to ‘0.5’, an order with end date at 16:00:00 will be available the next day, while an order with end date 04:00:00 will be available the same day. So if you want to move the availability date over to the next day, you should set the bucket offset to zero in the transportation lane. – SAP Support

Conclusion

We have to follow up on any lead to attempt to resolve this issue. However, some areas of evidence contradict what SAP is recommending. Essentially, SAP tells my client that the optimizer does not respect the GR Processing Time and that the real adjustment for the GR Processing Time is in the Transportation Lane Bucket Offset.

A significant amount of information contradicts this recommendation and explanation by SAP of how the GR Processing Time works. As for the recommended solution, we can easily and with less risk increase the Transportation Duration by the GR Processing Time. That would be my recommendation.

It also makes sense to go back to SAP to ask for another response because while this adjustment could be made quickly with minimal testing, it is not a good long-term solution.