Invalid NS API function name in debug logs - Serious bug or just logging bug?

Integrator.io
1

r.setCurrensetCurrentSublistTexttLineItemValue({"sublistId":"item","fieldId":"serialnumbers","text":"TESTIB07-2"}); specifically, setCurrentsetCurrent

It's been a while since I've needed to review Celigo debug logs, so maybe this is a legitimate method name, but sure looks like a bug! I know the SuiteScript API has no such method, it's clearly setCurrentSublistText dropped into setCurrentLineItemValue

It would also possibly explain why my 2 line fulfillment is only logging details for 1 line (other than the initial fulfilled flag clearing.

OK, here's the the full logs:

04/29/2026 9:51:04 PM	nlapi calls registered for $R	r = NRecord.transform({"fromType":"salesorder","fromId":9030418,"toType":"itemfulfillment","defaultValues":{"recordmode":"dynamic"}});
r.selectLine({"sublistId":"item","line":0});
r.setCurrentSublistValue({"sublistId":"item","fieldId":"itemreceive","value":false});
r.selectLine({"sublistId":"item","line":1});
r.setCurrentSublistValue({"sublistId":"item","fieldId":"itemreceive","value":false});
r.selectLine({"sublistId":"item","line":0});
r.setCurrentSublistValue({"sublistId":"item","fieldId":"line","value":"1"});
r.setCurrentSublistValue({"sublistId":"item","fieldId":"quantity","value":50});
r.setCurrentSublistValue({"sublistId":"item","fieldId":"itemreceive","value":true});
r.setCurrensetCurrentSublistTexttLineItemValue({"sublistId":"item","fieldId":"serialnumbers","text":"TESTIB07-2"});

And the IIO error from the flow run:

Failed to create, update/transform record because null Possible reasons include > Something went wrong on NetSuite side. > You might have specified an invalid field value for a field. > You may have submitted an invalid record. Please consult NetSuite Support with NLAPI calls obtained from NetSuite Connection Debugger.

My question for Celigo: Is this just a logging bug that shows that nonexistent method name, or is there a more serious bug that is possibly also responsible for my Fulfillment failing to save?

In case anyone in Celigo wants to take a look, Flow ID: 69d755deb8bbb3c7a02047b1

Funny! Even this forum software disagrees with that method name!

image
image1000×350 46.5 KB

2

I recreated the Import step to try and determine if I had done something to corrupt the original one. I ran the flow and receive the exact same result (failure to Import fulfillment and logs with FrankenFunction).

I then thought I'd try removing the Use Dynamic Mode (I only added it to try to workaround the error I'm dealing with) and the logs lack any odd method names, but they also only contain entries for the single line.

04/29/2026 10:27:23 PM	nlapi calls registered for $R	r = NRecord.transform({"fromType":"salesorder","fromId":9030418,"toType":"itemfulfillment","defaultValues":{}});
r.setSublistValue({"sublistId":"item","fieldId":"itemreceive","line":0,"value":false});
r.setSublistValue({"sublistId":"item","fieldId":"itemreceive","line":1,"value":false});
r.setSublistValue({"sublistId":"item","fieldId":"line","line":0,"value":"1"});
r.setSublistValue({"sublistId":"item","fieldId":"quantity","line":0,"value":50});
r.setSublistValue({"sublistId":"item","fieldId":"itemreceive","line":0,"value":true});
r.setSublistText({"sublistId":"item","fieldId":"serialnumbers","line":0,"text":"TESTIB07-2"});

So not really sure what's going on here. Have I made a mistake? Probably, but I'm not spotting it.

Celigo KNOWS there are two lines to create, you can see that in the logs on line 2 and 3:

r.setSublistValue({"sublistId":"item","fieldId":"itemreceive","line":0,"value":false});
r.setSublistValue({"sublistId":"item","fieldId":"itemreceive","line":1,"value":false});

Seems odd that it's setting the line field to a value, that is already sourced in from the linked Sales Order and the mapping is only there to resolve the correct IF line to update. Not saying this is wrong, just seems odd, but like I said earlier I've not looked closely and the IIO debug logs in quite some time so maybe it's always been this way, probably has.

Hopefully someone will pop up with an idea on what's going on, because I'm stumped!

3

Hi Steve,

Thanks for the detailed logs, they were really helpful in narrowing this down. Here's what we found:

1. The "FrankenFunction" is a NetSuite log display artifact, not a real call

The actual call our adaptor sent to NetSuite on that line is the valid SuiteScript 2.0 method: r.setCurrentSublistText({"sublistId":"item","fieldId":"serialnumbers","text":"TESTIB07-2"}). What you're seeing rendered as setCurrensetCurrentSublistTexttLineItemValue is two adjacent DEBUG log entries that NetSuite's execution-log viewer has collapsed into one. This is known behavior when many entries are written in quick succession, especially during a failure flush. Nothing in our adaptor invented or sent that method name, and it is not the cause of your save failure.

2. Why dynamic mode only logged one line

This is a symptom of the failure, not a separate bug. In dynamic mode, the expected sequence after setting line-0 fields is commitLine -> selectLine(1) -> set line-1 fields -> commitLine -> save. None of those appear in your log because the save attempt threw an exception inside (or immediately after) the setCurrentSublistText call on line 0. The adaptor then flushed the captured calls from its error handler before line 1 was ever touched. Toggling Use Dynamic Mode is a red herring here. It changes the call style but not the underlying reason NetSuite is rejecting the record.

3. The most likely root cause - serial number handling

The serialnumbers text setter is most likely what's triggering the generic "Failed to create, update/transform record because null" error. There are two scenarios:

  • If Advanced Bin / Lot-Numbered Inventory Management is OFF for that item: change the mapped value from "TESTIB07-2" to "TESTIB07-2(50)" (i.e., include the quantity in the format serial(qty)).
  • If Advanced Bin / Lot-Numbered Inventory Management is ON (the more common setup): drop the serialnumbers mapping entirely and instead map the inventorydetail subrecord on the item line, setting inventoryassignment.receiptinventorynumber = "TESTIB07-2" and quantity = 50. This is the supported path under Advanced Bin and mirrors what the NetSuite UI does behind the scenes.

Quick check for us: Are you still seeing this issue? And is it happening only for a specific record type, or across all record types?

  • If it's specific to one record type, it's possible that record has some account-level corruption in your NetSuite instance, and you may need to raise a support ticket directly with NetSuite to investigate.
  • If it's happening across all record types, we'd want to take a closer look on our end. Please open a customer support ticket so we can dig in further.

Let us know and we'll go from there!

4

Hi @sandeepchittaluri39 ,

Congratulations on a fantastic reply, very well done and greatly appreciated!

Understood on the logging issue, at least understood in that it's not a serious issue. The log corruption related to the flush is interesting. Would this be multiple streams trying to serialize to the same buffer or something similar? Just curious how it could happen and also wondering if it's something you think you'll be able to address in the future. The "FrankenFunction" was mildly concerning and burned up some time, but relatively benign. I could imagine a situation where the logs could be botched in a significantly more negative way and would be great to know a fix was on your radar.

I concur on the dynamic mode and lack of line 2 activity. If I was less annoyed by being stuck with this larger issue I would have thought a little more about what I was (or wasn't) seeing in the logs, but yes, it makes complete sense. I will say that the logs are misleading in this respect. By excluding the exception from the logs or any indication of incomplete task execution it potentially leads the user (me) down the wrong path. If we're in dynamic mode we really need to see client-side errors in the logs with context. Please.

And lastly, the serial number format. This project was a bit different in that the requirements explicitly called out "Only one lot number per order line will be supported", so where I'd normally code in support for multiple lots, in this case I did not. As I'm sure you know, in the NetSuite UI you can enter just the lot number as a valid input, in fact if you enter lot(full-line-qty) NS will reformat as just lot. Anyway, I could have sworn IIO supported the simple lot syntax and I was really surprised when it didn't.

But wait, something has happened! Before starting this reply I was writing up a SOX change request document explaining the script updates I need to deploy to force the lot<qty>) syntax. I went to production to grab screen shots of the error being addressed, but there were no errors! The flow ran perfectly fine on 7 records, no errors using plain ol' lot syntax. What the hell?

The only thing I can think of is that Celigo maybe did an update? I've not changed a thing. I also haven't take the time to test this theory, it's late and I came here to reply to you after noticing this strange, unexpected success :wink:

Did you guys do an update to auto-magically handle plain lot syntax? I hope you did, otherwise this leaves me in a weird spot.

- Not written or assisted by AI -