Enabling Validations on Transactions
After setting up the validations, you can apply any of the validations separately or in combination on sales transactions and inventory adjustments. When you create or use a specific transaction that has an enabled validation type, the validation that you set applies to the transaction.
Read the following topics for instructions on how to enable the validations in transactions:
Item Set Validation
This validation enables you to apply restrictions when selling items to a customer group. You can select which items are restricted to a specific customer group during the setup for Enhanced Validations and Defaulting SuiteApp.
When adding line items on a transaction, the item set validation applies when one or both conditions occur:
-
The item belongs to an item set that is excluded for the customer group.
-
The customer belongs to a customer group that is restricted to purchase the item.
For more information about applying customer restrictions, see Setting Up Enhanced Validations and Defaulting.
Negative Inventory Validation
On supported transactions, this feature restricts the entry of an item quantity that is more than the on-hand inventory across locations.
Item quantities in transactions must not exceed six decimal places.
Posting and Nonposting Transactions
When you modify the quantity of items in a transaction record, the SuiteApp checks for negative inventory differently for posting and nonposting transactions.
For posting transactions where the original item quantity is immediately fulfilled, the SuiteApp validates only the additional quantity requested. For example, a cash sale transaction has an item quantity of 10. When you edit the transaction and change the item quantity to 12, the popup message shows Requested: 2 ; On Hand: 0.
For nonposting transactions where the original item quantity is not immediately fulfilled, the SuiteApp validates the total of the original and additional quantity requested. For example, a sales order transaction has an item quantity of 10. When you edit the transaction and change the item quantity to 12, the popup message shows Requested: 12 ; On Hand: 10.
The Enhanced Validations and Defaulting SuiteApp can validate the posting and nonposting transactions as found in the following table.
|
Posting Transactions |
Nonposting Transactions |
|---|---|
|
Cash Sale |
Sales Order |
|
Invoice |
Work Order |
|
Inventory Adjustment |
Transfer Order |
For invoice, validation is available for both standalone invoice and invoice from a sales order.
Multi-Location Inventory Feature is Enabled
If the Multi-Location Inventory feature is enabled in your account, you can select different locations for each line item that you are add to the transaction. The SuiteApp then validates the inventory in each specified location to verify enough stock for the line item.
If the item quantity entered results in negative inventory, the Negative Inventory Validation prevents saving of the record. A message appears to show how many stock there is currently on-hand for the item. This occurs when the Prevent Negative Inventory preference is enabled for Negative Inventory Validation.
When this preference is not enabled, you can save the transaction even with negative inventory. The SuiteApp displays a warning message to show the negative inventory. To review information about this preference, see Setting the Prevent Negative Inventory Preference.
Multi-Location Inventory Feature is Not Enabled
When the Multi-Location Inventory feature is not enabled, the SuiteApp validates inventory across all locations when you add line items. A message appears when you enter an item quantity that is more than the on-hand inventory. The item quantity must be changed before you can add the item to the transaction.
A warning message is also displayed when you add multiple items to a transaction. The message identifies which items do not have enough on-hand inventory. It also shows the number of available items for a selected location. You can then change the item quantity or select a different location for each item before you can add the item to the transaction.
For more information about Multi-Location Inventory, see Multi-Location Inventory.
Default Discounts
Default Discounts enables you to assign header-level discounts for a specific customer or customer group. The default discount automatically applies to the customer on supported transactions.
After changing the value of the Customer field in a transaction, be sure to verify the values in the Discount Item and Rate fields. These fields are customer-specific and are automatically populated. When you edit a transaction and select a customer without a default discount, the SuiteApp clears any existing values in these fields.
Transformed Transactions
The Default Discounts feature of the Enhanced Validations and Defaulting SuiteApp supports the following transformed transactions:
-
Cash Sale from a Sales Order
-
Invoice from a Sales Order
The SuiteApp does not support Cash Sale and Invoice transactions created from a customer record.
Default Discounts Scenarios
By default, the discounts you set on the customer or customer group record automatically applies. However, some scenarios may occur that may change the default discounts applied to customers. Read the following examples to better understand how default discounts are applied:
Scenario 1: Customer has default discount and also belongs to the customer group with default discount
Default discounts on the customer record and customer group are both assigned to the customer. For this scenario, the SuiteApp applies the default discount set on the customer record.
Scenario 2: Customer belongs to two or more customer groups with default discounts
If there is no default discount set on the customer record, the SuiteApp applies the default discount from the customer group with the higher percentage or value.
For example, Customer A belongs to Customer Groups X and Y. Customer Group X has a default discount of 25% while Customer Group Y has 40%. The SuiteApp applies the default discount of Customer Group Y.
If the applicable default discounts are in currency value, the SuiteApp applies the discount of the customer group with the higher value.
Scenario 3: Customer is a parent subsidiary and default discount on customer record is for Child Subsidiaries
In this scenario, the default discounts selected on the customer record is for child subsidiaries. On a sales transaction, no default discounts apply for the parent subsidiary customer because the default discounts set is for a child subsidiary.
Scenario 4: Customer is a parent Subsidiary and belongs to two customer groups with different subsidiary discounts
In this scenario, Customer B is a parent subsidiary that belongs to Customer Groups F and G. The default discount for Customer Group F is 50% discount for child subsidiaries. Customer Group G has a default discount of 40% for parent subsidiaries.
In this example, no discount is applicable for parent subsidiary Customer B because the customer group with the higher default discount percentage (Customer Group F) sets discounts only for child subsidiaries.
Scenario 5: Customer is a parent subsidiary and belongs to customer groups with child subsidiary discounts
If there is no default discount set on the customer record, no discounts can be applied for the customer on the transaction.
The same result as in this scenario applies if a customer is a child subsidiary (with no discounts set on its record) and the customer group it belongs to have discounts only for parent subsidiaries.
Scenario 6: Customer belongs to two or more customer groups with mixed default discounts in percentage and currency value
This scenario illustrates a case where the customer groups where a customer belongs to – differ in default discounts. For example, Customer C is a parent subsidiary that belongs to Customer Groups J and K that both have default discounts for parent subsidiaries. Customer Group J has a default discount of 50% and Customer Group K has a default discount of 100USD.
In this example, the SuiteApp applies the discount from Customer Group J because the discount is in percentage. The percentage discount is always applied to transactions regardless of whether it has the lesser value in actual computation.
For a visual representation of the process, see Enhanced Validations and Defaulting Process Flow.