rework process

[#1]

We have a rework scenario in our make to order scenario. We are creating a rework production order based on the amount of rework we needed to do. Couple of issues I am facing

1) in the plan costs I am not able to see the labor costs.

2) when I do actual backflush for rawmaterial components, the transaction is going through but not posting any 261 to the production order. It is not showing in COGI either. Am I missing some settings like allowing backflush for these raw materials? These are same materials I used in make to order production order and have no issues.

Thanks in advance

[ajaycwa1981]

Hi

When you did 261, which CO object did it hit? Check MB51 report and see which CO object it was posted to

If it shows the Rework order, but does not display there, may be some technical issue then

Regards

Ajay M

[Former Member]

Thanks for the replies guys. Looks like they missed some PP settings. They fixed it now it is picking up actual costs of components but not doing a GR to the rework order. I mean it is not doing a 101 to Inventory from order. When I checked MB51 it is posting controlling document, profit center document with a zero value but no accounting documents is generated. Also still it is not showing labor value in plan but doing it in actuals. valuation variant is same for actual n plan. Any thoughts???

Edited by: nspv81 on Oct 5, 2010 3:48 PM

[ajaycwa1981]

Hi

Go to your rework prod order, "Goods Receipt" tab... Check if the "Non val GR" is ticked?

Regards

Ajay M

[Former Member]

No its not checked. I just had a chat with PP guy. He says rework orders will not have a GR. They are just cost buckets. So I am guessing they want to settle those costs to a cost center which I can specify in settlement rule. I still need to test if it works this way.

But still I am wondering how does it miss plan labor costs when it was able to calculate actuals.

[ajaycwa1981]

Hi

Usually rework orders dont hv GR, because they are created without material... But, you said in your earlier post that the material is KMAT, so I thought you have created with Material...

It is a practice to settle it to either a rework cost center or to the same prod order which generated the reworkable material...

You can use a different sec cost ele to settle this so as to identify it separately on the original prod order

Regards

Ajay M

[sivaprasad_r]

Hi,

I guess for rework orders, unlike regular production orders, no activity quantity is planned because, the qty of activity is unknown . However, for regular orders, Routing / Recipe contain the planned / standard activities.

The actual labour cost is accounted because at the time of confirmation, you have confirmed the actual labour hrs.. so the actual costs are calculated and displayed.

And as far as settlement of the Rework order is concerned you should prefer to use Secondary cost element i.e through a settlement cost element instead of primary cost element ( even SAP recomends this) to avoid duplicate calculation of Overhead. For more details, you can refer to SAP help.

Njoy

Siva

[Former Member]

Thanks Ajay n Siva for ur replies. I do have a routing on the rework order so u mean to say even if there is routing it doesn't calculate planned labor??? Is there any settings specific to this where I can look into it or is it that the order type is created that way? Also its not calculating target costs for version 0 even though setting says cost estimate is target costs and compoenent materials have standard cost estimate.

Ajay, those are configurable materials.

[ajaycwa1981]

Hi

Usually, if there is a routing on rework order and also you have entered planned qty, it should calculate planned cost

1. Check if Planned Qty is entered for the Labor hrs

2. Check if any operation qty is entered for the operation

2.a Usually, the control key for rework work center is marked for "Rework"... WHich means that Variable costs are calculated only if Operation qty is entered... Fixed costs are calculated independant of operation Qty

Check if any of these tihings apply to you

Regards

Ajay M

[Former Member]

Ajay

you r right. Operation qty is not entered. Is it needed to be manually entered or will it be picked automatically based on the order qty? I thought it would automatically populate based on order Qty? I will check with my PP guy Thanks for that

Its not calculating target costs even though version says use standard cost estimate ( components does have std cost estimate). Any thought?

[ajaycwa1981]

Hi

No question of calculating target cost when GR is not there....

Regarding op qty, check with your PP consultant... Check if he has switched on "Rework" in the control key of the operation

SImply change the op qty and see if plan value is calculated.. No need to catch hold of your PP guy, you can yourself do this

Regards

Ajay M

[Former Member]

Yes. U r right. No target costs if we don't have GR. How do I settle these costs to a cost center. Just maintain a settlement rule with CTR as receiver and do a settlement run transaction with out doing variance run calculation ( it is giving me an error message as no GR costs exists)

Also where would I maintain the default settlement receiver?? Right now is it pointing to MAT. In settlement profile I maintained Material, cost center and PSG as optional but where exactly I maintain which one to go to?

Thanks a lot for quick replies

[ajaycwa1981]

Hi

Just maintain settlement rule in the Rework order and specify cost center as the receiver.. Execute KO88 or CO88... No WIP or Var calculation needs to be done

If you have a separate settlement profile for rework order, better to allow only Cost Center and Order and specify all others as "Not Allowed"...

Default obj type can be CTR in the settlement profile.. No harm even if it is MAT

Regards

Ajay M

[Former Member]

I created a new settlement profile with valid receiver as cost center required and defaulted to rework order type. Now when I am creating a rework order it comes up with the settlement rule to populate. Is there a way I can default cost center so that it automatically creates settlement rule rather than asking me to do it.

Other requirement is to have different cost centers on different orders ( they will enter in custom transaction which will create rework order). I know this has to be an enhancement but is there a way to have different cost centers as receivers to different orders based on some rules?

[ajaycwa1981]

Hi

You are right.. It has to be an enhancement.... I think exit COOM0003 in SMOD should suffice....

Personally, I would prefer to maintain it manually - It being a critical activity...

Regards

Ajay M

[Former Member]

Looks like a promising one. I will check with my ABAPer as well. The problem is for our rework we have a custom transaction which will be entered and it will creata a planned order, production order and confirms it at the same time. So a settlement rule needs to be created based on the cost center that they enter when creating this rework. So this exit needs to read it from this and create a settlement rule with this cost center as receiver.

Thanks a lot, I will see if this helps. Other quick question is right now its asking me enter a cost center every time. Is there a way I can default to one particular cost center and make it automatically popultae it in the settlement rule rather than I enter is every time.

[Former Member]

Is the rework order a different order type? is so, compare the config settings.

Is the material on the order header a KMAT? valuated?

Check the costing variants used for the order type and be sure that labor is being valued

[Former Member]

Hi

yes it is a diff order type. Settings are same as the regular production order.

Material on order header is configurable material and a valuated one. I have issues with ROH component costs not picked up, they are valuated materials too.

Checked valuation variant. Both planning and actuals are using same one. But plan is not picking up the labor costs where as actuals are picking labor costs.

[Former Member]

The one time I saw something like this with labor, the solution was that the start DATES in the order were in the future, beyond the validity of the activity pricing.

If actual wil cost, then it seems to be something in the validity.