2022-06-04 2190855

2190855 - quantity discrepancies between GI and GR

with EWM relevant inbound deliveries in STO process
Version 16 Type SAP Note
Language English Master Language English
Priority Recommendations / Additional Info Category Consulting
Release Status Released for Customer Released On 27.11.2020
Component LO-SPM-STO ( Stock Transfers )

Please find the original document at https://launchpad.support.sap.com/#/notes/ 2190855

Symptom

You use EWM for an STO process with replenishment delivery and inbound delivery.

One main difference between an integrated STO scenario and an EWM related scenario is:

In the integrated scenario, you can react directly in the GR processing if there is a quantity discrepancy. If
there is too less quantity, you post GR the whole quantity and afterwards you post into scrap or make a
return. If there is too much quantity, that has to be posted, you create an additional replenishment delivery
with the quantity difference and post it GI.

In case of a receiving EWM, ERP has to execute the GR in the same way as EWM does, also with quantity
differences. If EWM closes the GR process, ERP has to close the GR process as well, and then in a way that
the purchase order history contains in sum the same GI quantity, the same GR quantity and the same
delivery quantity for all items, so that it can be closed and archived finally.

Other Terms

POD exception process, VR 537, VR537, AIPLOC000, /SPE/VL206

Reason and Prerequisites

Problems with quantity differences coming from a receiving EWM in an STO process can only be solved by
following the "STO discrepancy process". If you possibly get quantity differences between GI and GR, you
have to use this process in general, there is no other possibility in SAP standard.

This note describes the necessary settings and steps.

Solution

Settings:

1. You have to activate the BC-Set /SPE/STO_DISCREPANCIES.

It contains the necessary entries for tables /SPE/EXCP_REAS, T156N and for the output types UPOD and
RPOD.

2. The items of the replenishment delivery must be relevant for POD (POD relevance in item category and
ship-to party has to be set).

3. You have to define a 'POD' storage location for the supplying plant of the STO / replenishment delivery in

© 2022 SAP SE or an SAP affiliate company. All rights reserved 1 of 6

2022-06-04 2190855

IMG, "Logistics Execution -> Extended Warehouse Management Integration -> Cross-Process Settings ->
Proof of Delivery -> Define POD Storage Location for Shipper Discrepancies".

This POD storage location has to be a pure IM managed one and must allow negative stock. Negative stock
must also be allowed for the valuation area and in material master data.

4. In EWM, the process code 'SHIP' ('PREF') and 'CARR' must have the flag 'Send to External System' set in
the customizing under: "Extended Warehouse Management -> Cross-Process Settings -> Delivery
Processing -> Process Codes -> Maintain Process Code Profiles" for the profile
/SCWM/INB_PRD_DLV_TRANSFER. Also one of them must be set as "Default" so that quantity changes
result in either "CARR" or "SHIP" process codes.

5. You have to assign the inbound delivery type you use to an Output Determination Procedure in IMG that
contains output type UPOD. The new Output Determination Procedure SPEV10 fulfills this requirement. The
same has to be done for the outbound delivery, but on item category level you use, to get output type RPOD
that works on item level. The new Output Determination Procedure SPEV21 has been designed for this to
work with RPOD.

Both messages have to be found with the usual conditions in transaction NACE:

UPOD: select E1 > condition records > select output type UPOD > create an entry for the inbound delivery
type

RPOD: select V2 > condition records > select output type RPOD > create an entry for the replenishment
delivery type

if the messages can still not be found, please see in the delivery under Extras->delivery output and then
Goto->determination analysis

Steps:

1. During GI (or afterwards with VL71) to the replenishment delivery, the inbound delivery has to be created
(as a 1:1 copy of the outbound delivery) with message type SPED. SPED is the only possibility to guarantee
a unique reference from the inbound delivery items to the outbound delivery items (via fields LIKP-LIFEX and
LIPS-LIFEXPOS). Otherwise you get error message VR537: "There are no delivery documents for these
selection criteria" or error message AIPLOC000: "Incorrect callup of function module
AIP01_PLANT_DETERMINE".

2. The outbound delivery shall not be manipulated in its POD data (making entries or confirming) by
transactions VLPOD* or Idoc IDOC_INPUT_STPPOD.

3. The inbound delivery is distributed to EWM immediately even if the delivery type has the setting of delayed
distribution.

