Now I apologize, because the title of this post might suggest that you can actually accomplish this feat. Unfortunately, to the best of my knowledge, you cannot dynamically change plant based on the configuration. In my experience, this was always a no-no. Now if anyone has actually gone down the user-exit approach and made it work, I’d be curious to hear it. In the meantime, here are some approaches to potentially help you… or at least give you some ideas of your own to change plant for a configurable item based on the configuration.
The biggest problem is that you get to choose one plant for each sales organization to be the default. And even using configuration, it doesn’t matter if something within the configuration can only be done in Plant 0002, but Plant 0001 can do everything else (and should). That being the case, here’s some approaches/techniques that may help.
1. Multiple KMAT’s. This is probably the most common/standard approach to change plant for a configurable item. You can have one KMAT for each different plant. You can reuse all of the dependencies, and create new configuration profiles etc. Now the drawback to this approach is that you have to know in advance which product you want to manufacture.
2. Use special procurement keys on a sub-KMAT. Here’s the idea. Set up your main KMAT A. In the BOM add 2 SUB-KMATS, X & Y. X will be the standard produce here in house (whatever plant is listed on the sales order). Y will be a KMAT with a special procurement key pointing to the other plant. Then using object dependencies select either X or Y. I admit, I’m pulling this one out of my ass, so if anyone knows if this does or doesn’t work, let me know. It sounds promising, but I have my doubts it would actually work =).
3. Material Determination – this is a handy trick that could be used to make #1 easier for the sales order entry folks. What you could do is create something “meaningful” to the entry people, that they could type in and it pull up the second KMAT in another plant. For example it could X – Express, would pull up the KMAT with the least number of options that would be shipped the fastest.
4. User Exit – you could always go down the path of adding new entry into VCSD_UPDATE for werks and using User-exits, drive the plant change this way. Like any good SAP consultant, this is always the last resort, but for my current project, this may be the way we have to go. Based on a little online research, it appears you’d want to use the following: VCSD_UPDATE and transfer the changed values from the configuration to the sales order: EXIT_SAPLCEI0_001 (include fields in structure VCSD_UPDATE) EXIT_SAPFV45S_002 (process changed field values)”
Now, all that being said… option 2 would be the coolest way to “possibly” do it with standard SAP, but I have a feeling that #4 is only way to accomplish a change plant based on configuration.
Thanks for reading,
As always, thanks for reading and don't forget to check out our SAP Service Management Products at my other company JaveLLin Solutions,Mike
I haven’t done plant specifically, but I have used option 4 to change things like item category, profit center, and product hier and it works well. If the object is setup to do it….It will triggers price redeterminations, route calcs, runs the SD userexits just like a manual change
A couple things to watch for:
– I would think though that if yu chose to use the V/C to change the plant, you’ll want to look at putting in line-level status profile to ensure that they don’t try chainging it after something specific occurs – say after the planned order is converted to a production order.
– Also, you may need to put in custome availablity requirement to prevent the production order from being just “deleted’ if it’s changed (assuming this is an assembly order).
-If sales BOM re-explosions will be necessary… beware. SAP has some issues around this that I’ve had to design my product models around in the past. Recommend reviewing some notes (and many related notes) on this topic:
– 549341 – FAQ: BOMs in the sales order
– 486680 – Material substitution: No structure explosion
– 774347 – Collective SAP note: BOMs
My gut tells me that making this dynamically change is feasible…as long as you stop it from changing once your ‘past the point of no return’…..
Thanks Jer, since writing this post I’ve found that changing the plant should absolutely be possible, like you said.
I was surprised to read that you can change the item category. I was always told this was a no-no in VC.
The current thought is that the user exit will be implemented on my current project, so I’ll keep y’all updated on the results. I am concerned about sales BOM explosion, but on the bright side, this project has no nested KMAT’s, so I hope that will simplify any ramifications.
As always Jer, thanks for your ideas and information. It’s ALWAYS appreciated.
Mike
Hey Mike
One of the clients used the exit to change plant. One issue with this is if the nested KMATs are exploded onto sales order, then have to make sure manual changes allowed on configuration profile is not checked, if not it will try to re-explode BOM and looses VC on KMATs where plant is changed
Rama
My model is the step number 4 which is being used with one of our customers. The solution works like charm for the configurable material, but the problem comes up when the main material has BOM and some of the BOM components are fixed (not configurable) materials. For such cases, it is not possible to transfer VCSD_UPDATE will not work. This case poses issue when we enable to MTO scenario with sales order BOM and BOM components involve both configurable and fixed materials.