TroyT-EXH Red Ribbon

As a workaround, I have duplicated our Commissionable Item searches as standard saved searches, and in SuiteScript run those searches to determine the line level commissions, and link final commission calculations as custom records to the Estimate, displaying the employee and their commission total in a saved search.

Brief follow-up: I edited the bundles in our Sandbox after a refresh, removing the duplicated bits and deployed an "update". After several weeks of clean operation, I dissolved the bundles and re-installed APM; everything's happy now.

Just stopping by to indicate I had the same issue: the cause was a Purchase Order created for "testing" how POs could be linked to project tasks. I found a Purchase Order line linked to the Project Task, and the Project Task could not be deleted; as above, there were no dependent records displayed. Maybe this should be…

Our custom form is marked as "Preferred". I'm hoping this mitigates the vast majority of problems! Perhaps I should hide the custom form field everywhere else to prevent shenanigans. The field is Class (native NetSuite); it's not a custom field in this situation. Based on some debug logging it seems that custom fields…

To expand on "uninstall" vs "dissolve": help says that dissolving leaves the customization behind, so long as the bundle being dissolved was installed from your own sandbox. The result is that the components remain, unlinked from any bundle. This means they can't be "uninstalled" anymore and would have to be manually…

We're in a similar situation, and our case was attached to Defect 756500. We have a refresh started on 26 Feb 7:48am, and it's still at "Refresh in Progress" after 48+ hours. Our instance went live less than a year ago and weighs in at a measly 661MB. Technician indicated that sandbox refresh slowness has been an ongoing…

Final result: I reworked the custom record to an integer data type for the Line ID, so the conversion of numeric to string is no longer an issue. Chalk this up to the need for "belt AND suspenders" when it comes to type casting in Suitescript!

The saved search "unexpected error" turned out to be a false alarm, due to a Chrome browser plugin used to fill in field names for saved searches. The random floating point values are still an issue, but given it's truly not repeatable I'm not confident of a quick resolution with NetSuite. Further: Due to the…

Now the real pain point: if I reprocess the queued records the value is written as an integer as expected. It's literally not repeatable on-demand, which makes troubleshooting impractical. I'm going to have to resort to changing the data type from Free Text to Integer to block the possibility completely. And finally: if I…

Another update: unary plus isn't the problem. Further troubleshooting by log.debug() shows in the log that the value "1" is about to be written to the custom record; .setValue() sets the value; record.save() saves the record; and the resulting field contains "1.0". fieldstoCommit below is an array of field names in scope.…

Well, here we are in October 2023, and we were just upgraded to 2023.2. I'm cautiously optimistic that a fix to KPI has also fixed the speed of the standard reports. 18 months to fix.

Good news! KPIs are loading again! Our 2023.2 upgrade is complete, and KPI are no longer throwing errors and timing out.

Support advised this patch is released to 2023.2. We are upgrading later this month, so hopefully will see the fix then.

This just in from support: NetSuite Support Notification - U1 Defect 718518 - Performance optimalisation released Hello Troy, This is to provide an update for U3 Defect U3 718518 Dashboard > Standard Key Performance Indicator (KPI) Portlet Stuck on Loading. - Our Product Engineers have released performance optimalisation…

This just in to my email box! Looks promising. I wonder if it'll hit before our upgrade? Oracle | NetSuite has investigated the defect and a fix has been identified to resolve the issue. After testing the fix, we will prepare and schedule its release to your account. Issue Number: 718518 Abstract: Dashboard > Standard Key…

Notable: I received an email from support on our already-open ticket and received the following reply, which feels not quite the same, but pretty close to the existing issue: We have filed the following defect on your behalf: Defect 738297 : Performance > Admin Role > Key Performance Indicators (KPI) portlet > JSON.parse:…

@Karin Petkovsek if you don't mind sharing; how many years of NetSuite data do you have in your account? We've been in NetSuite since 2007; we are at ~1 million transactions per month and more than 800GB storage (not file cabinet, but Total Storage). I rather wonder if there is some critical point of legacy data size that…

That feeling when you find your own post from a year ago when you're looking for a solution to a problem that's been going on... for a year or more. No changes, except now we are seeing KPI timing out too.

Following. Just flushed my browser cache and am no longer getting the popup--but not sure if that's a side effect, or if a fix is rolling out.

Just encountered this situation again: except not against a Purchase Order receipt, but a Transfer Order. This tends to point toward something on the Item Receipt record(s) as being problematic, not the originating document.

In brief testing, the Accept Payment button loads much faster on customers with a smaller set of open invoices. This would tend to point to the load time of sublists as the primary issue. The save of the finished payment isn't too bad with 8 second average save time. It's the "new" action which spikes over 20+ seconds on…

Update: We have a case linked to a "known" Defect report #667177, "667177 Performance issue >Generating Standard Financial Reports is Extremely Slow". NetSuite indicates this is listed as "Open - Under Investigation". Glad to know it's not just us--but that doesn't provide much relief yet.

Quick update: after refreshing our sandbox (our last refresh was Feb 2022) we can definitively state that our sandbox is now just as slow as production when running out-of-box default financial reports. This is NOT progress in the right direction. However, perhaps it points out that something happened in our data (ie,…

No definite solution has been indicated yet. Performance has not improved very much, if any. Side thought: One of our NetSuite partners indicates "cautious optimism" in a theory (or hope...) that once all NetSuite systems are on OCI, it might improve performance across the board because Oracle/NetSuite won't be supporting…

Based on the "Scripted Record" page for item receipts, we have the following potentially-related scripts: User Event afterSubmit: Drag and Drop feature (NetSuite bundle). User Event beforeSubmit: Supply Chain Management Bundle 47193, Landed Costs feature (NetSuite bundle). This specific feature is disabled in our account…

The Purchase Order does NOT end up fully received, because the item receipt that is created correctly saved the partial quantity of the selected line. The selected line quantity and location are correctly saved. The other lines which were not selected in the item receipt end up selected and their quantities fully received.…

And we have a defect open! Defect 667177 Performance issue >Generating Standard Financial Reports is Extremely Slow More Options Alternate Solution: None The urgency level assigned to your defect is U4. If a product change is required, the NetSuite Product teams will target resolution in an upcoming E-Fix release. Based on…

Side note: we have tested on multiple PCs and multiple browsers (Chrome, Chrome Incognito, Firefox, MS Edge) with the same dramatic performance slowdown on Production vs Sandbox.

In my Zoom call with Support, I demonstrated that a single month Balance Sheet view in our Sandbox vs Production shows the same results, same number of lines, and same amounts to the penny. Sandbox runs the report for a month of data in less than 2 seconds. Production takes nearly 2 minutes; if we click the "Notify When…

Just realized the most notable change in our account was the move to "Oracle Cloud Infrastructure" on 14 Mar 2022. That seems to coincide with the performance drop.