4. When EWM detects quantity differences, it has to set an exception code 'SHIP' ('PREF') or 'CARR'. 'SHIP'
means that the source of the quantity difference has to be found in the supplying plant, 'CARR' means that
the carrier is responsible for the quantity difference.

5. EWM reports the exception code to ERP. It is translated there with table /SPE/EXCP_REAS into the ERP
reason code. This table contains also the POD reason for over- and delivery. Its IMG path is:

"Logistics Execution -> Extended Warehouse Management Integration -> Cross-Process Settings -> Proof of
Delivery -> Define Mapping for Warehouse Exception Code".

6. As long as the closing indicator is not set from EWM, the delivery item in ERP remains also opened. In

© 2022 SAP SE or an SAP affiliate company. All rights reserved 2 of 6

2022-06-04 2190855

case of reducing delivery quantity and posting (partial) goods receipt(s) (underdelivery case), nothing
happens in this time. In case of increasing the delivery quantity (overdelivery case) and posting (potentielly)
goods receipt more than the stock-in-transit stock contains (in case of CC STO: the dynamic stock-in-transit
stock), more stock is needed.

In case of reason code 'CARR', the additional stock is simply posted GR with movement type 501 (derived
from table T156N: 641+FCODE POD_CR_O / 643+ FCODE POD_CR_O_CC in CC case).

In case of reason code 'SHIP' ('PREF'), the additional stock must come first from the POD storage location of
the supplying plant into stock-in-transit stock with movement type 641 (derived from table T156N:
641+FCODE POD_SH_O) or (in CC case) with movement type 643 (derived from table T156N: 643+FCODE
POD_SH_O_CC). Then the additional stock is posted GR with 101 also (as the original quantity).

7. At some time, EWM has to set the closing indicator for the items. At this point of time, also the case of
underdelivery must be handled, because now there is still stock remaining in stock-in-transit stock.

In case of reason code 'CARR', the remaining stock is posted GR with movement type 101 and then (in the
same posting step) posted GI with movement type 502 (derived from table T156N: 641+FCODE POD_CR_U
/ 643+ FCODE POD_CR_U in CC case).

In case of reason code 'SHIP' ('PREF'), the remaining stock has to be posted back to the supplying plant, i.e.
into its POD storage location with movement type 642 (derived from table T156N: 641+FCODE POD_SH_U)
or (in CC case) with movement type 644 (derived from table T156N: 643+FCODE POD_SH_U_CC).

7a. Steps 6 and 7 have made sure now that the GI quantity is the same as the GR quantity in the STO
process.

7b. Note that this process can work only if the GI movement type is unique. Therefore SIT processes are
excluded, because they contain normally more than one GM step before the final GR.

7c. Note that this process can work only if intra company processes get (normally via delivery type NL)
movement type 641 and cross company processes (different company code of supplying and receiving plant
in PO) get (normally via delivery type NLCC) movement type 643! If you use e.g. movement type 641 for the
intercompany process, you will get an error message.

8. If the closing indicator is set from EWM, we know that the items get no quantity change any more. In this
moment, apart from point 7, also a message UPOD is triggered from the inbound delivery that contains the
relevant quantity differences together with the POD reason for overdelivery (normally 'DFG1') or
underdelivery (normally 'DFG2') from table /SPE/EXCP_REAS.

9. This UPOD message is sent to the replenishment delivery, only once if all inbound delivery items have got
their closing indicator, or each time for all delivery items that just got their closing indicator. In the last case
the message has been setup for multiple sending. This is also the better variant if you have additional
inbound delivery items that are not relevant for EWM and never get a closing indicator, else the message
would have never been sent.

10. POD differences can be assigned to the items of the replenishment delivery because of unique reference
of the inbound delivery items to the outbound delivery items, guaranteed in point 1.

10a. Note that only POD informations are sent for items with reason code 'SHIP' ('PREF').

10b. Note that LIKP-LIFEX has to contain the exact ID of the outbound delivery delivered in SAP standard by
SPED. If there are missing leading zeros, the outbound delivery can possibly not be read. The same holds for
LIPS-LIFEXPOS that must contain the item ID of the outbound delivery.

© 2022 SAP SE or an SAP affiliate company. All rights reserved 3 of 6

2022-06-04 2190855

11. Based on the POD data in the replenishment delivery, the internal invoice can be created.

12. GR quantity = GI quantity. But the original delivery quantity still differs from both quantities in PO history
and the POD storage location has an unbalanced stock situation. Therefore a RPOD message is processed
on outbound delivery item level that creates a correction delivery with the following properties:

