Executing the Goods Issue Process in a Distribution Center

The outbound delivery document is the central document in shipping. It forms the basis for further shipping activities such as picking, packing, and goods issue posting.

After creating outbound delivery documents (normally for stock transport orders or sales orders), you can group them together in wave picks (work packages for the goods issue processes that have to be processed during a specified time interval), if necessary. This can be done for example to map the shift plan of the warehouse. The outbound deliveries have to be picked, and can also be packed. Finally, they are ready for goods issue posting.

The standard version means that the picking storage location is not connected to a warehouse management system. Therefore, the picked quantities are directly maintained in the delivery, and after (optional) packing, the goods issue can be posted. In contrast, if the merchandise is picked from a full WM storage location, then a separate picking document is generated, the transfer order. The system determines the relevant picking storage bins based on the assigned picking strategy. The picking activities have to be confirmed. However, if desired, automatic confirmation can be set in customizing. It is possible to connect radio frequency devices, for example for voice picking to support the picking processes. With confirmation of the transfer order, the picked quantities are updated in the outbound delivery, which is then ready for goods issue posting.

Using Lean Warehouse Management (WM), you execute picking using transfer orders (picking requests), even though no storage bins are managed in the system. In Lean WM, neither the putaway processes nor the picking processes that use WM strategies are executed as follow-up processes in WM. This means that stocks are not updated at storage bin level using quants. Instead, goods receipt and goods issue processes are actually carried out at storage location level. Still, you can assign a fixed storage bin to the article/DC in the article master, which is later included in the transfer order as information for the picker.

The processes in Lean WM are fundamentally the same as those in standard Warehouse Management. For the picking step in the goods issue process, transfer orders are created for the outbound delivery items. The other structures in WM (storage types, doors, staging areas, storage sections) can be mapped in Lean WM in exactly the same way as in WM.

The shipping point is the organizational unit in the SAP system that is responsible for the execution of goods issue processes (and, as receiving point, for inbound processes). Consequently, it can be found in the header of the delivery documents. It is determined for a combination of the recipient’s shipping condition (for example, express), the article’s loading group (for example, forklift) and the supplying site.

Before you can provide your customer a delivery date for a particular article, the system needs to know all the necessary lead times for the different steps in the goods issue and transportation processes.

You can define time periods for preparation and loading merchandise for the shipping point.

The shipping point is normally determined automatically for each item in the sales document. The value proposed by the system can be changed manually at a later date if you have defined alternative shipping points for your DC.

When deliveries are generated for purchase orders and/or sales orders (referred to as PO/SO in the previous figure, Shipping Point), a delivery split might apply. This occurs when (based on the shipping point determination criteria) a different shipping point is determined for the items in a preceding document. For example, this could happen when different loading groups are assigned to the articles.

Outbound delivery documents consist of a header and any number of items.

The header contains data that is valid for the entire document. For example, this includes the recipient, the shipping point, and possibly the route.

The items contain all relevant information about the articles that are going to be delivered.

The information in the outbound delivery document is displayed in different screen areas:

The overview screen contains much of the header and item data, which are organized thematically in tab pages. This allows the user to find a lot of important data on the same screen.

An additional screen each is available for displaying detailed information at header level and item level. This data is also grouped in tab pages.

For example, at header level you can access data on processing, picking, loading, transportation, global trade services/customs, texts, partners, messages, parcel tracking, and conditions.

The item detail screen displays tab pages containing item-related information, such as processing information, material, and picking details, loading and shipment data, and so on.

When an outbound delivery is created, several background activities can be performed by the system, depending on customizing settings. For example, these are (re-)scheduling, (actual) route- and route schedule determination, door/picking zone determination, a (new) ATP check, and picking location determination.

The outbound delivery monitor displays outbound deliveries that are still to be processed, or which are already completed.

Numerous criteria exist for selecting the desired documents. You are going to receive a list of the selected deliveries and you can start the subsequent functions for further processing from the list. This also includes processing messages that have to be created during the goods issue processes (for example, generating delivery notes). In addition, information from the delivery document can also be called, such as the document flow. You can create user-specific variants for selecting and for displaying the documents (selection variants or display variants).

