Users - comments please - manufacturing accounting
Locked
12
12
 
|
Hi everybody,
We're planning on implementing accounting for manufacturing processes. I've created a document that describes how it will be done. Please give us your comments and feedback: http://sourceforge.net/tracker/?func=detail&atid=818035&aid=1460882&group_id=145855 There is also a Word document at the end you can download. Thanks, Si _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
Re: Users - comments please - manufacturing accounting
|
|
It all looks great Si! I like the idea of having services defined to calculate
specific steps in the manufacturing process. One thing though: "Ownership of the Inventory and Costs The organizationPartyId which will own the inventory and be responsible for the costs will be the organizationPartyId of the Facility where the manufacturing is taking place. If the raw materials inventory has a different ownerPartyId, then the system will generate an error. To use another party's inventory, transfer it to the owner of the Facility first, or create a manufacturing Facility for the organization on behalf of whom you are manufacturing." Why tie the manufacturing accounting to a facility in this way? From my perspective, the facility where the product is manufactured is non-essential data - like what brand of component was used in a sub-assembly. The party responsible for the costs may not be responsible for the manufacturing facility indirect costs. I used to have a customer that was a packaging plant. They were responsible for the facility's costs, but they didn't own the inventory. Their customer owned the raw materials and the finished product. Part of the cost of that finished product was the FEE they charged to package it. I'd recommend leaving facility IDs out of it. If someone has a need to tie a specific facility's costs to the manufacturing process, then they can develop a calculation service for it. Si Chen wrote: > Hi everybody, > > We're planning on implementing accounting for manufacturing processes. > I've created a document that describes how it will be done. Please give > us your comments and feedback: > > http://sourceforge.net/tracker/?func=detail&atid=818035&aid=1460882&group_id=145855 > > There is also a Word document at the end you can download. > > Thanks, > > Si > > > _______________________________________________ > Users mailing list > [hidden email] > http://lists.ofbiz.org/mailman/listinfo/users > _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
|
|
Thanks for looking at this. I guess we need some way to know which
organization the costs should be booked at. How else could we
configure that?
Si Adrian Crum wrote: It all looks great Si! I like the idea of having services defined to calculate specific steps in the manufacturing process. One thing though: "Ownership of the Inventory and Costs The organizationPartyId which will own the inventory and be responsible for the costs will be the organizationPartyId of the Facility where the manufacturing is taking place. If the raw materials inventory has a different ownerPartyId, then the system will generate an error. To use another party's inventory, transfer it to the owner of the Facility first, or create a manufacturing Facility for the organization on behalf of whom you are manufacturing." Why tie the manufacturing accounting to a facility in this way? From my perspective, the facility where the product is manufactured is non-essential data - like what brand of component was used in a sub-assembly. The party responsible for the costs may not be responsible for the manufacturing facility indirect costs. I used to have a customer that was a packaging plant. They were responsible for the facility's costs, but they didn't own the inventory. Their customer owned the raw materials and the finished product. Part of the cost of that finished product was the FEE they charged to package it. I'd recommend leaving facility IDs out of it. If someone has a need to tie a specific facility's costs to the manufacturing process, then they can develop a calculation service for it. Si Chen wrote:Hi everybody, We're planning on implementing accounting for manufacturing processes. I've created a document that describes how it will be done. Please give us your comments and feedback: http://sourceforge.net/tracker/?func=detail&atid=818035&aid=1460882&group_id=145855 There is also a Word document at the end you can download. Thanks, Si _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users_______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
Re: Users - comments please - manufacturing accounting
|
|
Scenario 1: I build widgets in my plant. I'm responsible for calculating
indirect costs based upon MY facility. Scenario 2: I build widgets, but some or all of the manufacturing process is handled by an outside company. I include their fee in the cost of the widget. I can also include indirect costs associated with MY facility (I have to pay rent after all). I may be reading your text wrong, but it seems to me Scenario 2 would generate an error. Si Chen wrote: > Thanks for looking at this. I guess we need some way to know which > organization the costs should be booked at. How else could we configure > that? > > Si > > Adrian Crum wrote: > >>It all looks great Si! I like the idea of having services defined to calculate >>specific steps in the manufacturing process. >> >>One thing though: >> >>"Ownership of the Inventory and Costs >> >>The organizationPartyId which will own the inventory and be >>responsible for the costs will be the organizationPartyId of the Facility >>where the manufacturing is taking place. If the raw materials inventory >>has a different ownerPartyId, then the system will generate an error. >>To use another party's inventory, transfer it to the owner of the Facility >>first, or create a manufacturing Facility for the organization on behalf >>of whom you are manufacturing." >> >>Why tie the manufacturing accounting to a facility in this way? From my >>perspective, the facility where the product is manufactured is non-essential >>data - like what brand of component was used in a sub-assembly. The party >>responsible for the costs may not be responsible for the manufacturing facility >>indirect costs. >> >>I used to have a customer that was a packaging plant. They were responsible for >>the facility's costs, but they didn't own the inventory. Their customer owned >>the raw materials and the finished product. Part of the cost of that finished >>product was the FEE they charged to package it. >> >>I'd recommend leaving facility IDs out of it. If someone has a need to tie a >>specific facility's costs to the manufacturing process, then they can develop a >>calculation service for it. >> >> >> >> >>Si Chen wrote: >> >> >> >>>Hi everybody, >>> >>>We're planning on implementing accounting for manufacturing processes. >>>I've created a document that describes how it will be done. Please give >>>us your comments and feedback: >>> >>>http://sourceforge.net/tracker/?func=detail&atid=818035&aid=1460882&group_id=145855 >>> >>>There is also a Word document at the end you can download. >>> >>>Thanks, >>> >>>Si >>> >>> >>>_______________________________________________ >>>Users mailing list >>>[hidden email] >>>http://lists.ofbiz.org/mailman/listinfo/users >>> >>> >>> >> >>_______________________________________________ >>Users mailing list >>[hidden email] >>http://lists.ofbiz.org/mailman/listinfo/users >> >> >> >> > > ------------------------------------------------------------------------ > > > _______________________________________________ > Users mailing list > [hidden email] > http://lists.ofbiz.org/mailman/listinfo/users _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
Re: Users - [OFBiz] Dev - comments please - manufacturing accounting
|
|
In reply to this post by Si Chen-2
On Wednesday, March 29, 2006 11:14 AM -0800 Si Chen
<[hidden email]> wrote: > We're planning on implementing accounting for manufacturing processes. > I've created a document that describes how it will be done. Please give > us your comments and feedback: >From the document: > In OFBiz, routings, routing tasks, production runs, and production runs > are all stored as WorkEffort with different workEffortTypeId. "production runs" appears twice. What was the intention there? _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
|
|
Typo. It should be "production run" and "production run tasks". Si
Kenneth Porter wrote: On Wednesday, March 29, 2006 11:14 AM -0800 Si Chen [hidden email] wrote: _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
|
|
In reply to this post by Adrian Crum
Adrian,
Scenario #2 is a form of purchasing. This is an interesting but, in my opinion, very rare use case. You can handle it one of two ways: 1. You can basically treat it as purchasing and then see about capitalizing your indirect costs against inventory. There are some however, who do not view this to be "sufficiently conservative" and would recommend that you expense your indirect costs. 2. You can set it up so that the billable unit cost for the items is directly calculated by a formula embedded in an outside service and then the indirect costs are billed on top. This would basically mean providing a service to WorkEffortCostCalculation and skipping calculation based on fixed cost, variable cost, and per millisecond, etc. I think that would work as well. Then you just enter your invoices from the outside manufacturer as any other party. The Facility.ownerPartyId is there to let the system know which internal organization to bill the costs to. It does not matter how those costs are actually incurred. Si Adrian Crum wrote: Scenario 1: I build widgets in my plant. I'm responsible for calculating indirect costs based upon MY facility. Scenario 2: I build widgets, but some or all of the manufacturing process is handled by an outside company. I include their fee in the cost of the widget. I can also include indirect costs associated with MY facility (I have to pay rent after all). I may be reading your text wrong, but it seems to me Scenario 2 would generate an error. Si Chen wrote: _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
Re: Users - comments please - manufacturing accounting
|
|
In reply to this post by Si Chen-2
Si,
here are some comments: 1) maybe the WorkEffortCostCalculation.costServiceName could point to the CustomMethod entity (instead of storing in it the service name): in this way it will be possible to provide drop downs for cost service selection 2) I think that the primary key of the WorkEffortCostCalculation should be composed by workEffortId, fromDate, costComponentTypeId (to specify the cost type to which the gl account types apply); or, at least, costGlAccountTypeId 3) instead of adding the new assoc entity WorkEffortCostComponent we could simply add a workEffortId field to the CostComponent entity; also, why not storing in the CostComponent entity the total cost of the task (instead of the unit cost)? Should we store in the CostComponent entity one record for each of the WorkEffortCostCalculation entries? 4) in OFBiz, there is an entity to store standard costs for fixed assets: FixedAssetStdCost; the fixed asset is associated to the routing task (and production run task) by the WorkEffort.fixedAssetId field; the entity is very similar to the WorkEffortCostCalculation entity, and it is used by the routine that computes the product's standard costs; should we add some of the fields (costGlAccountTypeId, offsettingGlAccountTypeId, perMilliSecond, currencyUomId, costServiceName) of the WorkEffortCostCalculation entity to the FixedAssetStdCost entity too? i think that the new costing process should consider both the FixedAssetStdCost and the WorkEffortCostCalculation entities. Jacopo Si Chen wrote: > Hi everybody, > > We're planning on implementing accounting for manufacturing processes. > I've created a document that describes how it will be done. Please give > us your comments and feedback: > > http://sourceforge.net/tracker/?func=detail&atid=818035&aid=1460882&group_id=145855 > > There is also a Word document at the end you can download. > > Thanks, > > Si > > > _______________________________________________ > Users mailing list > [hidden email] > http://lists.ofbiz.org/mailman/listinfo/users > _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
Re: Users - comments please - manufacturing accounting
|
|
In reply to this post by Si Chen-2
Hi Si
I thought I should mention that we run an apparel ‘manufacturing’ company and at least 90% of our production is outsourced, the usual process is as follows:
1. Start a production run 2. Dispatch a work order to a fabric cutting company who cuts our fabric and returns it to us. 3. Dispatch the cut fabric and additional trims(zips, buttons, labels, etc.) to a sewing company. 4. We may also dispatch parts of the cut to an embroidery/screen-printing company for logos, while the rest of the cut is at step 3 5. The finished garments are then sent to a presser for finishing, before being returned to us as finished goods
The final cost of each of these steps may not be known until a couple of weeks after the process has been completed, and some companies can perform all of the steps above and others may only perform one(this can change for the same product depending on who we choose to use for what). If we were to use ofbiz I would probably need to:
I can assure you that many apparel companies operate in this manner and it would be nice to see some extensibility included for this type of scenario (please note I’m still not very familiar with ofbiz so I can’t tell if these requirements would be at all hindered by any of your changes)
Regards Scott
From: [hidden email] [mailto:[hidden email]]
On Behalf Of Si Chen
Adrian, Scenario 1: I build widgets in my plant. I'm responsible for calculating indirect costs based upon MY facility. Scenario 2: I build widgets, but some or all of the manufacturing process is handled by an outside company. I include their fee in the cost of the widget. I can also include indirect costs associated with MY facility (I have to pay rent after all). I may be reading your text wrong, but it seems to me Scenario 2 would generate an error. Si Chen wrote:
_______________________________________________Users mailing list[hidden email]http://lists.ofbiz.org/mailman/listinfo/users _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
|
|
In reply to this post by Jacopo Cappellato
Jacopo,
Please see my replies inline. Jacopo Cappellato wrote: That's a good idea.Si, here are some comments: 1) maybe the WorkEffortCostCalculation.costServiceName could point to the CustomMethod entity (instead of storing in it the service name): in this way it will be possible to provide drop downs for cost service selection I think let's add costComponentTypeId to it as another key.2) I think that the primary key of the WorkEffortCostCalculation should be composed by workEffortId, fromDate, costComponentTypeId (to specify the cost type to which the gl account types apply); or, at least, costGlAccountTypeId I have no objections. Maybe we can call it totalWorkEffortCost? I think CostComponent.cost must be a "floating-point" for precision, but this CostComponent.totalWorkEffortCost can be a "currency-precise" (It is meant to add up to a "currency-amount")3) instead of adding the new assoc entity WorkEffortCostComponent we could simply add a workEffortId field to the CostComponent entity; also, why not storing in the CostComponent entity the total cost of the task (instead of the unit cost)? Should we store in the CostComponent entity one record for each of the WorkEffortCostCalculation entries? I'm not sure about this one. A single Fixed Asset could create several WorkEffortCostCalculation entries, for run time, indirect costs (ie, energy and spare parts usage), maintenance, and depreciation, all of which would need to go into separate GL accounts, while the standard cost of a Fixed Asset is probably one number which incorporates all of the above. So I think it is probably better to keep them separate.4) in OFBiz, there is an entity to store standard costs for fixed assets: FixedAssetStdCost; the fixed asset is associated to the routing task (and production run task) by the WorkEffort.fixedAssetId field; the entity is very similar to the WorkEffortCostCalculation entity, and it is used by the routine that computes the product's standard costs; should we add some of the fields (costGlAccountTypeId, offsettingGlAccountTypeId, perMilliSecond, currencyUomId, costServiceName) of the WorkEffortCostCalculation entity to the FixedAssetStdCost entity too? i think that the new costing process should consider both the FixedAssetStdCost and the WorkEffortCostCalculation entities. Si Jacopo Si Chen wrote:Hi everybody, We're planning on implementing accounting for manufacturing processes. I've created a document that describes how it will be done. Please give us your comments and feedback: http://sourceforge.net/tracker/?func=detail&atid=818035&aid=1460882&group_id=145855 There is also a Word document at the end you can download. Thanks, Si _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users_______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
|
|
In reply to this post by Scott Gray
Scott,
I think the new enhancements should support your process in the following way. You may not know your final cost of each step, but you probably have a concept of how much each step should "normally" cost. So what you could do (but please check with your CPA on this, obviously), is at the time of production Debit WIP Inventory, Credit Sewing/Cutting/Embroidery/Pressing Cost at the standard cost for that step Then when you get the bill from your contractor, Debit Sewing/Cutting/Embroidery/Pressing Cost, Debit Variance Expense, Credit Accounts Payable The Variance Expense account is used to record and charge off as a current period expense variation in actual versus normal costs. In the system, this can be set up as a series of WorkEfforts with offsettingGlAccountTypeId = Sewing/Cutting/Embroidery/Pressing Cost, and manufacturing accounting will take care of it. Later the Invoicing will take care of the rest. Si Scott Gray wrote:
_______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
Re: Users - comments please - manufacturing accounting
|
|
In reply to this post by Si Chen-2
Si,
Si Chen wrote: >> > I'm not sure about this one. A single Fixed Asset could create several > WorkEffortCostCalculation entries, for run time, indirect costs (ie, > energy and spare parts usage), maintenance, and depreciation, all of > which would need to go into separate GL accounts, while the standard > cost of a Fixed Asset is probably one number which incorporates all of > the above. So I think it is probably better to keep them separate. > I see, however my main concern is that, from the user point of view, it could be very time consuming (and difficult to maintain) to set the costs for each and every tasks; sometimes it's easier to set up the costs in the fixed assets (or workcenters). Jacopo _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
|
|
Jacopo,
I thought you might say that. :) With WorkEffortCostCalculation it is of course also possible to create just one entry for all the Fixed Asset's costs, or indeed for all costs of the WorkEffort, including those involving fixed assets, labor, and other variable costs. So if we keep everything in WorkEffortCostCalculation, we would have one entity with as much or as little detail as the user would need. If we put some into FixedAssetStdCost, I feel that we'd have two entities. Further, I feel (perhaps incorrectly) that FixedAssetStdCost is really designed to calculate the standard all-in cost of a Fixed Asset, so it would not allow greater detail should someone need to access the components of it. This makes me feel that using WorkEffortCostCalculation is still the better thing to do, but I'm happy to consider your perspective. Si Jacopo Cappellato wrote: Si, Si Chen wrote: _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
Re: Users - comments please - manufacturing accounting
|
|
Si,
Si Chen wrote: > Jacopo, > > I thought you might say that. :) > Hmmm... I'm not such a big expert really, but there is Mario in front of me that has a lot of stories to tell me about this stuff ;-) We can see the benefits of having just one entity to store the manufacturing costs, so we agree with you that this is the right way to go. However, in some of the manufacturing companies we have in mind, the number of fixed assets (workcenters) is rather small (let's say 10-50) while the number of routing task can be very big (let's say > 500, but this depends on the number and the nature of products). Jacopo > With WorkEffortCostCalculation it is of course also possible to create > just one entry for all the Fixed Asset's costs, or indeed for all costs > of the WorkEffort, including those involving fixed assets, labor, and > other variable costs. > > So if we keep everything in WorkEffortCostCalculation, we would have one > entity with as much or as little detail as the user would need. If we > put some into FixedAssetStdCost, I feel that we'd have two entities. > Further, I feel (perhaps incorrectly) that FixedAssetStdCost is really > designed to calculate the standard all-in cost of a Fixed Asset, so it > would not allow greater detail should someone need to access the > components of it. > > This makes me feel that using WorkEffortCostCalculation is still the > better thing to do, but I'm happy to consider your perspective. > > Si > _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
|
|
This is starting to feel like reality getting in the way again =-O
In that case it probably does make sense to support the same fields at FixedAssetStdCost. So how would it work? If WorkEffort has a fixedAssetId, then we go find the FixedAsset, see if it has costGlAccountType/offsettingGlAccountType? If so, then we use its standard cost or its standard cost based on the WorkEffort's milliseconds? Is it the same formula as with WorkEffortCostCalcluation? Si Jacopo Cappellato wrote: Si, Si Chen wrote: _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
|
|
Alternatively, Jacopo, how about we may WorkEffortCostCalculation an
entity which could be associated with either a FixedAsset or a
WorkEffort? It may require re-configuring its primary keys somewhat,
but if we could do that, we'd save ourselves from duplicating fields
across entities.
Si Si Chen wrote: This is starting to feel like reality getting in the way again =-O _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
|
|
Eureka! Why don't we normalize the relationship so that there is a
CostComponentCalc entity with primary key costComponentCalcId and all
the fields for calculations and a WorkEffortCostCalculation entity
which just links workEffortId, costComponentTypeId, fromDate, thruDate,
and costComponentCalcId? That way the same cost calculation formulas
can be used for many work efforts, and we don't have to bring in a
separate relationship to fixed asset?
Si Si Chen wrote: Alternatively, Jacopo, how about we may WorkEffortCostCalculation an entity which could be associated with either a FixedAsset or a WorkEffort? It may require re-configuring its primary keys somewhat, but if we could do that, we'd save ourselves from duplicating fields across entities. _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
Re: Users - comments please - manufacturing accounting
|
|
Si,
yes, this is very good! To summarize: # WorkEffortCostCalculation * workEffortId (pk) * costComponentTypeId (pk) * costComponentCalcId (pk) * fromDate (pk) * thruDate # CostComponentCalcId * costComponentCalcId (pk) * costGlAccountTypeId * offsettingGlAccountTypeId * fixedCost * variableCost * perMilliSecond * currencyUomId * costCustomMethodName (points to CustomMethod) About FixedAssetStdCost and FixedAssetStdCostType: I think that we should remove these entities and I'll have to patch the service that auto creates the products' standard costs to look at the new entities instead. What do you think? Jacopo Si Chen wrote: > Eureka! Why don't we normalize the relationship so that there is a > CostComponentCalc entity with primary key costComponentCalcId and all > the fields for calculations and a WorkEffortCostCalculation entity which > just links workEffortId, costComponentTypeId, fromDate, thruDate, and > costComponentCalcId? That way the same cost calculation formulas can be > used for many work efforts, and we don't have to bring in a separate > relationship to fixed asset? > > Si > _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
|
|
Pretty much agree with you on all points. See my minor coments. Jacopo Cappellato wrote: I don't think costComponentCalcId also needs to be a PK.Si, yes, this is very good! To summarize: # WorkEffortCostCalculation * workEffortId (pk) * costComponentTypeId (pk) * costComponentCalcId (pk) * fromDate (pk) * thruDate This looks good. So the idea is we look in costCustomMethodId (I think it should be an "ID" because it foreign-keys to an "ID" field?) and if it's there, returns the total cost and per unit cost from there.# CostComponentCalcId * costComponentCalcId (pk) * costGlAccountTypeId * offsettingGlAccountTypeId * fixedCost * variableCost * perMilliSecond * currencyUomId * costCustomMethodName (points to CustomMethod) There was to be another hook from WorkEffort for a costCustomMethodId which would call the method and get the unitCost for InventoryItem. That would allow all of these costs to be called. I know so little about those entities, I really couldn't say. If you think so and nobody disagrees, then that makes sense.About FixedAssetStdCost and FixedAssetStdCostType: I think that we should remove these entities and I'll have to patch the service that auto creates the products' standard costs to look at the new entities instead. What do you think? Jacopo Si Chen wrote: _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
Re: Users - comments please - manufacturing accounting
|
|
Hi all,
in rev 7255 I've committed the two new entities to support the work effort costing as discussed in this thread: are they ok? Jacopo Si Chen wrote: > Jacopo, > > Pretty much agree with you on all points. See my minor coments. > > Jacopo Cappellato wrote: >> Si, >> >> yes, this is very good! >> >> To summarize: >> >> # WorkEffortCostCalculation >> * workEffortId (pk) >> * costComponentTypeId (pk) >> * costComponentCalcId (pk) >> * fromDate (pk) >> * thruDate >> >> > I don't think costComponentCalcId also needs to be a PK. >> # CostComponentCalcId >> * costComponentCalcId (pk) >> * costGlAccountTypeId >> * offsettingGlAccountTypeId >> * fixedCost >> * variableCost >> * perMilliSecond >> * currencyUomId >> * costCustomMethodName (points to CustomMethod) >> >> > This looks good. So the idea is we look in costCustomMethodId (I think > it should be an "ID" because it foreign-keys to an "ID" field?) and if > it's there, returns the total cost and per unit cost from there. > > There was to be another hook from WorkEffort for a costCustomMethodId > which would call the method and get the unitCost for InventoryItem. > That would allow all of these costs to be called. >> About FixedAssetStdCost and FixedAssetStdCostType: I think that we >> should remove these entities and I'll have to patch the service that >> auto creates the products' standard costs to look at the new entities >> instead. >> >> > I know so little about those entities, I really couldn't say. If you > think so and nobody disagrees, then that makes sense. >> What do you think? >> >> Jacopo >> >> >> Si Chen wrote: >> >>> Eureka! Why don't we normalize the relationship so that there is a >>> CostComponentCalc entity with primary key costComponentCalcId and all >>> the fields for calculations and a WorkEffortCostCalculation entity which >>> just links workEffortId, costComponentTypeId, fromDate, thruDate, and >>> costComponentCalcId? That way the same cost calculation formulas can be >>> used for many work efforts, and we don't have to bring in a separate >>> relationship to fixed asset? >>> >>> Si >>> >>> >> >> >> _______________________________________________ >> Users mailing list >> [hidden email] >> http://lists.ofbiz.org/mailman/listinfo/users >> >> >> > > ------------------------------------------------------------------------ > > > _______________________________________________ > Users mailing list > [hidden email] > http://lists.ofbiz.org/mailman/listinfo/users _______________________________________________ Users mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/users |
«
Return to OFBiz - User
|
1 view|%1 views
| Free forum by Nabble | Edit this page |