MRP run on materials shared between plant and MRP area

[guruck]

Hi Team,

We have materials (say material A) produced both at the plant (say 0001 Sloc) and the MRP Area (say 0002 Sloc). After the MRP run on requirements for A at both 0001 and 0002, the planned orders on A at both 0001 and 0002 are cascading the dependent requirements on the BOM components (say B and C) only on 0001 Sloc. I can't update the Sloc in BOM as the material header is same (which is A).  We need to have the clear segregation of the requirements of B and C between 0001 and 0002 based on where the planned orders are created for A. Can someone please help on how to achieve this?

Thanks,

Regards, Guru

[preiss_consulting · Accepted solution]

there are ways to achieve this.

First have a look at MRP customizing 'Define Storage Location and Supply Area Determination in BOM Explosion'   ( SPRO ... MRP -> Procument Proposals -> Planned Orders ) .

For any solution you will need separate production versions, one for Plant MRP area with receiving SLoc 0001 and another one for SLoc 002. One solution would be to maintain separate BOMs in the prod. version with the corresponding component SLoc maintained in the BOM items. The other solution is to use the same BOM with empty SLoc in the BOM item in both production versions, maintain the Issuing SLoc in the production versions (0001 for the plant Prod. version and 0002 for the other) and set the SLoc determination customizing for the component so that the SLoc is inherited from the prod. version.

[guruck · Accepted solution]

I have the BOM on the material A at the plant location (default 0001). And I maintained a production version as well for this material. I didn't get when you stated 'separate' production versions - how do I maintain a production version at MRP area? In addition, even if I have different production versions, how do I let the MRP know which production version to read when there is a demand on material A. I need more clarity on your 'latter' solution - single BOM, and multiple production versions with different issuing Sloc. I will have the same question - how do I let MRP know which PV to consider while planning the material A?

[preiss_consulting · Accepted solution]

a production version (PV) with empty receiving storage location (RecSLOC) ist valid for all MRP Areas in the plant. A PV with a RecSLOC is valid only for the MRP Area which contains this SLoc.

[guruck · Accepted solution]

I tried with receiving sloc in PV, but that doesn't cascade that sloc on to the components which is what is my requirement. Though the selection of the production version now is appropriate, the dependent demand on the components from the planned orders of the header at 0002 still are showing up on the 0001 sloc. I need to have the component demand to reflect on the same sloc from the corresponding planned order.

[preiss_consulting · Accepted solution]

see my original comment: ... First have a look at MRP customizing 'Define Storage Location and Supply Area Determination in BOM Explosion' ( SPRO ... MRP -> Procument Proposals -> Planned Orders ) .... .... and set the SLoc determination customizing for the component so that the SLoc is inherited from the prod. version.

If you dont success then you might want to describe the settings you tried and their results. Then maybe somebody is willing to help with further answers.

[guruck · Accepted solution]

I tried with strategy 2 from the available options from 1-4, it is reflecting rightly the Sloc of the header only on the component which is not an assembly. for an assembly component, it doesn't take up the Sloc 0002 from header planned order but the dependent requirement is reflected on 0001. I have tried all possible values from 1 to 4 and it still doesn't work. Any feedbcack?

[guruck · Accepted solution]

It finally worked! Very much thanks for this consultation when I almost thought this is not possible in standard! Really helpful and kudos the support. The reason it didn't work with strategy 2 previously was because I mistakenly hardcoded the sloc in the BOM to 0001 for the assembly which I blanked out for the fix.