cancel
Showing results for 
Search instead for 
Did you mean: 

Confirmation control key check for inbound delivery creation

0 Kudos

Hi,

Currently, in the Client's company, the process of receiving goods from purchase orders looks like that (SAP-wise):

- create a purchase order,

- receive goods using MIGO and automatically create an inbound delivery,

- pack the delivery and post goods receipt.

Recently, some patches have been installed, including one described by note 1602047 (which basically enforces checking confirmation control keys if goods receipt assignment and goods receipt relevance are activated for inbound deliveries). Note says that it only affects two-step stock transfer and creation of automatic inbound deliveries using SPED output but it seems it also affects other basic processes like PO receipt in MIGO.

Now, when using the old control key (that had MRP-Relevant and GR-Relevant fields checked), the system is unable to automatically create an inbound delivery after the goods receipt is posted with MIGO (with message VL148 - Not possible to create an inbound delivery). I learned that this is because the "GR Assignment" field must be checked in the confirmation control key so it's possible to automatically create aninbound delivery after receiving a purchase order in MIGO.

After changing the confirmation control key to have the missing field checked it's not possible anymore to receive goods from PO in MIGO as the PO requires shipping notification in order to be processed in MIGO thus requiring of manual creation of an inbound delivery.

Is there any way to skip this check so the process would remain the same (this model has been working fine for few years in the Client's system) and the inbound delievery would be created automatically after posting the receipt in MIGO?

Thanks in advance,

Piotr

Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

Hi Piotr,

we seem to have the same problem at one of our clients.

Did you manage to resolve this issue? Would you be so kind to share your solution?

Thanks in advance!

Leentje

Former Member
0 Kudos

Hi,

don't know if you found a solution, but we received the following message from SAP:

The advent of the new version requires some attention to the users. It
was necessary to avoid inconsistencies which in the past version the
system was susceptible.

Main Program SAPMM07M
Source code of MM07MLVS
sy-msgid VL sy-msgty E sy-msgno 148

I have checked the process and through debugged I could confirm the
following information SAP is providing to all similar incidents reportedfor us:

Error message VL 148 is issued if in the confirmation control key used
in the purchase order, the fields for MRP-relevance (T163G-KZDIS),
GR relevance (T163G-WEREL) and GR assignment indicator (T163G-WEZUO)
are not set.

The correction of note 1602047 was necessary to avoid inconsistencies
(table EKES) in the purchase order. Without having the GR assignment
(T163G-WEZUO) set, there is no unique reference created between the
purchase order history (table EKBE) and the inbound delivery
confirmation (table EKES) at goods receipt which leads to a problem if
several inbound deliveries exist for the same purchase order.
If you set T163G-WEZUO to 'X', this assures that, for an inbound
delivery, the confirmation record (EKES) belonging to this inbound
delivery (EKES-VBELN) is also accurately updated at goods receipt.

How to solve the issue?

Use a confirmation control key with the GR assignment indicator set
and then create the inbound delivery with VL31N. If you want to be able
to create the inbound delivery with reference to a certain line item in
the PO, use transaction VL34.

If you still want to use transaction MIGO, there is the following
workaround:

- Create a purchase order without any confirmation control key
- Create a goods receipt (GR) in transaction MIGO with reference to this PO and post the GR to a non-HU-managed storage location
- Create a transfer posting with MIGO using movement type 311 to
transfer the goods from the non-HU-managed storage location to the
HU-managed storage location.

As the transfer posting is an additional step for the user, the whole
process could be automated using a partner storage location
(T001l-PARLG) for the GR which then triggers (through a modification)
the BAPI 'BAPI_GOODSMVT_CREATE' to create the transfer posting without
user interaction.

I hope to have satisfied you on the reason why it is now happening and
also I believe you can explain to business that it is a new behavior
necessary done from SAP side to avoid worse situations, we are aware of
potential dissatisfaction it might cause. SAP Support is always
available to clarify any issue.

Sorry for not having a more positive answer.

I hope it helps!

Leentje

rob_smeets2
Participant
0 Kudos

Hi,

This has recently been fixed, apparently, by note 1716889. Just fyi