• It corrects the stock situation of the POD storage location with help of the originally supplying storage
location.
• It updates the PO history to make the delivery quantity = GR quantity = GI quantity.
• It has no PO reference any more after this update, so that any GM with respect to the correction
delivery does not harm the balance of the STO history any more.

12a. In case of underdelivery, an inbound delivery (normally delivery type DIG) is created that transfers with
movement type 312 (without STO reference: 501) the quantity difference from the POD storage location to
the supplying storage location.

12b. In case of overdelivery, an outbound delivery (normally delivery type DOG) is created that transfers with
movement type 311 (without STO reference: 501) the quantity difference from the supplying storage location
to the POD storage location.

The movement types can be manipulated with movement type table T156N only as modification, via report or
SE16(N):

POD_CC_O _ -> 502

POD_CC_U _ -> 501

POD_UBQ_O _ -> 311

POD_UBQ_U _ -> 312

Remarks/Restrictions:

(A) Step 12. can only work if the supplying storage location is relevant for EWM (or decentral WM or HU), so
that indeed a delivery is created, otherwise only a material document will be created that will not have the the
second property mentioned in step 12 concerning PO history. (Actually, the STO discrepancy process has
been designed only for receiving AND supplying EWM!)

If the supplying storage location does not lead to a delivery instead of a material document, note 2104843
may help as a work around. The delivery has to be processed and posted then in the ERP system. It has to
be treated as a correction delivery with organizational means, so that it cannot mixed up with the normal
logistical documents.

(B) The STO discrepancy process is incompatible with the SIT process. Reason is mentioned in step 7b. and
in note 1682012, solution long text.

(C) Like in classic POD process, the STO discrepancy process can only handle quantity differences, not
other differences in batch, valuation type, serial number, or suggest a complete HU that has to be posted
back within correction delivery creation. Also if different deliveries have been mixed up, there is no clearing
function within the STO discrepancy process.

(D) A correction delivery shall never be changed manually in quantities or refused/deleted.

(E) The "STO discrepancy process" has only been designed with a receiving EWM system. It cannot be
applied without receiving EWM, and there is no work around to make this happen in an ERP integrated
scenario.

© 2022 SAP SE or an SAP affiliate company. All rights reserved 4 of 6

2022-06-04 2190855

(F) The "STO discrepancy process" can only work with the 1:1 design between inbound and outbound
delivery items designed with message type SPED. The original GI quantity of the outbound delivery items is
stored in the inbound delivery items (in field LIPS-ORMNG). Depending on this quantity, quantity differences
can be recognized. Therefore, the whole process will NOT work, if you create NEW inbound delivery items
during the GR process from the old ones, e.g. within a batch (or valuation type) split structure that didn't exist
in the outbound delivery, or with an inbound delivery split triggered from EWM. In these cases, the new items
have NO memory about the original quantity (LIPS-ORMNG cannot be inherited in any way) and therefore
cannot recognize or compute quantity differences.

Software Components

Software Component Release

SAP_APPL 600 - 600

SAP_APPL 602 - 602

SAP_APPL 603 - 603

SAP_APPL 604 - 604

SAP_APPL 605 - 605

SAP_APPL 606 - 606

SAP_APPL 616 - 616

SAP_APPL 617 - 617

SAP_APPL 618 - 618

S4CORE 100 - 100

S4CORE 101 - 101

S4CORE 102 - 102

S4CORE 103 - 103

S4CORE 104 - 104

Other Components

Component Description

LO-SPM-INB Inbound Process

LO-SPM-OUT Outbound Process

© 2022 SAP SE or an SAP affiliate company. All rights reserved 5 of 6

2022-06-04 2190855
LE-SHP-DL-STO Stock-Transfer-Order

This document is referenced by

SAP
Title
Note/KBA

3142235 no (or wrong) difference quantity posting when finishing GR for inbound delivery from EWM

2456392 Prevent split of inbound deliveries in STO process

The queues from EWM to ERP stuck in SMQ2 with the following error: "No exception code could be
2388385
determined for quantity difference in item XXX"

error message AIPLOC000: Incorrect callup of function module AIP01_PLANT_DETERMINE during

2217342
GR

Terms of use | Copyright | Trademark | Legal Disclosure | Privacy

© 2022 SAP SE or an SAP affiliate company. All rights reserved 6 of 6