cancel
Showing results for 
Search instead for 
Did you mean: 

Switching between MTO and MTS dynamically

rafael_zaragatzky
Active Contributor
0 Kudos

Dear Forum,

My client has the following requirement. They mix MTO and MTS production in the following way.

A sales order defines if it should be MTO. In such case the SO segment is created in MRP for the finished product. This is standard SAP and it is fine.

The question arises if the components shall also be planned MTO or MTS. Normally one would control this using the indiv./coll. reqmt flag in the material master of the components (MARC-SBDKZ), i.e. a component is always MTS (= collective reqmt) or it can be MTO if the finished product is MTO (= individual reqmt). This is standard SAP.

However, my client has the requirement to plan the components differently under different circumstances. If the dependent requirements are created for especially big sales order ("bulk order"), some of the components need to be planned in the SO segment too. For "normal" orders these components need to be taken from the general stock (even though the finished product is MTO).

My plan was to interfere in the MRP program at the point where it is about to create dependent requirements and reads the material master for components. The user exit will set the flag indiv./coll. as needed (dependent on the planned order being exploded). The problem is that MRP pre-fetches the material master for all the components when it starts to plan the product - before it starts evaluating the individual planned orders. At this point I can't set the indiv./coll. flag yet.

Therefore I am looking for the place where the pre-fetched material master data are considered again for creation of dependent requirements.

...Or an alternative way to meet this requirement.

Many thanks in advance,

Raf

Accepted Solutions (1)

Accepted Solutions (1)

Caetano
Product and Topic Expert
Product and Topic Expert
0 Kudos

Hi Raf

I think that you can do the trick with method CHANGE_MDPSX_MDRS from MD_CHANGE_MRP_DATA.

If you change the reservation before MRP reads it, then, your requirement will be planned as MTO.

The, when you convert the order you can use WORKORDER_GOODSMVT to update the order reservation on the database.

BR

Caetano

rafael_zaragatzky
Active Contributor
0 Kudos

Thanks, Caetano.

Yes, I am on my way to test this BAdI. I need only to prepare an example in the development system.

My plan is to merely substitute the MRP segment in the method CHANGE_MDPSX_MDRS and see what happens. When do you mean I shall call WORKORDER_GOODSMVT? And what is this name? There's no such function module.

BR

Raf

Caetano
Product and Topic Expert
Product and Topic Expert
0 Kudos

Hi Raf

This is a BAdI that can be used to update the production order components.

As CHANGE_MDPSX_MDRS does not update data on the database it may be necessary to use the other BAdI to change the reservation on the production order.

BR

Caetano

rafael_zaragatzky
Active Contributor
0 Kudos

Gues what! Seems like CHANGE_MDPSX_MDRS worked, even though I was skeptic to it (touch the wood!)

I have just replaced the MRP segment 20 (SO) with 02 (stock) and cleaned the segment no. and that's it! The MRP generated the dependent reqmts in the general segment despite the fact that the planned order was in the SO segment and the component had indiv./coll. = space in the material master!

Now I only need to program this logic when to switch back to the general segment and then have indiv./coll. = space on all the components that need to be "dynamic".

Thanks a ton again for the tip!

Raf

Answers (4)

Answers (4)

former_member208398
Active Contributor
0 Kudos

Dear Raf,

Conceptually there might be another 'not so good' solution. I thought over it and I know it may sound odd and complex. I need all you guys' experience and comments regarding this proposal, since this sounds funny. Can we use the concepts of variant configuration in this kind of scenario?

That is, we maintain these components inside the BOM twice, one having 'individual', whereas another having 'collective' requirement, controlled by the explosion type in BOM component level. We have object dependencies (selection condition) defined, such as when in SO, you select characteristic 'requirement' = MTO (characteristic value), the component entry with the individual requirement gets selected and similarly when 'requirement' = MTS (characteristic value), the component entry with the collective requirement gets selected.

The planned orders will be generated accordingly controlled by the SO.

Can this be 'conceptually feasible'?

Best Regards,

Rajen

rafael_zaragatzky
Active Contributor
0 Kudos

Hi Rajen,

Sounds like a good solution if one wants to stick to SAP standard. Unfortunately I am not familiar with variant configuration and I think my client will not like the idea of introducing this new functionality... Especially that there's a programmable solution with the BAdI above.

Thanks anyway for the brilliant idea - I appreciate it!

Raf

shailesh_mishra5
Product and Topic Expert
Product and Topic Expert
0 Kudos

Dear Rafael,

I have similar requirement. Can you please share the Custom Logic which have put on Badi MD_CHANGE_MRP_DAT.

