This article is relevant if you are looking to gain better visibility and control over NetSuite transaction approval and validation processes.

Background

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:

1. 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.
2. 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.
3. 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

Based on the concerns noted above, we worked with a client and invented the Transaction Approval Manager.  We like to call it TAM (click to enlarge supporting images)  With this bundle available to our clients as no charge, we attack the challenge from a different perspective:

1. 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.
2. Table Driven Rule Definition: Hold rules are now defined within tables allowing administrators more flexibility for ordering and driving behavior.
3. 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.
4. 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.
5. 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.

Many times, we are building custom eCommerce integrations to NetSuite and TAM works great to make sure that high volume orders automatically go to item fulfillment if all is in order.  The staff then focuses on anything that does not pass the hold rules.

Get Control over Transaction Processing

Marty Zigman

Holding all three official certifications, Marty is regarded as the top NetSuite expert and leads a team of senior professionals at Prolecto Resources, Inc. He is a former Deloitte & Touche CPA and has held CTO roles. For over 30 years, Marty has produced leadership in ERP, CRM and eCommerce business systems. Contact Marty to set up a conversation.

More Posts - Website - Twitter - Facebook - LinkedIn - YouTube