Overview

Goods receipt appointment is referred to the process of preplanning the inbound goods arrival related to purchase order, inbound delivery. With the help of appointment analysis, the deviation related to deliveries shall be identified and further course of action can be taken proactively.

Application

SAP IS Retail for Inventory movement

  - Lean Warehouse management

  - Centralized Warehouse management

Business advantages
- To plan material arrival effectively

- Optimize use of resources

- To analyze the variance

- To reduce the waiting time

- Better co-ordination with supplier, goods carrier and customer

Important point: If you refer to the purchase order for appointment creation then the corresponding purchase order should not have confirmation control like inbound delivery or a rough goods receipt.

Scenario (Without Variance)

PO is created without confirmation control (Inbound delivery). The required delivery date is mentioned in the purchase order. Please note, all items shall be created for the same plant and storage location. (In Retail site and storage location) and all schedule line shall have the same delivery date.

Carrier is maintained in the PO header level. (Optional)

After PO is getting created, go to Appointments: Process worklist (Transaction code: WAP1). Input the warehouse number and date range. Please note, the above mentioned steps are related to manual creation. Through SAP function module the appointments shall be created automatically.

On the output screen, input the door number (in case of manual creation), expected or planned time range and date.

you can overwrite the appointment time and default length of appointment time.

Once appointment is getting created, the same can be changed by using the transaction code WAP2. It will open the Gantt chart. On this, appointment date is indicated. In case, goods received the same is indicated in green colour. Here, you can edit the appointment schedule and even delete the worklist.

The appointments shall be monitored or viewed through the transaction code WAP4. In case goods receipt not happened for the particular procurement document, a red icon shall be displayed.

Goods receipt is done as per the delivery date mentioned in the purchase order.

By using the transaction code WAP4, the appointment data for actual goods receipt shall be entered. In case of automatic appointment update, a SAP standard function module shall be used.

Transaction code WAP3 shall be used to display the appointment. Green signal indicates goods receipt done and the appointment is completed.

Transaction code WAP7 is used to compare the planned and actual appointment data. Through customization a report can be triggered for the variance and further corrective action can be taken.

Scenario (With Variance)

PO is created without confirmation control (Inbound delivery). The required delivery date is mentioned in the purchase order. Please note, all items shall be created for the same plant and storage location. (In Retail site and storage location) and all schedule line shall have the same delivery date.

Goods receipt date is not inline with the delivery date mentioned in the purchase order.

The appointment overview is shows deviation and the reason code for the variance.

The report shows the deviation in the delivery date and it can be used for further analysis and leads to some corrective measures.

Configuration settings

Define control parameters and no ranges for warehouse number: (Optional)

Menu Path:

IMG-->Logistics Execution-->Shipping-->Picking-->Lean WM-->Define control parameters and no ranges for warehouse number

Lean wareshouse mangement is defined in the configuration by activating lean WM control parameter (Optional).

Appointment settings:

Maintain Appointment (Door Usage) Profile:

Menu Path:

IMG-->Materials Management-->Purchasing-->Purchase order-->Appointment (Door Usage)--> Maintain Appointment (Door Usage) Profile

Define a new profile, description as per requirement and mention the following parameters,

Appointment start time and end time (working time), minimum length of appointment time as well as default length of appointment time and possible business process during goods receipt. Also mention whether the appointment can be created without document reference like purchase order, etc.

Assignment of Profile to Warehouse Number:

Menu Path:

IMG-->Materials Management-->Purchasing-->Purchase order-->Appointment (Door Usage)--> Assignment of Profile to Warehouse Number

Here, assign the appointment profile created in the previous step to the warehouse number. Please note, more than one appointment profile can not be assigned to the warehouse.

Reasons for Date Variance:

Menu Path:

IMG-->Materials Management-->Purchasing-->Purchase order-->Appointment (Door Usage)--> Reasons for Date Variance

Define reason for delivery date variance for analysis and reporting purpose.

Define Doors:

Menu Path:

IMG-->Materials Management-->Purchasing-->Purchase order-->Goods Receiving Capacity Check-->Define Doors

Here, you define doors for warehouse structure. The doors could be any numbers. The key parameter is "GR indicator". It needs to be selected for appointment scenario. Without this setting, the appointment functionality will not work.

Conclusion

I believe, SAP MM/WM consultants would understand the appointment principle through the above procedure. Any suggestion towards improvement of this document is always welcome.

Author Bio

Mohamed Hasan Rifaie,  a SAP Certified Procurement consultant, is now an employee of Larsen & Toubro Infotech Ltd. He has overall 13 years of experience, out of 7 years in SAP Consulting (P2P, SRM, SCM & WM). He has business experience in various industries like Manufacturing, Electro mechanical Construction and process industries as a Procurement Executive.

Hi,