You can also use the outbound delivery monitor to execute important subsequent functions in collective processing in the background (for example, create transfer orders for picking, or posting goods issue).

The inbound delivery monitor provides you with the corresponding functionality for monitoring and performing inbound delivery activities.

You can manually or automatically trigger the printing of the picking list(s) for the warehouse from the transfer order. Instead of printing the pick list, you can, for example, pass the transfer order data to mobile/voice picking devices using radio frequency, or to an external warehouse management system, possibly also using mobile data capture (MDC) units.

If you have not set up automatic confirmation, you can confirm picked quantities manually when monitoring and checking the picking process. You can also confirm deviating quantities and record the reason for the variance by setting a variance indicator.

If the entire quantity can not be picked, you can do the following:

• Perform picking for the open quantities using an additional transfer order

• Reduce the quantities for delivery by copying the picked quantity

In the customer master data, it is possible to define percentage values for under- and over-deliveries (on the basis of the order quantity). When shipments occur with quantities within those tolerance limits, they are accepted, and the respective delivery item can be considered completed.

If you use the Warehouse Management (WM) system for picking, you have access to additional functions for WM transfer orders. This is also true for lean WM.

You can generate more than one transfer order from a single delivery, for example, when you want the system to split by picking area, or to distribute the workload to different resources (for example, manual picking, forklift, and so on). Several split criteria can be used in parallel.

With radio frequency, the system user ID is used to identify the user who processes a transfer order. Step-by-step confirmation means first the removal from the storage bin (quant) is confirmed, and then the merchandise is posted to the destination storage type/bin in the second confirmation.

In Customizing, you can determine that the transfer orders should be confirmed automatically. This means with the creation of the transfer order (TO), the initial statuses ’A’ for both the picking and warehouse management status (columns OPS / Pick.stat and WM / WMStat in the previous figure), automatically switch to ’C’.

If confirmation is required in a separate step, then with the transfer order creation, the warehouse management status only switches to ’B’. The confirmation by the picking agent then leads to WM status ’C’.

The picking confirmation status (columns C, and Confir... in the previous figure) is updated accordingly. The initial value is ‘blank’ (not relevant), and switches to ‘C’ (completely processed) when either the transfer order with automatic confirmation is generated, or when the picking agent confirmed the activity in case confirmation is required in a separate step. If only a partial quantity can be confirmed by the picking agent, status ‘B’ (partially processed) is available to track this entity.

The picking status is as follows:

• <blank> = Picking not relevant

• A = Picking not yet processed (but the item is picking relevant)

• B = Partially processed

• C = Picking completely processed

The WM status is as follows:

• <blank> = Not relevant

• A = Not yet processed (TO required)

• B = Partially processed (TO created, but not confirmed yet)

• C = Completely processed (TO confirmed)

Transfer orders, and with that picked quantities (Pick quantity field), have to be confirmed before the goods issue can be posted.

You can set up automatic confirmation, for example, when from an organizational point of view you can more or less guarantee that picking quantity variances occur very rarely, and would be reported promptly.

With the confirmation requirement active (WM status B), quantity differences can be captured during confirmation. You can also record the reason using the difference indicator.

The confirmation requirement is defined for each storage type in Customizing. It is sufficient if either the "removal from storage" from the ’from’ storage type or the putaway in the "to" storage type is set as requiring confirmation.

Handling Unit Management

The term, handling unit (HU), is the SAP term for a package (pallet, container, and commercial truck) and describes a physical grouping of packaging materials (for example, pallets, cardboard boxes, shrink wrap, containers, and commercial trucks) and merchandise (for transport, storage, and consumption).

Each handling unit has a unique identification number, so that it can easily be identified in the system. All data, such as packed merchandise, packaging materials, quantities, dimensions, can be read using this number.

Handling Unit Management enables you to control packaged stock at storage location level. For each storage location, you can define whether the handling units for the stock in this location keep stock autonomy or not.

Goods movement postings to storage locations, which are managed using handling units, are only possible if you specify the handling unit that contains the stock to be posted.

