In an afterSubmit function with SS2.0, I'm trying to determine if a sublist has been changed. Here is the code I am using to retrieve the sublist:

var newSublist = context.newRecord.getSublist('item');
log.debug('newSublist', newSublist);

When I add a new line to the Item sublist on a Sales Order and save, I expected to see the isChanged property on the newSublist variable set to true, but it still shows as false. Am I missing something here?

maybe

isChanged

only applies to client scripts?

The docs say it's supported in Client and server-side scripts, but I guess that may not mean that it works as expected in server-side scripts. I wonder if there is another efficient way to check if a sublist has changed that doesn't include looping through the lines of the sublist on the old and new record.

I'd be tempted to write that something like so:

const newSO = new SalesOrder(ctx.newRecord)
const oldSO = new SalesOrder(ctx.oldrecord)
const isChanged = _.isEqual(oldSO.item, newSO.item)

Ah the beauty of lodash. Thanks @stalbert

(full disclosure - such simplicity probably requires NFT or similar array-like representation for the sublists)

probably silly, but I'm not familiar with the NFT acronym

not silly at all - my bad for using the acronym. it's https://github.com/ExploreConsulting/netsuite-fasttrack-toolkit-ss2

That's something I've never heard of. I'll have to do my research as it seems pretty interesting. Thanks for pointing that out to me

I've noticed that inconsistency before as well and dealt with it on transactions by creating a scripted checkbox-type field to indicate if the

item

sublist changed and then checking that box in a client script's

sublistChanged

function using

CurrentRecord.getSublist('item').isChanged

(the client script is actually a hold-over 1.0 version using nlapiIsLineItemChanged() but I can't imagine the 2.0 equivalent won't work identically). It might be overkill depending on your needs, but then you've got a simple checkbox available with that flag in any other script deployed to the same record in case that's helpful at all.

@MTNathan that's a great solution. I'm in the early phases of working out this solution, so I'm not sure if it's worth attaching a separate script for it, but it may be necessary. Thanks for that!

No problem. The main caveat there is that it only works in a client context (at least as I described it), so if the server scripts relying on that info are triggered in other contexts, you may need something more robust, or you'll need to check the custom checkbox in whatever server scripts are modifying the sublist.