Before going to this document, I would suggest that reader must go through the well prepared and nicely explained document created by  Mr. Shankarappa H L (http://scn.sap.com/docs/DOC-45032).

This document is an extension of Basic process, so user may use it for processing a large no. of documents in mass rather than doing it one by one.

Requirement

In a Business, normally the requirement comes that User wants to create the Shipment Document and Shipment Cost Document for a large number of Delivery Documents simultaneously. It may be for a period (week or month), or for a Shipping Point(s), or may be based onsome other criteria. So there are two alternative for this (1) Use a Batch Process, and (2) Process the documents in Mass.

Here I will discuss the processing of Shipment Document and then Shipment Cost Document in mass, assuming that reader has gone through the document created by Mr. Shankarappa, so he knows the basic.

Process

For example I am taking three Deliveries at a time.

Step 1: Transaction - VT01N

          Select the Transportation Planning Point and Shipment Type.

          Then click on the Delivery push button.

Step 2: A selection screen for selecting the Deliveries, where user have different option to select the deliveries. As I mentioned, I am selecting the deliveries based on Delivery numbers (all the deliveries has same Forwarding Agent / Transporter).

          Execute by clicking the 'clock' or Press 'F8'.

Step 3: All the three deliveries will be selected for this Shipment Document.

Step 4: In Shipment Document, the Forwarding Agent is at Header Level, just like in Delivery it is Ship To Party. So it is easy to create one single Shipment Document for all the three deliveries since all has same Forwarding Agent,  And if the deliveries had different Forwarding Agent, system will create different Shipment Document.

In our case we have the same Forwarding Agent, as I mentioned earler, and we want to create separate Shipment Document for every Deliveries., so to do this select all the deliveries and then go to Edit --> Automatic Planning --> Shipment per Delivery.

Step 5: System will assign temporary Shipment Document nos. to each deliveries.

          SAVE the document, and system will create three different Shipment Documents.

We created the Shipment Documents, but in these shipment documents, the deadlines are still not filled. Without completing the Deadlines, system will not allow to create the Shipment Cost Document. You can check this by going to VT03N.

Step 6: Now we need to do this deadlines manually one by one by going to VT02N, and click the 'push button' from Planning to Shipment End, and system will fill the Execution dates accordingly and also pull the relevant data, like Forwarding Agent from Delivery.

However if you wish to do this in mass (only if you want to have same execution dates for all the  Documents) then use the transaction code VT06.

          Execute.

Step 7: This transaction gives you option for doing the changes in Shipment Document in mass for different activities like changing the Plan Dates, Forwarding Agents, Shipping Type, and many more. Here I am explaining it for Actual deadlines & status

          Go to the marked tab 'actual deadlines & status'

          You can see that in this tab there is option for entering the dates against the 'REFER' line. So enter the relevant dates against each activity and also if you wish you can enter the time, as below.

Step 8:

          After entering the date and time (if you wish), click on the 'set/reset status button' for every activity. By clicking on set/reset status button, system will set the status, and if the status is already set, then remove the status.

Step 9: Now select the deliveries which you wish to update with the dates and status maintained in 'REFER' line.

          And then click on the 'Templa' button so that system copy the data from reference line to all the selected documents, as below.

          Save the document.

Step 10: Now if you check one of the shipment document in display mode (VT03N), you will find that the dates and status changed.

Now just like Shipment Document, we create the SHIPMENT COST document in mass, for all the above three Shipment Cost Document.

Step 11:

          Transaction - VI04

          Just VL04, in this transaction also, you will get different selection criteria, based on that system will determine the Shipment Document which should be processed for Shipment Cost.

          Execute.

Step 12: System will display all the Shipment Document based on selection criteria. Select all the Shipment Document and then Execute (F8).

          After executing it, user should check the 'Log' by clicking on log button, system will display the Shipment Cost numbers created against each Shipment Document.

Step 13: Now check one of the Shipment Cost Document in VI03. You will find that Shipment Cost Document is created as required, but still it is not transferred to to FI.

Step 14: Transaction VI05.

Use this transaction for mass processing the Shipment Cost Document. You will get the relevant Shipment Cost Document based on the selection criteria you give in the input screen.

Step 15: Select the Shipment Cost document you wish to process and then click on Execute button (or press F8). System will do the transfer of account. To chek the document status check the Log, by clicking on Log Button.

          Check the log:

Step 16: You may also check one of the Shipment document, and you will found that now the Shipment cost is transferred to accounting and related PO and Service Entry Sheet created in background.

This ends the process of creation of Shipment Document.

Hope this will help, if someone wants to use the mass processing of Shipment Documents.

Looking forward for suggestions.

Thanks and regards,

Amitesh Anand

Purpose of this Document

The purpose of this document is to explain how you can debug an error message that is raised when output SPED is creating a delivery. SPED is an output that will create an inbound delivery from an outbound delivery. An error may occur during the processing of the SPED output. This error is stored in the processing log of the output and the inbound delivery is not created. This document shall illustrate how you can debug such an issue.

Motivation for this Document

As a trouble-shooter of LE-SHP issues, I would often be presented with the problem “Sped fails to create the inbound delivery”. Looking at the processing log of output SPED, I would usually see the error message preventing the creation of the delivery. The next step is to debug the error message to see why & where the error is being raised. To debug the error, I set a watchpoint on the message number (system field SY-MSGNO) and try to reproduce the issue. However, the watchpoint is never reached, yet the error is still raised. This prompted me to ask: “Where is this error raised?”, “Why is my watchpoint not reached?”. Digging deeper into the code, I discovered the answers to these questions. The motivation behind this document is to share this knowledge and to empower the reader to debug SPED error messages.

An Example

Outbound delivery is created. SPED has been determined (See figure 1)

Figure 1: SPED determined in outbound delivery, not yet processed because GI not posted.

The goods issue of the outbound delivery is posted. However, the red traffic light shows us that SPED failed (See figure 2)

Figure 2: SPED has failed

The first place to check why SPED fails is the processing log (See Figure 3):

Figure 3: Processing Log

We can see that error VL377 is the error causing a problem. If the long text is not sufficient, the trouble-shooter will proceed to reproduce the issue and debug to catch where the error is raised.

Debugging the error message

The SPED output is usually processed in the update task. Furthermore, the SPED coding processes the message in the background task. This means that there are certain flags that need to be set in the debugger for the system to reach the watchpoint.

1) Before saving the delivery, turn on the debugger and switch on update debugging (See figure 4)

Figure 4: Turn on Update Debugging. Menu: Settings - Display/Change Debugger settings

2) Save the delivery. This triggers update debugging (See figure 5) where the SPED coding is executed.

Figure 5: Update debugger triggered

3) In another session, go to customising transaction V/34 to check the processing routine assigned to output SPED (See figure 6)

Figure 6: V/34 – take note of the program / form assigned to the output

4) In the update debugger session (step 2), set a breakpoint at program /SPE/STO_ID_PROCESSING / Form STO_ID_CREATION (from step 3)

Figure 7: Breakpoint at output processing routine

5) Press F8 to get to the breakpoint (See figure 8).

Figure 8: Breakpoint is reached at output processing routine

6) Reading the code, you will see the following:

In this function, the system executes the following code:

In this code, you can see that function /SPE/CALL_PROC_NAST is called in the background task. This means that setting a watchpoint on SY-MSGNO will not be reached if the error is raised in that function.

7) Before the code reachs the “Call Function ‘/SPE/CALL_PROC_NAST’ IN BACKGROUND TASK”, you need to set the “TRFC (in Background Task): Block Sending” flag in the debugger (See figure 9):

Figure 9: Set the flag to prevent function from being processed in background

8) Press F8 to continue the process. You will receive an update termination message (as you interrupted the update).

9) Go to transaction SM58 and search for the entry you just created. Place cursor on the function module (Figure 10)

Figure 10: SM58 – place cursor on the function module.

10) Follow the menu path: Edit – Debug LUW (Figure 16). This will open the debugger. Here, you can set the watchpoint on SY-MSGNO = 377. If raised, your watchpoint should be reached (Figure 17). This answers the question “Where is this error raised?” which was asked at the beginning of this document. You can then continue your analysis from here.

Figure 11: Debug LUW Menu

Figure 12: Watchpoint on SY-MSGNO is reached

Conclusion

The above example uses error VL377. The long text of this error is clear and usually you would not have to debug VL377. However, there are other errors that do not contain such a clear long text. The above procedure can be applied to any error message arising from the SPED delivery creation.

Being able to debug SPED errors allows me to see exactly where and why the error message is being raised. It saves the trouble-shooter the time of searching SPRO for the appropriate setting as they can see the exact setting they are looking for in the code.

If you have any thoughts, insights or tips on the above content, I welcome your feedback. I will strive to improve the above content based on any feedback received.

This document explains some of the EDI messages commonly used in Logistic Execution or shipping process. We have tried to explain functionality of each EDI messages in brief which will help users to quickly refer and take decision on which EDI message is suitable for transmitting data from SAP to other involved parties or vice a versa. It is assumed that the target audience is aware of standard sales business processes mapped in SAP ECC.

We will cover below EDI messages –

EDI – 204: Motor Carrier Load Tender

This transaction set can be used to allow shippers or other interested parties to offer a shipment to a full load (truckload) motor carrier. This message is used to transmit information related to detailed schedule of the shipment, Equipment Requirement like size of the required Truck, Ship to Party details like name, location and contact details. Material / goods with weight and volume information along with Unit of Measure and shipping instructions. It is not to be used to provide a motor carrier with data relative to a less-than-Truckload bill of lading, pickup notification, or manifest.

The carriers will send EDI-990 as a response to Load Tender transaction indicating acceptance or declination of the load.

EDI – 990: Response to a Load Tender

Shippers send EDI-204 Load Tender transaction to Carriers normally for full truck load and in response to Load Tender transaction, carrier responds with EDI-990 transaction indicating whether the load is accepted or rejected. This transaction can also carry additional information related to acceptance or rejection of the offered load, freight acceptance along with conditions if any.

As an acknowledgement of the 990 transaction, EDI-997 functional acknowledgement will be sent by carrier or consignee.

EDI – 997: Functional Acknowledgment (FA)

This transaction is used to just acknowledge the receipt of the EDI transaction by receiver. This transaction means that the receiver has received the transaction and it is processed by EDI translator. This does not mean acceptance or rejection of the business function intended in the transaction. It may indicate if there are any issues observed in EDI standards for that transaction.

EDI – 214: Transportation Carrier Shipment Status Message

