Serial Number : MTS : MTO

[Former Member]

Hi,

We use one material for both MTS & MTO process. However, business would like to track material serial number Only in the case of the MTO process but not for MTS process. So, we are thinking of skipping the standard serial number check that happens during the PGI in the delivery document.

The production of the Material (MTS & MTO) would be serial number managed.

Only in the case of Sales we have this difference in requirement for serial number, that is to track serial # for MTO & not for MTS.

Any suggestions / thoughts whether this approach is feasible ? If feasible what is the impact in the system as in warehouse / inventory the material is serialized & when we do the PGI no serial number is considered ?

Also, would like to know from a technical point how this requirement of skipping the standard serial number check can be achieved.

Please help.

[Former Member]

Hi All, Any other thoughts / views/ suggestions...

Regards

[Jelena]

I'm not an expert on this but let me poke some holes in this using simple logic.

When I buy a laptop, it does have a serial number no matter whether I buy it off the shelf at the store or order it built to specification from a website. Here laptop is still a laptop (i.e. the same MATNR). If one product is MTO with a serial number and another product is MTS without serial - is this even the same product?

For example, would you ever substitute MTO item with MTS item? Obviously not because it would have no serial number. Would you substitute an MTS item with MTO item? Most likely not because why would you even have extra MTO stock? An exception could happen (e.g. customer cancelled order late and not accepting stock) but how difficult in such case would be to just move the inventory?

Not sure why you're not considering that financial data may need to be captured differently for MTS and MTO process too. This might be more complex than you think. I'd say don't reinvent the bicycle, just create two different materials and use standard as Mother Nature intended.

[Former Member]

Hi Jelena,

Thanks for the response.

While I appreciate your suggestion to go for two different materials, unfortunately we are in a stage of the project, wherein it has already been decided to go with the customer requirement, that is to have one material code for both MTS & MTO processes.

To answer your point on "I'd say don't reinvent the bicycle, just create two different materials and use standard as Mother Nature intended".

SAP has provided in standard that the strategy group can accommodate both MTS & MTO strategies, (I think thats why there is provision in configuration to provide multiple strategies under ONE strategy group).So, which means its not something new that we are trying to adopt.

About your below point on financial data "Not sure why you're not considering that financial data may need to be captured differently for MTS and MTO process too".

The Item category of the material in the sales order item would take care of how the financial data has to be handled : Like, for example : In the case of MTS process, item category TAN can be used which along with the material type would have a requirement type and there on the "Requirement Class". This requirement class would have Costing as "not Relevant", and and that means VPRS cost would get captured as part of the other conditions based on the standard cost of the material.
Now, lets take the case of MTO process, item category TAM can be used which would have requirement requirement class with Costing as "Relevant", and that means EK02 would get captured as part of the other conditions based on the BOM of the material.

Any other views / suggestions.

Regards

[Jelena]

Yes, you can use the same material for MTS/MTO but here you are running into an issue with the need to manage serial numbers differently. (Otherwise this wouldn't even be a question, would it?) I don't really see how you could accomplish this in standard. Of course, there is always ABAP but in this case I believe you're talking some heavy customizations.