Hello everyone,
Looking at the transaction history, the following transaction is generated.
We only did Receipt once on March 11th. What kind of transaction is this transaction that appeared on March 16th?
Thank you in advance!
That happens when cost on the receipt is changed and doesn’t match the PO.
1 Like
Thank you for your reply.
But, I checked the cost of the receipt and the PO, and they are the same.
Did I misunderstand your answer? Could you Please explain a little more about the above reply?
@pilio.lee , with out clicking around your system, I’m not sure. Variances happen when something doesn’t match, so something somewhere doesn’t match.
Thanks for the reply.
The strange thing about this case is that the Arrived Date and Receipt Date are different.
Can this happen in this case?
Yeah, you can enter the lines, and that generally is when the arrived date is set, and then when you set the line as received, it sets the received date. If you don’t do that on the same day, they can be different. Generally the arrived date wouldn’t be later than the receipt date, so it looks like someone was messing with the dates.
Add the TranNum field to your grid and then sort descending. I bet you will find that the lowest transaction (first) from the screen shot above is your STK-MTL transaction which would have driven your on hand negative giving the variance.
Or if you are on std cost and the standard does not match the PO price. That’s not necessarily bad - it’s actually the point of std costing.
1 Like
We use Std cost, but in this case, Std cost and PO Price are the same.
Does this happen even if the cost is the same?
In testing with other cases, this happens when the Arrived Date and Receipt Date are different. However, the problem is that the Arrived Date is set only on that day, not on the specific date entered.
Is this something unavoidable? Can something change if I change the settings?
Hi Pilio,
Is it possible that someone unchecked received on the receipt? This would back out the quantity and the cost. Here’s an example in our system ( we use std cost too) where user likely entered the receipt, wrong bin, unchecked received, fixed bin then re-received.
Nancy
We have the same issue occasionally with purchase order receipts and I have not been able to replicate the issue.
I have tried deleting the Receipt Line, Unreceiving the PO Line, deleting the Receipt Head, Unreceiving the Receipt Head, changing the receipt and arrival dates.
None of these transactions create the ADJ-CST transactions that we are seeing.
I’d really want to see some of the cost fields in Part Tran History Tracker. Ext cost, mtl cost, (mtl burden) cost.
I see that “qty of 212” is cost-adjusted, but the dollar/euro/whatever amount should give a major clue as to where it is coming from.
Does the part have a material burden rate set on it in Part Maintenance?
Below is the cost field.
Because we use Std cost, the material burden rate is not set in parts maintenance.
Last requests - in the screen shot of Part Transaction History Tracker, include
- both dates in there: system date and tran date
- the transaction ID integer (or the time field; either one is fine)
And sort on UOM. (Yes, UOM; I know it’s all the same. The point is to make sure you have it sorted in the ordinary Epicor way, and the easiest way to do that is to sort on a column that has the same value on every row.)
I think you set your standard cost (i.e. made it not zero) after you did these receipt transactions.
So, you are right, MB is not your issue today. But as a sidebar, you can use MB with Standard Cost. We are looking into that ourselves.
1 Like
OK, so this is very normal.
-
You did the receipts when the standard cost was zero, so the entire PO price goes to variance (ADJ-CST). And this is all about system date, not “Date” - which is transaction date.
-
Then (again, I mean in real-life time, not transaction date time) you did the std. cost adjustment to value the part, and since you had 212 OH, you get another ADJ-CST for the value of the entire inventory.
(That total just so happens to be the same currency total as the PO receipt ADJ-CST, but it’s not always so clean like that - if you had done other transactions between those two times.)
- And then finally (in real-life time), you issued all of them to a job at their nonzero cost.
- Now, realize that if you had done this in a different order (like 1,3,2), you could issue all those parts to the job at zero cost, thus making the job look like it made a huge profit!
So, going back to point 2, where I work, we use the same GL account for both kinds of ADJ-CST, so here the whole thing would wash out. But everyone basically hates that and I don’t get why we do it either. 
PS, last year I finally made a BPM to block any transaction at zero standard cost - with some exceptions (PUR-UKN and KIT-CUS, for example).
1 Like
Thanks for your detailed analysis.