EDI – 214 transactions are used by carrier agencies to provide shippers / consignee the status of their shipment. This transaction can include information related to Ship from to SHIP To location details, address, co-ordinates, date and time stamp of pick up and estimated delivery, Shipment information like packing, weight and quantity and most important information reason for status and exception information.

The receipt of shipment status transaction can be informed using EDI – 997 functional acknowledgements.

EDI – 304: Shipping Instructions

This transaction serves different purpose when used for Ocean carrier or forwarding agents or brokers. 

In case of an ocean carrier, this transaction is used to provide information required to create Ocean BOL (Bill of Lading document), Sea waybill and other shipping documents. However, when it is used to transmit data to freight forwarder or custom broker, it provides information on shipping and financial details.

EDI – 856: Ship Notice/Manifest

This transaction is used to send Advance Shipment notification (ASN) between the trading partners. This transaction contains information about Order data, materials or goods, their weight, and volume, packaging information, and carrier and tracking information along with ship to location details.

The EDI 856 transaction is commonly used in response to EDI 850, EDI 830, or EDI 862 transactions.

EDI – 940: Warehouse Shipping Order

This warehouse shipping order transaction is used to instruct remote warehouses to ship orders. It is commonly used by manufacturer or wholesaler, to instruct a warehouse to make a shipment to a buyer. The 940 may also be used to confirm a shipment, modify a shipment or cancel a previous shipping order. The 940 transaction normally instructs the warehouse on what to ship, how much and when. The transaction may include specific information relating to Manufacturer, item quantity, shipment method, shipping party details and billing related data. The 940 Warehouse Shipping Order data can be generated from Sales Order or Purchase Order information.

An acknowledgement transaction EDI-997 will be submitted by warehouse in response to EDI-940.

EDI – 945: Warehouse Shipping Advice

This transaction will be used by warehouse to confirm seller that the shipment has been made. The transaction includes data such as Ship From and Ship To location along with Date stamp, shipment method, service level and items and quantity shipped. The 945 transaction provides the information needed for the seller to reconcile the quantity shipped against the order quantity, create an invoice and generate an 856 Advance Ship Notice (ASN) transaction.

Mapping EDI messages with SAP IDOCs

IDocs and EDI transactions are only data structures, so we can literally map anything to anything. The most important thing is to understand the underlying business process before you can select the appropriate EDI and corresponding IDOC. The key is business process.

In case of inbound processing the user needs to understand which business document / transaction to be triggered from incoming EDI message and that will drive selection of IDOC to perform the desired transaction. The determination of IDOC also needs additional information on process code, function module which can be obtained with the help of technical team.

However, in case of outbound processing the SAP document / transaction drives IDOC selection to transmit application data to outside systems. All the application data is transmitted but its functional consultant’s role to perform mapping of this data with the appropriate fields of EDI message fields.

Most generally used mapping of EDI transactions with SAP IDOCs –

References:

1. scn.sap.com
2. help.sap.com

Decision to use SAP WM is one of the major decisions that a company has to make while implementing SAP. There are pros and cons to go with either option; a company needs to perform a detailed analysis on logistics/storage requirement to arrive at the decision. Some of the influencing factors that can help companies arrive at the decision are mentioned below :

1. Volume of Materials: If the company deals with a large number of materials during each stage of production and have a large number of end items, implementing SAP WM can help track the materials at each stage. If the volume of materials handled are low, WM need not be implemented.

2. Storage Space: If the Storage space is very large and goods are stored all over the place, SAP WM can keep track of materials stored accurately. On the other hand, a small storage space with a relatively low volume need not have tracking at such a detailed level.

