I believe I have found a couple of bugs in 2022.2.13.
I have been going back and forth with support for 3 months trying to convince them that there is a problem. We upgraded from 10.2.600 to 2022.2 4 months ago.
The last response I got was, “I can’t replicate this in the latest version (2023.1.13)”, which is frustrating because part of why we upgraded was to stay on a fully supported version.
Today, I set up a test environment running 2023.1.13 and I can replicate the issue. I updated my ticket and now I’m waiting to hear back.
I’m worried that this will take another 3 months as the support person gets bounced back and forth between development and myself.
I remember being able to decompile client DLLs back in E9, which provided a lot of insight into what was happening behind the scenes. It helped me pinpoint specific lines of code where the bug existed and expedited getting the issue resolved.
In E10 and Kinetic, it seems like most of the code on the client side is just passing data to the server.
My question is, where can I look to find the correct DLLs to decompile to understand what the methods are doing to help me find the bugs for this issue? Is this possible in Kinetic?
I didn’t want to outline the bug in my OP to avoid making it too long.
I found two bugs.
One in the scheduling engine and one with how Job Receipt to Inventory updates Time Phase (PartDtl).
The bugs come up when we do a Job Receipt to Inventory to a warehouse other than the warehouse on the Job’s demand summary (JobProd).
The scheduling engine updates PartDtl’s job receipt quantity (open job quantity) by subtracting prior receipts to inventory from the job’s production quantity ONLY for receipts into the job’s demand warehouse. So, if the job prod quantity is 10 and the demand warehouse is A, and I receive 2 into warehouse B, and then reschedule the job, PartDtl receipt quantity is reset to 10.
Related to above, if I do a Job Receipt to Inventory into warehouse B, PartDtl is correctly updated to a receipt quantity of 8 (10 - 2). If I keep on receiving into warehouse B, I’m ok. If someone does a single receipt into warehouse A PartDtl is updated to prod quantity - ONLY those receipts to warehouse A. All prior and subsequent receipts into warehouse B are not reflected in PartDtl.
Both of these issues are causing MRP to overdrive manufacturing and purchasing.
We also rely heavily on PartDtl being accurate to help us manage excess materials.