We have one area that has been reporting duplicate entries as an issue for mfg-stk or stk-mtl transactions. It doesn’t seem to happen every time but appears to be happing at least once a day for different operations. None of our other locations are reporting this issue. I’ve reviewed parttran and it does appear to be a true duplicate down to the date time stamp. It does not appear to be the same employee every time and has occurred on different jobs. A few part numbers keep coming up but nothing on the job or the method seem to indicate why it would cause a double transaction in parttran. Any suggestions on what to trace or review?
2 Likes
I would create a BAQ listing both part transaction records and every field in the table and see if their are any differences. You might see 2 demand types or 2 warehouses or something to make sense of it.
In reviewing PartTran both in a BAQ and SQL query to be able to see “all time”. Not seeing anything that specifically repeats to help with sorting it out.
We double checked BPMs and there’s nothing acting against these transaction types. Just a pop-up reminder about selecting the right bin location and not using the default.
We see no obvious patterns. Here is my query (note it does not show the duplicates of the records, only records that have a duplicate). This is for the last several days - the issue goes back further, but seems to be intermittent.
It affects several many trantypes (MFG-STK,STK-STK,STK-MTL,STK-SHIP) so it’s not a method directive (and we also checked).
There are 2 Data Dirs on PartTran, both seeming highly unlikely to be related:
- Email on specific condition
- First condition looks for 2 specific records a)STK-INS b)INS-DMR Neither of those conditions show up in the list of duplicates, also looking in the gerenal TranNum vicinity of any dupes I do not find either of those TranTypes.
@Chris_Conn These are backflush materials and the tranreference is the laborhedseq\labordtlseq that made the parttran.
Are they identical at the assemblyseq and mtlseq?
do you have any bpms or errors on labordtl?
The backflushed items shown are part of a phantom BOM with duplicates between the stages. It’s part of a coating package so the way that it was setup is based on the equipment it runs through by 10, 20, 30, etc. There can be the same base part number used in multiple steps.
@lindsayc Any update on this case? We experience the same issue for an employee that uses Kinetic. Other users that use the classic engine never have this problem. Had double bookings on MFG-STK and STK-STK.
Check the backflush material log and look for two sets of logs for the job asm and mtl seq you are seeing duplicates for.
there was an old updatable dashboard that was doing something extremely strange and it ended up backflushing things twice and we caught it by looking at the log.
We’ve tested several things to no luck. @Chris_Conn ran a bunch of stk-stk transactions through, no recreation of the issue. However, we continue to receive reports from production that it’s occurring.
We’re ignoring backflushed material. Backflushing should occur at the same time and if a part is duplicated on the method then this would be expected behavior. In our instance, we use the same base coatings on different coating phantoms that would be backflushed in a single operation reporting.
This is one example that happened today. The annoying fact that it’s booked to stock with the same cost value as the first transaction, while if you would do this by a normal transaction there would be no WIP costs left for the second transaction in this case.
For any interested, I tried my darndest to break it.
I wrote an external exe that rapid fires thousands of STK-STK transactions via REST. I ran this on my PC as myself, and also ran it on a PC we know has had a duplication as a user we know has had a duplication.
After probably 20-30k transactions, I have not been able to reproduce a duplicate. 
Did you try any other trantypes? Like MFG-STK? Thanks for putting in the effort to trying to reproduce it. It is also possible that REST isn’t the issue? My theory is that when a call is made via rest and fails on the UI, it calls it again making it kick off twice. I am not sure, I am at a loss myself.
We have seen it affect multiple tran-types, I just focused on once so I didnt have to write more code, but I may have to.
I agree with you, I dont think the issue is server side\REST (at least directly).
I suspect its one of the following, in no particular order:
- UI based issue (havent been able to catch it in the act because its very intermittenet)
- Network based - (I am no net engineer so forgive me if it makes no sense) - I wonder if some network issue, perhaps redundancy of some sort, could allow a duplication of the TCP message.
- PartTran BO itself - based on some strange data or race condition
Not sure if you have access to a screen recording software, but I’d put that on that computer and let it run. Then look at the video of the screen for date and time it happens.
Does this happen at least every other day?
Looking at the recent history, I am going to say yes. I’ll ask my IT folks whats available. Thanks for the input Utah.
Here is the SQL query I am using. Anyone feel free to use this if you find it useful (or tell me how to make it better). Note I have a few specific conditions you may not care about.
WITH DuplicateCheck AS (
SELECT
PartTran.Company,
SysDate,
SysTime,
PartTran.PartNum,
PartTran.WareHouseCode,
TranQty,
TranNum,
BackFlush,
CONVERT(time, DATEADD(SECOND, SysTime, '00:00:00')) as FormattedTime,
-- Add ROW_NUMBER to identify duplicates
ROW_NUMBER() OVER (
PARTITION BY
PartTran.Company,
SysDate,
SysTime,
PartTran.PartNum,
PartTran.WareHouseCode,
TranType,
TranQty,
OrderNum,
PackNum,
PackLine,
PartTran.JobNum
ORDER BY TranNum
) as RowNum
FROM [KineticLive].[Erp].[PartTran]
left join JobMtl jm on jm.Company = PartTran.Company and jm.JobNum = PartTran.JobNum and jm.PartNum = PartTran.PartNum
Where (TranType like '%STK%' or TranType like '%INSP%') --stk-mtl mfg-tk
and TranDate >= '2024-11-06' --and (BackFlush = 0 or BackFlush is null)
)
SELECT
*
FROM DuplicateCheck
left join PartTran pt on pt.Company = DuplicateCheck.Company and (pt.TranNum = DuplicateCheck.TranNum) -- or pt.TranNum = DuplicateCheck.TranNum-1)
WHERE RowNum > 1
ORDER BY
pt.Company,
pt.SysDate,
pt.SysTime,
pt.PartNum,
pt.WareHouseCode,
pt.TranQty;
1 Like
Last week we instructed our colleagues responsible for job receipt to inventory to not use the To Bin in this Kinetic screen and to keep it the default value. 1 double booking was made in that time where the colleague told me that he used the To Bin accidentally. More double bookings were found in the following Inventory Transfer. I get a feeling it’s related to the operations/methods responsible for the inventory transfer, as this is a build in function with Job Receipt to Inventory too, using a To Bin, but not sure how to find out. When I use the tracing/debug option from Edge I can’t replicate the error, while turning it off, i got it multiple times in our test-environment. Probably the tracing/debug option slows the process down enough to handle the method calls the right way.
p.s. once again, this only occurs using Kinetic (we use the Edge browser in this case). All methods are operating fine using the Classic interface.
1 Like
We typically recommend working in Chrome over Edge. We’ve run into a few things that are issues in Edge but work fine in Chrome.