Business process step 9: Carry out warehouse processing .1 Description

There are several ways to carry out warehouse processing with SAP for Retail:

With EWM, the extended warehouse management solution With a third-party warehouse management solution With Lean WM inside SAP for Retail

With LES-WM implemented on SAP for Retail or as a satellite system

For all process variants where the core warehouse processes are executed on a separate system, the interface is more or less the same. Within SAP for Retail, outbound deliveries are created as explained in the preceding chapter. These deliveries are then replicated to an external system, where the logistic processes are carried out. Once they are finished, the deliveries are confirmed in the WM system and confirmed to the SAP for Retail system where the delivered quantities are updated. Based on these updates, the goods issues in the DC are posted. This process flow is shown in Figure 19.

Figure 19: Business process step 9 – Process flow

2.2.5.2 Monitoring requirements

The monitoring requirements and the adequate monitoring tool vary depending on the warehouse management solution chosen. For the examples given above, the monitoring requirements are as follows.

For EWM, the extended warehouse management solution

Deliveries are replicated based on changes using the ALE distribution model. Between SAP for Retail and the EWM solution, qRFCs are used to replicate the deliveries. From SAP for Retail to EWM, the function module to do this replication is called “/SCWM/OUTB_DLV_SAVEREPLICA”. In order to confirm quantities from the distributed delivery, use the function module BAPI_OUTB_DELIVERY_CONFIRM_DECENTRAL.

For monitoring queues, use transaction SMQ1/2. For details, refer to the Interface Monitoring with SAP Solution Manger guide available at http://service.sap.com/bpm. Also, the usual backlog and performance monitoring requirements are described there. For the monitoring of the EWM processes, a dedicated document will be made available underhttp://service.sap.com/solutionmanagerbp.

For third-party decentralized warehouse management solution

Deliveries are usually replicated using IDocs. Between SAP for Retail and the warehouse management system, the SHP_OBDLV_SAVE_REPLICA05 iDoc is used. Deliveries are confirmed with the IDoc SHP_OBDLV_CONFIRM_DECENTRAL04. For this process variant, the IDoc status needs to be followed.

With other third-party warehouse management solution

Deliveries can also be replicated using DELVRY05 IDocs. From SAP for Retail to the warehouse management system, IDoc DELVRY05 is used to send the delivery details. Deliveries are then processed by the external WM solution and changes to the deliveries are again confirmed with IDoc DELVRY05 as an inbound IDoc. For this process variant, the IDoc statuses need to be followed.

For Lean WM inside SAP for Retail

The monitoring requirements are listed in the following chapters.

For LES-WM implemented on SAP for Retail or as a satellite system

If LES-WM is implemented on SAP for Retail, the process steps and the monitoring tools of the Lean WM scenario apply. For the usage of a satellite system, the monitoring requirements equal those of a third-party connection.

2.2.5.3 Create transport orders

When using Lean WM, stock transport orders are created with reference to the outbound deliveries using transaction VL06P (program WS_MONITOR_OUTB_DEL_PICK).

Scenario-specific sample

In order to initiate the goods issue processing, stock transport orders are created for the deliveries created in the previous step.

2.2.5.4 Monitoring requirements Error monitoring

After this process step, all deliveries due for picking should be updated with a current status (see below).

Performance monitoring

Depending on the amount of data to be processed and the time frame restrictions, the processing needs to finish within a given time frame.

Throughput monitoring

The throughput needs to respond to the time frame restrictions. You can analyze the amount of data to be processed by selecting deliveries due for picking.

Backlog monitoring

The amount of deliveries still due for picking after the job has been executed indicates a backlog.

2.2.5.5 Monitoring objects

Monitoring Object

Selection Criteria Alert Analysis Tool

on Satellite System

Monitoring Frequency / Data Collection Job runtime S_DE_R_WS_OUTB_DEL_PICK

_D_DEL1

Start delay, maximum duration

SM37 Every 5 minutes

during every job execution Job status S_DE_R_WS_OUTB_DEL_PICK

_D_DEL1

Job cancelation SM37

Table 7: Business process step 9 – Monitoring objects

2.2.5.6 How to find meaningful thresholds per monitoring object

The thresholds for throughput and processing time depend on the project requirements.

2.2.5.7 Error handling per monitoring object

When it comes to monitoring the results, you can check the line items of the outbound deliveries.

Figure 20: Business process step 9 – Error handling per monitoring object 1

If the business process requires that transport orders are created, then the WM status field in the delivery line item is set to A when a corresponding transport order line item is generated.

If the business process does not require transport orders to be generated, the WM status field is blank.

Figure 21: Business process step 9 – Error handling per monitoring object 2

The WM status field has four different possible values:

<blank>: not relevant A: Not yet processed B: Partially processed C: Completely processed

However, the Pick.stat field is always updated, regardless of whether transport orders are compulsory or not.

The four possible values of this field are:

<blank>: not relevant A: Not yet processed B: Partially processed C: Completely processed

Due to the high volumes normally involved, checking the status of each delivery line item individually is not practical. In this case, you can check table VBUP. Whenever a transport order for an outbound delivery is created for warehouse management, the field LVSTA has the value A. Similarly, the field VBUP-KOSTA for the pick status is updated whenever the goods have been picked and moved to the shipping point.

In addition to the status in table VBUP, you can use transaction SLG1 (program SBAL_DISPLAY) to check application logs for possible entries.

2.2.5.8 Scheduling of background jobs

Note that VL06P has no built-in parallel processing option. If parallel processing is required, you need a custom program to pre-select the deliveries due for picking, use the delivery document numbers to populate variants of VL06P dynamically and to kick off parallel batch jobs.

Table 8: Business process step 9 – Job scheduling requirements

2.2.6 Business process step 10: Post goods issues in warehouse