Menu
▾
▴
Forums
- Language-Serbian 15
- Language-Romanian 9
- Language-Hebrew 2
- Language-Farsi 3
- Language-Bosanski 4
- Language-Slovak and Czech language 9
- Language-Arabic 14
- Functional-Posterita 99
- Language-Turkish 14
- Language-Hungarian 7
- Functional-Human Resource 65
- Localization Brazil 64
- Language-Greek 1
- Language-Filipino 16
- Language-India 36
- Language-Thai-Siamese 47
- Functional-Manufacturing 290
- Language-Chinese 98
- Language-Finnish 5
- Language-Nusantara 56
- Language-Italian 81
- Language-Japanese 33
- Language-Portuguese 82
- Language-French 55
- Language-Bulgarian 7
- Language-German 223
- Language-Russian 15
- Language-Spanish 1180
- Functional-ERP 866
- Content & Documentation 128
- Functional-Financials 503
- Bazaar Projects 136
- Specifications Requests 16
- Developers 3195
- Community Process 327
- Business & Marketing 122
- Functional-Web-based Modules 103
- Help 1700
- Bazaar Open Discussion 2060
Hi All,
We had a problem with standard costing in 340 and ask if anyone has a suggested solution.
The system used Standard Costing and the standard costs were manually set for things like BOM parent products (in fact for all products). Many transactions were posted with Std Costs that were set incorrectly. The Std Costs were then changed and the transactions were reposted.
In the past the reposting would have picked up the current Std Cost but the system now seems to create a cost detail record for each movement of product and then always use that cost in the posting instead of the current cost.
That cost history is great ... unless you are trying to correct an error and actually want the new current cost to be used.
Deleting the Cost Detail record caused the current cost price to be used for the posting but the cost detail records are set as non-deletable so users can not do this.
I wonder if another option should be provided such as storing a Current Cost (Std Cost) record with an effective date (like Currency Rates). This would store the cost history and allow reposting at the Std Cost applicable for the accounting date of the transaction but still allow the cost to be manually changed/corrected.
Perhaps both options could be supported via a configuration flag? Anyone have any thoughts on this?
regards
adaxa
Hi Adaxa!
+1 From my side to support this in Adempiere.
Currently there is nothing related to dates in the Adempiere costing implementation, so no matter which method are you using, all the reposting will end up with the current cost available at the moment of the reposting.
This problem is very important when using standard cost. When you are trying to use another method with Adempiere such as FIFO,LIFO,Average Adempiere should indicate the date when the new cost element was introduced for accounting purposes. So in case of resetting the accounting facts, Adempiere would first sort the costs by date and reapply them.
This could be also the base for another problem that I have faced:
An accounting effective date would be also useful for cost correction with landed cost.
Example:
Purchase 1 unit
Sold that piece.
A Cogs is created
Receive your Landed Cost invoice
A cost correction should be run using the accounting effective date.
Best Regards!
Hi Moyses,
Thanks for feedback.
re: ".... so no matter which method are you using, all the reposting will end up with the current cost available at the moment of the reposting."
I don't think the above statement is still completely correct... although it is not specifically date related, it seems to be that if a Shipment ID exists in a Cost Detail record then the shipment won't repost at the new cost ... perhaps something to do with making sure a return has the same cost as the original shipment (guess?)
Try the following: Install 352 (and we saw it in a patched 340). Change the GW costing method to Standard Cost. Set a Standard Cost for a Product. Process a POS Order for that product. Post the Shipment. Edit the Std Cost to another value. Click "Repost" on the Shipment. Nothing is changed.
Note that it appears to be only the existence of a Cost Detail record for a Shipment that prevents the transaction from being reposted with the new Std Cost. Other records like Material Receipt _will_ repost with the new cost .. seems it is only the customer shipment that will not.
I can understand the desire to have an RMA post at the same cost as the shipment but I am not sure it should if you are using standard costing. If you buy 5 widgets for $10 each, sell 1 and ship it out your inventory is 4 @ $10 = $40. If you then change the Std Cost to $11 then your stock is revalued to $44. If the 5th one is then returned, the debit to inventory should be $11 not the original $10. But I am just guessing that the change was related to managing RMAs.
Anyone see any reason why having an "effective date" on a Std Costing record would cause a problem?
regards..
Adaxa,
That RMA example raises an interesting question.
When I sold my widget I increased Cost of Good Sold by $10.
Now when it is returned I guess I should reduce CoGS by $10.
But the product asset should be increased by $11 (new standard cost) but then how do we balance this? I guess we need to make an additional post to the same account we did when we changed std cost and increased the value of our product asset account?? When we change the standard cost does it actually make such a post or does it simply increase the value of the std cost? (that's not a rhetorical question :) I have no idea what happens currently)
colin
Hi Colin
The reality is that you would debit inventory $11 and credit cost-of-sales $11 ... and hope it was not the only transaction in the month so no-one noticed!
Even if you use Std Costing as your method of managing ins and outs to inventory you will still value inventory at period-end at the lower of cost, replacement or realisable value (or whatever variation of this may exist in your jurisdiction) and debit/credit any difference to cost-of-sales, so it will get absorbed in COGS in that process somewhere.
regards..
Hi All,
We would like a vote on some proposed changes to Standard Costing. The proposed changes are:
1) add a date field to the Std Costing records so the posting engine can use a Std Cost that is defined for a particular period. This will affect M_Cost, the posting engine and the processes in the Costing area on the menu.
2) either removing the creation of Cost Detail records for systems using Std Costing or at the least, making a change so that the existence of Cost Detail records has no impact on the M_Cost values used when posting transactions in a Std Costing system. (Someone went to a degree of trouble to add these Cost Detail records so please advise your views/issues)
If the community agrees to the proposal we will create a spec of the proposed changes before proceeding.
regards
Steven
Hi Steven,
1) good idea +1
2) +1 to make the records have no impact. The detail records can still be helpful in analysis.
Looking forward to progress here!
Regards,
Joel
In principal I agree,
But like the question with RMA, couldn't the same occur here. We buy using stdCost of $10 and increase our productAsset Account then change our stdCost to $11 and sell.. this then reduce the productAsset account by the new changed stdCost. It doesn't seem right. And I wasn't convinced by the RMA answer - to paraphrase "yeah it's wrong but that's the way it's done" :)
It would seem to me that changing the stdCost should be a much bigger process than simply changing an amount. We are effectively increasing our asset value so we must capture that and account for it... (then the above scenario would be ok) .. and when void/reverse - RMA or any other process that potentially uses two different stdCost - then we must account for the difference too.
I guess if all that is too much work, there is an option (I think there is anyway) to post any imbalance in posting to a suspense account. Could we use something similar when stdCosting is used to capture these values?
Or have I misunderstood and the purpose of the proposed changes is to address this very issue? by not using the "current" stdCost value but the cost at the trx date???? Hmm... in which case it all looks good to me :)
colin
Hi Steven,
Sorry I missed this discussion. How is the progress?
As fas as I remember, the cost detail is used to support accounting reset for average costing method. It's obviously unnecessary for standard costing. A quick fix to current logic in DocLine.java can be applied like below so when you're using standard cost, it won't use cost detail.
public BigDecimal getProductCosts (MAcctSchema as, int AD_Org_ID, boolean zeroCostsOK, String whereClause, String costingMethod)
{
if (!costingMethod.equals(COSTINGMETHOD_StandardCosting) && whereClause != null)
{
MCostDetail cd = MCostDetail.get (Env.getCtx(), whereClause,
get_ID(), getM_AttributeSetInstance_ID(), p_po.get_TrxName());
if (cd != null)
return cd.getAmt();
}
return getProductCosts(as, AD_Org_ID, zeroCostsOK);
} // getProductCosts
I could help fixing that into trunk.
Best regards,
Armen Rizal
Hi Armen,
Thanks for response.
We will discuss internally and then get back to you.
regards
Steven
Just a review of this thread while testing Standard Costing. Its been more than 2 years since Adaxa said they like to get back on this. I checked the code in stable branch, this Armen Rizal's suggested fix is not taken. Is it still useful?
@Armen
our humble apologies for not following up after your offer to fix.
@Red1
I am advised that in the site where we were having real problems, we applied Armen's code as below and it solved the problem. I think it would be good to have it the base product. We are happy to apply if there are no objections. Anyone with concerns please advise.
// MZ Goodwill
/**
* Get Total Product Costs from Cost Detail or from Current Cost
* @param as accounting schema
* @param AD_Org_ID trx org
* @param zeroCostsOK zero/no costs are OK
* @param whereClause null are OK
* @return costs
*/
public BigDecimal getProductCosts (MAcctSchema as, int AD_Org_ID, boolean zeroCostsOK, String whereClause)
{
if (whereClause != null && !as.getCostingMethod().equals(X_C_AcctSchema.COSTINGMETHOD_StandardCosting) )
{
MCostDetail cd = MCostDetail.get (Env.getCtx(), whereClause,
get_ID(), getM_AttributeSetInstance_ID(), as.getC_AcctSchema_ID(), p_po.get_TrxName());
if (cd != null)
return cd.getAmt();
}
return getProductCosts(as, AD_Org_ID, zeroCostsOK);
} // getProductCosts
// end MZ
regards
Steven