Hi
This behavior could be because when an HU is transferred from an EWM-managed storage location to an ERP storage location that is also HU and WM managed, the system treats it as two distinct logistic areas, even though the EXIDV (external HU ID) remains the same. Upon posting the Goods Issue (GI), the HU in the source location remains in status 0050 (In Transit) instead of being closed, and when the same HU is received in the destination storage location, a new record with the same EXIDV is created in VEKP, leading to multiple entries for the same HU number.
This duplication in VEKP confuses transactions like LM18, which are designed to read one active HU record per EXIDV. Since the HU now has multiple records with different statuses or locations, the standard function module behind LM18 might pick the first matching record, which may not be the one actually relevant for the transaction, especially if the older HU record is still in status 0050.
To resolve this, you must ensure proper HU closure after GI in EWM or manual cleanup of HU statuses in ERP. After GI posting, if the HU is not physically returning or reused, it should be set to status 0060 (Closed) to prevent system reuse or confusion. Alternatively, if the HU is still active and being reused, you need to update the original HU record instead of letting the system create a duplicate.
A recommended approach is to avoid creating multiple VEKP entries for the same EXIDV. This can be enforced by controlling the process through BAdIs or enhancement points at the interface between EWM and ERP, specifically at the point where the inbound delivery or putaway is processed. Also check if the system is configured to allow HU reuse or new HU number assignment upon receipt. Review the HUMO transaction to analyze HU lifecycle and use the report HUMO_DELETE_SINGLE_HU if needed to clean obsolete HU records.
Br
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.