Inbound Delivery VL31N versus Expected Goods Receipt /N/SPE/GRE

INTRODUCTION:

 

The following can be considered as a simple inbound process scenario:

Creating a Purchase Order > Creating an inbound delivery > Distributing it to the EWM system > Posting Goods Receipt > Put away

 

The transaction codes used in the ERP system are:

ME21N: Creating a Purchase Order. (Fill in the required master data - vendor, materials, tax code and ensure to select "Inbound delivery" as the confirmation control)

VL31N: Create an inbound delivery from this PO.

VL06ID: Distribute the inbound delivery to the EWM system.

This leads to the message DELVIERY_REPLICA being sent to the EWM system.

VL06ID is required only when the customization is set to "Stop distribution" instead of "Distribution controlled by Warehouse" which results in automatic distribution to the EWM system. This customization is found under the following IMG path:

 Display IMG > Logistics Execution > Shipping > Define Delivery Types:

  

Select the delivery type and change the distribution mode accordingly.

If the distribution mode is set to "Stop Distribution", on saving the delivery, the field "Dec. Warehouse" will have value 'D' (planned for distribution). Otherwise, it will have value 'B' (distributed).

 

In the EWM system, the transaction code used to view the distributed delivery is:

/N/SCWM/PRDI: To maintain inbound deliveries distributed from the ERP system. Here, one can post the goods receipt and then create and confirm warehouse tasks from the menu.

Once these activities are completed, the delivery completion flag will be set to X and this will be communicated to the ERP system via a message queue. Goods reversal will no longer be possible now. It can only be done by creating a returns delivery.

 

Ensure to enter the correct Warehouse number in the EWM system (in transaction /SCWM/PRDI) that corresponds to the Warehouse in the ERP system in order to find the inbound delivery.

To find the correct warehouse in the EWM system given just the warehouse number in the ERP system (VL33N > delivery header > Stock placement tab) is done by viewing the table /SCWM/TMAPWHNUM in SE16 in the EWM system. This table maintains the mapping between the two warehouses - ERP and EWM warehouses.

 

Important Tables:

EKKO: PO Header

EKPO: PO Item

 

The table EKES is a linkage between the Purchase order and the inbound delivery created - EKES-EBELN is the PO number and EKES-VBELN is the Delivery number.

The linkage between the Material Documents and inbound deliveries can be found in table VRSLI. VRSLI-AUFNR is the Order number which can be used to find the delivery linked to it.

 

STOPPING AND STARTING THE QUEUE:

 

Stopping the queue is done to view its contents and for debugging. To stop queues in the EWM system, set the parameter /SPE/IF_DEBUG_QRFC with value 'X' in the ERP system by following the path: System -> User -> Own Data

 

To stop the queue in the ERP system the parameter /SCWM/IF_DEBUG_QRFC is set to 'X' in the EWM system.

(View KBA 754820 - Debug control of Q-RFCs between R/3 <=> EWM / CRM - for more details)

 

Starting the queue requires using the transaction SMQ2 (Inbound queue monitor) and finding the corresponding queue by searching with the original inbound delivery number.

Select the entry and click on the Execute LUW button or hit F8.

 

Related Function Modules (messages in queue):

• SAVE_REPLICA - Delivery creation message (Usually from ERP to EWM except in the case of Direct Outbound Deliveries)
• CONFIRM_DEC - Goods Receipt message; also for setting close indicator
• GOODSMVT_CREATE - GM status change (Posting change)
• ME_CONFIRMATION_READ_AVIS - Reading PO at the time of delivery creation

 The transaction VL34N can be used to create inbound deliveries. It is a mass transaction and the processing is done in the background. 

 

ANOTHER INBOUND PROCESS SCENARIO:

 

Using the transaction code VL60:

 

The transaction VL60 allows partial goods receipt and to reverse goods receipt partially. It directly distributes the delivery to the EWM system after saving the delivery.

In addition, it allows changing a delivery after distribution, provided no changes have been made in the EWM system yet. When such changes are made in the inbound delivery, the message DELIVERY_REPLACE is sent to the EWM system instead.

