I recently got a call from a CFO of one of my customers explaining to me that custom transactions were grossly understated. Custom transactions were used to satisfy a unique way of accruing cash that NetSuite did not handle out of the box. We created a scheduled script to handle this concern which had been working correctly, but recently started creating transactions with a drastically understated cash balance.
After some debugging, I found a portion of the script was failing because of a search timeout. Searches will timeout when they have too many transactions or have complex joins and take too long to render. It’s a rare event but it can happen. When it does, NetSuite returns a message suggesting you schedule the search and email the results. Not an option in this case. I had to learn why the search just started timing out.
The search was used to aggregate data which made up a portion of the lines in the custom transaction. It was based on a custom record type which references invoices. Since I only wanted invoices that were paid by a particular bank deposit I filtered by the applying transaction. This gave me a list of invoices which I mapped to an array and fed to another search for the retrieve the data that created the lines. While complicated it tested fine and created the custom transactions I expected. We checked the cash balance and it matched the expected result.
The balance of the transaction was off because the lines that would have been written by the failing search were skipped because of the timeout. The script would run the search, timeout, which appears to be 3 minutes in the land of NetSuite’s evil ruler Governor Nance and run thru the error handler. After some testing, I learned the applying transaction filter was causing the search to timeout. I subsequently removed this filter and the search performed fine. No timeout!!! I took the list of invoices and fed it to the 2nd search and found it timed out as well. Why the 2nd timeout? It used a joined filter as well. After removing the joined filter this search performed fine too. It was clear that searches with complex joins were failing.
I opened a case with NetSuite hoping they could enlighten me. They could see there was a problem and filed Defect # 90 billion. It would be resolved in, hoo hum, 4-6 weeks and we would let you know blah blah blah. This is New York we need it in 4-6 hours sorry NetSuite. I can’t tell my customer that this will fail for another 2 months so we had to take a different approach. The ironic part of this problem was the searches only failed when filtering by joined field. When I added those same joined elements to the results tab, it worked fine. So, for some crazy reason you can’t filter by data elements from joined tables, but they can be included in the results tab.
The lesson to learn here is in a cloud environment the back end could change. What worked today could fail tomorrow. Fast forward 2 months, NetSuite calls me back to test if the defect is resolved. They didn’t care to inform me they fixed anything just to test it again. Sorry Guys, but someone needs to explain to them what a “New York” minute is. We handled this problem 6-8 weeks ago. I contacted my customer and the CFO can see a clear cash balance again. Custom transactions are no longer understated. Case closed. MIBAR 1 NetSuite 0.