We are in the process of producing the same item in different plant. In one plant I will be providing with all materials in the other plant they would provide with all the materials. I have found that by having one BOM the cost is been calculated wrong since both production show the same BOM but in reality both production have different cost. How can I override the cost without do it manually, or do you know if there is any module that I can use to have 2 different BOM?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Different BOM for same manufacture item
- Thread starter mongos30
- Start date
If they have the same BOM, how is it tha they have different costs? Are the components a different cost at different locations, or are the workcenters carrying different costs?
Software Sales, Training, Implementation and Support for Exact Macola, eSynergy, and Crystal Reports
Software Sales, Training, Implementation and Support for Exact Macola, eSynergy, and Crystal Reports
- Thread starter
- #3
They have different cost because in one we provided the material and in the other one they provide the materials which is much cheaper then the first one. For example: One is produce here in the plant and the other one is produce in China. Both are the same item and is bill and sold with the same code and retail price. But as you can see they both cost differently. What we have done is when we create Production Order we modify the BOM so materials would take it out of inventory properly, but this would not modify the standard cost for the item.
If you are using standard cost and you purchase the item from China rather than manufacturinging it, would you not want o simply recognize a favorable purchase price variance when the PO is received?
Software Sales, Training, Implementation and Support for Exact Macola, eSynergy, and Crystal Reports
Software Sales, Training, Implementation and Support for Exact Macola, eSynergy, and Crystal Reports
- Thread starter
- #5
Why not track this by location. You could build a BOM in location 01 with components coming from location 01 with a total cost of $100. You could also build the same BOM in location 02 with components coming from location 02 that are purchased and have different costs and the total cost would be $150.
If you don't assign a location on the BOM itself, it should use the location for the parent and components based on the production order.
Kevin Scheeler
If you don't assign a location on the BOM itself, it should use the location for the parent and components based on the production order.
Kevin Scheeler
While you can certainly have a separate item location record with a different cost, you cannot have different BOMs in Macola. There is only one BOM active at a time for a given part # for a given database.
If you have a separate company in Macola you could do this, but it also raises a whole lot of other issues.
Software Sales, Training, Implementation and Support for Exact Macola, eSynergy, and Crystal Reports
If you have a separate company in Macola you could do this, but it also raises a whole lot of other issues.
Software Sales, Training, Implementation and Support for Exact Macola, eSynergy, and Crystal Reports
- Thread starter
- #8
Here's my thinking on this - I haven't been directly faced with this problem, but I believe this would work: You have to solve it with either an Access query or Flex, but it is much better solved with Flex, as you can just add a button to push to change the costs on the PPO after it has been entered but before production starts on the item. It would take the form of a popup screen after the PPO is initially entered. I don't believe the PPO looks at the IMINVLOC cost again after the initial order entry, so if you change the cost on the PPO itself it should post thru the system correctly.
If you don't have Flex, you can add a similiar Access program to the menu tree to do the same thing, but if your operator forgets to run it you'll have to fix it later.
Kirk
kirk@viningcomputers.net
If you don't have Flex, you can add a similiar Access program to the menu tree to do the same thing, but if your operator forgets to run it you'll have to fix it later.
Kirk
kirk@viningcomputers.net
Dgillz,
From what I understood, the BOM is the same regardless of the costs of the components. Multi locations would handle it using the same BOM. If the item needed a different BOM, we would either have to do it with different parts or different companies.
Kevin Scheeler
From what I understood, the BOM is the same regardless of the costs of the components. Multi locations would handle it using the same BOM. If the item needed a different BOM, we would either have to do it with different parts or different companies.
Kevin Scheeler
Kevin,
That is correct. There is only one BOM, you cannt have multiple BOMs per item.
I think Kirk is on to something here.... you could use flex to write the component item cost from the particular location to the BMPRDSTR, then roll up that particular location's costs, then do it again for the following location, etc., etc.
You would need a flex event to fire on the loss of focus of the location field on the "Print Costed Bill" screen to do this.
Software Sales, Training, Implementation and Support for Exact Macola, eSynergy, and Crystal Reports
That is correct. There is only one BOM, you cannt have multiple BOMs per item.
I think Kirk is on to something here.... you could use flex to write the component item cost from the particular location to the BMPRDSTR, then roll up that particular location's costs, then do it again for the following location, etc., etc.
You would need a flex event to fire on the loss of focus of the location field on the "Print Costed Bill" screen to do this.
Software Sales, Training, Implementation and Support for Exact Macola, eSynergy, and Crystal Reports
I don't believe the production order is the issue here, I believe he wants different standard costs for different locations, which is no problem, but he wants to base it on 2 different BOMs, which is a problem.
Mongos, what do you want?
Software Sales, Training, Implementation and Support for Exact Macola, eSynergy, and Crystal Reports
Mongos, what do you want?
Software Sales, Training, Implementation and Support for Exact Macola, eSynergy, and Crystal Reports
MacolaHelp
Instructor
Another thought: I have a similar situation. I can manufacture a particular item in my US plant with a BOM that includes components I buy & any costs I care to associate with the BM. My std cost in this location is updated when I run costed BM update.
I can also buy this item from overseas already complete. When I do this, I purchase the item (tho mfg flag is set in item master, you CAN purchase a mfg item on a PO) into another location like CH for China. My CH location carries the std cost of the item on the PO. When I enter my sales order, I choose if I am selling from US loc (mfg in US from BM) or CH loc from China as a purchased product complete. My decision on which location sometimes has to do with which one has stock, sometimes customer requests "made in USA". Either way, cost comes to the order from iminvloc to the oeordlin & therefore the GL, POP orders are only affected if I need a POP to build in the US, otherwise costing comes from issue/receipt of PO in the CH location. In vanilla macola, you cannot change locations of line items on the fly, once saved to the order. You must delete & readd the item back in to draw from the alternate location. Peak BestOE allows a change to the location, however. As long as you are on cost to use when posting = "billed", all is fine if you use this source code enhancement, soon to be part of 7.6.300, I hear.
Sometimes we get so caught up in customers' unique needs, that we forget that macola can handle many combinations of variables generically. It can be worthwhile to visit the basics when presented with a new client request. Since macola already has some 7 million lines of programming code, trying to work within their framework, limited as it can be at times, can save many hours of future headaches by trying to "work around" the cobol code.
I can also buy this item from overseas already complete. When I do this, I purchase the item (tho mfg flag is set in item master, you CAN purchase a mfg item on a PO) into another location like CH for China. My CH location carries the std cost of the item on the PO. When I enter my sales order, I choose if I am selling from US loc (mfg in US from BM) or CH loc from China as a purchased product complete. My decision on which location sometimes has to do with which one has stock, sometimes customer requests "made in USA". Either way, cost comes to the order from iminvloc to the oeordlin & therefore the GL, POP orders are only affected if I need a POP to build in the US, otherwise costing comes from issue/receipt of PO in the CH location. In vanilla macola, you cannot change locations of line items on the fly, once saved to the order. You must delete & readd the item back in to draw from the alternate location. Peak BestOE allows a change to the location, however. As long as you are on cost to use when posting = "billed", all is fine if you use this source code enhancement, soon to be part of 7.6.300, I hear.
Sometimes we get so caught up in customers' unique needs, that we forget that macola can handle many combinations of variables generically. It can be worthwhile to visit the basics when presented with a new client request. Since macola already has some 7 million lines of programming code, trying to work within their framework, limited as it can be at times, can save many hours of future headaches by trying to "work around" the cobol code.
I have read these posts and I have a thought about this. You could possibly do something with the dates like use an obsolete date way in the future and a effective date for the different BOM way in the futeure and then when you run the standard cost you could select teh appropriate location and dates and probably accomplish what you want.
Steve Henley
trianglepartners.com
Exact Software consulting, sales and implementations.
Steve Henley
trianglepartners.com
Exact Software consulting, sales and implementations.
I don't know - it just seems to me that a PPO in essence is just a copy of the BOM, and it carries costs at the time of manufacture, so it would be the logical place from both an auditing and programming standpoint to put a cost change. I'm at a loss right now because I'm not working at a Macola client today, but if I remember right, Macola allows for a temporary BOM to be created in response to a production planning change. Are the users allowed to change costs there, or just materials?
The single BOM has always been a pain. I've had customers who have bought one item as a completely built assembly and used it as a component in manufacturing an item at one location, while at another location they build it from scratch themselves. This sounds pretty simliar.
The single BOM has always been a pain. I've had customers who have bought one item as a completely built assembly and used it as a component in manufacturing an item at one location, while at another location they build it from scratch themselves. This sounds pretty simliar.
MacolaHelp
Instructor
Kirk/vbajock: when you enter a POP, it captures the BOM at that point in time. So . . . whatever is there in the bmprdstr will flow into imordbld for that finished good. You can edit it in POP, manual production entry & swap out the location cost for US vs CH or vice versa on that single captured bill, which I think they already do based on the initial post. So, if the BOM changes between POP entry (order capture) & POP order completion, nothing will have changed on the captured bill dynamically, only the parts you have manually edited, if any.
Steve/tpllc: have you considered that the blending of stateside mfg & overseas mfg may cause a hiccup in the avg cost? Std cost is not updated dynamically from BM or SC, so we are just creating variances to std when manufacturing items w/o correct costs. We need to run processes in either BM or PP to document std cost changes.
Steve/tpllc: have you considered that the blending of stateside mfg & overseas mfg may cause a hiccup in the avg cost? Std cost is not updated dynamically from BM or SC, so we are just creating variances to std when manufacturing items w/o correct costs. We need to run processes in either BM or PP to document std cost changes.
Yes, thats what I thought. So if you wanted a custom multiple BOM app, you could put a button on one of the PPO screens that could pop up alternate BOMS for an item, and use the alternate BOM to change the Production Order itself. When the item is produced, as this altered PPO is posted, it will automatically post costs and quantities thru Macola based on the PPO regardless of what is in the original BOM. Correct?
I still would do this with two locations. Here's the scenario. Location 1 has PAR1, COMP1 (cost $1) and COMP2 (cost $1). The rolled up BOM will have a cost of $2 if produced in Location 2. The same two components in location 2, COMP1 (cost .75) and COMP2 (cost .75) will roll up to a cost of $1.50 for the same BOM.
When you enter the POP order, you would choose the location you are producing it in. If it's made in house, you would choose location 1 and if it's an outside process, you would choose location 2. It will relieve the raw materials from the same location you build into.
You mention that you use standard as your costing method. Do you want to hold different standards for this item depending on how it's built? Multi locations would allow you to do this. You could then either sell from both locations or transfer stock back to your primary location. If you transferred stock from one location to another, you would get a gain/loss entry which you could put to a specific account if you wanted to track it seperately.
Kevin Scheeler
When you enter the POP order, you would choose the location you are producing it in. If it's made in house, you would choose location 1 and if it's an outside process, you would choose location 2. It will relieve the raw materials from the same location you build into.
You mention that you use standard as your costing method. Do you want to hold different standards for this item depending on how it's built? Multi locations would allow you to do this. You could then either sell from both locations or transfer stock back to your primary location. If you transferred stock from one location to another, you would get a gain/loss entry which you could put to a specific account if you wanted to track it seperately.
Kevin Scheeler
That works for all but one scenario, and its the one I keep hearing about as a problem from mny customers. Say you produce a particular item, made up of a list of raw materials you keep stocked. At the same time, your buyer has found that he can buy three of the raw materials are ready preassembled, cheaper than you can do it inhouse, but he can only rely on the supplier for 50% of total demand, so he has to keep building them out of inhouse RM as well. This creates big headaches. To use your method, he has to receive the sub-assembly, then break it down into components, put the components in a separate location and calculate the correct roll up manually. This drives both the buyer and the receiver nuts. This also drives the P/IC person nuts, because now he has inventory that doesn't actually exist, and if there is a mistake he has to
mentally reverse engineer things to get his transactions right. The core problem is a lack of a dynamic BOM. The subassemblies can be stored under their own item key, and the switchero at the production line covers everyone with no added work involved. I don't know if this is precisely the problem this guy is having, and since he seems to have dropped off the post this is mostly a mental exercise at this point, but this has become a common problem in Texas because a lot of subassemblies like this are being built in job shops across the border, and the different labor spread changes the costing dramatically. I'm sure people dealing with Chinese suppliers are having the same problem for the same reason.
Kirk
mentally reverse engineer things to get his transactions right. The core problem is a lack of a dynamic BOM. The subassemblies can be stored under their own item key, and the switchero at the production line covers everyone with no added work involved. I don't know if this is precisely the problem this guy is having, and since he seems to have dropped off the post this is mostly a mental exercise at this point, but this has become a common problem in Texas because a lot of subassemblies like this are being built in job shops across the border, and the different labor spread changes the costing dramatically. I'm sure people dealing with Chinese suppliers are having the same problem for the same reason.
Kirk
- Status
Similar threads
- Locked
- Question
- Locked
- Question