A temporary delivery, containing the new data will be created when this is done. It is linked to the original delivery in the table /SPE/INB_ID_LINK.

It also allows the recording of timestamps.

 

In addition, when an inbound delivery is created in the EWM system, it invokes the transaction VL60 in the ERP system.

 

Once a delivery is created and distributed using VL60, the rest of the process is similar.

In the EWM system, create and confirm the warehouse task.

It is possible to change the quantity before confirming the warehouse task, in which case the user switches to form view, enters the exception code "DIFD" and the quantity difference. The system automatically calculates the actual quantity. Now confirming the warehouse task posts a quantity difference and hence a partial goods receipt.

 

CHANGING QUANTITY IN THE EWM SYSTEM: 

 

Use the transaction /N/SCWM/PRDI to view the inbound delivery distributed from the ERP system. Under the "Process Codes" tab pick "With quantity adjustment - I001 Vendor" for change in quantity, then change the quantity and save.

The change will be communicated to the ERP system only once the Goods Receipt is posted.

 

For split delivery creation select the process code "I002" and enter the quantity (negative for splitting) and save.

To view the split delivery click on "Inbound Delivery Notification" and then on "Inbound Delivery".

Two deliveries will be seen -

The first is the original delivery, containing the new reduced quantity.

The second is the split delivery with the quantity entered in the process code (x-). 

 

The split delivery process does not need PGR to take effect like the quantity change process does.

 

A positive stock increase is indicated by a '+' in the document flow (eg: Movement type: 101 +).

 

A list of material documents corresponding to a particular material can be found in the transaction MB51.

An important table in this regard is MKPF which is the Material Documents Header table - to find data on the header level of any material document.

From this table, we can find the linkage to the delivery (field MKPF-LE_VBELN) and the number of the material document on the EWM system (field MKPF-SPE_MDNUM_EWM).

Material document item table is MSEG. 

 

NOTE: 

Since S/4HANA 1709 with embedded EWM, Process Code I002 works as I001, i.e. no new PDI and no PPF is generated when inbound delivery split is done.
SAP Note 2494704 - SAP S/4HANA 1709: Release information and restrictions for EWM in SAP S/4HANA - contains the following information:
 •Elimination of inbound delivery notifications. Embedded EWM directly creates warehouse requests for inbound deliveries. 

 

SERIALIZED MATERIALS:

 

Serialization of materials is a way of keeping track of individual items.

Thus if the quantity of a particular material in a delivery is 2, there will be a unique serial number for each item of that material.

Any material that has a non-blank value for the field MARC-SERNP is a serialized material.

View the material in the transaction MM03 - stores material master.

The serial number profile of a serialized material can be found by selecting the view: "Sales: General/Plant Data" for that material.

 

There are 2 ways of assigning serial numbers to materials:

1. At the item level: In the delivery, select the item, go to Extras > Serial numbers. For inbound deliveries, serial numbers can be created through goods receipt - the serial numbers are either copied from the Purchase Order (for higher releases) or are created on selecting the material - Extras - Serial number for items: Create automatically. Once saved and distributed, the serial numbers will appear in the Serial Numbers tab in the EWM system. Posting GR will create a material document in the ERP system and the serial numbers can be viewed by clicking on Go To > Serial Number. 
   
   
2. At the HU level: In the delivery, click on "Pack" and create the required number of packaging materials and pack the materials. In the detailed screen, go to the "Cont.s" (Contents) tab, select the HU and click on the push button "serial number". Upon distribution of the delivery to the EWM system, the serial number can be seen in the packaging screen (Follow-on-functions) of the inbound delivery. Go to the packed item, and click on the serial number tab. New serial numbers can be assigned to the materials in the EWM system as well if the materials do not have them yet. But this will not lead to any message being sent to the ERP system.

 

Packing can be done in the EWM system as well, where the quantity and HUs can be managed by clicking on Inbound Delivery > Follow-on-functions > Pack.

Saving now will produce no messages to the ERP system, only posting goods receipt will send the message to the ERP system.

 

Associated Function Modules:

FM to delete the serial numbers: DELETE_SERNR_LS 

FM to add serial numbers: SERNR_ADD_TO_LS

When the goods receipt is posted, the serial numbers are copied from the delivery to the material document and this is done in the FM: SERIAL_COPY_LS_MM

 

The number of serial numbers assigned to a delivery is stored in LIPS-ANZSN and the serial number profile is stored in LIPS-SERAIL.

The table storing the linkage between the delivery and the serial number key is SER01 - Serial number key is stored in the field SER01-OBKNR.

And the main table holding the serial numbers assigned is OBJK, where the serial numbers assigned to that delivery can be found using this key OBJK-OBKNR. 

 

PRODUCTION PLANNING - EWM INTEGRATION:

 

A production order is an order created internally in a company to produce a certain quantity of a specific material.

The transaction code used to create a production order is CO01.

LPK3 is a transaction code used to display the control cycle for WM.

Here, the source and the staged destination storage locations can be seen.

 

Scenario:

 

Create a production order: Fill in the dates.

Component overview: Shows the finished product and all the raw materials (components) used in the process of its production.

Saving this production order calls the GN_DELIVERY_CREATE FM and an outbound delivery (also called staging delivery) is created (as the product is moved from one storage location to the production supply area, where the raw material is moved).

 

If the Warehouse is the same but the storage locations are different, it is a posting change process. Whereas if the Warehouses were different as well, it would be an outbound process.

 

After the distribution of this outbound delivery to the EWM system, viewing it in the EWM system is done using the transaction /SCWM/IM_PC.

Here, a warehouse task can be created and confirmed. The GM status will be completed now.

 

The document flow of the outbound delivery in the ERP system will show a transfer posting indicating movement from one Storage Location to another.

 

The transaction code to confirm the production order is CO15.

The field "Yield t/b conf." is used to report how much of the material has been produced so far.

 

The VRSLI table also links the production order and the two deliveries created - the inbound delivery for the completed product as well as the consumption delivery.

 

Both these deliveries can be found in the EWM system. 

 

For the inbound delivery, you can post GR and perform the put-away.

The consumption delivery (found using the transaction /SCWM/PRDO) will have GI automatically completed.

 

During the creation of a production order, while debugging, the buffer table (saplcobc)resb_bt with fields PRVBE (Production supply area) and BERKZ (set to 1 on saving the Production order) can be viewed.

 

Once the production order is released, the material staging is triggered in the background and as a result, the staging delivery is created.

This is controlled by the Production Scheduling profile.

If the staging delivery isn't getting created upon release of the production order, check if the value of the field "Transfer order and Delivery upon Rel." is 2.

The path to check this is:

Transaction SPRO: Display IMG > Production > Shop Floor Control > Master Data > Define Production Scheduling Profile.

 

It is also possible to manually trigger the material staging by clicking on the pushbutton "Functions" > WM Material Staging > Execute.

 

The main class for the staging delivery process is /SPE/CL_EWM_STAGING_INTF and two important methods are EXECUTE_PICK_PARTS and the POST_PICK_PARTS (which is called shortly before the saving of the production order).

 

At the end of the EXECUTE_PICK_PARTS, the buffer table (saplcobc)resb_bt is populated.

 

Displaying the PP confirmation shows on the right side the delivery number linked to that PP confirmation.

 

A component with the "Backflush" flag set implies that the system will consume the component automatically and therefore this component will also automatically be proposed in the confirmation of the production order.

For any components without this flag set, the consumption will be done manually and it will not appear in the confirmation of the production order screen.

 

In the screen "Display confirmation of production order", the delivery linked with the confirmation can be found by scrolling to the far right. 

 

TABLES:

 

AFRU: Confirmation table - AUFNR is the confirmation number.

From the AFRU table, obtain the confirmation key (AFRU-RUECK) and use it to view the delivery in the table AFWD (Deliveries for confirmation Goods Movement in EWM).

 

Once the confirmation is done, the warehouse tasks must be created and confirmed in the EWM system - Post the GR and perform the Put-away for the inbound delivery.

 

