Our organization has two defects preventing us fro...
# defects
b
Our organization has two defects preventing us from implementing Netsuite features and they are "taking the case offline". What does this mean and I don't remember agreeing to anything other than them to investigate further? It's related to older cases too and it has a low priority so I'm kinda worried it's just going to get insta-closed again, but they are documenting them as defects for the first time so that makes me hopeful
k
Taking them offline means they are reviewing in the back end. Typically I have found that means I've managed to wrangle someone who's not an end support user to get involved and help solve it.
Often that does result in the escalation going to closed status on some bullshit - but sometimes it means actually getting resolution
b
i hope so, they closed one ticket, but acknowledged its the same old defect, but they keep asking us over and over and over again why not having accurate quantities on our inventory item records is affecting our operations
k
Have you tried coming here for help with your inventory issue? I might be able to point you in the right direction. I've very rarely had issues with inventory accuracy with NetSuite - and typically that was due to people doing stupid shit like backdating inventory, running underwater, failing to enter receiving transactions, or making the mistake of doing bin putaways and then editing the item receipts to put it in a bin.
b
I have asked the #C2SGFFVLG channel a few times in the past year about this issue which has helped me create transaction saved searches to isolate the problem and create workarounds for our team to get accurate data. The specific issue is that "Quantity Committed" is incorrect on some of our inventory item records for one location. These items (and location) have transactions going back to 2006 so we're at this point thinking of just doing a complete reset instead of spending more time trying to convince Oracle Customer Support why having inaccurate information is disruptive to our operations
k
Any lot/serial numbers involved?
b
No lot/serials and no bins....but these items were components for assemblies back in 2012
k
Can you not create new items - adjust inventory out on the old, and in on the new and just be done with it?
At some point - you have to cut your losses and figure out a path forward. NS isn't likely to resolve your issue anytime soon
Plus, perhaps in fixing your open transactions, you'll identify the issues and clear them out
b
if defect is tied to the item and not the location then our inventory manager is fine with creating new items...if its a defective location where this could happen with future items in this location then that will be a huge problem down the road
k
It's highly unlikely the location is the issue - and honestly, I doubt the issue is even the item itself. It's more likely an issue with your transaction entries. Someone started a fulfillment and never finished it. Someone backdated something. Someone invoiced without being tied to a sales order. Someone deleted a transaction.
b
interesting... i'm all about cutting losses but I also want to make sure we have procedures/policies in place where our users aren't continuing to create more transactions that is causing new items' Quantity Committed to drift into a defective state. We create a lot of standalone invoices without being tied to a sales order, a practice we've been moving away from, so that's some good food for thought. thank you
m
Yea, we had this happen too. We created a new item because we couldn't wait on support when they said it was a U7 (potentially never to be fixed). In our case we think it was due to using a linked work order and then closing or deleting the WO or build. So it always saw the quantity if we ordered the same item for the same customer again, but otherwise it was not on hand or allocated/committed. Can't adjust what you can't see. Very strange.