When crafting saved search formulas that depend on transaction types, one might be tempted to use the screen names of those transaction types (e.g. “Bill”, “Invoice”, “Journal”, etc.). However, since NetSuite allows users to rename transactions, this approach is brittle. In this article, I show you a more stable, account-independent approach to capturing transaction types in NetSuite Saved Search formulas.
TL;DR
Instead of using the customizable {type}
field in your transaction Saved Search formulas, use the account-independent {typecode}
field.
Situation
Recently, I needed to create a saved search in which, based on the transaction type, a different action was required. If you’re familiar with NetSuite saved search formulas, you know that a CASE
or DECODE
statement would work in this scenario. In my case, DECODE
produced a more compact and readable formula. (Refer to SuiteAnswers Answer ID: 10101 for a list of supported SQL functions.)
Weak Approach
Consider the following simplified example. The function produces an identifier for different transaction types and defaults to “9” if no match is found.
DECODE({type},
'Bill', '1',
'Invoice', '2',
'Journal', '3',
'9'
)
Unfortunately, the above solution is weak because it depends on the default names of the transaction types. However, these names can be changed via Setup >> Company >> Rename Records/Transactions
! Consider the following results from an account where the “Bill” record has been renamed to “Vendor Bill”. As illustrated below, the formula incorrectly produces a “9” for Vendor Bill instead of a “1” due to the renaming.
Better Approach
Consider the following improved approach. Instead of using the {type}
field, we use the {typecode}
field. The latter is fixed in the system for each transaction type and is not affected by renaming records.
DECODE({typecode},
'VendBill', '1',
'CustInvc', '2',
'Journal', '3',
'9'
)
With {typecode}
our formula works as expected:
Granted, it is not typical for records to randomly get renamed in an account. In most cases, renaming would occur during the initial NetSuite implementation. Therefore, one might argue that the weak solution, though brittle, is good enough. However, that argument is not true if you are crafting solutions that should work across accounts, in which case, it is important that you make no assumptions about parameters that are configurable such as the screen names of transactions.
Reference List of Transaction Type Codes
I was unable to find any SuiteAnswers article that lists the {typecode}
values for all transaction types. Gladly, there’s an easy way to extract this information: create a temporary transaction type saved search with criterion Type = any of <select all available transaction types>
. Using a tool like the very useful NetSuite Search Export Chrome extension, you can then export the types. To increase your coverage, be sure to do this in an account with as many transaction types enabled as possible.
For your convenience, here’s a list of the types that I extracted using the above method, at the time of writing. While the list might not be complete, the values presented are accurate.
Transaction Type | Type Code |
---|---|
Bill | VendBill |
Bill Credit | VendCred |
Bill Payment | VendPymt |
Bin Putaway Worksheet | BinWksht |
Bin Transfer | BinTrnfr |
Blanket Purchase Order | BlankOrd |
Cash Refund | CashRfnd |
Cash Sale | CashSale |
CCard Refund | CardRfnd |
Check | Check |
Commission | Commissn |
Credit Card | CardChrg |
Credit Memo | CustCred |
Cross Charge Journal | XChgJrnl |
Currency Revaluation | FxReval |
Customer Deposit | CustDep |
Customer Refund | CustRfnd |
Deposit | Deposit |
Deposit Application | DepAppl |
Deprecated Custom Transaction | DeprCust |
Expense Report | ExpRept |
Finance Charge | FinChrg |
Inventory Adjustment | InvAdjst |
Inventory Cost Revaluation | InvReval |
Inventory Count | InvCount |
Inventory Distribution | InvDistr |
Inventory Transfer | InvTrnfr |
Inventory Worksheet | InvWksht |
Invoice | CustInvc |
Item Receipt | ItemRcpt |
Item Shipment | ItemShip |
Journal | Journal |
Netting Settlement | NettStlm |
Opportunity | Opprtnty |
Payment | CustPymt |
Purchase Order | PurchOrd |
Quote | Estimate |
Requisition | PurchReq |
Return Authorization | RtnAuth |
Sales Order | SalesOrd |
Sales Tax Payment | TaxPymt |
Statement Charge | CustChrg |
System Journal | SysJrnl |
Transfer | Transfer |
Transfer Order | TrnfrOrd |
Vendor Prepayment | VPrep |
Vendor Prepayment Application | VPrepApp |
Vendor Return Authorization | VendAuth |
WO Build | Build |
WO Unbuild | Unbuild |
Work Order | WorkOrd |
Work Order Close | WOClose |
Work Order Completion | WOCompl |
Work Order Issue | WOIssue |
I hope you found this article useful.
NetSuite Insights is on a mission to raise the standards around NetSuite practices, one insight at a time. If that resonates with you, learn how you can become an author/collaborator here.
Don’t miss a beat – subscribe to our no-nonsense email list to have these game-changing insights hit your inbox as soon as they’re published. Ignorance? Nah, you’ve got a smarter option. Choose wisdom, choose insights!
Great job on this excellent writeup.
Thanks, Roy. Glad you found it useful.
Chidi,
This is very good! In 2014, I wrote this article with a static list of codes. It’s great we can gain access to this information dynamically.
https://blog.prolecto.com/2014/01/03/netsuite-searchfilter-internal-transaction-type-codes/
Marty
Thanks, Marty!
Great article! FYI, I found that {type.id} has the same results as {typecode}.
Good to know. Thanks, Elie!
Thanks for the reference list, it might come handy. I didn’t know about {typecode} but you would get the same result with {type.id}.
Another disadvantage of {type} in formula is that it’s language specific. So if user is using different language than English he would get transaction type translated. So {typecode} or {type.id} is the way around it.
There is also a field {recordtype} (or Record Type in UI) that could be used but it’s returning different values. However, I remember a case when I used it to return record type of the transaction referenced in a custom record field and it didn’t work as expected, it returned the custom record type instead. But it only happened if I set it in UI as Custom Record Field : Record Type, as formula {custrecord_field.recordtype} it worked fine.
Thanks Lukas for your insightful comments!