Skip to Content
avatar image
Former Member

Delivery not showing up in MD04 - STO process

Hi all,

I've read a few threads on this subjects but haven't found my answer.

My problem :

checking group KP seems to take my STO (intra company) delivery out of the requirements.

My data & customizing:

material with checking group KP
Delivery type is ZNL copy of NL, Delivery item type is ZNLN copy of NLN and the Schedule line category is NN (standard no update).

My material has a copy of strategy 40 (Z4) giving a SD requirement class 50 (keeping atp check and requirement transfer active).

What my tests data shows:

CASE 1 - with the data above : STO comes in the supplying plant requirement list in MD04 and is MRP relevant. VL10B to create the Delivery : the Delivery doesn't appear in MD04 for the supplying plant (and of course the STO disappears). the Delivery doesn't appear in VBBE table.

CASE 2 - I change the checking group to 02 : STO is replaced by the Delivery which can be seen in MD04. in LIPS table, this Delivery has the exact same data as the previous one but it appears in VBBE table.


Why does the checking group have any impact on the requirement transfer?? if it is because NN category doesn't allow req transfer, then how come this seems to be ignored in the second case?
On another system both cases (KP and 02) work fine and my delivery is planned & mrp relevant but the customizing is exactly the same as shown above...

any thoughts?


ob22w.png (18.3 kB)
76rjs.png (20.5 kB)
zut39.png (19.0 kB)
qafck.png (8.3 kB)
qdgzo.png (13.4 kB)
Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

4 Answers

  • Best Answer
    Feb 23, 2018 at 03:04 PM

    I would not know how to help, this is just teeming with Z. and you also are saying that another system is working with these settings.

    I can hence just assume that the programs are different, maybe different release, maybe user exits or BAdIs which are different

    You may start with OSS notes which explain certain settings like this: 181990 - No transfer of requirement during check KP

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member


      I have spoken too fast, your OSS note was exactly what I was looking for as I was in an MTO process using project stock with WBS elements. On the other environment, I was also on MTO but only for half of the end to end process.

      many thanks

  • Feb 20, 2018 at 08:24 AM

    It is the standard that if the Availability Check is (MARC-MTVFP) set to 02, the related orders / deliveries will get updated in VBBE table. If the Availability Check is set to 01, then you need to check in VBBS table.

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member


      Thank you for your answer.

      My question is why am I not able to see my Delivery with availibility check = KP when I can see it with availibility check = 02 ?


  • avatar image
    Former Member
    Feb 23, 2018 at 02:28 PM

    Hello SAP community,

    Any help really would be much appreciated, and I am here to answer all questions you could have to be more precise!

    thank you

    Add comment
    10|10000 characters needed characters exceeded

  • Feb 25, 2018 at 11:04 AM

    Are you sure NN is the standard schedule line category? In my experience, it would be NL and the w/o MRP in the schedule line category rings my internal alarm bells.

    If the schedule line category is not MRP relevant and you have the checking rule set to KP (no checking?) then there is no reason to transfer the requirements data.

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member

      Hi Robyn,

      thanks for your answer, I agree NN seems to be MRP independant and so it would be normal, but this customizing has always transfered our requirements in the MRP without any enhancements.

      Is there a way to check the Schedule line category of a delivery? I've seen the table that links the line category to a sales order item but not to the delivery item.