Web Development Archives - Michael Bianco

Notes on Locked Records in NetSuite

In NetSuite, records can be "locked". This is a special state that is poorly documented and introduces some very strange behavior. Hopefully, some of these notes save someone banging their head against the wall to solve this problem! Records can be locked in NetSuite in one of two ways: (1) the accounting period the transaction is in can be locked (2) or the record can be explicitly locked. You cannot determine if the accounting period is locked directly from the record. You’ll need to pull the associated AccountingPeriod posting_period object reference. You cannot "explicitly" lock a transaction in NetSuite via the API. I have not found a way to do this through the GUI either. A workflow can lock a record in NetSuite…

Depositing Transaction Records in NetSuite

Moving transactions in NetSuite from "Not Deposited" to "Deposited" is not straightforward when using NetSuite SuiteTalk. You need to ensure that undocumented requirements for each record type are met. After you’ve validated that your records are properly configured, you can include them in a new deposit using the following structure: Note that you don’t need doc, type, or any of the other fields available on the a DepositPayment item. It’s also important to note that the other fields on the DepositPayment don’t actually effect how NetSuite handles the referenced transaction record. deposit, id, and payment_amount are the only fields that matter when referencing a NetSuite transaction on a deposit.

Using Browser Sync with Rails and Local SSL

I’ve always been a fan of LiveReload since I first saw it years ago. However, the rack-livereload gem hasn’t been updated in a long while, and the livereload parent project seems to have died out too. rack-liveload doesn’t support reloading on local HTTPS connections, which was a requirement on a recent project—I needed a new tool. BrowserSync came to the rescue. In most cases, using BrowserSync’s proxy mode to reverse proxy a rails app running via a *.dev pow domain works well. For this particular project, there were a couple of specific issues: Many pages on the project force HTTPS…

Using HTTPS Locally: Pow, SSL, Rails, and Apache

Using HTTPS local development or testing environments is a hassle. A common practice is to disable SSL in development, but I’ve had too many cases of minor bugs creeping in when routing works differently between environments. I also don’t like manually having to let my browsers know that a self-signed certificate is valid. Here’s the configuration that I use to easily add https support on my development machine to any application served—or proxied—through port 80. Pow I use Pow as my development rails server. However, because I often work with other languages as well, I run Apache (you could just as easily use nginx) and reverse proxy Rails application requests to Pow. To do this, you’ll need Pow to bind to a port that is not port 80…

How to Refund a Customer Deposit using NetSuite SuiteTalk

When refunding a NetSuite CustomerRefund or CashSale you’ll add it to apply_list: Refunding a CustomerDeposit works a bit differently. If you inspect the SuiteTalk XML response for a CustomerRefund created for a CustomerDeposit it will appear under the apply_list XML tag. If you use that XML tag when creating the CustomerRefund you’ll get the following error: Instead, you need to use the deposit_list tag:

Determine Deposited Status of CustomerRefunds in NetSuite

Most payment and refund records in NetSuite have a straightforward way to determine if they’ve been deposited or not. The CustomerRefund is one exception: there is no way to determine from the GUI, or from the SuiteTalk API response for a CustomerRefund, if a given CustomRefund has been linked to a deposit record. However, you can search for CustomerRefunds which are deposited or undeposited using a couple poorly documented search filters:

How to Find the NetSuite Web Services Account Number

Finding the account number for NetSuite’s SuiteTalk WebService API isn’t very straightforward. This number is required for any applications with connect to NetSuite via their SuiteTalk API. Navigate to the SuiteTalk preferences via "Setup > Integration > Web Services Preferences", by searching for "page: Web Services Preferences" in the global search bar, or by visiting this URL (may not work depending on your NetSuite data center). You’ll see the following screen containing the Account Number (also called the Account ID): Some things to keep in mind: The account number is not always a number. It can be a string of letters…

Resolving the NetSuite LIST_ID_REQD Deposit Record Error

Creating deposit records in NetSuite using the SuiteTalk API can sometimes result in the following error: This error is not well documented at all and does not point to a single issue. In order to properly handle and prevent this error from occurring you need to implementation validation before upserting (or adding, updating, etc) the record. Here are the various causes of the error: The included refund’s (CashRefund, CustomerRefund) account field is not set to the NetSuite instance’s “Undeposited Funds” account. The easiest way to determine what the “Undeposited Funds” account internalId is to search for the account by name and grab the first search result. The name of the “Undeposited funds account can be customized…

How to Close a NetSuite SalesOrder Using SuiteTalk

Many things in NetSuite’s SuiteTalk XML API are not intuitive or obvious: closing a SalesOrder is one of them. When you create a SalesOrder using upsert or add you can set the order_status to _pendingFulfillment or _pendingApproval directly through the order_status field. However, you can’t simply update the order_status field on a SalesOrder to close the record, you need to set is_closed field on each line item in the SalesOrder. Other SalesOrder states work in a similar way: _partiallyFulfilled, _fulfilled, etc are only achieved by modified the item_list sublist or by creating a separate record (ItemFulfillment, Invoice, etc).

NetSuite SuiteTalk User & Role Edits Are Delayed

If you work with NetSuite’s SuiteTalk API, you know that: You must access the API via employee/user record in NetSuite API calls specify the user role to use You will get different results based on which user and which user role you are accessing the API with. For instance, if the employee record has the “Sales Rep” option checked, all Sales Orders created using that employee/user credentials will have the “Sales Rep” field assigned to the user’s record. Each role has a different set of permissions. You will get different fatal error messages depending on which user role you are operating under. Often, when developing a NetSuite integration, you’ll need to make edits to the SuiteTalk user/employee record or the role…

Category: Web Development