CaroLab04/11/2022, 9:57 AM
Alex Pilgun04/11/2022, 4:13 PM
NS Expert04/11/2022, 10:34 PM
$service->setPreferences(false, true, true, true);
santhosh kumar04/12/2022, 10:23 AM
fsandi04/15/2022, 2:36 PM
fsandi04/15/2022, 2:37 PM
fsandi04/15/2022, 2:39 PM
Austin Cai04/16/2022, 1:36 AM
error while trying to submit the very first request. When I check the Login Audit Trail Search within NetSuite, I don’t see any trace of my login attempt. Any pointers on how to debug this issue?
401 Invalid login attempt.
screnshaw04/18/2022, 3:52 PM
Alex Pilgun04/18/2022, 10:44 PM
When getting the date field through SOAP web services, your preferred time zone influences the resulting datetime. Midnight in the user's time zone of the stored date (which is also displayed in the UI) is converted to Pacific Standard Time (PST) or Pacific Daylight Time (PDT), and sent to the SOAP web services user.Ok, that was easy (before daylight savings started): • API user's timezone is GMT. • Netsuite UI date = 2022-04-18 • Netsuite SOAP date value = 2022-04-17T160000.000-08:00 Totally makes sense, since this is converted to 2022-04-18T000000.000Z and I get the expected date part of 2022-04-18. Quote #2 from the same article:
The NetSuite time zone settings in Home > Set Preferences are based on standard time settings. You must keep in mind the required adjustments during daylight saving time in the year. For example, if your time zone setting in shows (GMT-06:00) Central Time (US & Canada), this is perceived as -05:00 in SOAP web services context during daylight saving time, but -06:00 in standard time.
Therefore, if you send a SOAP web services request indicating CST (-6) when daylight saving time is in effect, as in the following example: <tranDate xsi:type="xsd:dateTime">2015-04-13T222626.923-06:00</tranDate>, the datetime field on the target record is set using CDT (-5) i.e.232626.923 instead of the intended 222626.923.
Important: If the time is close to midnight, the date may change to the next day after the conversion.With the same API user with GMT timezone and same Netsuite UI date = 2022-04-18 I now receive in SOAP 2022-04-17T160000.000*-07:00* instead of -08:00. By taking the date part this actually converts to 2022-04-1*7* instead of expected 2022-04-1*8* in GMT. Just..why does this happen? And how Netsuite suggests to work with this? Does the bold sentences in quote #2 imply that my client code needs to remember when daylight savings are in effect in my timezone and to account for that 1 hour difference somehow? Am I missing something?
santhosh kumar04/21/2022, 12:03 PM
Pavol04/26/2022, 1:25 PM
in comparison to
? Is it faster? Even compared to SOAP list (bulk) operations?
Tom Robertson04/28/2022, 7:26 PM
. I’ve attached what my request looks like in Postman. Can anyone identify what I’m doing wrong?
Brian Brown05/06/2022, 4:34 PM
Charlie05/12/2022, 6:00 PM
Will05/13/2022, 5:32 PM
Nicholas Penree05/19/2022, 4:57 PM
Sim Greenbaum05/23/2022, 4:01 PM
Andrii05/25/2022, 8:51 AM
Shawn Talbert05/25/2022, 10:07 PM
like other transactions. Is this a known bug?
Bruce Backman05/26/2022, 7:17 PM
Kristopher Wood05/31/2022, 7:07 PM
Kristopher Wood05/31/2022, 7:35 PM
Steve Cahill06/01/2022, 2:53 PM
<core:customField scriptId="cseg_my_custom_segment" xsi:type="core:SelectCustomFieldRef">
But how do I unset that value? I tried I few variations similar to
but can’t find anything that will set that field to
rudler06/02/2022, 12:40 PM
Caleb Evans06/02/2022, 4:06 PM
). However, attempting to call
(endpoint for a list of customers) returns me a 400 error, even though I believe I have all the correct permissions and parameters. I've tried with and without the
parameter. Could someone please advise what I am missing here? (see my attached screenshots)
Kristopher Wood06/02/2022, 10:20 PM
Kristopher Wood06/02/2022, 10:40 PM
Slackbot06/03/2022, 10:50 PM
NickSuite06/06/2022, 3:33 PM