Use a scalable approach to add custom restrictions to Items’ accounting impacts
NetSuite’s permission structure makes it usually easy to separate the responsibilities of traditional Departments (like Accounting, Purchasing, A/R, Sales) so that duties are segregated appropriately, and so that those pesky SOX Auditors are kept happy (hopefully they are too busy to read blogs like this one).
However, NetSuite’s permissions access options are generally limited to records. This means that a role can have “Full, Edit, Create, View, or None” access for a particular record, but it’s difficult to grant permission to part of a native record or transaction. (If the concepts so far are unfamiliar to you, please see SuiteAnswers Article #9921 for more about NetSuite roles and permissions.)
Customer Record Credit Terms
A common use case requirement is setting credit terms or limits on a Customer record. Often, a Customer Service department is responsible to create a customer record, but only the Accounting department should set Credit Limits and Terms. There is no native permission to meet this need. A common workaround is to create custom forms with different field visibility options, and then to restrict forms to particular roles. Some sort of alert or dashboard would typically be set up so that Accounting is notified that a Customer record has been created and needs attention. Alternatively, a Workflow or custom scripting can be set up to achieve a similar result.
Below, I will discuss a different use case, and I’ll try to demonstrate how to make customizations future-proof and scalable, which is something that Marty Zigman and my developer friends and colleagues at Prolecto always remind me to keep in mind when designing solutions.
Item Records
The “Account” fields on Item Records in NetSuite control the General Ledger impact caused by using the items on transactions. Usually, an Operational Department such as Manufacturing or Purchasing is responsible for setting up Item records, but accounting people (like me, for example) get a severe allergic reaction from the thought of anyone outside Accounting having the ability to control GL impact of transactions.
NetSuite does have a check-box in the Accounting Preferences page of the Setup menu (Items/Transactions tab) usefully called “Anyone Can Set Item GL Accounts”, and un-ticking this preference does restrict the Accounting fields to only those users with appropriate Account record access. However, importantly, all this does is hide the Account fields, and NetSuite will pre-populate them with System Defaults. (System Default accounts are set up in the same area of the Accounting Preferences page.) This works well in situations where the same accounts can be used across all Items and where all Subsidiaries use the same Chart of Accounts.
What about where different item types need to hit different Asset, Revenue, COGS Accounts? or when Subsidiaries do not share the same Chart of Accounts? Here’s a solution that I’m currently working on for a client, with help from my friend Carl at Prolecto:
Step 1: Create Mapping Using Custom Records
The specific requirements of the client were to allow users to only set certain pre-defined GL Accounts on the Item Records, based on Item Type and Subsidiary. However, the same structure could be extended or easily modified for different requirements. In order to hold the “rules”, Custom Records are created which contain the ability to select an Item Type and Subsidiary, and then to define the allowed GL Accounts for each Item Record Account field (such as Asset Account, COGS/Expense Account, Revenue Account) using Multi-Select fields on the record. You don’t need to be a developer for this part, it’s easily done using point-and-click NetSuite functionality. See the image for an example.
Step 2: Write a Script to Guide Users
Here’s where I need help from a Developer. Carl will write a Client script that will trigger an alert to users when they select a “wrong” account. The alert will inform the users which accounts are allowed based on the parameters set in the custom records. Under the hood, what happens is that the code creates its own little “saved search” that looks up which accounts are allowed per the custom records, based on the item type, subsidiary, and account field selected in the UI.
Step 3: Think!
This step really occurs chronologically before Step 1 (hopefully!), but it’s easier to explain now that you can see some of the logic. We need to error-proof the solution based on all possible scenarios – what should happen when no Custom Record is found that matches the particulars of the Item Type and Subsidiary? What ought to happen when there is more than one custom record found for a scenario? What if a user selects more than one Subsidiary allowed for an item record? These possibilities need to be considered and incorporated into the solution. Intellectual energy is needed at the outset to avoid costly refinements later.
Reflections
What I like about using custom records to define the parameters of scripted solutions is that it is more future-proof than hard-wiring the logic into a script. The Chart of Accounts can change over time, Subsidiaries are added, and new rules need to be defined. Since we use Custom Records to store the rules, the client can easily make changes to the logic on their own. Moreover, it is scalable. If more complexity needs to be introduced – for example, if the allowable accounts should be based on a different Item Classification – we can add fields to the custom records, and add logic to the script to accommodate it.
If you’d like to hear more about efficient ways to improve your NetSuite internal controls environment, or have general NetSuite questions, we’d be happy to hear from you!
Conversations with Meir Bulman 