Reply from giso_vonpetersdorff on Dec 18 at 1:48 PM Hello Carl,
Now that you have described your situation more fully, I can appreciate that SAP does not have the answers for you. A thought did come to mind, which would only work if the attrition rates on the components are all similar, and that would be to add the finished product to itself as a recursive item in the proportion of the scrap %, and mark it as a phantom too and assign it to the rework operation. Then all the items would be listed and assigned to the rework operation in one go. The original components would not have any scrap factors.
If the rates are not the same, it might be possible to use variant configuration to adjust things. Create a class without any characteristics so that it does not interfere with the sales process. The finished item would be added with quantity 1 and the scrap factors would have to be maintained in a variant table, with a dependency to change the component quantity. This is a bit creative but might be simpler than creating a Z-solution. I did something slightly similar for maintenance routings a few years ago, which in that case was designed to reduce the effort of routing maintenance.
Regards,
Giso
| | | ---------------Original Message---------------
From: CWK
Sent: Wednesday, December 17, 2014 11:38 AM
Subject: How Do You Handle Real Factory Attrition?
Giso and Phil -
Thanks for your responses. They've been helpful, if only to confirm that we're going to need some serious customization. We cannot use component scrap the way it's designed.
If SAP provided two fields on the reservation record (one for actual required quantity and one for scrap quantity) or if (better still) SAP generated two reservations for scrap-relevant BOM Items (one with actual required quantity and one with the scrap quantity), then we'd have something to work with.
With a customized solution based on the current component scrap percentage, we can theoretically "reverse calculate" the actual requirement and scrap requirement for every reservation that includes a scrap percentage -- but we've always run into rounding problems when we try to do this in the past – and that's only the beginning of a tortured process.
If we customize our kitting functionality to allow kitting to recognize two distinct quantities (the reverse calculated requirement and scrap qtys) and made it easy for kitting to issue only the required quantity, we'd be close to a solution. (Maybe we will take this route eventually.) There are a number of problems with this. The scrap quantity looks like a material shortage when it really isn't. Annoying, but survivable. The required date on the scrap (short) quantity is inaccurate because operation confirmations have locked down the required date for the scrap. We end up with false overdue requirements in MRP. This is hard enough on MRP visibility accuracy and re-planning, but we also have metrics for the planning, purchasing, and manufacturing departments that cause people to get dinged for overdue components.
We also have customized rules that prohibit us from completing an order that still has material shortages. We'd have to update every order prior to completion to either reduce the required quantity or set the final issue flag on every scrap-relevant component. That's a lot of extra work and could easily lead to failure to recognize true material shortages.
Giso, regarding your BOM suggestion -- there's no way we can get anyone to manage (thousands of) BOMs that have two items for the same component (one for the actual requirement and one for the potential scrap requirement). Even if we did, we'd still have to get the scrap item moved to a later operation on the master routing so that it is scheduled better after the production order is released – and that is more industrial engineering time than we'd be willing to spend.
There is also no way that we'll be allowed to issue all of the requirements (actual plus scrap) when the order is released and then cross our fingers that the unused scrap is actually returned to inventory. Even if we did, we'd still end up with apparent shortages on the order unless we manually reduced the requirement quantity or flagged the component as final issue.
We have 10's of thousands of orders (with components that are relevant for factory attrition) open at any given point in time and 10's of thousands in planning – spread across dozens of WBS Elements. We can afford very little manual manipulation of orders just to fake out SAP's component scrap process.
Thanks for trying. The SAP Developer Network can't figure this problem out, either – so all of the best SAP minds in the world are stumped when it comes to managing attrition during the manufacturing process (although there are claims that the APO bolt-on can handle it – I wonder?).
Back to the drawing board.
Gratefully,
Carl |
| Reply to this email to post your response. __.____._ | In the Spotlight Become a blogger at Toolbox.com and share your expertise with the community. Start today.   _.____.__ |
