Can't print 1099s or open receipts

Epicor ERP 10
, ,
1

I couldn’t find anyone talking about this issue, so here’s something I discovered this week and how my organization is working around it.

The symptom:
When AP runs “1099 Generation US” with mode set as “New Forms” or “Regenerate all forms” for 2020, the process fails. The system monitor will error out and show “Unit of measure conversion not found for Class:Count UOM EA-D”

The problem:
It was discovered that opening (some) receipts in receipt tracker would illicit an identical error to that produced by the 1099 generation. These receipts are for PO lines using parts on the fly (POTF) that were later added to the part master. Only POTF line items that used the EA-D UOM could not be opened, however. This combination of POTF & UOM = EA-D & added to part master later, narrows the problem down significantly.

I believe the reason this combination prevents viewing a receipt is because the part master specifies the UOM class, which is used to select a conversion from the receipt UOM. When the receipt UOM (i.e. EA-D) does not belong to the UOM class of the part (Count), it fails to load, hence the error (“Unit of measure conversion not found for Class:Count UOM EA-D”). This can happen even if the part master record is created after the cutoff date for the 1099s you’re generating.

This is why my 1099s fail, because Epicor must be accessing the receipts to find the value of received items per vendor. My advice to anyone with similar 1099 issues would be to search for receipt lines for POTF with a part master definition whose UOM class is inconsistent with receipt UOM. Fix those receipts or remove them from the automated 1099 process.

Here’s some SQL/BAQ I’m using to identify these unopenable receipts:
SELECT
ArrivedDate, PRT.UOMClassID,

  • FROM Erp.RcvDtl RCV
    INNER JOIN Erp.Part PRT ON PRT.PartNum = RCV.PartNu
    WHERE RCV.PUM = ‘EA-D’ --set to your POTF UOM

Potential solutions:
Use AT YOUR OWN RISK.

  1. Remove the part record.
  2. Change the EA-D UOMs.

I’ve opted to change the EA-D UOMs to match the part master. I’ve successfully repaired a receipt this way, using SQL update statements for UOM fields. I get a bad feeling when I do this, but so far so good.

So far, my testing is telling me these are the required tables that need UOM updates.
APInvDtl
NonConf
PORel
JobMtl (the demand source)
PODetail
PartTran
RcvDtl

I will be correcting a few dozen receipts and will reply to this post with my final results.

2

A good general search would be for any entry records that reference partnum (like: OrderDtl, RcvDtl, ShipDtl, InvcDtl, etc…) That have a Part table entry, but no UOM for the part’s UOMClass.

3

Thanks Calvin!
Update: I applied my fix to over 2 dozen records with success.
Afterward, I was able to access the receipts in question and generate 1099’s!
Long term, I’ll implement a BPM that warns users at part creation for mismatched UOM class. And we may stop using POTF UOMs on POs.