When handling units are changed, unpacked stock is reposted to non HU-managed storage locations, and packed stock is reposted to HU-managed storage locations.

Using Handling Unit Management, you can map packing-controlled logistics in the SAP system. Here, you do not generally process individual articles, but instead a number of articles that are grouped to form a package.

The aim is for the handling units to remain unchanged on their way through logistics. When the handling units were created, all subsequent processes can use this information. In particular, they can be moved through the entire logistics and passed on to partners in the supply chain. If necessary, they can also be changed, of course.

The procurement supply chain includes documents such as the purchase order, notification, inbound delivery, putaway, and the goods receipt posting of the ordered merchandise.

The main advantage of mapping the goods receipt process using an inbound delivery is that you can carry out a number of processes before the actual goods receipt is posted. The inbound delivery describes exactly which articles or which pallets can be expected to arrive at what time.

The following functions are available with the goods receipt process for the inbound delivery:

• Transfer order for inbound delivery

• Batch information

• Inventory management of packaging materials

• Inbound delivery monitor

• Determination of goods receiving point

• Incompleteness log

• Change documents

• Document flow for inbound delivery

The delivery item category determines if packing for an item is optional, mandatory, or not allowed. Packing involves assigning delivery items to packaging materials. The handling units (HU) that are created during this process can then be packed in further packaging material. This creates new handling units. There is not really a limitation to the number of levels that can be used in multilevel packing, as the number of possible packaging levels is 999999.

In addition to the normal packing of delivery items in handling units, you can have the system automatically distribute an item quantity in equal amounts over several handling units (packing per partial quantity). If you want to pack items, but do not know in advance how many handling units you require, you can have the system create a new HU if one is full.

The HU is assigned a number from a defined number range or it can be identified using an SSCC18 (Serialized Shipping Container Code) number.

Items that have already been packed can be unpacked again. This is also the case for multi-level-packed handling units. Handling units can also be unpacked, emptied or deleted.

The packaging material to be used is defined in the handling unit header. The contents overview for the packaging material indicates which delivery items or handling units it contains, as well as all relevant quantities.

Automatic packing uses packing proposals to create HUs automatically in the background. For each delivery type, you can define if automatic packing should take place directly during delivery creation.

A packing proposal is defined either through packing instructions and the respective determination records, or customer-specific (BadIs).

The goods issue process is complete when the goods issue for a delivery is posted. Goods issue can only be posted if all the compulsory activities in the goods issue processes have been performed. For example, if you work with picking relevance and confirmation requirement, these steps must be completed.

Goods issue posting can be performed by changing an individual outbound delivery. Alternatively, you can use the collective processing via outbound delivery monitor to select all the deliveries that are ready for goods issue and then actually post goods issue. You can also schedule a selection variant of the outbound delivery monitor for background processing, or, if relevant, use the wave pick monitor for goods issue posting.

In addition, you can post goods issue by confirming the transfer order.

Situations where errors arise are logged - for example, if data are incomplete, or if items have only been partially picked. In such cases, the goods issue is not posted.

A goods issue enables the following:

• It reduces the warehouse stock

• It posts the value change to the stock accounts in article accounting

• It reduces the delivery requirements

• It updates the status information in the delivery

• It is recorded in the document flow

• It generates the worklist for billing (if billing is relevant)

• It posts a goods receipt in the receiving store at the same time, if the one-step stock transfer procedure is defined for the issuing and receiving site

• It posts the stock to stock in transit, if the two-step stock transfer procedure is defined for the issuing and receiving site

When the goods issue is posted, the editing options of the outbound delivery are limited. Quantities, in particular, can not be changed. The outbound delivery must exactly represent reality, that is quantities, dates, and so on, must be correct.

If you want to be able to execute billing also prior to goods issue using the Create Billing Document transaction, you can make the relevant setting in copy control for the billing document in Customizing.

Delivery notes can be printed for an outbound delivery before or after goods issue posting. A delivery note normally contains the delivery note number, the delivery date, the recipient and the individual delivery items. Delivery notes can also be sent using EDI.

The layout of the delivery note can be created flexibly using suitable forms. The retail price for each item can also be included in the delivery note, thereby making price labeling easier in the store.