Now if the AFWD table is refreshed, the field GMSUC (Goods Movement SUCcessful) field will be set for the inbound delivery.

In case of any errors occurring in the process, the ERROR field will be set.

 

On displaying the production order confirmation again, the link between the inbound delivery and the production order will be removed and the "Delivery" field on the far right will be blank as the Goods Receipt has been done.

 

However, the linkage to the material documents can be viewed through the table AFWI by using the confirmation key RUECK and AFWI-MBLNR is the associated material document.

 

Similarly, for the consumption delivery, after the distribution to the EWM system, the GI will be automatically completed and on refreshing the AFWD table, the GMSUC field will be set for the consumption delivery as well. On refreshing AFWI, a new entry with the material document for the GI of the consumption delivery can be seen for the same confirmation key.

 

For components that do not have the Backflush flag set, the Goods Issue of the consumption delivery must be done manually and for this, the IM-transaction MIGO can be used. Posting the GI here will lead to the creation of a delivery instead of a material document.

The rest of the process is the same as for the components with the Backflush flag set. 

 

KANBAN PROCESS:

 

PK13N is the transaction code used to view the Kanban board, i.e. a demand-source view.

 

The UI shows storage bins.

 

Setting the Kanban status to empty for any of the bins causes a delivery to be created as the consumption of the bin contents must be done.

And since the contents of this bin are used up and the bin is empty, it requires a replenishment delivery.

 

This is the same scenario as that of the material staging of a production order.

 

RETURNS PROCESS:

 

A returns process occurs when the customer returns goods either fully or partially. It begins once the Purchase Order and Inbound delivery for it are created.

 

The following can be considered as a simple returns process:

Create a PO in ME21N.

Create an Inbound delivery for this PO.

It will automatically be distributed to the EWM system where the GR and put-away can be done.

 

On viewing the PO history now in the ERP system, we can see the quantity reduced is the quantity that has been GR posted and the Material document has been created.

 

Now the returns process can be started.

This returns process will be an unplanned returns process since the material document for the GR is available.

 

The Returns delivery can be created using the transaction code MBRL.

Using MBRL, you do not create a new PO but return the delivery from the material document directly.

Enter the material document number here and check the checkbox for "Create Delivery".

(Standard Movement type for returns process is 122).

 

Use the outbound delivery transaction VL03N to view the created returns delivery.

The delivery type is RLL and the item category is RLLN. It will be distributed to the EWM system.

 

In the EWM system, use transaction /SCWM/PRDO to view the returns delivery and here the picking and Goods Issue processes are completed.

 

In the ERP system, as the returns delivery is linked to the same Purchase Order, the PO history tab will show the material document after posting the GI and the open quantity will be updated. 

 

A planned returns process requires creating a Purchase Order with a "returns" flag (EKPO-RETPO) set. The flag will be found as a field along the item overview for that line item.

This action grays out the confirmation control key as it is not required.

 

Now, a returns delivery must be created and this can be done in VL10B - by entering the Purchase Order number and clicking on execute.

Select the entry and create a delivery in the background by clicking on the "Background" button.

To view the newly created delivery, select the new entry and click on "Log for delivery creation". From here, the documents created can be viewed by clicking on the "Documents" pushbutton. Clicking on "Display Documents" is equivalent to running VL03N transaction and the returns delivery is displayed. The delivery type is RL and not RLL and the item category is RLN and not RLLN to differentiate the two types of returns processes.

The plant returns process has movement type 161.

The PO history also shows this.

 

EXPECTED GOODS RECEIPT:

 

It is a feature in the EWM system that allows the creation of a Goods Receipt without a delivery creation message sent from the ERP system.

 

Here is a simple process demonstrating the EGR functionality:

In the ERP system, create a Purchase Order and save it.

Enter the transaction /N/SPE/EGR - Expected GR - this triggers a report in the ERP system to create EGR.

Enter the Warehouse number and the Purchasing document number.

Select "Create Expected Goods Receipts".

Two sections exist for creating EGR - Creating from a Purchase Order or from a Production Order.

Thus if a Production order were used - Enter the Production Order number.