3. Material Movements: If the facility is required to handle a lot of material movements due to different production activities on the shop floor or it requires an elaborate packaging/shipping systems for end items in a specified time frame, SAP WM can be used effectively in these scenarios. On the other hand a low number of movements in the facility doesn`t warrant a SAP WM solution.

4. Traceability and Visibility:  Use of SAP WM is recommended if the company wants the full traceability of materials during production and delivery pick up process.

5. Special Requirements: If there is a requirement to store certain materials at certain temperatures only due to safety or shelf life concerns, SAP WM can help making storage, retrieval and tracking these materials easier and faster.

6. Integration with External Third Party Applications:If any third party application is used for performing or aiding the plant processes, a thorough analysis on its integration with SAP WM or SAP in general, becomes necessary. Another analysis also needs to be done to replace the third party system with SAP offering if required. A thorough cost benefit analysis will help in making an informed decision.

7. Integration with RFID devices: If the facility uses RFID devices for functions like picking, storing and verifying the materials, it would be a good idea to implement SAP WM. This can help in streamlining the warehouse processes.

8. Training / Opportunity Costs: If the cost of training the warehouse or plant operators exceed the potential benefit of implementing SAP WM in terms of reduced costs on account of lack of pilferage , materials lost  , streamlined processes , accurate monitoring of the stocks etc. , then implementing WM should be preferred. The direct benefits coming out of the implementation should be quantifiable.

9. Change Management:Implementing SAP WM will also increase the administrative effort associated with Plant/Facility/Warehouse Admins and Shop Floor personnel. This also needs to be taken into consideration while making a decision on implementing it.

Requirement Gathering:

Once the decision is made to implement SAP WM, next step is to determine how the client or company plans to use it. To facilitate the requirement gathering, workshops should be conducted to gather the business processes and all functional requirements (including special business needs). These requirements are thoroughly analyzed and documented.

Consultants can make use of workshops to understand the client processes thoroughly. They can also use other techniques like one on one interviews or group interviews to understand the business process. SAP also provides questionnaire database in ASAP methodology that can be used to gather the requirements.While conducting the workshops or interviews for implementing SAP WM, following should be discussed to have a full idea of client organization structure and business processes:

• Warehouse Facility Locations : These details help the consultants to understand where the facility is located, what manufacturing and distribution centers it caters to, physical layout of its premises etc. These details help SAP Consultants to answer questions on the organization structures in SAP, how many storage locations will be Warehouse Managed, how many storage types will it have etc.

• Business Processes: These details help the consultant to understand the functions carried out in the warehouse. It will provide details like the use of premises to store and supply goods only for production only or also to sale for end items. It will also provide details on whether quality function is carried out in the premises or not; whether or not the facility also helps in prepack the goods to be sent to other distribution centers. This will also list out any other specialized business process that the facility is used for

• Storage Requirement: These requirements will provide an idea about how the client goes about placement of goods in the warehouse facility. It also brings out the details of any hazardous materials that are stored in the facility. Endeavor is to capture the specific requirement for a group of materials to be stored at a particular place due to shelf life, size, ease of movement, specific temperature requirements etc. These details helps consultants to define stock placement strategies in SAP to facilitate correct placement of materials.

• Removal Requirements: These requirements will provide an idea about how the client goes about removal of goods from the warehouse facility for fulfilling’s shop floor or sales orders. Whether the shelf life expiry date is the deciding factor or they are removed based on the goods placement date or they consider any other factors while removing the goods. These details helps consultants to define stock removal strategies in SAP to facilitate correct placement of materials.

• Inventory Count: These details will provide an idea about how client carries out its inventory counting. These details help consultant to decide on the use of inventory counting methods like Annual Inventory, Cycle Count, ABC system of inventory etc.

• RFID Requirements: These requirements will provide details about the integration requirements of handheld or RFID devices with SAP. This will provide information about the usage of RFID devices in the facility, what functions they carry out etc. This will help consultant to analyze the requirement about developing new custom made enhancement that can be used with SAP WM. These requirements will also help consultant to reach a decision to use SAP Console or ITS Mobile.

Generally, while gathering the business requirements, a mix & method of well-defined questionnaires, workshops and interviews gives the desired result. Output of this phase should be a Blueprint document that covers all the functional requirements and business processes.

This Blueprint document should be signed off by the clients Business Process Specialists as well the Logistics Lead to confirm that all the requirements have been captured in the document.

The Blueprint document forms the basis of the To-Be document or the Final Design Document that the Consultant draws up to replicate the enterprise structure and business processes in SAP WM.

Final Design / To- Be Document: 

Once all the business requirements are captured, a detailed design document addressing the requirements needs to be drawn up. This document should be able to address at least 70-80 percent of the client business processes that can be replicated across geographies with minimal or no changes. This design document would be used as core/kernel for handling change management in future. The remaining 20-30 percent of the design should be flexible enough to accommodate for changes due to specific process, legal, regulatory & language requirement for different regions.

The Final Design / To – Be document should contain:

• Final Organization Structure: The document should contain To Be Org structure in SAP based on the blue print document. It should have a clearly defined warehouse structure definition like the proposed warehouse , the storage locations and plants it caters to , number of storage types , storage sections etc.

• Stock Placement and Removal Strategies: The document should also capture the placement or removal strategies to be used in the warehouse. If there are multiple strategies to be used in the same warehouse, the same should be documented as well. If due to special requirements, custom enhanced removal or placement strategy is required that would require a user exit to be triggered, the same should be documented as well.

• Physical Inventory Method: Final design document should also contain the details about the physical inventory method that is going to be used using SAP.

• Transfer Order / Transfer requirement Creation: The document should contain the details about the trigger points for Transfer requirements / Transfer Order creation. It should also point out the details like automatic/manual creation of TO and their confirmation. For Example, after production order release, a Transfer requirement would be created automatically for components issue. This Transfer requirement needs to be converted into Transfer Order manually and will be confirmed automatically.

• RFID Developments: The activities to be performed using the handheld devices in the applicable warehouses need to be captured in the document. Typical activities that can be done using RFID devices include stock picking, stock placement, inventory count, material handling verification etc. New customized enhancements or developments that are required to be done need to be documented as well.

• Reports & Forms: The design document should also capture the various reports that will be used. If there is a specific requirement that is not met by standard set of reports provided by SAP, the need for creating a custom report(s) should be documented. The document should also capture the requirements for transfer order / transfer requirement form, sticker, labels printing requirements etc. It should clearly highlight at what step the forms should be printed.

• Interfaces: If any third party interfaces are used to capture any real time information in the warehouse, perform any functions or to send the data to an external party, its integration with SAP WM should be captured. If the proposal is to replace the third party interfaces with standard SAP or SAP Add ons, then those details should also be captured.

• Miscellaneous Requirement: This may cover any specific activities or functions that the warehouse facility performs. An example of it can be to store the material or batch samples separately due to legal requirements while doing a goods receipt for an incoming batch of material. There could also be a requirement to add a new movement type to perform any special functions.

The output of this phase should be a Final Design document that should be signed off by clients Business Process Specialists as well the Logistics Lead to confirm that all the business requirements have been met in the Design/To Be document and configuration and development as per the document could begin.

The  route determination based on the following criterias:

• Departure Zone
  
• Shipping Condition
  
• Transportation group
  
• Transportation zone

1, Departure zone

Departure zone is location for your shipping point.

Path: IMG ➢ Enterprise Structure ➢ Definition ➢  Logistics Execution ➢ Define, copy, delete,  check SHP ➢ Location

2, Shipping condition

Specified in the customer master record on the Shipping tab. Shipping condition could be assigned
to a sales document type. In the sales order, maual override is permitted.

3, Transportation group

A groupe of materials that share the same route and  transportation requirements.

Path: Customer Master (MM02) ➢ Sales General/ Plant

4, Transportation zone

A group of destination locations.

Define

Path: IMG ➢ Logistics Execution ➢Shipping➢ Basic Shipping Function➢Routes➢ Maintain Country and Tr. zone for SHP (Tr. code: OVR1)

Assign

Path: IMG ➢Logistics Execution ➢Shipping➢  Basic Shipping Function➢Routes➢Maintain Country and Tr. zone for SHP (Tr. code: OVL7)

5, Maintain Route

Path: IMG ➢ Logistics Execution ➢ Shipping➢ Basic Shipping Function➢Routes➢ Route Determination (Tr. code: 0VRF )

Current Scenario

You want to create a delivery as a reference from a Purchase order and you performed the following steps:

1. You run transaction VL31N
2. You enter the scheduling agreement
3. You click on "Save"
4. The system prompts the below error:

What's the reason for this error?

There are 2 reasons: a) Missing EKES entries for the inbound delivery and the affected field EKET-DABMG

was not updated and b) Field EKES-ETENS.

How to deal with the error?

The error is giving here:

1.- For the first case (EKET-DABMG)

You could run report ZCREATE_EKES from SAP Note 1130335

2.- For the second case (EKES-ETENS)

Put a breakpoint in the following program:

and check the value of field "highetens".

Field "EKES-ETENS" is only a 4 digit NUMC field so you can only have max.

9999 entries. If the highest EKES-ETENS is 9999 and there are 9999 entries,

you can not longer use that Scheduling agreement, this apply to the SA that

is close to 9999 entries also (i.e. 9990 entries).

The only way you can solve this is by creating a new SA and try not to reach

this number of entries.

Conclusion

This is my first document that I share here so feel free to post any comments

and I hope you find it useful.

Significance of RF in Warehouse Management:

Mobile data entry in the warehouse involves the use of wireless radio frequency (RF) terminals or devices carried by the warehouse staff to record data. The use of bar codes and RF devices has made warehouse operations more efficient. Data entry errors are fewer and the time needed to perform operations in the warehouse has been reduced because the date can be collected by a RF device without requiring manual collection and manual entry of data. The use of RF devices for data collection and transaction processing in warehouse management has been increasing over a number of SAP releases. The modern efficient warehouse uses RF technology and constantly reviews procedures to further adopt the technology to improve operations.

Technical and Functional Landscape of RF environment

Efficient warehouse management processes requires faster data entry and processing for inbound, outbound and internal warehouse operations. SAP transactions can be executed on RF devices that are handheld (terminals, barcode scanners) or forklift mounted. No middleware software is required to connect the devices to SAP.

SAP’s functionality enables real time handling of material flow through RF scanning devices. There are two standard RF devices that can be used with SAP which are

1. 1. GUI Devices: uses windows based operating system and this graphical user interface RF device can use a small keypad, touch screen or some other procedure, but the data is always displayed to the user in a graphical manner. The device is connected to the SAP system as any other standalone computer.
2. 2. Character based devices: The character based device is not connected directly to SAP but communicates via an interface called SAP Console. Thecommunication between SAP console and the RF device can be achieved using a Telnet server. Two industry standard screen sizes are supported by SAP

A.    RF Devices for Forklift: 8 X 40 (8 lines by 40 characters)

B.    Portable RF Devices: 16X20 (16 lines by 20 characters)

RF screen for 8X 40 looks like

SAP Console enables RF devices to be run within SAP applications. SAP Console is used as a framework for automatic data collection in a warehouse environment. SAP console translates GUI screens to character based screens that are used on a variety of data collection devices. The SAP console does not contain business logic, database or external functionality. Its sole function is to translate SAP GUI screens in the SAP environment to the character based equivalent. The SAP console consists of four components, which are:

1.      RF terminal: The RF terminal which is the Telnet Client receives data directly from the SAP System and transmits the results back to the system. We can scan the information that needs to be recorded, such as storage unit numbers, using a bar code (for example, based on UCC/EAN128 standards), and also use the bar code scan to verify the storage bins.

2.      RF Access Point which allows for wireless Ethernet

3.      Telnet Server/SAP Console Administrator, which allows each RF terminal to convert to the window machine in character, based mode and supports VT220 terminal emulation.

4.      SAP R/3 system that receives the data from mobile terminals

1.     RF in distribution environment

Radio Frequency is primarily used in Warehouse Management process in distribution environment as it efficiently handles the huge volumes of transactional data processing requirements and minimizes human interventions. The high volume of warehouse transaction processing requirements in industries like Retail, chemicals, pharmaceuticals, Auto Components can be handled using the RF integration with warehouse Management. The following processes can utilize radio frequency devices:

1.    Goods Receipt Processes with shipping notifications

2.    Goods Issue Processes for outbound Deliveries

3.    Internal Warehouse Processes

4.    Stock Transfer Processes within the Distribution Network

5.    Physical Inventory Processes for the warehouses within the Distribution Network

2.     RF Supported Warehouse Processes: The following Warehouse Management Processes are supported by RF

A.    Goods Receipt Processes with RF:

RF supports Goods Receipt Processes with Inbound Delivery. The goods receipt for the inbound delivery can be performed based on the Inbound Delivery number, Handling Unit Number, Staging Area, Shipment Number etc. warehouse workers can perform the following goods receipt-related functions:

• Check all delivery items and report differences
• View and change shipment information
• Print shipping unit labels
• Unload deliveries
• Pack/unpack delivery items
• Generate and confirm TOs for delivery items
• Post goods receipts to Inventory Management

B.    Goods Issue Processes:

The goods issue processes are based on the outbound delivery and can be performed for the outbound deliveries identified by Delivery Number, Handling Unit (HU) Number, Staging Area, Shipment Number, Group Number etc.

Using the RF devices, Warehouse Workers can perform the goods issue related activities like view and change shipment related information, print shipping unit labels, pack/unpack delivery items, load deliveries, split deliveries, generate and confirm transfer orders for delivery items, post goods issue to inventory management

C.   Put away Processing:

Radio Frequency supports the put away processes and it is based on the Transfer Orders created in warehouse management. Put away can be performed based on the selected storage unit/handling unit, selected by deliveries, selected by transfer orders or cluster

D.   Picking Process for Deliveries: Picking execution is based on transfer orders created in the warehouse management as part of the delivery processing processes.

E.    Physical Inventory:

RF devices can be used for inventory counting, enabling a greater degree of accuracy and efficiency. New Dynamic Cycle Counting functionality provides a number of features that facilitate cycle count in the warehouse including Physical Inventory counting against inactive inventory documents (while open transfer orders exist for a bin), inventory counting at quant level, creation of inventory documents by RF users and automatic clearing of active and inactive documents.

3.     Associated SAP Configuration for RF

a.     Configuration for Bar codes: Verification profile is a set of fields that can be verified by the user.
Path: IMG>Logistics Execution>Mobile Data Entry> Verification control> Define Profiles

b.     Verification profile can be assigned to movement  types used in warehouses that will be subject to bar code scanning.
Path: IMG>Logistics Execution>Mobile Data Entry> Verification control> Assign Verification Profiles to Goods Movements.

c.     Define bar codes for warehouse
Path: IMG>Logistics Execution>Mobile Data Entry>Bar Code> Assign Bar Code Types to Warehouses.

d.     Maintaining Bar code specifications
Path: IMG>Logistics Execution>Mobile Data Entry>Bar Code> Maintain Bar Code Specification.

e.     Defining the Radio Frequency Queue: To assign a range of activities to certain users, functionality called the RF Queue Management must be defined
Path: IMG>Logistics Execution>Mobile Data Entry>Rf Queue Management > RF Queue Definition

Path: IMG>Logistics Execution>Mobile Data Entry>RF Queue Management > RF Queue > Assign areas and activities to queue

Path: IMG>Logistics Execution>Mobile Data Entry>RF Queue Management > RF Queue > Assign processors to queue

4.     Reasoning for Developing Custom RF transactions

The following developments take place in warehouse management with RF

1.    Making Changes in Standard SAP Transaction using user exits

2.    Making Custom Development

In the first case like other SAP modules, changes can be made in the standard SAP transactions to meet the specific business requirements using the suitable user exits. In general the custom RF transactions are developed to merge several RF transactions into one RF transaction in order to optimize and reduce the process steps to be carried out. For example for a goods receipt of an inbound delivery with handling units the GR transfer order should be created, it should be confirmed and put away transfer order should be created for the same. Thereforethe GR process includes execution of three standard SAP RF transactionsbut the same processes can be executed using single custom developed RF transaction.

The custom RF Transaction development includes the following steps:

1.    Creation of the executable program

2.    Creation of the screen

3.    Creation of the function module to access the screen

4.    Screen Programming

5.    Subroutines to call the screen and check the data coming from the screen

6.    Assigning transaction code to the program

7.    Assigning transaction code to the RF menu

The custom development should be made considering the workload and the extent to which the automation is required in the warehouse. The average transaction volume, warehouse efficiency and the cost/benefit analysis should be made before deciding on the custom development requirement. 

5.     Day in the Life flow using RF Technology

Warehouse Management transaction LRF1 is used to monitor the queues of warehouse person. Warehouse supervisors can drag and drop the transfer orders from one queue to other as per the load situation, user absence. The transfer order priorities can also be changed as per the requirement.  The monitoring of the queue can be configured per warehouse based on the business requirements by following the given steps:

- Define Queue

- Assign areas and activities to the queue

- Assign processors (users) to the queue

The limitation imposed by the transaction LRF1 restricts more than one user to access the transaction per warehouse. The transaction LRF1 can also be used in conjunction with the SAP Delivery Monitor transaction VL06 for warehouse workload estimating.

6.     Change Management Related topics for WM and RF

The following change management related topics should be considered before implementing WM and RF

1.    Selection of appropriate RF Device based on the existing business processes

2.    Transaction Volume analysis and assessment of custom developments

3.    Identifying users and setting up appropriate users profile and assigning users to the RF monitoring queue

4.    Users training and Process Documentation

This document explains design concept of how to use scanning of outbound shipment barcode to complete putaway at receiving plant for a group of replenishment deliveries created under a single outbound shipment

Goods Receipt using Outbound Shipment

The Outbound Shipment under consideration is only those that contain outbound deliveries of replenishment deliveries of Stock Transport Orders (STO)

Goods receipt can be done in PC using the following documents

·         Purchase Order.

·         Production Order.

·         Stock Transport Order.

·         Inbound Delivery.

·         Outbound Delivery (In case of STO).

·         Inbound Shipment.

Goods receipt can be done in RF HH (Radio Frequency Hand Held) using the following documents

·         Inbound Delivery.

·         Inbound Shipment.

This paper describes the design and actual successful implementation of a process of doing Goods Receipt with respect to outbound shipment for replenishment deliveries which is not available in Standard SAP either in a PC or RF HH Transaction.

The Design was approached with a philosophy of minimum developments and maximum Standard SAP.

Scenario: Outbound shipment for many outbound deliveries of stock transport Orders from Plant A to Plant B in the same company code.

The assumption is outbound shipment is PGIed

Design Step:

1.    Create a SAP Standard Output type SPED to create inbound deliveries automatically when  outbound deliveries are PGIed( Refer Note 965176)

2.    In any document that is printed and sent along with deliveries, print the outbound shipment document number as barcode for it to be scanned at the receiving Plant.

3.    Since SPED is used outbound delivery number is captured in the field External Number (LIKP-LIFEX) of the inbound delivery.

4.    Develop a small RF HH TCode to scan the outbound shipment number which will list all relevant Inbound deliveries for putaway (The table SHP_IDX_EXIB Contains the inbound delivery VBELN for outbound delivery LIFEX). Choose one inbound delivery at a time and on selection design the program to call LM71 (GR with inbound delivery), with the inbound delivery prepopulated.

5.    Once Step 4 is complete, use all the possibilities of LM71 Like generate TO, Confirm TO, Check if any TOs are open and even Post GR.

The only area which requires some development is to scan outbound shipment to list all inbound deliveries and call LM71. The 2 can be done in a single Custom RF TCode.

I gave a look at the few docs on WM/RF and failed to find good info on the processes not covered by SAP WM RF functionality, be it ITS / telnet or whichever you use.

This is meant to be used as a reference on a few projects.

1. Putaway - COVERED
2. Picking - COVERED
3. Replenishment - COVERED
4. Relocation - NOT COVERED
5. Physical inventory - COVERED
6. 2-step confirmation - NOT COVERED
7. 2-step picking - PARTIALLY COVERED
8. Return of the goods from delivery (LT0G) - NOT COVERED

Now, let's see which of those is likely to be covered by a development of some sort.
There is always a way to develop a transaction / RF screens which will do anything, but in my experience, these approaches are good.
I will only list the uncovered processes and their development approaches.

1) Relocation:

As simple transaction as possible, 2 screens + 1 screen for messages.
Depending on the use of SU or not:
screen1- scan SU, or scan MATERIAL / BATCH
screen2- enter relocation qty and san the destination bin
actual processing- after screen 3 and before screen 4. You can use Function Module L_TO_CREATE_SINGLE
screen3- for messages - error and success message display
You can also implement less screens if you want to enter all the details on one screen,
but sometimes it is better in practice to show the scanned SU (quant) contents so the WH worker
can check if that is the right SU (or quant) to relocate to another bin.
Note: It's good to allow relocation to another storage type, not nly bins in one storage type.
That might be tricky because one more entry field on RF is not a good option. In this case,
good planning can work miracles. If you don't have duplicate bin coordinates in your entire
warehouse, you will know by only scanning a bin, from which storage type it is, and therefore
won't have to enter the storage type itself on the RF screen.

2) 2-step confirmation:

Achievable, but requires much ABAP work on developing the transactions for 1st and 2ns step confirmation.
I will not go into detail on this, since it requires too much ABAp work and I would recommned if you need to use
2-step processes with RF to go with 2-step picking instead of confirmation.
Of yourse in some specific situations  you will require exactly this process.
Why would I recommend 2-step-pick instead of 2-step-conf?
It's because you also have a record on both of the users/dates-times of confirmation of the both steps.
So you can monitor the work in your warehouse in more detail, and by individual steps.
So go with 2-step-picking unless you really require the functionality of 2-step confirmation.

3) 2-step picking:

In this case, much easier than the previous, you already have support for 1st step.
So you only need to develop a transaction / RF screens for 2nd step in the picking process (e.g. 200 => 916).
2 step picking makes sense mostly in cases with SU / HU management.

Possible transactions steps:
screen1- scan SU
screen2- list of quants on SU and confirmation
actual processing- with t-code L_TO_CREATE_SINGLE or L_TO_CREATE_MULTIPLE
screen3- mesages (success and error)
Note: what you need to take care of is if you have delivery grouping and using LT0E, you might have
the same group SU/HU for more deliveries/customers. (e.g. more customers/delvries picking zone => to 1 pallet)
You might use screen 3 for an info on this too if you have grouped TOs. Facing this depends mostly on your previous
processes - prior to 2nd step.

4) Return from delivery - lt0g:

As simple as possible, again. Possible steps:
screen1- scan/enter the delivery number and material.
screen2- check the qty confirmed on the delivery, and allow qty entry only up to that qty found on the delivery item
actual processing- process by L_TO_CREATE_SINGLE - if you have SU management active you will also have a SU printout as a result
screen3- message handling (error , success)
Note: While creating a TO for the return, see if your client requires return to the original bin or using the putway strategy. Apply the desired technique.

There are requirements to print a pick list from SAP when system creates a transfer order. Once a transfer order is created for picking, SAP has a capability of printing a Pick list on a printer based on applicable conditions provided by SAP.

Prerequisites: Printer need to be configured in SAP by BASIS team.

Following are the step by step configurations for printing a pick list from a transfer order.

Transfer order gets printed from the print code assigned in Warehouse management movement type. There are following important configurations that have to be configured for printing pick list from SAP.

1. Spool Code
2. Sort Profile
3. Print Code
4. Printer assignment
5. Printer assigned to your Picking area/storage type.
6. Assigning Print code to you warehouse movement type.
7. Printing Program.

    Menu: SAP Reference IMG -> Logistic Execution -> Warehouse management -> Activities -> Define Print Control or Transaction Code: OMLV

Spool Code:

Spool code controls the behavior of Print outs.
For example: Number of copies/Print immediately/Delete after print out.

No of Copies:

You can enter ‘1’ if you just want to have original document to be printed, if you want system to printout original documents & also to keep a copy for future reference enter ‘2’

Print Immediately:

The system will print immediately as soon as transfer order is created.

Switch for printing immediately. Printing is immediate if this switch is set. Otherwise the output is held in the spool.

Delete after printing:

Switch for deleting a print job. If the switch is set, the spool job is deleted immediately after printing.
Otherwise it remains in the spool file for printing and can be printed again if required.

Sort Profile

The system can print TO using SORT profile you
can provide system different option of sorting TO accoding to the criteria
mention in Sort profile. SAP has provided upto 15 sorting options system will give priority according to
the Sorting Sequence you maintained in Table.

Eg: In the table, if you enter
data as follows into the first three sort fields as follows. The system will
sort transfer orders first by transfer order item (TAPOS), next by material
number (MATNR) and finally by source storage bin (VLPLA).

Table:
Profile for Sorting in the TO Print Process

SRTF1    SRTF2    SRTF3

TAPOS    MATNR    VLPLA

System by default will sort in ascending order but if you want to sort in descending order activate the check boxyou can also have system to start new page when particular group gets change

EG: If you select TANUM in the the sort field, the system prints a new page whenever the transfer order
number changes.

Print Code:

Print code plays very important role in Printing TO. The print code is assign in Warehouse movement type .The print code defines the Spool(mention above),Form(layout of p), also decides if Printing for multiple transfer order or/and transfer order item can print together. You have to configure print code at the warehouse level. You can have multiple print code created for the single warehouse.

Process:- when particular warehouse movement type is trigger system identifies print code & print accordingly. Following is the configuration for the print code.

Printer Assignment

You can assign a printer to warehouse with the criteria of source storage type & destination storage type. If the material is moving from 001to 002 & TO should be printed in Printer name ‘LP01’ you need to assign Srce stor.ty ‘001’ & DestStor.ty ‘002’ & mention the printer name in printer column. In vice versa if youdon’t want the system to print on that particular printer for respective source storage type & destination storage type you have to activate ‘NoPrint’ indicator. You can assign a printer to each storage type. If you want the system to print in Source storage type printer you have to activate indicator  Print ‘Src  ST  Type’. In form column you have to mention the layout name(form) for your print layout.

Assigning Printer to picking storage types

You can assign a printer to each storage type for each warehouse or picking areas.

Storage type

Picking areas

Last steps are assigning Print code to the warehouse movement for which pick list is required

Assigning Print code to you warehouse movement type

Printing Program

You need to have to Printing program that will print TO periodically or immediately.SAP
system provides standard printing program ‘RLVSDR40’

Transfer order (Picklist ) can also be manually printed using transaction code LT31

Introduction: Two process is used to optimize the picking process. Suppose, one material is being used more frequently either in Sales order or in Production order or being transfer one SLOC to Another SLOC. If frequency of picking of material is more as it is being used in multiple outbound delivery, we can use 2 steps picking to optimize the performance.

Two Steps picking are broken in to 2 steps-1) Collective picking of materials linked to all Reference documents (OBDs or TR's) 2) Allocation of materials to respective OBD/TR's

All OBD or transfer requirements are clubbed in one group and picking happens for all materials mentioned in OBD or TR clubbed in Group. A transfer order is created to pick the materials and materials are being brought to Interim Storage type 200.  Another TO is created to allocate the materials to respective OBD/TR's and materials are moved from Storage Type 200 and process is complete.

Two Step process is very efficient and improves performance of system.

This Documents will discuss about required configuration for Two Step picking.

Process Involved: Two steps picking are broken in to 2 steps- 1) Picking with respect to group which are created to combine all OBDs/TR's

2) Allocation of materials to respective OBDs/TR's

Two Transfer order is created in this process- one for group picking and another TO for allocation. First TO brings the materials to interim storage Type 200 from a bins which was used for picking. Second TO is used to allocate the materials to respective OBD's/TR's.

We need to configure to make this happen. I will only touch upon configuration involved for Two step Picking. Will not discuss about Strategy for removed from Bins.

Configuration Involved: As We discussed above, TO can be created either from OBD or TR's so we need to set up configuration for 2 steps     picking for shipping used for OBD as well as Transfer requirements.

A) Activate Two step picking for Transfer requirement: We need to activate 2 step picking for Transfer Requirement. We can make 2 step picking material dependent or Independent.

Menu Path-

SPRO-->Logistic Execution-->Warehouse Management-->Activities-->Transfers-->Set up 2 step picking process for Transfer Requirement

When click  on Set up 2 step picking for Transfer Requirements, another screen opens where we have 2 activities need to be performed as shown below

Under Transfer requirement control, we have to make following setting

1) Assign 2 step picking under column 2stP for given Warehouse No

2) 2 Step is Material dependent or not. If check  column 2-stMatl, only those Materials  will be part of 2 steps picking where 2 step  provision is made  in Material  master under Warehouse view 1

3) Movement type 850 needs to be assigned as this is movement type will be used during first TO during collective picking to bring the materials to interim Storage Type 200

Once it is done, we need to set up 2 step picking for transfer type- Stock removal under transfer type control.

Same configuration is involved for outbound Delivery. Configuration path can be found under Interface-->Shipping-->2 step picking

Now once it is configured, We now need to set up Storage type search for 2 step picking. Here we need to assign operation 2 and give storage type as 200 as stock will be kept at storage type 200 before final allocation.

Configuration step will be same as we do for normal Put away and Stock removal Storage type search

SPRO-->Logistic Execution-->Warehouse Management-->Strategies

Now Configuration is complete. Now let's have a one  2 step picking example for better understanding.

We will take 2 step picking for transfer requirement document. We will create TR via SLOC to SLOC transfer. If both SLOC are warehouse Managed under same Warehouse no, Posting change notice is created but we need to have TR so I will transfer from WM managed SLOC 1000 to non WM managed SLOC 2000 in below example.

Following steps needs to be executed

1) Assigning 2 step indicator in Material Master:

2) Creation of TR via Transfer Posting in IM via MB1B with movement Type 311:

We have Generated 3 TR via 3 Transfer posting which we can see in LB11 report

3) Creation of  group : Now we need to create group combining all these 3 TR's  which will be reference documents for first TO for collective picking. Group is created via LT41 transaction

Screen is showing 3 TR's have been clubbed. Now Select Row and press Assign Group to create Group. Another Screen will appear where give Description of group as shown below

4) Run LX39report :

System will ask to enter Group no created above and Warehouse No. Execute the report. System will display 2 Row- Picking and allocation if group is 2 step relevant else System will give warning message

5) Creation of TO for collective Pick:Now put cursor at Pick row and click on Create TO to initiate picking process

Press Enter .

Select Stor type Srch Seq to see which Storage type is being proposed for Destination. It should Be 200. Once it is done, Generate TO

6) Confirm TO: Confirm TO to complete the picking step. Run LT12  and enter the TO generated above

7) Run LS26 report: We can see stock status. Stock will be lying under Storage type 200

Now Collective Picking process is done. We can see  Picking row will be green if we put cursor on pick row and press Data

8) Create TO for allocation: Put the Cursor on Allocation and select create TO button to create TO

Select Start multiple Proc. button to initiate TO

So we can see that Allocation to respective TR has occurred via TO#98,99 and 100. Now we can see that LX39 report shows allocation green as it is completed.

Now 2 Step picking process is completed.

This Document was created with Co-Author-Pankaj Agarwal who is very much enrich in SAP-MM/WM coming from very rick background of Procurement and Planning.

Automatic creation of Packaging Delivery item from Handling Unit Packaging Material:

Handling Units essentially consists of one or More Packaging Material (Boxes, Cartons, Pallets, Container etc) and Items that are to be Packed so that their Handling becomes easier and Convenient.

The Packaging Materials used for Packaging Goods also contribute a significant portion of the Overall Delivery Cost and considering this a Business Requirement can arise to Charge the Customer with the cost of the Packaging items used in Packaging of Goods that are to be delivered against a Particular Customer Order.

In certain cases, it may be required to get back the Packaging Materials example Containers etc( Returnable Packaging Materials) after the Delivery has been made at the Customer Location.

In view of above Business Requirement, I will be explaining how we can automatically generate a Line Item in the Sales Order Delivery for the Packaging Material especially Load Carrier used in making up the Handling Unit.

Lets Begin.....

I have created below Sales Order for Sales Area: 1000/10/US against Customer: 1046000 and Material: 003900954 ( Bottle )

Before I go on to Create a Delivery against the Sales Order, let me show you some of the Important configuration i have done in below highlighted SPRO Node below:

The Delivery Type that is going to be triggered is of type 'LF'. I have the Item Requirement Routine setup as 202 (Order w.independent item). Also make sure the Two fields which represent Automatic Packaging and Generate Packaging Line Item are turned ON.

Note: Packaging Materials have Gen Item Category Group in Material Master maintained as either VERP for Normal Packaging Item and LEIH for Returnable Packaging Material.

Make below Highlighted Entries for Delivery Type-Item Category Group and Item Usage "PACK". For Materials with Gen Item Category Group "VERP" assign Item Category Group "HUPM" while for Materials with Gen Item Category Group "LEIH" assign Item Category Group "TAL".

For automatic creation of Handling Unit, you would need to set up the Packaging Instruction in Transaction: POP1

Here 256 Bottles are to Packed in One Pallet as shown below.

Create the Condition Record for Automatic determination of Packaging Instruction in Transaction: POF1 for Determination Type: SHIP.

I have maintained below Condition Record for the Combination of Material and Ship To party of Sales Order.

Also Note: For the Packaging Material 'Pallet' of the Handling Unit you have to extend the Material master for Sales Area 1000/10/US of the Sales Order. In short you need to make sure all necessary Master data for creating a Sales Order for the Packaging Material needs to be maintained so that we don't face any issues when creating the Delivery Item against the Sales Order Created.

Lets now move on to create the Delivery for the Sales Order in below Step.

You can see that a Line Item for the Packaging material "PALLET" is created for a Qty of 1 is created with Delivery Item Category "HUPM" based on our initial Configuration.

The Handling Unit is created automatically which can be seen below:

Now you can save Your Delivery Successfully.

Automatic Nested Handling Unit creation with Multilevel Packaging Instruction

Here I am going to explain how we can create Nested Handling Unit i.e Multiple Handling Units in SAP.

Handling Units is an important functionality for easy identification and Handling of Goods that require Packaging.

In the Below demonstration, I am going to show the Master data and Configuration required to create Automatic Handling Units when you are creating a Delivery against Customer Sales Order.

So, Lets begin....

I have a Business Case in which 4 Bottles are packed in a Small box, 4 Small Boxes are to be packed in a Carton and 4 such Cartons are to be packed in One Pallet. The Picture below depicts our Business Requirement. Here at each stage of Packaging we need to create Handling Units. This sort of Multiple Handling Unit creations in which several Handling units are grouped together to create another Handling Unit is termed as Nested Handling Unit.

I am now going to create a Sales Order for 256 Nos. of Bottles against Sales area 1000/10/US for a Given Customer.

Now before I create the Delivery,  I would show you the Master data that I have created to achieve our Business Requirement.

We would first create below Packaging Materials in Transaction MM01:

1. Pallet: Material Type and General Item Category Group as VERP (For Returnable Packaging Use General Item Category Group as LEIH)  with Packaging Material Group: S003 & Packaging mat. type:  0004

2. Carton: Material Type and General Item Category Group as VERP (For Returnable Packaging Use General Item Category Group as LEIH)  with Packaging Material Group: S004 & Packaging mat. type:  0006

3. Box: Material Type and General Item Category Group as VERP (For Returnable Packaging Use General Item Category Group as LEIH)  with Packaging Material Group: S005 & Packaging mat. type:  0006

4. Bottle: As a Normal Finished Product of Material Type FERT in Sales Area 1000/10/US with necessary Pricing Condition Record.

Make below settings in SPRO Node Highlighted below:

Now for Material:  Bottle we will create a Packaging Instruction as shown below.

An important thing to note here is Handling Unit Number is generated only for the Load Carrier of the Packaging Instruction.

In view of this since we want to generate Handling Unit for Boxes, Cartons and Pallet, we would need to treat them as Load carriers in our Packaging Instruction and since One Packaging Instruction can have only One Load Carrier in it, we will have to create separate Packaging Instruction for each of the Load Carrier.

Below  Packaging Instructions have been Created in T Code: POP1:

a. Packaging for Carton:

b. Packaging for Box:

c. Packaging for Bottle:

In order for Automatic determination of Packaging instruction we will create Condition Record in T Code: POF1 for Determination Type "SHIP" for Material Bottle and Ship To Party Combination.

Once all the Master Data has been created we will now go on with creating Delivery against the Customer Order.

The Delivery type that will be getting created when we try to create Delivery against the sales Order needs to have Automatic Packaging Tick in the Delivery Type Configuration as shown below:

On the Delivery Handling Unit Icon, we can now see below Handling Unit created.

Now you can Save and Delivery will be created.

The Above Handling Unit then can be Displayed in T Code: HUMO..

Auxiliary Packaging Materials are essentially Packaging Materials that are used for Packaging the Materials for their Safety, Separating,  Ease in Handling etc.

The Only difference with respect to Packaging Material in a Handling Unit is that the Auxiliary Packaging Material cannot be the Load Carrier in a Handling Unit.

Lets take an Example Below where we would illustrate how Handling unit is created automatically with a Load Carrier & Auxiliary Packaging Materials.

I have a Business Case in which 16 Bottles are packed in a Small box, 4 Small Boxes are to be packed in a Carton and 4 such Cartons are to be packed in One Pallet.

The Picture below depicts our Business Requirement. However, we want to create Handling Unit only at the Pallet Level. Also the individual Pallet has a Top Lid and Mid Layer for extra protection.

If you wanted to create Handling Units at each stage of Packaging, you can refer to my below Link..

Automatic Nested Handling Unit creation with Multilevel Packaging Instruction

Lets begin now..

I am creating a Sales Order for 256 No. of Boxes. Our Aim is to create Handling Unit at Pallet Level and the different Packaging Materials used inside the Pallet like Box, Carton, Pallet Mid Layer and Pallet Top Layer are the Auxiliary Packaging Material.

What i have done is for each of the Auxiliary Packaging Material, I have assigned a Packaging Material Type "0006". Lets look into this Material type to see what makes it Auxiliary Packaging Material Type.

Lets see for One of the Material PALLET LID, where the Material Type 0006 is attached in Material Master.

Now Lets go on to create the Delivery for the Sales Order.

Now we go on to Click on the Packaging Icon, to see if the Handling Unit has been generated automatically with the required Auxiliary Packaging Materials

As Seen below, we see that the Handling Unit has been created only at the Pallet Level. The Auxiliary Packaging Materials with their respective Quantities have been indicated in the below Screenshot

Save the Delivery...

Now lets see how we created the Handling Unit automatically with required Auxiliary Packaging Materials. The answer here lies in the Packaging Instruction creation.

What i have done is created a Packaging Instruction for Material BOTTLE as shown below with PALLET as Load Carrier.

Since a Packaging Instruction can have only one Load Carrier, all other Packaging Materials added in this Packaging Instructions will be termed as Auxiliary Packaging Materials

In Order to determine the newly created Packaging Instruction automatically at the time of Delivery creation, we will create a Packaging Instruction Determination Record for Determination Type "SHIP" for a combination of Material and Ship to Party as shown in below screenshots..

SpecialMovementIndicator:

It is always possible to influence the movement of material within WM via the special movement indicators. You can assign another movement type in the Warehouse Management System (WMS) to a movement type from Inventory Management using this indicator.

Since you can specify interim storage areas and interim storage bins within the WM movement types, you can determine which interim storage areas and bins will be selected in WM for a goods movement depending upon the special movement indicator used. You can thereby actively influence the interface between Inventory Management (IM) and Warehouse Management (WM).

CONFIGURATION

First Step:

As a part of Configuration, First Step is to Create the Special Movement Indicators in the below Path:

Logistics Execution --> Warehouse Management --> Master Data --> Material --> Define Special Movement Indicators

Created Special Movement Indicator ‘Z’ – Test.

Second Step:   Assign the WM Movement type to the newly selected Special Movement Indicator.

First assign the reference Movement type to Inventory Management Movement type

Logistics Execution --> Warehouse Management --> Interfaces --> Inventory Management --> Define Movement types --> Assign WM Movement Type References to IM Movement Types

IM Movement type 101 is assigned to Reference Movement type 101.

Then Assign the Warehouse Management reference to the Warehouse Management Movement type.

Logistics Execution --> Warehouse Management --> Interfaces --> Inventory Management --> Define Movement types --> LE-WM Interface to Inventory Management

WM Movement type 105 is assigned to the reference movement type 101 for Movement Indicator B Warehouse 008.

For the 101 Movement type at Inventory level, the Warehouse Movement would be 105 for all Materials with Special Movement indicator ‘Z’ . For others it would be 101.

Step 3:  Define Warehouse Movement type

Now Define the Warehouse Movement # 105 as per your requirements.

Logistics Execution --> Warehouse Management --> Activities --> Transfers --> Define Movement types

Step 4: Define the Storage type Strategies to determine the receiving Storage type based on the Reference storage type search as defined the Warehouse Movement type.

In the below Config, I have assigned Storage type EXW for Warehouse 008, Storage type Indicator 200 and Reference Storage type search 105

Logistics Execution --> Warehouse Management --> Strategies --> Activate Storage type Search

  Master Data

Maintain the below settings in the Material Master [WM View 1] for the warehouse# 008 as per above Configuration.

Special Movement Indicator – Z and the Storage type Indicator for Stock Placement – 200

With the above Configuration and the Master data, All the Materials received with Special Movement Indicator ‘Z’ would move in to Storage type EXW.