on 04-26-2010 8:00 AM
OM Fill-up orders are order type ZKB which pulls item category ZKBN. Independent Requ2019s are kept at consignment location and consumption should happen there however, Item Category ZKBN is consumption relevant. As there is a separate Independent Requirement at DC u2013 for customers that are delivered directly from DC u2013 forecast consumption is incorrect. Any time a fill-up from DC to consignment location is created customer forecast gets consumed and this should not happen.
Hi DB49
Start by creating a new ZKB order so as to minimize any possible confusion. Create an item. It should automatically determine ZKNB Item category. Does It?
ANS: Yes.
Now, before saving, review the requirements type for your new item by selecting the Procurement tab. It should have determined KSL automatically. Did it? Save the order.
ANS: Yes
If the answer to both questions was yes, now go into MD63 and review your Planned independent requirements. Select the item (should be active) and then Environment > Total requirements. Here you will see the SD orders that are consuming forecast. You should see no requirements from your newly created ZKB order.
ANS: True, there was no requirement for the newly cretaed ZKB order I created.
How come it's still consumption relevant?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Gery,
Don't know why you have created all this Z* stuff, but I will assume there is a good reason.
In the definition of Requirements Class are the settings for consumption of planning (Independent requirements). OVZG; column is "AllIn". Requirements Type is in turn assigned to Requirements Class OVZH. Finally, Requirements type is assigned to your item category OVZI. If you have already created a custom Requirements Class to support this z ordertype, you should be able to change the Requirements Class 'AllIn' without impact. If you have instead used an existing Requirements class, It is usually not advisable to change the settings for an existing Requirements Class with existing Requirements type assignments, due to unintended consequences to other sales docs. Instead, you could create a new Requirements Type, assign it to an existing class which has no consumption, and then assign it to your custom item category in OVZI.
Rgds,
DB49
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello DB94!
Thanks for addressing my concern.
I checked the transaction codes you stated in your reply and here are the values assigned for the item category ZKBN:
Re Class: 030
Alln: Blank (No consumption w/ Customer Requirements)
Req Type: KSL
Alln was already set to No Consumption but still ZKBN reamined consumption relevant resulting to wrong planning picture.
Can you suggest anything else? I am relatively new to SAP, I just started using it this year and I will really appreciate an expert's point of view on this issue.
Thanks,
Lhoyd
Hello Geyr,
I will assume that you have already assured yourself that you are using a consuming planning strategy, such as 40, in the Material master.
Start by creating a new ZKB order so as to minimize any possible confusion. Create an item. It should automatically determine ZKNB Item category. Does It?
Now, before saving, review the requirements type for your new item by selecting the Procurement tab. It should have determined KSL automatically. Did it? Save the order.
If the answer to both questions was yes, now go into MD63 and review your Planned independent requirements. Select the item (should be active) and then Environment > Total requirements. Here you will see the SD orders that are consuming forecast. You should see no requirements from your newly created ZKB order.
If you see the order in MD63, and you have previously found that type KSL is assigned to 030 in config, and you have previously found that class 030 has Alln set to 'blank' in config, then something is wrong. I would suggest you engage a developer to look for userexits that are bypassing standard functionality.
Rgds,
DB49
User | Count |
---|---|
95 | |
11 | |
11 | |
6 | |
6 | |
4 | |
4 | |
3 | |
3 | |
3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.