ADJ-CST / ADJ-PUR Question on CostMethod Avg

It is my understanding that typically ADJ-CST and ADJ-PUR, PartTran records get created when you Variance. PPV/IPV. No problem. Usually it will use your STD Cost.

I have noticed that in my PartTran table exist Purchased Parts (Not in Inventory) and, either the process created the records or Finance Adjusted the records.

What I can’t figure out how does Epicor know to stamp these as PartTran.CostMethod = ‘A’ and Varianced based on Avg Cost; we have no “Avg” costing whatsoever in our PartCost tables and these parts are on-the-fly; like staplers, toilet paper…

Dear CostMethod = ‘A’ where are you coming from my friend?

SELECT CostMethod, * FROM Erp.PartTran WHERE CostMethod <> 'S' AND TranType LIKE 'ADJ%';

There is a default costing method setup in company config. Take a look there.

Does the transactions math actually use the AVG method of:

(Prior QOH x Prior Cost + Rcv Qty x Rcv Cost) / (Prior QOH + Rcv Qty)

And are their PartTrans of type ADJ-PUR, for those parts that aren’t CostMethod ‘A’?

Try:

SELECT PartNum, CostMethod, COUNT(TranNum) 
FROM Erp.PartTran 
WHERE TranType  = 'ADJ-PUR'
GROUP BY PartNum;

and see if it is always just the one Cost Method for each part. If a single part has different CostMethods for the ADJ-PUR tran type, see what is different about those. Received to stock, Received to Job, etc …

All Defaults are STD, we have 0 trace of AVG anywhere.

For some, not for all - but even the ones with 1 all have a Variance with CostMethod = ‘A’ and I can’t figure out, how Epicor decided that should be the variance based on what historical information does it know that “charming toiletpaper” should variance lol

These parts are not inventory parts, they are purchaed with Type: Other on PO.

@hkeric.wci - That shows the Qty of trans using AVG costing.

I want to know if a part (say 63132) has some trans with method ‘A’ and some with method ‘S’

If so, what is different about those trans that caused them to use a different method?

See it has nothing besides ‘A’ - which is what I am hunting for how did it know to use A unless thats an Epicor default based on PO Other Parts.

Are these non-qty bearing items? Or BTO?

Why do PUR-UKN transactions have a value in the BinNum field?

Edit:

Do these even have entries in the Part table? If not, then cost method Avg is the same as Last. And if no Part master entry, where do you think the STD cost would be?

Those are PO Parts, not inventory.

That Part does not exist in Erp.Part

I dont know why it has a BIN, odd - obviously at PO Level it wouldn’t know, unless its just the Receiving BIN

PS: Excuse if I dont know the full process =) I know enough to be dangerous, but some of these “special anomalies” are a bit beyond me

Okay.

A Buy to OTHER expenses the cost upon receipt. so the flow is:

  1. Buy to OTHER PO line entered with qty and unit cost. No GL or PartTran trans happen.
  2. The PO Receipt happens. No PartTrans happen as this is not a Qty Bearing part. GL Trans are created with the Expense Account and AP or Accrual accounts CR’d and DB’d (not sure which is which)
  3. The Supplier invoice is entered and the cost differs from that of the PO. This has to then make adjustments so the expens account is corrected and the AP Accrual are correct.
  4. AP Cash disbursements then zero out the AP Accrual amonut.

So it is step 3 that is happening.

Lets say theoretically I get it:

We have a PUR-UKN and then someone Invoiced it causing a ADJ-PUR and that’s my variance. But, is Epicor by default assuming “A” as AVG Cost for these parts, how so, when I have 0 trace of AVG Setup anywhere?

What I am trying to build is a IPV Dashboard and I just need to know which formula to use for my SUMs() perhaps for these A’s i use AVG() =)

To use averaging it would have to have old and new Qty’s. So I doubt very much that it is.

Maybe you can just pretend that ‘A’ is for “Adjustment” :slight_smile:

Maybe it is, thats what I was trying to figure out… Epicor’s logic… Perhaps it treats PUR-UKN as A and simply just considers it an Adjustment :slight_smile: and the ‘A’ has no meaning. =)

Perhaps Its assuming, since its not an Inventory Part you cant really get a Standard and you have no Price List on Supplier Record, you do not control the cost, so we are going to consider it AVG, which makes sense. I just havent found the docs to proove it.

What do you think @ckrusen any final thoughts? =) Before I consider it as a move on.

@ckrusen maybe its the default for PUR-UKN parts; judging based on the Receiving Internal Code:

ttPartTran.CostMethod = 
((PartPlant != null) ? 
PartPlant.CostMethod : ((Part != null) ? Part.CostMethod : "A"));
Part = FindFirstPart(RcvDtl.Company, RcvDtl.PartNum);
if (Part != null) {
    vCostMethod = Part.CostMethod;
}
else {
    vCostMethod = "A";
}

Obviously those Part’s don’t exist in Inventory and have no PartPlant or Part record. Now I just have to find the help or documentation support this claim =)

One more question to answer, is does it Recurse through PartTran if you have purchased this PartNum in the past to determine an actual AVG, If it’s from the same Vendor. (I can test this logically)

1 Like
  1. I’d mark post 16 as the solution
  2. I would be incredibly blown away if it did that recursion thing you mentioned. We have many PUR-UKN PO lines that use the same “Part Number” for entirely different things. Like the following:

image

Using historical costs for something that might not even be the same thing, would be incredibly bad.

I wonder if they recurse with the VendorNum in mind… I doubt it, I doubt they recurse, perhaps they don’t recurse and its a 1 time thing, Per TranNum.


EDIT:
Based on your screenshot, you have proven that it doesnt recurse, aslong as its for the same Vendor, is it? =) otherwise your AVGs would be diff.

Yes. All PO’s for the part in my example were for the same vendor.

1 Like