WIP Not Tied Out Again

Epicor ERP 10
1

Looking to see if anyone else can make sense of this. In this particular the case there are very few transactions and the job was a very simple one. One operation, very few materials, and make to stock.

I show 56 reported on the only operation we have and that ties with completed qty as you would expect

image
image733×462 24.7 KB

image
image1091×270 24.1 KB

There is only one receipt and it’s for the full pallet of 56 as we would expect. I confirmed in Trans Tracker

image
image1246×268 21.1 KB

image
image764×532 24.1 KB

However there are still 42 in WIP at the assembly level. I can’t even wrap my head around 42 because it’s not even a number that matches any other transaction.

image
image1336×333 24.8 KB

I can’t reason out how this kind of stuff happens anyone else?

2

image

2 Likes
3

Was 56 the original Production Qty?

Any of the “rebuild process” programs address this?

image

4

56 was the original production qty the best that I can tell but perhaps it was 42 originally or maybe 98? I can check on that. I’m not sure that any of those processes would do anything for that, maybe the last one the orphaned picked/mtlqueue but I somehow doubt it. I’m not familiar with that one, but I have used the others.

5

I just double checked the change log 56 was the original qty.

6

Production detail report show anything odd?

7

Other than way too much waste on material no LOL. I should add that this issue is not unusual for us to see. It’s been happening less frequently than prior versions, but I think I’ve been relatively vocal about the issues with WIP when using the Advanced Material Module.

8

If AMM allows WIP to be tracked in a Bin, then maybe the “Refresh PartBin QOH” process would clean it up. There is a “Report Only” option you could run.

9

The qty in bin is still tracked in PartWIP and there are no transactions for WIP so by it’s name I assume there would be no impact, but i’ll run report anyways and see what we get.

10

Set your Cut off date to 1/1/8999 – see if its one of those where someone fat fingered a future TransDate.

Happens quite often for us when someone does Qty Adjustment – they accidently start typing in the TransDate field the part number and before you know it they posted inventory into the year 9999 and Epicor deducts it from current Inventory and throws off reports.

11

It would still show up in job tracker.

12

why not 12/31/8999 just to be sure? :wink:

13

No dice. Just some crappy backflushed materials in the report nothing else.

14

John Susil said the same thing, until it didn’t :innocent:

1 Like
15

Here all part tran for that job. There are no additional transactions I assure you.

image
image1112×448 26.8 KB

1 Like
16

I was more interested in seeing if the Part itself had anything funky going on or PartWIP

Ours at one point looked like:

2018-08-05_0010
2018-08-05_0010966×514 50.8 KB

17

No i’ve been down this road before but I can never reproduce the issue. Really hoping someone else had the key.

18

Unless its related to this bug, or a hidden bug. Is this something new in 10.2.600 your seeing or you had this in the past as well with 400 etc…

image
image1179×51 24.3 KB

The other one I saw somewhere, found even back in 10.1.600 and not sure if it ever was patched:

When a Part WIP record is moved to a backward Job OperSeq, this Part WIP is deleted from erp.PartWip DB. This is not happening when moving a Part WIP record to a forward Job OperSeq. Expected Behavior Move WIP should be able to move to a backward Job OperSeq.

19

I have seen that issue before. I’m not sure if it’s been patched, but in this case only a single operation.

20

They did fix this in 10.2.600.4 – assuming your on .3. But I doubt your job is SubContract :slight_smile:

WIP quantity is not calculated correctly on subcontract job if a Receipt Dtl line is removed

WIP quantity is not consumed corresponding to multiple assemblies for Nonconformance transactions