Check This Out. Part 3

Originally Posted 2016-03-05

Where were we….

Alright, we added a Customer! So long as that went well, we’ll get a response from the call to add or update. The response carries a SOAP response full of information. So long as it went well, you can get the internalId of the object you created or updated.

That’s useful, because the next step would be to add a Sales Order, and that needs a customer.

Adding a sales order works similarly: you’re going to use the AddRequest object again, and the responses come back similarly. But, honestly, this was the hardest part to figure out for me, and it all has to do with permissions.

So, web services in netsuite work in an interesting way with regards to permissions. Instead of your web services log in being allowed to edit whatever they have access to, the web services act almost exactly as if you were editing a form manually through the UI. This has several implications when you consider default custom form settings.

It turns out that if you set a field to be invisible in a form for your users, is you’re not careful, this will also mean that your web service checkout application will also not be able to edit these fields. So be careful!

This all makes sense, really. But I haven’t ever seen this behavior documented clearly, and it flies in the face of how most APIs give access.

Your business will have its own set of default fields for a sales order, and so I can’t predict all of them. The customer record gets set through the “entity” field, and should be set as a RecordRef object type. RecordRefs are how most form items that get set from a drop down are referenced, throughout netsuite. The obvious exception is a static list, which usually have static values associated with them.

You’ll also probably want to add one or more line items, as the customer almost certainly wanted to buy something. That is done in the order items list, which is an object that has a sub list of InventoryItem, NonInventoryItem, or DiscountItem. These objects have RecordRefs to your Products, as well as PriceLevel and currency, quantity, and other settings. This is where we put that information we pulled about these earlier.

There’s also the billing schedule to be set, which is on the sales order object, and not the individual item. Usually this is not mandatory, and if it is not set will begin billing immediately.

Alright! You created a customer and a sales order. Netsuite can be set to take care of the rest of the transaction, send follow up emails, decrease inventory, calculate postage… Really whatever needs to be done in your business. So Let’s put this live and get hundreds of customers buying every minute, right? Well…. Maybe not so much.

So it turns out that the suitetalk API is severely rate limited. You can only perform one action at a time per user name, unless you pay an exorbitant amount of money to up that to 10. If you wanted 100s of sales every minute, you’d be dropping customers left and right. Trust me, that happened.

So to correct for this, we need to create a queue. And we need to change up the order of the actions so that our users aren’t waiting in line as long as our transactions are. I’ll leave that as an exercise for the reader. But if you really want help, leave me a comment below and I’ll be happy to discuss.

We can also get around a lot of the issues by writing this with RESTlets. They don’t have the severe rate limiting issues that suitetalk has, and may be faster to boot. Unfortunately I discovered that solution a bit too late. Thanks a lot for reading!