Part Tracker shows conflicting QOH

On Part Tracker, the On Hand -> Sites tab shows a QOH for one site that is incorrect.


Switching to the On Hand -> Warehouses tab, shows the correct QOH


The On Hand -> Bins tab is correct too.

Any idea why this is?

Hi Calvin,

We are on 10.1.600.5 and are experiencing some of this too :frowning:See screenshots below where we’re getting TX QOH added to our PA QOH. It has happened because somehow the system has added a “bad warehouse” of TX Main to our PA site. We do not have shared warehouses. Your Guthrie site has the 63,728 from Denver in it. It shows up incorrectly in timephase too and i expect MRP might be using bad number.



I have 2 suspicions. Either it’s due to PO suggestions or it’s due to RMA processing, maybe “move checkbox”.

  1. Our PO suggestions since going live on this version have been a nightmare (Epicor SCR208390) where 90% of our suggestions for other sites get assigned to be bought for the correct site but have TX Main warehouse on them. I suspect that when a PO is cut and the buyer doesn’t change the PO release to the correct site warehouse and the part is received in, this “bad warehouse” is made in wrong plant. I am testing 10.1.600.20 where it SCR208390 has been fixed, and so far so good. At the end of it, I’m going to have to try and figure out how to get rid of the bad warehouses on some of these parts however :frowning:

  2. RMA processing… all of our parts with this problem have at one time or another hit RMA processing over the years. I can no longer get back to my E9 database to see if we had this problem before upgrade. We have had some issues with “request move” checkboxes causing downstream problems, either on RMA receipt entry or disposition of RMA to inventory.


Nancy - I expanded the tree view, and see what you’re saying.

Under the Guthrie Site, (2) warehouse show. The second actually being the lone Warehouse for our CHALFONT site.


Since the QOH reported for GUTH (when viewing the Sites tab) is equal to the sum of the QOH at the GUTH and CHAL sites, I’d doubt its a lone odd record or two (like an RMA, or arrived but not received, etc …)

I double checked, an ther is just the one warehouse for the GUTH site, and none of the sites are setup for any warehouse sharing.

Not sure if it is relevant, but we started with one site (CHALFONT), and after a few months, added the other 3 (Guth, Houston, & Denver)

I’m unlocking mental vaults from over a year ago, and since then we’ve gone through a Go Live Implementation, but I think I remember having a QOH discrepancy and a consultant had me look into the “Refresh PartBin QOH From PartTran” in the Rebuild Processes menu because some condition caused a QOH to go awry.

I think the utility has a “Report Only” option so you can run it and see what changes it would make before committing anything to the database. I don’t remember if we ever ran it or what came from it, but it rang bells when I read your problem. Cheers!

1 Like

We’ve run the “Refresh PartBin QOH From PartTran” process before, because the Part Transaction history wasn’t balancing.

I just ran it in Report Only mode and got:

> Processing Started: 02/15/18 13:22:47, UserID = manager, Company = MC, report mode.
> No differences found.
> Processing Completed: 02/15/18 13:24:08, UserID = manager, Company = MC, report mode.
> Total parts processed = 6040. Total PartTran records processed = 61809.

So that’s not it. :face_with_raised_eyebrow:

Bummer. What about the adjacent “Refresh Part Quantities and Allocations?” Just grasping at straws here.

1 Like

Just ran “Refresh Part Quantities and Allocations” (in report mode). The part in question doesn’t show in the report.

In fact, none of the QOH required any updates. Only demand QTY’s changed.

A more detailed look at the Part Tracker shows site GUTH with 2 warehouses, when it really only has 1. The odd thing is that both are designated “Primary Warehouse”, and have the same bin ID


Hmmm, the thing that jumps out at me is the SiteOwner. “MfgSys” is the default Site ID of the first site that is created when you set Epicor up.

We have one site right now, and its ID is “MfgSys.” Was the GUTHRIE site by chance the first site you created?

