Sometimes the total amount on the invoice is a little different than our PO due to rounding. Some of our sites are able to charge the 1 or 2 cents to a variance account, but others are not able to do this. Even though the LINE_UnitPrice field is a BigDecimal, it still doesn’t calculate using more than 5 decimal places. In some cases that’s not enough decimal places to get it to exactly match the total amount. In these instances, our AP processor has to key these into Epicor manually.
Is this a PNP or Line IDC workflow?
It is IDC.
You can change it, we ran into this as well in ECM, not IDC though so now I’m confused.
You are having this in IDC?
The issue is in ECM, not IDC, since that’s when the unit pricing gets pulled in from the PO.
Yeah, so is the field in your field group already set to big decimal?
For us it was the vendorqty not the line unit price, but we just changed this to BigDecimal and then we were fine.
It will break your attachments though. Like we chose to use big decimal, but it broke attachments when you double click them.
I would add a tolerance to the match and resolve mismatch steps on the unit price, then the match will allow the value to match, since more than 5 decimals is not possible on ECM. For the PNP workflow you can use the extprice as the only variable and clear the unitprice/qty. For the IDC workflow, you need to add a tolerance for the mismatch/match, then the precreate will check for an overall variance.
You have a display format in there, do you know what c2 means when it comes to display?
@fredmeissner would you please respond to let others know if that was the root cause in case they also come across this problem?
That displays it as “currency, 2 decimal places”, but it’s just for displaying. It still stores 5 decimal places.
And is your vendor quantity only ever 2 decimals?
Not necessarily. It is not set to BigDecimal. Maybe this affecting the calculation?
Okay, I’m not saying you need that, but for us we didn’t’ need big decimal at a unit price, we needed it at the vendor qty level. Maybe you need both? Are your vendor quantities adding up just fine then? It’s really just the price?
Fred,
Here was our business case:
Business Case:
We order 150 LBs of product which is 1000.12345678 gallons and is received in 100 totes of 10.00123456 gallons.
So, we enter 100 receipt lines to generate 100 unique lot numbers, one for each 10.00123456-gallon tote.
Now when ECM processes the invoice and pulls in the receipt lines, it cuts off the last 3 decimals on each of the receipt lines and those decimal quantities stay out there as un-invoiced. So, a receipt line in the example above for 10.00123456 is pulled in as 10.00123 in ECM and .00000456 stays out there as “un-invoiced” in the system.
At the end of the week, month, whatever, we print off the received not invoiced and see 200+ pages of receipt line quantities for many different POs that we then have to manually pull in and re-invoice because we can’t use the same precision in ECM that Epicor uses in their own AP module.
Furthermore:
@fredmeissner this is what precision big decimal uses:
And this is what the unit cost field is on APinvdtl:
We are having a continued issue with decimals from invoices processed with ECM.
It’s the whole number of decimals issue. I think you mentioned that the our qty and vendor qty fields were limited to 5 decimals in ECM.
We need them to have the same precision as Epicor which I believe decimal(22,8). We are being left with hundreds of partially invoiced receipts each month because of these fractional decimals being left out.
Every month we must go clean them up and manually create invoices, select the fractional receipts, and post. It’s becoming a large burden on our staff and taking away from the goal of AP automation which is to automate the process by eliminating clicks and manual entry.
Is there anything that you could do to help us that would be blessed by Epicor as a workaround? And could we have the work performed by you guys so it’s acceptable?