So, we had an instance just recently where someone messed up the quantity per on a PO. It was supposed to be $7,364 per 1000. They left it as /1. So the line price was now $920,500 instead of $920.50. (Of course they blew by the warnings we already have in place to warn them of this, and of course didn’t send the change PO to the supplier, or they would have seen it… but I digress).
The inventory gets received. Pack slip with a unit cost of 7,364.
Looking at the log this made it past the 3 way match.
Looking at the workflow, It looks to me that it should be comparing the unit cost from the pack slip to the unit cost on the packs slip to what’s in the record. But somehow… this didn’t get stopped.
So I’m obviously not understanding something here. The screen shots of the “bad” PO are from a copy of the database before this was all fixed. And since it’s so hard to set up these workflows to other databases, I don’t have great way to test and see what’s going on here.
Can anyone see what I’m doing wrong here, or what I should look for to figure out why this would have made the 3 way match when it clearly should have failed?
I’ve used OurUnitCost when workflows need to use qty per on a Purchase Order.
I would look at the integration and use the VendorNum/PONum on the Read Uninvoiced Receipt Lines to validate which field contains the correct value that you would like to compare to.
I believe that the initial Auto-Match step would have matched on the PartNum and Qty values. Depending on the settings in that Auto-Match step, ECM may then have calculated the UnitCost based on the captured ExtCost being divided by the confirmed Qty value. ($964.68 / 131 = ~$7.36)
If this is what occurred, then by the time it arrived at the 3 Way Match step it would be “correct.”
Can you provide a screenshot of the Auto-Match task? If you have a recording you could share, that would be even better!
But that wouldn’t have matched. The PO was wrong, and so therefore the invoice total shouldn’t have matched the PO/receipt total.
I just realized that I assumed if the line prices were set by the import, that they wouldn’t be changed. So I check the XML file coming out of IDC and it read the line costs as $7364 (because of the per cost).
So IDC didn’t do the per/price correctly, which is what I would expect. I just would have thought that the 3 way match would have either failed if it didn’t match, or if it was all wrong and it did would have had a variance, which if did not.
However, the line is ECM says $7.63. What I can’t figure out is how that somehow changed after the match??, but before the invoice got created.
Unfortunately I don’t have a recording of the issue, because I wasn’t watching it when it happened. We just saw a massive PPV which is why this got brought up. But we are trying to figure out how this even got through the system and matched.
Normally something like this would cause a variance, and we have our workflow set up that if there’s a variance, it simple creates the header record only, and the AP people would bring in the lines manually and they would have caught this. In this case, IDC/ECM brought everything in with no warnings or any reason to think that something was wrong until after the invoice was posted.
Things are a little more clear with that you’ve provided, but tough to say exactly. From what I can tell from the XML of your workflow, it seems that you’re doing a direct match on Quantity and UnitCost in the Auto-Match Receipts workflow step, but not the PartNum. If that fails, it will send it to the Auto-Match workflow step where it will only compare the invoice subtotal to the combination of uninvoiced receipt totals in Epicor for that PONum. In this case, it didn’t fail as it found a match and sent it to the Match workflow step.
ExtCost of $7,364 and Quantity of 131 matched the PackSlip details.
Based on the above, I would estimate that this went through as a match and then got sent to the Pre-Create. The Pre-Create is not looking at the receipt to validate anything and then calculated the UnitCost based on the math of ExtCost / Quantity. ($964.68 / 131 = ~$7.36)
Essentially, this is a rare case where the fact that the invoice stated the UnitCost in /1000 and the PO/Receipt used that exact same value by mistake, it all matched up. I can’t say I’ve experienced this rarity myself…
I realize I’m coming into this pretty late, but it seems that the only fields that DON’T match properly are the CostPerCode field and the Extended Cost value. Unless your workflow looks at those specific fields, this kind of error can slip by.