Change the end date to a later date than that of the PO or else it will not be selected.

(Deselect whichever activation isn't required - in case a Purchase Order is being used, deselect Production Order Activation).

 

Run the report in test mode.

As the creation of a delivery is involved, GN_DELIVERY_CREATE is triggered.

EGR document reflects in an inbound delivery creation.

 

Error logs: Number of error-free docs is 1. (If the number is zero, check if the Confirmation Control is set to Inbound delivery, without which the PO will not be found.)

This EGR document is created only in the EWM system. There is no creation in the ERP system. The data is passed to the EWM system wherein the EGR document is created.

 

Uncheck the run in "test mode" checkbox and run it a second time.

This leads to a dispatched message.

 

In the EWM system, the queue will be found with the Purchase Order number since no delivery was created for this Purchase Order.

The process looks similar to a distribution but an Inbound delivery hasn't been created in the ERP system.

 

To view the EGR document use the transaction code /N/SCWM/GRPE: GR Preparation: External Procurement (Warehouse No. XXXX)

Check the flag "Without TU".

Enter the PO number.

Execute.

 

The EGR document created appears.

These EGRs are temporary and exist in the EWM system. They are used to create inbound deliveries in the EWM system.

 

In order to create the corresponding delivery, one doesn't have to switch back to the ERP system again.

In the EWM system, drag and drop the entry into the Search Results tab.

 

External delivery number: Enter the required ASN.

Change the quantity if required. For instance, out of 10 pieces, if only 1 arrives, then the quantity in the EGR document is 1.

 

An Inbound Delivery is then created in the EWM system. It has the external delivery number: To find it, scroll to the field "ERP Document".

The user in the EWM system has created a new Inbound Delivery and this has been communicated to the ERP system.

Click on Save.

 

In the ERP system, use the transaction /NSMQ2 and select the row. 

The SAVE_REPLICA message is now in the opposite direction. (Delivery from the EWM to the ERP system)

Display the inbound delivery in VL33N.

Check the predecessor data tab, it will contain the PO number.

 

The same process can be done for a production order.

 

In the update and delete EGR process, we trigger a report in the EWM system.

 

/N/SCWM/ERP_EGR_DELETE: Transaction triggers an EWM report to delete the EGR Document in the EWM system.

 

Running this with the PO number and selecting the "Delete only" radio button causes the EGR to be deleted as is seen in the EWM system using the TCODE /N/SCWM/GRPE and entering the PO number deletes the EGR. The original inbound delivery is retained.
 

Changes in the purchase orders lead to an update in the existing EGRs once /SPE/EGR is re-run.

 

In the EWM system, using the transaction code /N/SCWM/GRPE and checking "Without TU", select free interval for the selection time period.

Run the report and delete the EGR

The real Inbound delivery must still be there.

 

BATCH MANAGED MATERIALS:

 

Create an Inbound Delivery with respect to a Purchase Order containing a batch managed material.

There are two ways of splitting the batch split material - in the ERP system and in the EWM system.

In the ERP system - Perform the batch split in the Inbound Delivery creation step itself. 

 

To perform the batch split in the EWM system, i.e. only the batch main item is present in the Inbound delivery, save the created delivery and distribute it to EWM system.

 

In the EWM system, find and process the queue.

View the Inbound delivery in /SCWM/PRDI.

The indicator is locked (marked red) because we have to assign batches. 

To do this, click on Process codes > Create batch subitems. 

 

Scroll to the right, you will find the new batch split item(s) and the batch main item. 

Saving the document leads to an automatic communication to the ERP system.

 

In the ERP system, find and process the queue.

Use VL33N to view the delivery.

The Inbound delivery will have the batch main item that can be expanded - Expand the batch (+ push button). Now, the two batch split items are seen.

 

While debugging, note the table XLIPS:

UECHA - x(number of) batch split items from the main item.

LFIMG - Quantity in SU of Measure

LGMNG - Quantity in Base Unit of Measure

KCMENG - filled on the main item level: it indicates the sum of the delivery quantities of the batch split items.

 

Quantity for the main item will be seen as 0 if it has been split fully among the split items.

 

Displaying the material document will show the batch split items as having different material documents. There will be no zero quantity entry in the material document.

 

Inbound Delivery display shows the Status overview: GM is 'B' - Partially completed.

 

Displaying the Purchase order shows the main item is split to different lines as well.

 

In the EWM system, confirm the Warehouse Tasks together for the two line items.

 

Now the Status shows completed as the close indicator has been sent to the ERP system. It is no longer possible to reverse the delivery - The only alternative is to create a returns delivery.

 

Thus the ERP system will have 2 queues in SMQ2 - On for the posting change and one for the close indicator.

 

Checking the Inbound Delivery now in VL33N. It shows Status 'C' for all items and the Goods movement data tab shows the close indicator has been set. 

 

STOCK TRANSPORT ORDER PROCESS: 

 

Consider the requirement of a particular material in a plant. This material can be brought into the plant by means of a simple inbound process wherein an Inbound delivery is created from a Purchase Order with the Vendor as the required external vendor.

A Stock Transport process involves an inbound process where the vendor is not an external vendor but a vendor with an assigned plant or even just a plant.

 

A stock transport process involves an issuing plant and a receiving plant. The Stock Transport Order (STO) is the initial document in this process. 

     

The STO process can be demonstrated in the following manner:

1. Create a Purchase Order: Enter the supplying plant and the receiving plant. In the item overview, under the shipping tab, you can see the delivery specific data - relevant to the replenishment delivery created from this STO. Based on this data, the replenishment delivery is created.
   
   
2. Create the replenishment delivery using transaction code VL10B - Enter the STO number and execute. This data is the same as the data in the table VETVG - Database index. Enter the value for VBELN as the STO number and execute. This entry is the same as shown in VL10B. Select the entry displayed in VL10B and click on Background. This creates a delivery in the background. Select the new entry and click on "Log for delivery creation" to view this delivery. Click on "Display document". Confirm the picking by entering the quantity picked and click on save. Now the picking status will be completed - 'C'. Post the Goods Issue for the replenishment delivery. Now the material document will show two lines: The first one posts the goods out of the first plant and the second line posts the goods into the receiving plant at the plant level. This stock is in transit and hasn't been moved to a storage location.
   
   
3. An Inbound delivery can be created for performing the Goods Receipt in the receiving plant. Or the IM-transaction MIGO can be used for posting the GR for the replenishment delivery. Thus using the transaction code MIGO, select Goods Receipt, enter the outbound delivery number and click on execute. In the quantity tab, we can change the quantity if the received quantity is different from the posted GR quantity. Select the checkbox "item ok" and click on save. This generates a new material document in the outbound delivery's document flow with the received quantity. A second GR can be posted in MIGO for the remaining quantity if any and this will generate a new material document with the corresponding quantity. The goods received come from the stock in transit of the receiving plant. All these documents can be seen in the PO history of the STO. This is a two-step STO process:  

                          

The Goods Receipt Cancellation is a similar process. Use the transaction MIGO, and instead of the movement type 101, use 102. Saving this will leave the GR quantity open again.

The Status of the replenishment delivery doesn't change - it shows the GI status. 

 

CROSS COMPANY PROCESS:

 

This time, use a Standard PO and enter a vendor in place of the supplying plant. This vendor will have a supplying plant. LFA1 is a central table for vendor data where the vendor name can be entered - LFA1-LIFNR.

The associated plant is LFA1-WERKS.

The receiving plant belongs to another company code. The company code entered at the organization level is the company code of the receiving plant.

Using the transaction VL10D (it is different from VL10B as it shows more data at the item level; VL10F shows data on a schedule item level) enter the PO number and create a delivery in the background and display the document. The delivery type of the replenishment delivery thus created is NLCC (Replenishment delivery Cross Company) as opposed to the delivery type of the replenishment delivery created using a two-step STO process, which is NL. The item category here is NLC, the previous method has NLN as the item category.

 

Perform the picking and Post the Goods Issue of the delivery.

 

As the company codes are different for the two plants, the material document of this delivery's Goods issue will contain only one line as it is equivalent to issuing goods to an external customer.

Perform the goods receipt of the outbound delivery using the transaction MIGO. 

 

Customizing for the STO process:

Display IMG > Materials Management > Purchasing > Purchase order > Define Shipping Data for Plants (It shows the sales area for a particular plant.)

 

Assign Document Type, One-Step Procedure, Under-delivery Tolerance allows the user to set for the supplying plant and receiving plant pair, a one-step procedure implying that the GR step is not done separately but as part of the GI step.

The movement type in the replenishment delivery then becomes 647 which is similar to 641 but automatically does the GR.

Thus the material document has 3 rows instead of two. 

At the end of an STO process, the delivery quantity must always be equal to the goods issued and to the total goods received quantity. 

 

GENERAL CUSTOMIZING: 

 

Inbound processing - Customizing:

Display IMG >  Logistics Execution > Service Parts Management > Extended Inbound Delivery Processing (SPM) 

 

 

Define different profiles - for instance how the deliveries should be selected: 

 

 

Integrating the ERP system with the EWM system: 

 

Maintain Extended WM-Specific Parameters: shows the means of communication between the ERP and the EWM system - through Queued and serialized asynchronous RFC.

 

Configuration of EWM communication via Queues: 

 

Setting the Queue type to Inbound queue will stop the queues on the inbound side and thus the transaction SMQ2 must be used to view the stopped queues.

 

Customizing distribution model from ERP to EWM: 

 

This lets the ERP system know, based on a model, what the target system is and which FM must be called for that particular queue.

 

SLG1 - Application log customization:

Path: Logistics Execution > Service Parts Management > Integration SPM with other components > Log Sent and Received Messages 

 

The setting to both "Log success + error messages" leads to all messages being logged and this is the suggested customizing as it shows the complete picture of the communication between the two systems.

The SLG1 log can be used to analyze the messages sent from that system at any time. It allows opening the queue container to view the contents of the queue as well. 

 

FUNCTION MODULES: 

 

Consider creating a delivery from an existing delivery using VL60:

Clicking on save calls the main program /SPE/CL_ID_HANDLING and the method called is SELECT.

The buffer tables have names beginning with "AT_" i.e. AT_LIPS and AT_LIKP.

 

Changing any data on the UI calls the Enrichment functionality: Program /SPE/CL_ASN_ENRICHMENT; Method: FILL_PREDECESSOR_DATA (data is being read from the predecessor - the PO to the delivery).

 

Classic Shipping functionality calls GM_DELIVERY_CREATE method in the program SAPLV50S each time a delivery creation is required.

 

Shortly before saving the delivery, the GN_DELIVERY_CREATE calls the method DLV_DISPATCH (responsible for the dispatching of messages to the EWM system) in program /SPE/CL_DLV_DISPATCH.

If the delivery is relevant for EWM distribution, the method SEND_TO_EWM within the program /SPE/CL_DLV_DISPATCH will be called.

 

The queue name is created with the delivery number in the method - EWM_QUEUE_SET_INT in program /SPE/CL_DISTRIBUTION.

 

Changing any data in the original delivery and saving causes the creation of a temporary delivery which is again distributed to the EWM system (the queue name still holds the original delivery number) and the FM called is not SAVEREPLICA but /SCWM/INB_DELIVERY_REPLACE.

 

If the EWM system accepts this change, it sends a response message to the ERP system - FM /SPE/INB_DELIVERY_RESPONSE in the program /SPE/SAPLINB_DELIVERY.

 

LS_VBKOK - Details about the Delivery Header

XT_VBPOK - Details about the delivery items.

 

In the EWM system, during the Put-away process, if the number of goods received is lesser than the GR posted quantity, this change can be made by clicking on "Switch to form view" after confirming in foreground.

In the form view, the destination difference quantity is entered as the difference in the original quantity and the quantity received.

The exception code is DIFD.

  

Function ME_CONFIRMATION_CHECK_QUANTITY checks the delivery quantity against the purchase order quantity.

The report /SCWM/R_MESSAGELOG_RESET is used for resending messages (missing/lost messages).