This article is relevant if you are looking to gain better visibility and control over NetSuite transaction approval and validation processes.
After doing many client implementations and listening to all types of different concerns as it relates to accepting transactions meeting specific criteria, a pattern emerged that allowed us to produce an innovation to get in front of these types of challenges. ¬†To help describe the challenge, I will use the NetSuite Sales Order ¬†as an example. ¬†NetSuite offers a basic built-in switch to indicate if a Sales Order is approved. ¬†The Sales Order status is driven by an on / off dropdown field that has the value of either “Pending Approval” (unapproved) ¬†or Pending Fulfillment” (approved). ¬† ¬†NetSuite’s general thinking behind the switch is that when you are committed to deliver on a customer order, modify the Sales Order status to Pending Fulfillment. ¬†NetSuite offers tools to help this process to allow you to approve orders in bulk or individually. ¬†NetSuite doesn’t allow you to move to the the item fulfillment stage unless the Sales Order is approved; and, if you are working to manage a perpetual inventory, a Sales Order must be approved before inventory can be fully committed.
Naturally, NetSuite suggests to use the power of the platform (workflows or SuiteScript) ¬†to drive any behavior around an order before it is approved. ¬†Our team excels at discussing and producing business functions to drive transaction behavior as frequent readers know that I am passionate about the NetSuite customization platform. The most common technique used to manage the Sales Order is to check rules with workflow or scripts at the time the the order is going through BeforeSubmit ¬†transaction event while it is moving between unapproved to approved status. ¬†For example, one client had a rule that when an order is over $1,000 USD, a manager must be be the one to approve. ¬†For another client, they were concerned that one big order would deplete all inventory on hand (the large order case). ¬† Here, they invented a rule that if any order would consume more than 10 units (large in their case) do not allow the order to go through without manager review.
These two examples illustrate the need for transaction review by managers. ¬†Using the traditional approach, you throw an error if the user who is trying to approve the order is not a manager. ¬†Then, a manager can work transactions one at a time and by clicking the built-in “Approve” button and the same script will this time see that the user is a manager in a role with sufficient privileges to allow the approval to complete . ¬†Other examples include rules which ensure that the user gathered sufficient information but is not marked mandatory; for example, collect a purchase order number or ensure the customer has available credit. ¬†Using the same approach, you check th rule and throw an error during the approval evant and try to provide meaningful descriptions so the user can fix the transaction.
The General Challenge with Traditional Transaction Approval
With the background provided, I offer that the traditional approach is weak based on these points:
- Visibility: Most NetSuite administrators will argue that Workflows provide good visual indication of transaction approval states. ¬†However, what about users and management ability to see what is going on while transactions are in play? ¬†There is no offer.
- Role based Rule Override: there is no capacity to indicate which roles should be able to override transaction approval exceptions. ¬†NetSuite administrators often produce multiple NetSuite forms to refine transaction edit capacities leveraging the permission system. ¬†Over time, this approach becomes challenging and costly to manage.
- Auditability: Once a transaction has been approved, there is limited visibility about what happened. ¬†Yes, system notes help, but they are not going to help you see how business rules passed their check.
Introducing Transaction Approval Manager
- Auto Approval: Instead of pushing orders to approval, the system works on your behalf to auto approve orders if they pass all validation checks. ¬†Each validation check is considered a hold rule.
- Table Driven Rule Definition:¬†Hold rules are now defined within tables allowing administrators more flexibility for ordering and driving behavior.
- Transactional Rule Exposure: ¬†Based on the table driven rules, every transaction gets a copy of the hold rules so that each one can be checked. ¬†Status on verification is visible to all users.
- Override by Role Management: The table driven rules allow for the definition of which NetSuite roles can override a transaction rule that does not pass.
- Auto Item Fulfillment Generation: based on the rules defined, if after a Sales Order is approved, it can automatically move to item fulfillment. ¬†One approach is to approve a sales order but prevent an item fulfillment record from generating until a future ship date arrives.