Main Line = T: stop transaction searches from exploding

Ever run a Transaction saved search and get way more rows than you expected? You’re probably looking at line-level data without asking for it. When I was first learning NetSuite this was an issue I ran into a few times before learning the importance of this criteria.

On Sales Orders, Invoices, Bills, and friends, NetSuite stores a header and a row per line item. Leave Main Line unset and you get both; so a 10-line order can show up as 11 rows (or more, once you add tax/shipping lines).

The fix: add this criteria to almost every header-focused Transaction search:

Filter: Main Line
Operator: is
Value: True (or T in a formula / SuiteScript filter)

In SuiteScript that looks like:

filters: [
  ['mainline', 'is', 'T'],
  // ...other filters
]

When to leave it off: you actually need item, quantity, amount, or other line fields. Then keep Main Line = F (or omit it) and be intentional about grouping/summarizing.

Rule of thumb: if you care about the document (status, date, entity, total), turn Main Line on. If you care about the lines, leave it off — and expect more rows.

Comments

Turning Saved Search Logic Into Insight: A Lesson in NetSuite Date Math

Sometimes it's the smallest slice of a project that demands the most ingenuity. What seemed like a simple enhancement to a Saved Search ended up stretching my understanding of NetSuite’s formula logic—and my patience. 🔍 The Objective I needed to compare two types of project actions occurring within a 30-day window. Here’s the twist: Project Actions are a custom child record of a NetSuite Project (Job) , and they’re not stored in a way that makes direct comparison easy. So, I had to retrieve them through a Project Search , pulling in individual Action records via joins—first hurdle cleared. 📅 Date Math, NetSuite Style Next came the math. I needed to calculate whether one action happened within 30 days of another, but NetSuite doesn’t make date arithmetic feel intuitive. My first instinct was to use TO_NUMBER() to convert the dates into values I could compute on. Spoiler: it didn’t work. So I tried a workaround—subtracting a fixed reference date ( TO_DATE('01/01/2000...

PDF Issue in NetSuite after 2025.1 update

Came across a weird issue after updating to NetSuite 2025.1. Our PDF Printing function was showing the underlying code for the PDF instead of rendering the PDF. Looked at many possible issues and discovered that it was in our header: old code had name : 'Content-Type:' , value : 'application/pdf' I removed the : and it worked as before name : 'Content-Type' , value : 'application/pdf' Found the solution on Reddit. Posted to a StackOverflow: pdf generation - How to Change NetSuite 2025.1 PDF Renderer Back to Previous Instead of BFO? - Stack Overflow

NetSuite - Force Single Select on Multi-Select Field

Issue: We had a request from our Stakeholders to change a Multi-Select Field to a Single Select. The Issue came up with this field being part of a bundle that we use. We didn't want to deal with this being reverted or causing issues after we updated the bundle in the future, so I cam up with this work around. It is a Client Script that will throw an error to the user if they select more than one, and then it will reduce the selection to one option. /** * @NApiVersion 2.x * @NScriptType ClientScript * * 2025 Prevents multiple selections in a multi-select field * by showing an error message and removing the last selected value. * */ define ([ 'N/ui/message' , 'N/runtime' ], function ( message , runtime ) { function fieldChanged ( context ) { var scriptObj = runtime . getCurrentScript (); var fieldName = scriptObj . getParameter ({ ...

Dustin Stubbs

Search This Blog