Skip to end of metadata
Go to start of metadata

Purpose

This process includes the steps after creation of the purchase order: notification, the inbound delivery, subsequent putaway of goods, and the goods receipt posting of the ordered goods.

Overview

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

  • Transfer order for inbound delivery: Like the outbound delivery, the inbound delivery is a request for putaway that is sent to the warehouse. You can create a transfer order for putaway from an inbound delivery.
  • Batch information: The batch split that is already possible for outbound deliveries is also available for inbound deliveries, since batches are often first identified in the inbound delivery.
  • Inventory management of packaging materials
  • Goods receipt for inbound deliveries

- Define order confirmation for inbound delivery: You can use this key to configure your settings such that planned inbound deliveries are automatically created through a collective processing run.

- Inbound delivery monitor

- Determination of goods receiving point

- Incompletion log

- Change documents

- Document flow for inbound delivery

DO NOT mix up the GR for inbound

Make absolutely sure that you do not mix up the goods receipt process for inbound delivery.

  • You must organize your tasks in such a way that the goods receipt posting is only
    executed using one of the two ways described:
  • VL32/VL32N/VL09
    or
  • MB0A/MBST/MIGO
    Please review the following details from SAP Note 199703

Table of Contents


a) Inbound Creation

Transactions:

1. VL31N, VL34, Idoc DESADV1 (standard cases)

MIGO, MB01, MB11

  • with or without reference to a purchase order
  • only for HU managed or decentralized storage locations
  • inbound deliveries are created automatically (instead of posting GR)- VLMOVE:
  • without reference to a purchase order
  • not only for HU managed or decentralized storage locations

2. VL31W: creation via Internet

3. SPED Output (from replenishment delivery)

4. VL60: All-in-one transaction

Conditions:

1. Processing VL31N, VL34, Idoc DESADV1 with respect to purchase order (item) if:

  • confirmation control key (EKPO-BSTAE) is set
  • no deletion or final delivery indicator is set (EKPO-LOEKZ/ELIKZ)
  • no return flag is set (EKPO-RETPO)
  • purchase order is released and completed (EKKO-FRGRL/MEMORY)
  • purchase order can be locked
  • document category must be "purchase order" or "scheduling agreement" (EKKO-BSTYP)

Differences Between VL31n and VL34:

1. VL31N: (processing the last inbound delivery in dialogue mode)

  • accepts only confirmation control keys with internal category "shipping notification" (T163D-IBTYP)
  • authority check is done with object 'M_BEST_'

2. VL34: (mass transaction, processing in background)

  • accepts confirmation control key only if automatic flag is set (T163L-AAGEN), but no special internal confirmation category "shipping notification" is needed
  • no authority check is done
  • Further differences are described in SAP Note 386409 , that especially describes the quantities that are taken over.

b) Goods Receipt via Inbound Delivery

Goods Receipt via Inbound Delivery

History and Goods Movement Relevance

Up to release 4.5

Since release 4.5

  • Shipping notification as document without relevance for goods movement
  • The shipping notification has become an inbound delivery that is relevant for goods movement if the following holds:
  • Goods Receipt has been done with MB0A with respect to the purchase order or the shipping notification.
  • A movement type is assigned to the item category (TVLP-BWART)
  • Reference-to-vendor-confirmation indicator is set (T163G-WEZUO)

Processing Goods Receipt:

Inbound delivery as shipping notification (message)

  • TVLP-BWART or T163G-WEZUO is not set
  • no putaway relevance (or only SD putaway or Lean-WM relevance)
  • no relevance for goods receipt
  • GR with transaction MIGO/MB01/MB0A (cancelling with MB*)

Inbound delivery reflecting outbound delivery

  • TVLP-BWART and T163G-WEZUO are set
  • relevance for goods receipt
  • GR with transaction VL32N, VL06I (cancelling with VL09)

Before ECC6

Since ECC6

both processes shall not be mixed up

MIGO can also update document flow of inbound delivery, if SPM (service part management) function is activated.

Please read SAP Note 199703 : Goods receipt for inbound delivery using MB0A, MIGO, VL32

Please read SAP Note 1050944: GR for inbound delivery using inventory mgmt as of ECC 6.00

Inconsistency: Mix up of Both Processes:

Customer has created inbound delivery only as shipping notification, but wants post GR for it.

  • Make sure (by little correction report) that  LIPS-BWART = '101'  (normally) and LIPS-NOWAB is initial.
  • Apply correction report for status correction RVDELSTA

Customer has created inbound delivery with own goods movement status, but wants to post (or has posted) with MIGO. Delivery shall be finished in its status (and possibly deleted).

  • Apply correction report Z_COMPLETE_INBOUND_DELIVERY.
    Please read SAP Note 570991: Correction report for completing open inbound deliveries

c) PO Update from Inbound Deliveries

Find about Update from Inbound Deliveries


d) Partial Goods Receipt

Find about Partial Goods Receipt