Our E10 was a virgin install (not a conversion from V8). Originally setup with just one site, which defaulted to MfgSys. the other sites GUTH, HOUS, and DENV wer all added a few months later (all at the same time.

So is MfgSys the Site ID for CHALFONT?


Site ID  Site Name
MfgSys   Chalfont
GUTH     Guthrie
HOUS     Houston
ROCK     Denver (was originally Rock Springs)

Warehouses are:

Code  Name
mfg   Main, Chalfont
Guth  Main, Guthrie
Houst Main, Houston
Rock  Main, Denver

So what we’re seeing in your Part Tracker is that the GUTHRIE site has a CHALFONT Warehouse listed as an available Warehouse for this Part for this Site. Is that physically correct (or even possible?)

And it’s really odd that they’re both marked Primary. In my One Site setup, I’m constrained to a single Primary Warehouse. If I check another Primary Warehouse, it unchecks the current Primary Warehouse. I can’t speak to whether a Multi Site setup would allow multiple Primary Warehouses, but you’d think that would completely defeat the purpose of a Primary Warehouse for a Site, right?

Can you change the state of the two Primary Warehouse checkboxes to the varying combinations of checked/unchecked and save between each change? Does it bark at you with any particular combination?

And just for my curiosity, what warehouses are listed under CHALFONT site for this Part?

It’s really weird because A query of the Warehouse table shows just one warehouse per Site

Company Plant WarehouseCode Name

Query of the PartBin table

PartNum WarehouseCode BinNum OnhandQty
CB-0002 Guth I-0001 15764
CB-0002 mfg c0304 6600
CB-0002 mfg c0401 8806
CB-0002 mfg c0402 13200
CB-0002 mfg c0403 6600
CB-0002 mfg F 28522
CB-0002 Rock FLOOR 3800

Query of the PartWhse table (limited to the P/N in question)

Company PartNum WarehouseCode
MC CB-0002 Guth
MC CB-0002 Hous
MC CB-0002 mfg
MC CB-0002 Rock

A query of the PartTran table for this part shows no records that list a WhseCode that doesn’t exist for the Plant the tran was for.

I tried deleting the Warehouse from the Part in Part Entry, but get:

“Delete not allowed. Referenced by at least one Part Warehouse”

BTW - in what table is the Primary Bin stored?

The “bad warehouses” are in the PlantWhse data. I only find it has a bad effect when we have QOH in the actual warehouse that became a bad warehouse once upon a time under wrong site.

I just went back to my old E9 database to see if these bad PlantWhse data records were in there, and I had only 4 ni E9 compared to about 50 in E10 now. Therefore, whatever is creating the bad PlantWhse records for us is since upgrading to E10. :frowning:
I looked up Epicor SCRs and see some historical issues with PlantWhse, but nothing that looks applicable in E10. I wonder what would happen if I deleted these bad PlantWhse records…

They only time this “bad warehouse” error causes us problems that I’m aware of is when we have QOH in the warehouse that is the “bad warehouse” name for a part. Then it gets double counted, once for the correct site where it’s actually located and then also counted in the site where it is a “bad warehouse” on the part setup.

Calvin, do you have alot of bad warehouse assignments visible in PlantWhse data too?


I only know this because I just did a huge customization around our Primary Bins. Epicor Technical Field Help says the Primary Bin Number is in the PartWhse.PrimBinNum, but it’s wrong.

The Primary Bin Number is in the PLANTWhse.PrimBin field. However, I believe there’s logic linked in with the PartPlant table, as that’s where the Primary Warehouse is called out for your part. A Part can have multiple Primary Bins called out in the PlantWhse table, but the PartPlant table only allows ONE Primary Warehouse.

So PartPlant has the Primary Warehouse for a part, then you look at the PlantWhse table for that Part, Plant, and WarehouseCode. The PrimBin that matches all three should be the Primary Bin.

Nancy - A query of PlantWhse shows 39 of 9713 records with a WhseCode that is incorrect for the Plant.

All the miss-matches are between GUTH and MfgSys.

We never see the “Bad Warehouse error”. I only noticed this while confirming a BAQ I made was matching what the Part Tracker showed.

We are running into exactly the same issue. Epicor provided a fix program, but no insight as to why this is happening (want us in a vanilla environment on the latest version to see if we can replicate it at will and let them know what is causing it).

Glad to see we are not the only one with this issue. The fix program works (one off data fix), but I want to get out of the business of running a fix every day. On a given day, I’ve seen anywhere from 3 to 38 bad records created. So far, nothing recent in the part transactions for any of these parts when this comes up.

We see the same problem with our on-hand quantities in time phase including the invalid warehouse in the running total - so our users don’t trust on hand quantities in the system.

If anyone had this problem and got a one-off for the SCR mentioned please let me know if you found it worked for a permanent solution.


Tech Support provided me with a datafix “”

This fixed the problem by removing the bad PlantWhse records

The ReadMe.tx for the fix is as follows:

DATA FIX FOR CHANGE REQUEST 38105MPS -  - Remove PlantWhse If Warehouse Code Is Invalid or partnum is invalid

Remove PlantWhse If Warehouse Code Is Invalid or partnum is invalid 

Required Input:

Table.Field	Chg Type	Comments
PlantWhse	Delete	

     Object Name

Please read the attached Word Document "Running Erp10 Data Fix Programs.doc" for complete instructions on installing
and running Erp10 fix programs.

VERSION:  10.1.400.23

Hi Calvin,

Did support provide any details on how the bad PlantWhse records got there in the first place?


No. But the datafix included some DLLs to copy to the server and my client. Not sure if those were just required by the Datafix Workbench, or if any would stop this from happening in the future.

Also, I had to run a process in the Epicor Admin console using “Import DB Health Scripts”. Again not sure if that was just allow running the one time fix of the existing bad records, or somehow fixes what would cause them in the future.

One last thing. Besides having mis-matching Plant-Warehouse records, it also identifies reocrds with “invalid Part Number”. Which looks more like it was parts that are not setup to be Qty Bearing, or otherwise shouldn’t have Plant-Warehouse records.