Manufacturing Costing

[red1]

This is a technical scrapbook when studying Mfg's Standard Costing accounting consequence based on the previous :
1. Cost Details need to be created and populated for Doc_PPCostCollector to createLines() in FactAccts.
2. They are best created through Purchase Order of the needed items. However PPCostCollector CompleteIt() that activates the about FactAccts process still does not get any extra amt value for other Mfg elements such as Burden, Labor.
3. So we need to investigate CompleteIt() in CostCollector to see what it is really doing. I suspect the other elements are to be organised via separate invoicing of such costs.
4. Meanwhile below is the dump of the Fitnesse Test on the Std Costing accounting for the purchase portion. The output is displayed full to date and will be added when the Cost Collector accounting elements are resolved.
5. And they are! Further down is a break-thru in the output. Explanation given there why it is so.

[red1]

Note that with the above purchase, we obtain serial numbering or attribute set instances for the raw materials. Right click and select 'View Image' to see the full image with the accounts entries.

[red1]

The reason why the other costing accts does not kick in is that there is no CurrentCost in the MCost records. In order to do that you need to do as shown in the following screens, which is to run a Standard Cost Update with the following parameters for the Patio group. While doing this i detected a soft error which is the Update does not ignore deactivated CostTypes. (this does not seem critical as it happens due to user ignorance in setting up in the first place).

After running it, you will get a positive updated feedback:

This will be replicated in the Fitnesse test by calling the above process and feeding the needed values into the parameters.
However i found another reason (which is better). The Cost Type in the Accounting Schema was not set to Default which is using the Standard Costing Method! When that is taken care of, the results below is more satisfactory. Thus there is no need for Cost Update as it will be done automatically. Just set the CostType.

Below you can now see that the Cost Collector records are added with Rate Variance type.

The accounting consequence has increased with the work-in-process / rate variance accounting elements.

Note also at the end the postings for a finished PatioSet presented itself.

[red1]

Committed in SVN:
Revision: 15220

Author: red1
Date: 2011-04-08 03:54:12 +0000 (Fri, 08 Apr 2011)

Revision: 15221

Author: red1
Date: 2011-04-08 03:57:10 +0000 (Fri, 08 Apr 2011)

[red1]

From here we close the loop by shipping the sales order of a PatioSet and invoicing it. The further consequence to the Fact_Acct table is as follows (displaying again the last two lines of above):

Note that the cost of the PatioSet is rolled-up from the individual costs of the BOM children which totaled at $125.56.
So here, the most important point we learnt is that Manufacturing only works with Standard Costing and it works well with it.

The latest adjustments for this final effect is made and committed to SVN.

A complete one shot view of the output is given .

[red1]

Question of Backward Compatibility. AFAIU, this question is examined by looking closely at the new code in the branch if they override the core code. There are few packages of core code:
1. Accounting package such as Doc_Invoice and Doc_InOut that handles accounting consequence of the respective document types. So far from what i see, there are no such class override.
1.a The new CostCollector has its own Doc_PPCostCollecter and Doc_PPOrder (Mfg Order) classes with their own default accounting elements. These are fine as they work as separate documents in the system.
2. Cost Engine and Storage classes are separate new classes that may override legacy Cost, Cost Dimension and CostDetail tables. This can be compared with my early days . Certainly there is some change affected as those were previously handled by accounting package core.
3. Any other code that other verticals or customization may reuse also. LiberoValidator does not override any accounting code thus far.

Of course this is as far as one has the opportunity to examine the Libero code. Issue will surface when there is a test case that touches on a certain pattern of code. Thus any test case scenario is highly welcome to expose any potential issue.

The tests constructed here and committed to SVN can be reused on other verticals to see if they comply to expected results. The APIs or components it calls during testing are quite black-boxed so they can be reused on much of the same model code.

[red1]

Below i put in some youtube screen capture movies to help understand how these tests are operated. Enjoy!

[red1]

Here is how to debug such a test via Eclipse: