Non Nettable BINs

Epicor ERP 9
1

Is any one aware of a BUG or ISSUE in Epicor 9.05.702A with Non-Nettable BINs?

We always seem to have some strange issues with ours.

2

Can you be specific with the “strange issues” ?

You do know that Qty’s in Non-nettable bins aren’t always included in QOH counts? The SSR report for one, can exclude non-nettable bins for being included in the report.

3

Yes, but we have a Non Nettable bin for shipping. They move all parts there that need to be shipped. It doesn’t always take inventory out of the BIN and not from anywhere else too. Or there will be enough on hand to ship but says we will go negeative…just not adding up.

4

Just a guess, but the nature of having a Non-netable bin seems like the movements in and out of that bin should be done by inventory transfers, not automatic transactions.

So you have a qty of a pert in a non-netable bin, and during packer creation, you specify the non-netable bin as the source for those parts. That correct?

  1. Does the Packer show the proper qty pulled, in the “Shipped from Inventory” field?

  2. What does the part transaction history show for parts that were shipped from an non-nettable bin? Does the running total change appropriately?

1 Like
5

The SO shows non on-hand but I thought since a Non Nettable it would not show it.

image
image.png900Ă—894 52.7 KB

Here is me creating the Pack and it shows 25 in the BIN I am selecting

image
image.png1291Ă—774 122 KB

But then it tells me I will go negative. I can only ship up to 17
Finally let me save on 17 ship qty

image
image.png1002Ă—760 66 KB

You can see here in Part Tran where the parts were moved successfully but the Running total starts to reduce and then 0 once it is all in the Non Nettable BIN. Parts are moving in there as expected but the BIN itself seems out of sync. We have ran a couple conversions too. II have some other parts that are in limbo in the Non Nettable BIN for other parts. They were shipped successful but the Inventory never moved. Is there something about a Non Nettable BIN that will make it perform clunky. Anything documented will help the business get away from it.

image
image.png1324Ă—706 83.1 KB

6

Those screen shots all in order?

Is the PartTran Histroy screen after the packer was marked shipped? Because I don’t see transactions for the 17 you pulled in the packer. (Remember, a packer doesn’t do the STK-CUS until it is marked shipped)

dumb question … Do you really need to use non-netable bins?

Also, I’m on E10, but we had to run a maintenance process once when our QOH’s got out of sync with Part Tran history. This must be such a common problem, because the added it as a menu item right in E10. :wink:

image

7

Yes they are in order. No it wasn’t marked shipped but even when i did 22 and allowed to go negative it still didn’t show in Part Tran.

We don’t have this in E9.

I don’t know if we need to but any changes are like pulling TEETH.

8

My guess is that you use non-nettable bins to “hide” qty’s that are already spoken for.

If you 100 in Bin A ( a netable bin), and 0 in Bin B (a non-netable bin), everyone knows you have 100 to do whatever with

If you transfer 25 from bin A to bin B, then people only think there are 75 available, and won’t over commit them. But this obvious;y requires that someone knows that 25 were moved to B for a specific demand. And doesn’t include that demand in determining if they need more.

BTW - I think that allowing bin qty’s to go negative is a setting in the company config or maintenance. We allow qtys to go negative, and then regularly do STK-STK transactions to get the bin qty’s to match the physical QOH in each bin.

9

Yes that is why we use Non Nettable. And no they don’t want to allow to go negative.

10

A test in E10 shows that the Running Total column of Part Tran History excludes qty’s in non-nettable bins.

Referring to the red numbers in the pict below…

  1. QOH was 200. It was all in bin SHOP ( a nettable bin)
  2. A qty of 50 was transferred from bin SHOP to bin NN (a non-nettable bin). Running Sum goes down by 50, even though the Qty is on hand
  3. A packer is created (and marked SHIPPED) with QTY of 100 coming from bin NN. the Running Sum remains unchanged. Referring to Pict 2, the QOH of Bin SHOP is 150, bin NN is -50, for a total of 100. This is correct (we had 200 , then shipped 100), eventhough Part Tran Hist shows 150.
  4. An Inventory Transfer is performed to move 50 from bin SHOP to bin NN. Afterwards, the Running Sum correctly shows 100. (The top two lines in the Tran History are from the same Inventory transfer operation)

image
image.png773Ă—337 22.1 KB

Pict 2
image

It also seems like most data entry screens that show QOH, exclude the non-nettable bins too.
I did a transfer of 11 from SHOP to NN, then went to transfer the 11 back, and the screen shows none in NN
image

Part Tracker seems to be one of the few places that always shows the QTY in a non-netable bin
image

11

I can see my QOH it is just doesn’t match what the system is doing. My Part On Hand Status shows 25 but it will not allow me to ship more than 17 from that BIN. I even ran a conversion that is suppose to fix Part Bin Non Nettable Qty’s…not luck.

12

Trying to figure out where this magic “17” is coming from.

What are the qty’s of each bin? (use Part Tracker)
Are any negative? (I know you said you’re setup to not allow negative qty’s, but maybe the system did it anyway).

Any packers contain lines for that P/N, but aren’t yet marked shipped?

What does running the Time Phase Inquiry for the part show? (thinking there is some allocation that isn’t letting you ship the parts on hand).

13

I didn’t think about an allocation. What is the easiest and quickest way to find that.

Thanks Kim

14

Time Phase Inquiry

15

Time phase is showing correct.

16

You can also check for allocation using the part tracker.