PlantWhse, PartWhse: how do these relate (Think we have bad data)

We have a warehouse under one site, but parts are showing up in that warehouse under a different site.

In one of our companies we have two sites, the main site MfgSys has multiple warehouses, the other site (AUS) has a single warehouse (warehouse code FULO). MfgSys does not have a warehouse FULO.

but… erp.PlantWhse is showing (for many parts, just looking at a single part here) that warehouse code and bin associated with both sites?


It looks to me like we might have screwy data here? (We are still pre-production, building pilot type databases. I have a suspicion parts were put into stock when the warehouse was under the main site, and then the warehouse later was moved to the AUS site… but I wasn’t involved with this)

When i look at stock level in the Part module, under Sites tab, I’m seeing confusing data, eg:
image
so looks like 332 parts total.

But if I click on each Site in turn i see:
Australia (shows nothing):
image

Main Site (shows the Austalian FULO stock):
image

shows total 322, so is my total stock on hand 322 or 332?

I found a useful entity relationshsip diagram from @timshuwy here Documentation via PlantUML - #2 by timshuwy but the post context was more about the diagramming tool than the diagram content.

I’m confused about how these tables interact and what their function is , esp PartWhse, vs PlantWhse.

Did you check your Site setups to make sure you are not sharing warehouses?

1 Like

We are.
Site configuration → MfgSys site → Shared Warehouses shows the Future Logistics (FULO) warehouse there. Does this mean that the main site can put its stock in the other (AUS) site’s FULO warehouse?

If so then does that mean the “on-hand qty” below is a little misleading?

image

It appears when I actuallly go into sites that all the stock belongs to main site, with 312 in the AK (auckland) warehouse, and 10 in FULO warehouse, and that the au site has no stock of its own, so 322 is the total “stock”?

I’m not sure how that functionality works, I just thought that might explain why the part was showing in both warehouses in the DB.

There was a bug in PO suggestions we ran into at 10.2.600.??. We had a fix from support to delete the corrupt warehouse. Something with running MRP wide open for both sites. If we would run MRP with the plant filter it was fine (full regen). It was a fix program we couldn’t schedule, so we ran it almost every day. Now Epicor is going to data specific fixes, so not sure how that would work if you are running into the same issue.

It was confusing some of our personnel because it looked like you at twice as much stock on a part in time phase. MRP only counted that stock in the legit warehouse.

Looks like you’re on a Kinetic version so I will have to do some testing to make sure we aren’t seeing it again. Thanks for the heads up and good luck!

Jenn

1 Like

PlantWhse facilitates the feature of Shared Warehouses and defines the relationship between the PartPlant table and the Warehouses in the Company (Site Configuration > Inventory > Shared Warehouses). If Shared Warehouses are enabled or not then the Plant that the warehouse belongs to is defined by the PlantWhse table.
Data Dictionary Table Description:

Warehouses associated with a Plant via a part. Needed since Plants can share warehouses and the Primary bin may be different for the same warehouse for different plants.
At least one PlantWhse record will exist for each record in the PartPlant file.

But notice that the Warehse table, nor the PartWhse table contain a Plant field to define which Plant the Warehouse belongs to, this is done with the PlantWhse table. It’s best practice to link through the PlantWhse to Warehse, PartWhse, PartBin, ect. If you don’t you can get incorrect data in BAQs.

However, from your screenshots, you might have corrupt data, but Epicor includes a built in data fix processes to correct on hand balance issues, there are two you can find in the menu:

  • Refresh PartBin QOH from PartTran
  • Refresh Part Quantities and Allocations
    Each offers a Report/Log only option so you can first review any potential issues before affecting on hand inventory balances. Use these processes with caution as you can cause a mess if you don’t know what speicifical will be ‘fixed’ and how that may affect accounting.
    I once assisted a client through this process, but they had a lot of corrupt data back from Vantage days and their finance team was making journal entries to ‘true up’ the GL to the Stock Status report, which caused a bit of a mess. While these processes do not create any transactions and will not cause any Journal Entries when running the capture, it may change PartBin & PartWhse balances, which may need to be corrected to actual on hand with a manual count, which those transactions would get captured. And if your finance team has been entering Journal entries trying to ‘tie’ the GL to the Stock Status, there will likely be differences that they will need to adjust for. So run the processes in Report/Log only mode or use your Test DB to evaluate the issue. You can also run the processes by Part number so you can minimize the impact.
    Check the embedded Help articles on these processes as well as the following EpiCare KBs:
  • KB0111804
  • KB0119618
  • KB0117244

If you intend to run these processes and find that PartBin has inconsistancies, you would first run the Refresh PartBin process, and then the Refresh Part Quantities, since PartBin is updated based on PartTran and Part Quantities relies on accurance PartBin balances.

5 Likes

Thanks Rick, I’m gonna read this another two or three times to get my head around it, then hopefully do something amazing. :grimacing: :grimacing: :grimacing:

As we are not live yet, if stock levels go wrong during cleanup, but at least become self-consistent, that will be fine.

I ran these, the first Refresh PartBin QOH from PartTran made some adjustments to 4 parts, but not the part X10981 I’m looking at.

The second Refresh Part Quantities and Allocations I have run report only, and produced a pdf report that had 22 pages but no reference again to my test part, i didn’t run this in update mode.

Are you certain you do not have any Shared Warehouses configured in Site Configuration?

No, I do indeed have one shared warehouse as per PlantWhse, PartWhse: how do these relate (Think we have bad data) - #3 by Chrisw

What I think I have seen is that when I look at the aucland site its including the stock in the australian shared warehouse. I can live with that once we understand that to be the case.
ie On the Sites tab the actual On-Hand qty across both sites is what is shown in Auckland (322, being 322 in Ak warehouse and 10 in AUS site’s shared FULO warehouse).

And if I click on the auckland site I can see that spelled out.

But why when I click on the australian site does it show no warehouse containing this part?
(This is from Part Tracker, no customization)

stockissue