My Stuff
Comments
-
Did you remove the 2.5 web reference and add the 2.6 reference? If not you need to. -John
-
How would you search for it in the Web Browser / what field would you use there? -John
-
What happens if you don't set location - do the payments get routed properly? -John
-
The message indicates that you have included Created Date in your SOAP. Even if the value is the same as the original, you shouldn't include it. -John
-
What does the SOAP look like for the search? I don't see anything obviously wrong with your code. -John
-
The code looks good at first glance - what error are you getting? What does the SOAP look like? -John
-
File a case with the request and response SOAP. You should be able to find these in your Integration Usage reports. -John
-
Do you have team selling on? If so customer_salesRep would not be a valid field on the Customer form. Take a look in the browser. -John
-
It's really strange since the SOAP returned clearly has a CustomFieldList. I don't know why .NET isn't deserializing it for you. I would be interested to hear if other users are having the same problem. -John
-
25 is great. As a practical matter, you won't see a difference in performance between 25 and 100 or 200 for add/update/get. Note that 200 is the most you can do for get (I believe), it certainly isn't 25000 or even 1000. For searches, a pagesize of 100 is probably optimal. -John
-
I'm not sure what 10785 represents, is it an internalId or a string value? To do a search for the record you just get()'d, what you want is a TransactionSearchBasic where you set custbody3 on the CustomFieldList. -John
-
It sounds like things are moving along well. You are correct that "store values" will do what you want. -John
-
To reiterate what Derek said, the correct forum is the E-Commerce / Web Store forum, this is Web Services. Much more knowledgeable people are here https://usergroup.netsuite.com/users/forumdisplay.php?f=20 -John
-
The ususual suspects are entityId/parent and externalId for customers. Do a search in the UI to make sure that there is not a matching customer or entity. If that doesn't work, file a case with support, hopefully they can find the problem record. -John
-
If you set externalId, it could be another entity type (you can not have a partner and a vendor with the same externalid). Otherwise, I think support is your best option - file a case and give them the SOAP to reproduce in your account. -John
-
Make sure you are not setting the Account cookie either via the c=? or in the http headers. If you are using .NET, make sure you don't create your cookie container with =new CookieContainer(2); instead use =new CookieContainer(); -John
-
Even a simple script that makes a call to nlapilogexecution causes the session timeout fault. I believe sklett's probelm is unrelated to the cookie / c parameter. You do not need the c parameter and should no longer use it. You also do not need to set the ACCOUNT cookie before logging in -John
-
We currently support all WSDLs back to 1_0. We will give an end-of-life notice before we remove an endpoint. -John
-
One way would be to be to create a custom field "historical close date" that you set and run reports on. This works if you can treat the old data as purely historical and you don't have a report that queries both old and new opportunities together. -John
-
Do you have bodyFieldsOnly set to false? If not, by default lists are not returned on search. You can set bodyFieldsOnly in your SearchPreferences. -John
-
What if you do a get() on the individual record? -John
-
I have some questions for the user group on this subject. We're thinking of making it possible to include credentials with every WS request. If you have a valid session, we will attach to it, otherwise we will create a new session and use it. Would putting credentials in the HTTP headers or the SOAP headers be preferred…
-
Yes, a 5 user WS user gives similar access / adds similar load to 5 individual licenses. I'm not sure on the pricing, but it is more than a single user license. -John
-
Five concurrent sessions with the same credentials. Talk to your sales rep, but you need to have concurrent users provisioned for you first. -John
-
It looks like something is off in your code. The SOAP you posted does not contain internalIds for the tax codes. There should be internalId="1234" inside your taxCode tags. <listAcctPurchaseTaxCode xsi:type="platformCore:RecordRef"/> <listAcct:salesTaxCode xsi:type="platformCore:RecordRef"/>
-
With .NET you may need bodyfieldsonly.specified = true. Check your import reports, look at the SOAP, and make sure that the searchpreferences are actually being set. -John
-
You need to set bodyFieldsOnly in your searchPreferences to false (it defaults to true which is more performant). -John
-
With .NET you may need bodyfieldsonly.specified = true. Check your import reports, look at the SOAP, and make sure that the searchpreferences are actually being set. -John
-
It's contains. You can request an enhancement to make it a searchfield. -John
-
Instead of using SalesOrderOrderStatus._pendingFulfillment, use TransactionStatus._salesOrderPendingFulfillment. The error message was trying to indicate that with "...for Enumerated Type TransactionStatus". -John