[jeremygibbens Contributions: 0Level 1☆]

Perhaps there was an API change I missed between 2013.1 and 2016.1, but we recently upgraded our SuiteTalk code from the former to the latter and have found that custom fields included in add and update requests aren’t being set.

Here’s an example SOAP request from our 2016.1 code that does NOT correctly set the custom field (reviewing the system notes for this Cash Sale record, the custom field in question has no update entries, either). Note that no errors are returned from this operation. It’s reported as successful.

******************************* *****

***@***

***************

******

true

1234

Here is the same request but made from the 2013.1 version of our code. Same record, same custom field, same value. Only difference is that there isn’t the applicationID reference in the 2013.1 request (since that wasn’t added until a later version). This time it does update the field correctly. I’m assuming I’m missing something here, but is this a bug?

***@***

***************

******

true

1234

This is a cached copy. Click here to see the original post.

[jeremygibbens Contributions: 0Level 1☆]

Ok, so apparently somewhere between those versions of SuiteTalk, the API was changed such that the internalId of the custom field now requires the actual numeric record ID from netsuite instead of the string. I’ll just update our code so it uses the scriptId attribute instead of the internalId attribute. Though I find it more than a little aggravating that the above example silently fails instead of throwing an error related to the invalid reference.

[gculler@rugsdirect.com Contributions: 0Level 1☆]

I was having the same problem with Item Fulfillment. Your post saved me a whole lot of headaches. Great catch!

[Author]

Posts