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. 
Bummer. What about the adjacent “Refresh Part Quantities and Allocations?” Just grasping at straws here.
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?
Yes.
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 |
|---|---|---|---|
| MC | GUTH | Guth | MATCOR INC, - GUTHRIE |
| MC | HOUST | Hous | MATCOR INC. - HOUSTON |
| MC | MfgSys | mfg | MATCOR, INC - CHALFONT |
| MC | ROCKSP | Rock | BRAND/MATCOR INC-COMMERCE CITY |
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. 
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?
Nancy
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.
Thanks!
Jenn
Tech Support provided me with a datafix “CR38105MPS_10140023_SQL.zip”
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
FX_Del_PlantWhse_Invalid.df
Remove PlantWhse If Warehouse Code Is Invalid or partnum is invalid
Required Input:
Company
Plant
TABLE(S), FIELD(S) AND/OR OBJECT(S) AFFECTED:
Table.Field Chg Type Comments
PlantWhse Delete
Fixes
Object Name
FX_Del_PlantWhse_Invalid.df
HOW TO RUN THE FIX PROGRAM:
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.23Hi Calvin,
Did support provide any details on how the bad PlantWhse records got there in the first place?
Thanks!
Nancy
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.
Thank you Calvin!
Nancy
I’ve done some testing and think I have it narrowed down. I will just need to get a vanilla environment at the latest version to see if I can recreate it and then report it.
The bad plant warehouses are coming through on PO Suggestions. It looks like this happens when we have a purchased part with a revision. The revision is set to Site A, a PO suggestion for Site B adds the main warehouse for Site A to plant warehouse table in error.
From a technical standpoint you don’t need a revision on purchased parts, but from a business process you should so your suppliers know what version to be producing. We’re not about to add alternate methods to all of our purchased parts with multiple plants (alt methods are very confusing), so I’ve just kept up the daily routine of running the data fix for now.
Would you please share the script?
I no longer have access to that Epicor system. Probably better off getting it from support for your version.