Another 26.1 funfetti moment. record.findSublistL...
# suitescript
s
Another 26.1 funfetti moment. record.findSublistLineWithValue seems to require a string to be provided when searching for a select field in a sublist. In 25.2, finding a transaction line by item worked by providing a number. In 26.1 it returns -1 (not found) 😢
c
Yes, just ran into this one as well. 🤯
s
It appears to be server-side only. Client-side code doing the same thing works fine 🤷
c
So it's inconsistent, too. That's great.
šŸ˜† 1
d
@starlingMark! We found this too. As a defence, we've implemented a double-fallback feature. If our original findSublistLineWithValue fails to find, we fail back to a
string
version of findSublistLineWithValue, and if THAT fails, we perform our own loop lookup. You can never be too carfeul!
s
That’s beautiful and sad all at the same time šŸ˜‚
d
Yep
@starlingMark @Craig Haroldson, do you know if there's a Support Case for this I can reference?
s
We didn’t bother making a case. Was way faster to just update our code than to go through the ā€œis it plugged in, is it turned onā€ stuff šŸ™ƒ
now, if SDN partners had a different support channel…
c
We didn't bother either, for the same reasons Mark mentioned. An hours long call with level 1 support was not in the cards that day.
d
I know right?!?!! Not worth the pain. However, that's not an option for us. Gotta grind through it
s
{maybe there’s a Claude skill for that šŸ¤” }
s
yah, that example will defo not work šŸ™ƒ
d
Wait sorry ... what I meant it look at the
Last Updated
value
s
3 days ago - strange
d
Copy code
Upon initial investigation, the behavior of how values are accepted in the findSublistLineWithValue(options) function changed with the 2026.1 update. This change was undocumented prior to this release.

SuiteAnswer 45391 - options.value: number | Date | string | array | boolean

The specification defines the types accepted by the method but does not guarantee implicit conversion to the target field type.

Behavior by Release:
- 2025.2: Implicit number → string conversion (undocumented behavior)
- 2026.1: Strict type matching per field type (NUMBER field requires a number value)

The 2026.1 behavior aligns with the field definition (refnumber: NUMBER) and with the technical expectation of type-safe matching. The automatic conversion observed in 2025.2 was an undocumented implementation detail.

To fix the issue, you may need to ensure that the value type you pass to the function matches the field type. For example:
var lineNumber = objRecord.findSublistLineWithValue({
 sublistId: 'item',
 fieldId: 'item',
 value: Number(itemInternalId)
});
s
well how about that
but also, the example they show on the SA article defo will not work šŸ˜‚
d
And to be crystal clear here .. we all observed this only on 'select' type sublist fields?
šŸ‘ 1
I also say that I need to use the boolean
true
(rather than 'T') when checking booleans
I'm all for being more strongly typed ... but how about a heads up NetSuite? Also, 'select' behaving like a string is weird as well. Unless that field is a multi-select? (Which I'd prefer to see an array of numbers)
s
I haven’t tried looking for checkboxes yet - that scares me
in my experience it also matters if the checkbox is shown or hidden - true/false are acceptable values when displayed but T/F are values if they are hidden
d
Well, our approach will be to build our own and have 100% control and visibility
s
your own function or your own sublist?
d
own function
šŸ‘ 1
w
I just encountered this issue as well. We were using the function to find the lineIndex using the
lineId
Apparently the field
line
is a string according to
getSublistLineWithValue
but it is a number according to
getSublistValue
😔 netsuite
@darrenhillconsulting did you get that response from support? Could I reference your case?
d
@Watz, please do.
w
@darrenhillconsulting feel free to dm the case#. I've already created my case.
d
@Watz Case #6837532
šŸ‘ 1
w
I've done some testing with date-fields, and I've not been able to find a sublist-line at all in server-side scripts anymore I also discovered some quirk where the function won't work (in Client or in 2025.2) if you run
getSublistValue()
on the
record.Record
before running
findSublistLineWithValue()
Copy code
require(['N/record','N/format'], function(record, format){

const searchOptions = { sublistId: 'expense', fieldId: 'custcol_eqt_test_date_field' }
const stringValue = '2026-03-24'
const id = 16239148
const type = 'vendorbill'

function logger(optionA, optionB) {
    if(typeof window !== "undefined") {
        console.log(optionA, optionB)
    } else {
        log.debug(optionA, optionB)
    }
}
    
const rec = record.load({ type, id })

const getValue = rec.getSublistValue({ ...searchOptions, line: 0 })

const findWithString = rec.findSublistLineWithValue({ ...searchOptions, value: stringValue })
const findWithDate = rec.findSublistLineWithValue({ ...searchOptions, value: new Date(stringValue) })

logger('results - running getValue before findSublistLineWithValue', { getValue , findWithString , findWithDate })


const rec2 = record.load({ type, id })

const findWithString2 = rec2.findSublistLineWithValue({ ...searchOptions, value: stringValue })
const findWithDate2 = rec2.findSublistLineWithValue({ ...searchOptions, value: new Date(stringValue) })

const getValue2 = rec2.getSublistValue({ ...searchOptions, line: 0 })

logger('results - running getValue after findSublistLineWithValue', { getValue2  , findWithString2 , findWithDate2 })


const bp = 2 //breakpoint
})
For me, it seems as select-fields are searchable with both a number and a string values. But for
line
it doesn't. I'm guessing that
line
is some construct from transactionline.id where it is cast as a string. And I guess that if the field is a string, you have to supply a string.
lineuniquekey
works with both string and number. confused dog