Appreciate your reply

Best regards

Shailesh

rupesh_brahmankar3
Active Contributor
0 Kudos

Dear,

Do you want to have the header material in always in individual customer segment?

If not then you can work with requirement type for bulk order you should have MTO requirement type like KE. And other you can have the MTS requirement type like KSV.

You can the stratgey group with combination of MTO and MTS strategy. For dependent demand material keep ind/collective indicator as blank.

So when you will have the Bulk sales order all the material will be in individual customer segment and when non bulk order it will be MTS.

Regards,

R.Brahmankar

rafael_zaragatzky
Active Contributor
0 Kudos

Thanks, Rupesh.

The finished product is indeed sometimes MTO and sometimes MTS dependent on the item category (requirement type) in the sales order. This is not the issue.

The issue is that also the components need to be sometimes MTO and sometimes MTS, even if the product is MTO in the specific case. If I leave indiv./coll. empty in the material master of the component, it will always be MTO whenever the product is MTO...

BR

Raf

rupesh_brahmankar3
Active Contributor
0 Kudos

Dear,

Yes your are right by Item category you can have the requirements type in sales order like MTS and MTO.

If your order is MTO then your dependent materials will be MTO only and if your requirement type is MTS then your dependent material will be MTS.

Could you please test the same?

Regards,

R.Brahmankar

former_member208398
Active Contributor
0 Kudos

Dear Raf,

Since the order quantity determines the requirement type, can you control this using Explosion type control inside the BOM component field (STPO-DSPST)?

Suppose I have two alternatives for the header material, one for normal and another for "bulk" (say, greater than 100).

So I maintain two alternative BOMs and in material master of the component, the requirement type is collective (2).

In the alternative for "bulk", I configure a new explosion type with individual requirement and assign to the component.

Since the BOM component level data takes priority over the material master data, this can work.

Please try and revert back.

Best Regards,

Rajen

rafael_zaragatzky
Active Contributor
0 Kudos

Dear Rajen,

The data in the BOM is again static data, i.e. it can't change from one planned order to another of the same product. I checked if the parameter DSPST was also stored in the planned order. In such case I would be able to alter it using e.g. the BAdI MD_PLDORD_CHANGE above or the method CHANGE_MDPSX_PLAF of the BAdI MD_CHANGE_MRP_DATA.

But the field is not there in the table PLAF. Maybe it is replaced by some other parameter having the same function? I couldn't find one.

TIA again for any tip,

Raf

former_member208398
Active Contributor
0 Kudos

Dear Raf,

You can have alternative BOMs according to the header lot size. In one of the BOMs, you can have this component as individual whereas in another it can be collective by using the explosion type. MRP will choose the alternative according to the quantity of the header.

The main question is whether you have the boundary of the header lot size well defined or not.

Best Regards,

Rajen

rafael_zaragatzky
Active Contributor
0 Kudos

Hi Rajen,

Many thanks for this idea! Currently the switch between MTO and MTS of the component planning is not solely defined by the quantity produced. There are other factors. However, I think this might be a compromise solution. I will raise this to the client!

BR

Raf

Caetano
Product and Topic Expert
Product and Topic Expert
0 Kudos

Hello Ralf

Please take a look on the following document that I wrote about the available BAdIs on MRP:

http://scn.sap.com/community/erp/manufacturing-pp/blog/2013/08/12/badis-for-mrp

You should check if it is possible to change that with MD_CHANGE_MRP_DATA.

BR

Caetano

rafael_zaragatzky
Active Contributor
0 Kudos

Dear Caetano,

I turned to implicit enhancements when I couldn't find a BAdI for this requirement. Particularly in MD_CHANGE_MRP_DATA I checked the method CHANGE_MDPSX_PLAF. However, it seems like it only allows you to alter the planned order data (PLAF) when it is read from the database, not to affect the generation of the dependent requirements.

The method CONSIDER_RESB allows you to make the dependent requirement to be subcontracting requirement, phantom, separate stge loc. or reorder planning. It doesn't allow moving the dep. reqmt over to the SO segment.

I wonder if I can use the method CHANGE_MDPSX_MDRS (Change data when importing dependent requ./ reservation) to move the dep. reqmt from the SO segment to the general segment. In such case I will set the component to "indiv." and let this exit move the generated reqmt to the general segment when appropriate. Are you familiar with this method?

I have also look at the BAdI MD_MRP_PARAMETERS. However it only fires when a material starts to be planned - not on every planned order.

The BAdI MD_PLDORD_CHANGE doesn't allow changing of the dependent requirements, only the planned order itself (PLAF).

BR

Raf