Here at SquareWorks we’ve done implementations and support work for clients in biotech, software and technology, warehousing and distribution, and multiple other verticals. While the industries may vary, many of the requests we hear are surprisingly similar.
One topic that comes up regularly is making the financial segments (i.e. department, class, location) mandatory on transaction records. There can be strong business cases for this, but there can also be unintended downstream consequences. It’s important to be aware of the potential issues and make a plan to mitigate these risks when possible. How you go about making these fields mandatory can have a big impact.
We’ll use the Class segment as our example here and walk through the risks and some of the alternative ways to approach this.
Making Class Mandatory Throughout System
First, what does it mean to make class mandatory? The most common request is to make class required across the board. If classifications have been enabled at the line level, this would include both header and line level fields. NetSuite does allow for journal entries (JEs) to be exempted from this via Accounting Preferences, but all other records would be included.
- Class field will be mandatory for all transactions
- NetSuite will not allow transaction to be saved without providing a Class except for Journals (depending on the selected settings)
- The change applies prospectively
- Existing transactions are not affected unless these are edited, then a class would be required before re-saving
The three most common issues with this approach are:
- User frustration at the extra steps to populate this field, especially if it’s on a transaction with a large number of lines where a per-line class is needed.
- Bad data entry due to users selecting the first value they find because they don’t know what to choose and just want to move on.
- If a default value is present, users simply leave that default and never update with accurate values so they can get through their work quickly. The default value would need to be set with a secondary process (i.e. scripting).
Depending on your situation, this would be the quickest and easiest approach. However, to avoid these common issues, the following are four alternatives:
1. Make Class mandatory on a per record basis via the form
The benefit of using the form is that we can make the class field required for specific transactions, though only at the header level. Unfortunately, the forms in NetSuite only allow for exposing, hiding, and renaming line-level fields and not the ability to make those fields mandatory.
In addition to setting the header class field as mandatory, you could create role-specific forms. This would allow for more fine-tuned control on when class is required based on job duties.
2. Default it on the item record (for Order To Cash or Procure To Pay records)
For transactions that include items, we always have the option of setting a default class on the item record itself. The result is that each line with an item would default to the value selected on the item record, though that value can be updated as desired. This option is one of the easiest to implement, but doesn’t meet most companies’ needs since it’s limited to a smaller set of records.
Using a workflow to selectively make these fields mandatory is a great option for some record types. There are some distinct limitations with this approach. While it won’t work with journal entries, it could be used for most other records.
As with some of the approaches above, there are additional pitfalls when working at the line level. Workflows in NetSuite have improved, but are currently limited to the Item sublist.
Using a workflow is possible, but limited in its applicability.
4. Custom scripting
Of all the options, the one that gives the most flexibility is custom scripting. A fairly simple script can be used to set the class as mandatory at either the header or line level, and can even specify which transaction records make class mandatory versus optional. A default value can also be assigned in the same script if desired.
Each of these configuration options have their pros and cons. For help on deciding which to deploy based on your organization’s needs, reach out to our consulting team at email@example.com