I would like to know if there is a standard approach to handle the following use case:
we have a company which produce assemblies (semi-finished products with a BOM) internally but sometimes find more convenient to buy them externally. Currently if you flag a product as purchased the MRP will create a requisition for it and not a MO, also I remember that we got an error some times ago for an assembly for which we forgot to unset the purchase flag, but I can't remember which error or where.
Using two different products and define them like variants maybe could be an option but it will be harder to track Qtyonhands. Also we are using the make-to-order type of BOM so not sure if variants are applicable
Any luck with the approach. I have currently come across a similar requirement. If you have any solutions please share.
I'm sorry but as you can see nobody replied to my question and we are still groping in the dark :)
Luckily in our case it's just a seldom requirement, but I think there should be a proper solution since this scenario could be quite common
Manufacture vs Buy is a complex topic and is not yet handled by Libero MFG module, as far as i know.
Thinking loudly, i got some ideas about how shall be done:
* extend MRP engine and allow pluggable classes that take this decision based on company policy (cost, lead times etc)
* alternative MRP plans - posibility to generate different MRP plan versions, compare between then and then take the right decission - this one would be quite complex
I think those 2 ideas are complementary and not alternatives.
I am sure i did not turn on the light on this subject, but i hope at least i let a light ray in.
I like both approaches. You said the latter could be complex, maybe I'm missing something because it seems simple to me: MRP could generate both a PP_Order and a Requisition and then let the user choose which one to keep. Since our customer is small and not willing to pay for a more complex solution this could be done with little effort.
As u described, can work for your particular case. But generally speaking, it's a little bit more complex because it can result to a tree of versions, why is huge, resource and time consuming. Even if MRP is designed as a batch process, we should keep it at a reasonable duration.
More, in case of MRP plan versions, the MRP code needs to be modified and make it to consider only the inbound and outbound qtys for the current plan.
At this moment i don't have much time to think about this but you can read also some similar discussions:
Hope it helps.
It seems good at first to create both a PP_Order and a requisition and let the user choose which to keep. But thinking loudly on this insight, we may hit an ice berg on the way:
- While MRP generates a supply(as both PP_Order and Requisition) for the raised demand, until the user cancels one of it, there will be double the supply for the demand. Thus MRP will never have things tally between Supply and Demand.
- Suppose the user is careless and he goes ahead and completes both the PP_Order and Requisition, he will receive excessive supply to his demand and thus blame the system of being incapable.
I think a little modification to this method may do the trick. What if, there is a prompt to the user (may be while completing the SO, or while running the MRP) asking him, if he wants that particular product to be Manufactured OR Purchased. And accordingly a PP_Order OR a Requisition is generated by the MRO.
You were right in telling it may be slightly complex. Extending MRP engine class to fit in company policies too would be a great way! a complex way too! would be superb if it can be done!
The latter seems easy with may be a check or so like suggested above.
Thanks for the insights.
Philip, there is another problem with this approach the PP_Order for the semi-finished product will also create requisitions for the raw materials, and I think it will be cumulative in respect to every BOM use, so it will be hard to correct the quantities once the user decide to keep the requisition and get rid of the PP_Order. Prompting the user is not very practical since MRP is meant to be a batch process. So in the end Teo's suggestion about extending the MRP process seems the solution that fit most .
Hi Angelo, Philip , Teo
To give a more accurate recommendation requires more detailed business case.
MRP is a planning tool, so the parameters defined are based on the vision of the planner.
If a product is defined as manufactured by the planner is a decision based on the capacity of the plant, and the typical case is that the plant capacity is exceeded, therefore is necessary to look for alternative sources of supply.
In a standard workflow manufacturing is set as follows, the plan is initiated by a demand which may be established by a sales order or forecast, then a materials plan (MRP) is executed to determine the suggestions for the supplies, the plan can sometimes be different than the schedule the scheduler may decide that production planned supply must be different, this decision is based on different business conditions and is usually taken by a human being.
Thus the solution to this dilemma is simple, the scheduler must create an approved material requisition instead of a manufacturing planned order, this indicates that the plan was approved and the material is considered as a supply for a demand, so MRP will not create a new manufacturing order for this request.
An idea to facilitate this work is to add an option in the form "Approval Order Planner" to convert a manufacturing planned order in a approved material requisition.
If this case is business recurrent issue, then the recommendation is to setup the system to plan the source of supply, so you may wish 100% of the demand is met by several sources of supply, for example 60% of demand will be served by the supply from source A (Manufacturing Plant Intermediates) and 40% are served by the supply source B (distribution warehouse).
Based on this scenario you should create a Distribution Network to identify the sources of supply, the percentage of supply allocated to each source and the data planning for each resource.
When the MRP is calculated with synchronized the Distribution Plan (DRP) option chosen, two distribution orders are generated: one for Supply Source "A" by 60% and one for the supply source "B" by 40%. So, it is possible for each supply source establish different planning parameters for each resource
For the supply source "A" Manufacturing Orders are generated and for the supply source "B" Purchases Order are generated.
To solve this business case I propose to change the way MRP determines whether a supply is generated as a Manufacturing Order or as a Purchase Requisition, now this is determined based on the fields "Is BOM" and "IsPurchase" of the master data for each product.
The solution is to add the field "isPurchase" into product data planning to overwrite the default value defined in the product master data.
So we can define that the product in the supply source "A" is manufactured, and the same product on the supply source "B" is purchased.
What do you think?
thanks for your valuable suggestions, I have some questions:
About the Manual Solution: for this to work we should have the isPurchase flag set to No on the Product and still be able to create a Requisition for it. The MRP should take into account for the Requisition Qty and skip the creation of the PP_Order or reduce the quantity accordingly. Will this work out of the box or we have to change the code?
About the Complete Solution: it sound promising, but quite complex. If I understand it well you need to define a fake distribution network with two factories; factory (A) receive semi-finished goods both from a supplier and from another factory (B) which in reality is the same as A. I wonder if it will be possible to accomplish this.
For our simple case, I think we will try the manual solution, I will let you know if it will work.
MRP generated Manufacturing Order or Purchase Requisitions with a status as "Draft", if MRP is executed again, the supplies with status as "Draft" are removed and generated again.
For that supply is not removed on next MRP run, is necessary change the status from "Draft" to "In Progress", indicating that supply is in firm.
So if you want a Material Requisition a instead of Manufacturing Order, you need to create a purchase requisition with the same amount, product , date promised and change the status to "In Progress".
When MRP is run again, only the supply with status "In Progress" are maintained and the new Manufacturing Order is not generated
Hi Victor and Angelo,
The last (above comment) of Victor seems the best way to go about a manual solution. That would mean MRP working fine and things going according to plan - with the exception that if you require a Material Requisition instead of MO, the user should manually make sure the amount, product etc should be exactly same as that of demand while creating!
However, more manual = more prone to mistakes. If the user is careless about the details being exact, he would end up with surplus goods in inventory. (say Date is different, or product chosen for eg: )..
Alternate, I like the suggestion Victor gave in Comment #9.
This seems a better user friendly method. Yes, of course the COMPLETE SOLUTION will be/may be the perfect solution to the situation but considering its complexity, The AUTOMATIC SOLUTION will provide a best alternative w.r.t efficiency, and user friendly.
To be the devil's advocate, i must say that the "automatic solution" is also complex and is not supported by the architecture that we have it today, but of course it can be improved ;)
The biggest problem with converting an MO to Requisition without running MRP again is that an MO trigger also other supply documents which in their turn can be MOs that are balancing the supply but they are also creating demand that needs to be balanced.
The first issue is that we don't have a direct connection between supply documents and demand documents that trigger that.
The second issue, even if we would have a connection, the case would work only for Lot-For-Lot (L4L) policy because only in that case the supply is not aggregated.
PS: sorry for bringing more problems in ;)
We need problems!! Only then can the development stand the test of time!! :) he he!!
One question : Wont the MRP itself, take care of the demand Vs Supply Tally?
You were absolutely right when you said that the MO generated by MRP would be an aggregate of similar Product's Demands; and also This MO would in term fire demand for it's BOM components leading to another MO/Requisition.
Now comes my question: Wont the MRP take care of itself.
If A had a BOM component B, and B had a BOM component C.
Consider a SO entered for Product A, and MRP triggered MO for B, and in tern triggered for C to satisfy B's Demand.
Now the MO generated for B may be/may not be aggregated from similar demands.
Now say, I convert this particular MO (the MO with product B) to a Material Requisition as suggested by Victor's AUTOMATIC SOLUTION, and keep the Requisition in "In Progress".
At next MRP run, the engine finds a Material Requisition satisfying A's demand for B. Thus it will drop the MO for product B (This MO should be in draft mode). Since Demand for Product B is now gone (gone b'cause Requisition satisfied it already) , The MO for Product C will also be removed (Provided it is in draft mode). The MO for Product C will be deleted as there is now NO DEMAND FOR C to satisfy B.
Sorry if you guys are confused with my A,B,C… but even in the Adempiere present now this feature already exists. Try creating a Requisition in "In Progress" for a product whose MO is generated by MRP and the MO is in "Draft Mode". At next MRP run this MO will be removed as a Requisition already exists the product's supply.
Yes you are right. But as i said, the MRP needs to be run again. Maybe this can be tolerated.
Can you guys help me in running MRP on Adempiere; I have created a FinishGood with 2 RawMaterils in its BOM. Have also created workflow and rest of the links but when I run MRP no MO/PR is created; would appreciate your reply in this case.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.