user10648298 Newbie

Is it hidden/disabled/not on your entry form? Log in with the WS User Id and create a new Job. If the contract_date_due field is not on the form or not settable, it won't be via WebServices as well. -John

Reuven, sprefs.bodyFieldsOnly = true; //needed to get price info should be sprefs.bodyFieldsOnly = false; //needed to get price info bodyFieldsOnly means that you don't get any information that is on a list, this significantly speeds up search times and is the default. -John

You can look in the integration reports, Reports->Integration->Integration and Automation Usage Summary by Job. Once you have found the correct job, drill into the Response Doc. -John

Take a look at the SOAP and see if you find that value. As Terry said, Invalid Reference Key errors are the result of key validation problems. -John

For free-form text the limit will be 4000. For Text Area, the limit is essentially infinite. If you want to reduce the field size below these numbers, you can set the maximum field size. -John

One thing to know is that the territory assignment keys off of the Billing Address of the Customer. So if you don't an address to be the default Billing, the territory rules won't kick in. Here's a CSV thread that explains it https://usergroup.netsuite.com/users/showthread.php?t=9708 -John

The problem seems to be in the namespaces for your customer add - the SOAP should look like [CODE] <nu6191:add xmlns:nu6191="urn:messages_2_5.platform.webservices.netsuite.com" > <record xsi:type="listRel:Customer" xmlns:listRel="urn:relationships_2_5.platform.webservices.netsuite.com"> <listRel:entityId >Shutter…

For example, you cannot create a new Vendor Bill based on a Purchase Order. True, but Vendor Bill is on the roadmap for the first release of 2008, so PO->Vendor Bill will be out soon. -John

Your session isn't disconnected due to inactivity. What you are seeing is the underlying tcp connection being closed due to inactivity on the http connection (ie your results are taking too long to get back to you). This happens so that zombie connections aren't left open on our servers, it's a different mechanism than the…

You can not specify internalId on an add(). I think you want update(). The recommended way to update is to create a new record, set the internalId and only the fields you want to change (eg custrecord_phys_order__status). Do not resend a whole record that you retrieved as you will often get permission violations. -John

You need to set bodyFieldsOnly to false, the search is slower, but it will return the lists (such as itemList). _service.searchPreferences.bodyFieldsOnly = true; SearchResult response = _service.search(transactionSearch); -John

The country list is here https://webservices.netsuite.com/xsd/platform/v2_5_0/commonTypes.xsd You would have to do reflection on the Country object to get the complete list. -John

We are restoring the old behavior via issue 134298. The best way to handle this in the meantime is to send a Time Zone, it complete disambiguates the problem. -John

Where is that error coming from? Is it a .NET/Java reported error or is it an UNEXPECTED_ERROR or USER_ERROR? how long does it take? There are probably ways around this error. One thing to do is set an externalid on all of your customers. Then you can do a getList() by externalId before adding, and if a record doesn't come…

"instanceof" is useful here. ... if (cfr[j] instanceof StringCustomFieldRef){ bankgironummer = (StringCustomFieldRef) cfr[j]; ... -John

You actually provided a good example, the -07:00 is the time zone. There is no possible ambiguity on 2007-10-11T00:00:00.000-07:00, it's an exact moment in time. Without the timezone (what Jan posted) there are 24 different instants in time you could be referring to. -John

When you set timeout on your NetSuiteService object, you are actually telling you client code to timeout if a response has not been received. This is not communicated/propagated to the server. If you performed a search that took longer than 20 seconds, you would get a Fault from your client code. -John

We would like to have the attribute internalId on our base class (customFieldRef). However, .NET does not handle the inheritance of attributes and would not be able to generate client side libraries if we wrote the wsdl/xsds that way. Unfortunately, the PHP libraries do not robustly support inheritance either. I don't know…

1540 seconds is over 25 minutes, the underlying connection will be closed by then. I wouldn't code anything that routinely takes over 5 minutes (though this is not a hard and fast rule). I would advise using a smaller page size - if you are not doing a body fields only search, it's really no faster to have a page size of…

If you go to Reports->Integration and drill down with the integration reports you can see SOAP you submitted. If it is not there, it's because we either did not understand it as valid SOAP, or we could not associate it with you (due to session problem or a poorly formed http request). I strongly suggest than every…

1) Date/Times without timezones were considered PST/PDT 2) Yes. Always send timezone. Most SOAP libraries will do this. -John

There doesn't seem to be a timezone on those dates - how was this SOAP generated? -John

I've gotten the MS soapExtension to work on my machine. I can't re-publish it because it is Microsoft's code. See this link http://msdn2.microsoft.com/en-us/library/system.web.services.protocols.soapextension.aspx -John

Yes - you are performing a search without a searchtype. This is probably because we have an abstract SearchRecord and ContactSearch, etc descends from it. Every toolkit besides .NET and Java have trouble with abstract types. Your soap should read &lt;nu4233:search…

Try doing an ItemSearch for the item and see what type you get back. Print out your get SOAP and make sure they match exactly. -John

No problem. We use the HTTP header "SOAPAction" to route requests properly. This HTTP level header must match the Web Services operation. Thus you are doing a get(), but saying in the HTTP headers that you are doing an add(). This is because there is a bug in the nsLib.php code for the get() function [CODE] function get…

You are the reverse of me - I'm experienced with SOAP, flying a little blind with PHP. It's complaining that Item is not a valid recordType, which it is not. You want 'invetoryItem' or 'nonInventoryItemForResale'. For the list of valid RecordTypes, see https://webservices.netsuite.com/xsd/platform/v2_6_0/coreTypes.xsd -John

We'll take a closer look. Please make sure that date/time SOAP includes a TimeZone, without a timezone there are 24 correct times it could be. For example, UTC could be inferred, of in a multi-subsidiary account the root or current subsidiaries' timezone. -John

We're looking at releasing at about the same time as 2008_2 (our second half 2008 release) in part because it meshes well with the upcoming "request level credentials" feature. Take this as a goal, not promise, and as we get closer there will be more concrete information. -John

I think this is what you want [CODE]$sb = new nsSearchBasic('ItemSearchBasic',$sf);[/CODE] The type of Search is an ItemSearch(basic), the Search Field Type you are using is an SearchTextNumberField. -John