Fred,
What I am saying though is that the Epicor field actually has less precision in it’s unit price field compared to big decimal.
Precision, scale, and length (Transact-SQL) - SQL Server | Microsoft Learn
What is IT in this sentence? The total amount?
I see what you’re saying. When I go into Invoice Entry there is only 5 decimals precision for the unit cost.
The calculation between quantity, cost, and extended cost is much more dynamic in Invoice Entry. This is what allows our processors to set the total cost, and the unit price will be calculated automatically. The calculation* that ECM is doing seems to be a lot more rigid in that it determines the total cost based on the unit cost, and only in that direction.
I put an asterix on calculation, because I thought ECM was actually just pushing the values to E10, it did the calculation, and then spit it back to ECM. Maybe that isn’t the case?
1 Like
Fred, you just said the answer and the way to go about this.
You need to study the fields that are involved with the calculation on the Epicor screen and then find out what those fields are in ECM and make sure they are matching in precision.
@vleveris @BScanlan is there anything y’all could do to help, via consulting or here on the forum? Maybe summarize the issue/solution in a different way to help @fredmeissner see the issue here?
@fredmeissner has somewhat of the same issue as me, but we overcame by putting one field as big decimal.
Keep digging here and you’ll figure out what you need to do on the ECM side.
What do you mean it’s much more dynamic…
Give me some math. give yourself some math.
To reiterate Utah’s point above, the first step would be to determine what field(s) are causing the most issues - is it the unit cost or is it the quantity that is causing the number of decimals to go beyond 5 (or a combination of both)? You can then check how those fields are setup in ECM to ensure that as the data is being pulled into ECM from Epicor it is bringing in the same values as what is stored in the Epicor database.
Once that is determined - you can play with setting the appropriate fields to be big decimals and see how that impacts the workflow.
1 Like
By dynamic, I mean that in E10 you can set the extended cost and it will automatically calculate the unit cost. If the same could be done in ECM, I believe it would resolve this issue. I know I could add my own task that does this, but I’d like to understand why the standard “E10_Read Invoice Line Items” Datalink doesn’t allow for this functionality, or if it could be adjusted to allow for it.
@fredmeissner, when I did the homework and realized exactly what I wanted the workflow to do, based on how we do it in Epicor, I had @BScanlan help me execute it.
There’s been pretty much nothing she can’t do.
I would take the time to work with teccweb and/or study the process yourself and make the datalinks and workflow steps/actions work the way you need them to by modifying the existing ones, or creating your own.
We had @BScanlan make the workflow recalculate based on unit cost and/or quantity updates that we’d make so that the ext cost would be recalculated. We didn’t do it the other way around, although if she got the ext cost to recalcuate based on updated receipt line unit costs/quantities, I don’t see why she couldn’t do the inverse, you see what I’m saying?
I agree with you, in many ways “AP Automation” is misleading when it doesn’t do very simple things that the Epicor interface already does, but I think that Epicor has improved a lot since the very first pitches they were doing. In the beginning it was being way oversold- with all due respect. But now, they are adding a lot to it and truly making it marketable as “AP Automation.” What they are still missing in the out-of-the box workflows (which I would argue should do exactly what the Epicor interface does), they burden us with, but working with @BScanlan and some of the other ECM support agents and higher level team members there, we have overcome that. I sit in on some of the product meetings as a customer and I will bring this up in the next meeting okay? Cause you and I both deal with it.
I also see that you are on 10.2.600, are you using the V2 workflows or V1? Because I think @BScanlan has told me that calculation issues like this have been a little smoother in V2 as opposed to V1, but I don’t know if this situation applies.
2 Likes
Especially without IDC. It’s AP Almostmation.
1 Like
Yeah definitely need IDC to automate it.
We are actually in the process of moving to V2, so I will bring this up with our consultant who is handling that!
1 Like
I’ve definitely ran into issues with unit costs as these can be rounded differently by each vendor and cause mismatches when ultimately it is the extended cost you care about. Since you’re using the IDC PO Invoice workflow, you are likely bringing in the line items from IDC.
A workaround that I have often found useful is to change how the lines calculate in IDC. Rather than calculating the Extended Cost from Quantity x Unit Cost, I would switch to calculating Unit Cost from Extended Cost / Quantity. This helped in situations where the unit cost on the invoice isn’t in the UOM that the extended cost is calculated from. Eg. 10,000 ft x $1/1000ft = $10. In IDC, this would often calculate as 10,000 x $1 = $10,000, which is obviously incorrect.
The same can be done in ECM, though, and is something we’ve often had to do in the v1 workflows. The v2 workflows do handle things better, but it ultimately comes down to the fact that the extended cost is the critical value. While the IDC PO Invoice workflow does require strict matching by default, you can increase the thresholds, where needed, to find the matching receipt. From there, you can evaluate the variance and then choose to use the IDC values instead of the Epicor ones.
2 Likes
Thanks for taking the time to write that Victor.
Thank you too, Beverly!