SuiteCommerce InStore

SuiteCommerce InStore (SCIS) uses a phased release process. Each phase consists of a different group of customers upgraded to the newest version of SCIS 2018.2. All administrators receive an email notification with information about when accounts are scheduled upgrade.

Note

Contact your account representative or Customer Support if you have questions about availability.


Preview in Sandbox

Before your account is upgraded, you can install SCIS 2018.2 in your sandbox account. This provides the opportunity for testing new features with your own data and business processes in advance of the production upgrade.

After you have installed SCIS 2018.2 in your sandbox account, you should do the following:

  • Use your sandbox account to learn about new features and to test the upcoming release.

  • Use your production account to run your daily business.

The following new features are included in SuiteCommerce InStore, Bundle ID 233001 (SCIS 2018.2):

Enhancement to Image Resizing in SCIS

In SCIS 2018.2, new Image Size IDs have been added to the list on the Advanced subtab of the Web Site Setup page. The new values enable administrators and web developers to create a richer experience for sales associates. Now, a greater variety of images can be displayed in SCIS.

Required Action

If you are currently using SCIS 2018.1.x, you must add the new Image Size IDs, along with values for Maximum Width and Maximum Height to your account. Go to Setup > SuiteCommerce Advanced > Set Up Web Site, and then click Edit next to your SuiteCommerce InStore website. On the Web Site Setup page, click the Advanced subtab, and update the Image Resizing list. Perform this task before upgrading to the new version.

Add the following new Image Size IDs:

  • cartitem

  • receiptitem

  • itemdetails

  • quickadditem

Copy the maximum height and width parameters from the table below. Ensure that all image size IDs are marked as Enabled. This table shows the complete list of image size IDs required for SCIS 2018.2.

Image Size ID

Maximum Width

Maximum Height

fullscreen

1,600

1,600

main

600

600

search

150

120

thumbnail

100

100

tinythumb

50

50

zoom

900

900

cartitem*

150

150

receiptitem*

80

80

itemdetails*

300

375

quickadditem*

90

90

*Indicates new image size IDs for SCIS 2018.2.

For more information, read Configuring Item Images for SCIS.

EMV Processing Optimization

A new check box has been added to the SCIS settings record, Optimize EMV. Administrators can check this box to benefit from a performance enhancement to sales transactions submitted with EMV payment methods.

Note

To use the Optimize EMV setting, you must use the accounting preference, Invoice in Advance of Fulfillment.


The new check box affects the device priming process. The priming process is the action that triggers the PIN pad initialization. This action submits a transaction in NetSuite with the EMV payment method information and SCIS device ID included. When the box is not checked, the SCIS priming process operates as it has in previous releases, it submits a cash sale transaction.

However, with the Optimize EMV box checked, during the priming process, SCIS submits a customer payment and invoice instead of a cash sale. Because customer payments do not calculate taxes, or typically run several user event scripts, this optimization speeds up the process of submitting a sales transaction.

This check box affects specific types of sales transactions:

  • Sales transactions where the entire amount is processed using an EMV payment method.

  • Sales transactions where an EMV payment method is the first one used in a split payment of more than one payment method.

Important

This enhancement changes the payment process. If you enable this enhancement, you should use your sandbox account to test sales and return transactions in SCIS, prior to using this enhancement in your production account.


For more information, read Optimize EMV Enabled Sales Transactions. Read also, SCIS Settings for Orders to learn about the Optimize EMV setting on the SCIS Settings record.

Enhancements to the Workflow for Returns

SCIS 2018.2 includes enhancements to workflows for sales associates processing validated returns and working with quotes. These enhancements are intended to improve ease-of-use for sales associates working with SCIS.

In SCIS 2018.2, when you click the Return button to initiate a validated return, the enhanced user interface provides a clear display of items that are available for return and the items that are not. In addition, there is a new check box for applying the return reason. Sales associates can apply a return reason to each line item on the return transaction, or apply the same return reason to all items on the transaction.

For more information, read Processing Returns in SCIS.

Ability to Modify Expiration Date on Quotes

In SCIS 2018.2, sales associates can modify the expiration date on quotes. If the quote expiration date is in the past, the sales associate can still open the quote, modify it, and change the date if needed. This enhancement enables the same capabilities for quotes in SCIS as estimates in NetSuite.

Also, if the expiration date of the quote is in the past, you can still open the quote, modify it, change the date, and save it again if needed. Alternately, you can convert the quote to an order.

Expired quotes are displayed in search results. Expand the line in search results to see the expiration message highlighted in yellow.

For more information, read Entering Quotes in SCIS.

Ability to Create Extensions for SCIS

In SCIS 2018.2, retail establishments can work with web developers to create extensions for SCIS. In this release, components have been added to the Extensibility API to enable web developers to create popup windows that can affect the sales associate’s workflow.

Previously, as of 2018.1, web developers could only use SCIS Event validators to trigger events based on actions that took place mostly in the cart. Now, starting in 2018.2, developers can use the Extensibility API to write code that triggers actions in the frontend, after certain events have already occurred in the cart. The same events that are used in backend validators are available to use in the Extensibility API in the frontend.

For example, a sales associate goes to add an item into the cart. A web developer using the Extensibility API creates an option window that validates a condition to determine if the item should be added or not.

Note

This feature includes the following limitations:

  • The behavior of events used in the backend are different from events used in the frontend.

  • Custom fields created on any record in NetSuite, are not available to be used with the Extensibility API.


Option Windows and Information Windows

Additional components in the Extensibility API, enable web developers to create option windows and information windows that provide sales associates with feedback about an operation. These windows fill only the amount of space required for the message, so the current activity in the cart remains visible to the sales associate. Note the following:

  • Option window – This window enables the sales associate to choose between two options. Use the option window to show the following:

    • A Toast notification (short popup message) based on one of the status values available for extensions (warning, error, success, information).

    • Text that can be loaded dynamically.

    • Two buttons that can be customized by developers.

    The following screenshot shows an option window with a warning status.

  • Information window – This window shows an informational message. Only one action can be associated with the Information window. Use the information window to show the following:

    • A Toast notification based on one of the status values available for extensions (warning, error, success, info).

    • Text that can be loaded dynamically.

    • One button that can be customized by developers.

    The following screenshot shows an information window with an error status.

  • Status values – Option and information windows indicate a particular status. Each window is marked with a status value color bar at the top. Note the following supported status values and colors:

    • Warning – yellow

    • Error – red

    • Success – green

    • Information – blue

Creating Extensions for SCIS

To start creating extensions for SCIS, web developers must install the SuiteCommerce Extension Management bundle. Use the developer tools provided in the bundle to deploy extensions to a NetSuite account. Administrators can activate SCIS extensions using the Extension Manager in NetSuite.

For more information, read SCIS Extensions.

Transaction History in SCIS

The Transaction History enables sales associates and sales reps to view recent transactions. They can also print receipts for quotes, returns, or purchases. Click the clock icon at the top of the screen to view the Transaction History.

In SCIS 2018.2, the Transaction History includes filters: Mine, and All. Sales associates can filter the results to view only transactions that they submitted (Mine), or transactions submitted by all sales associates (All). It can be useful to view all transactions when called upon to process a return for a customer who originally worked with a different sales person. Sales associates can use the date filters to view transactions that occurred during a specific date range.

For more information, read Printing Receipts from the Transaction History.

Ability to Assign Customers to Orders in Fallback

In SCIS 2018.2, a new link in the order summary sidebar enables a sales associate to assign a customer to an order submitted in Fallback. Sales associates can touch or click the Assign Customer link, and then enter a customer identifier in a popup dialog window. The customer identifier can be an email address or a customer ID. The sales associate must enter at least one identifier to assign a customer to the order.

Entering the customer’s first or last name is optional. The sales transaction submitted in Fallback is matched in the system based on the customer ID or the customer email field in NetSuite. The customer name is used as a filter, to refine the search.

During the consolidation process, the identifier entered in Fallback is matched against the list of customers in the NetSuite account. If the identifier matches an existing customer, the customer information is associated with the Fallback transaction and is carried through to the final NetSuite transaction.

Note

If there is more than one match on a customer email address, then the customer name can help identify the correct customer. However, if the customer name is incorrect, and not matched, then consolidation cannot occur, and a final transaction is not created in NetSuite.


For more information for sales associates, read Assign a Customer to an Order in Fallback.

Ability to Assign Sales Reps to Transactions in Fallback

In SCIS 2018.2, sales reps can be assigned to transactions, exactly the same way as they are in SCIS online. Sales associates can click or touch a link in the cart to display a list of sales reps, then add one of them to a sales transaction entered in Fallback.

Note

The sales rep selected is only added to the current transaction. After a transaction is submitted in Fallback, the sales associate can select a sales rep again for the next transaction.


The sales rep data in the Fallback transaction is captured from the device, and then transferred to NetSuite along with other data from the order. The Sales Rep name appears on the receipt, the SCIS Fallback Transaction in NetSuite, and on the final transaction. If no sales rep is selected in Fallback, then a sales rep is not specified on the final transaction in NetSuite.

Note

If the sales rep record becomes inactive, or the sales rep location changes in NetSuite, then reconciliation of the NetSuiteransaction is required. You must edit the final transaction in NetSuite to reset the Sales Rep field.


For more information, read Enter an Order in Fallback.

Split Payments in Fallback

In SCIS 2018.2, sales associates can create split payments for sales transactions entered in Fallback. They can divide a single a payment in two or more different payment methods. After full payment is applied to the sales transaction, and the data delivery and consolidation process have completed, an invoice transaction record is created in NetSuite. All payment methods applied to the transaction are displayed on the final transaction in NetSuite.

In the event of an interruption in the Fallback session, partially paid transactions are suspended. The Fallback session can be interrupted if the sales associate switches to SCIS online, closes the app, or logs out of Fallback before completing payment on a sales transaction. The incomplete Fallback transaction is saved on the device, and is not transferred to NetSuite until full payment is applied. Any sales associate with the appropriate Fallback PIN can resume the transaction and finish applying payments in Fallback. Immediately after logging in to Fallback, a popup message indicates that there is a pending transaction waiting to be completed.

Sales associates can ignore a pending sales transaction, and then resume it later. However, there is no option to discard the transaction if partial payment has already been applied. Best practice is to ensure that there are no remaining suspended transactions in Fallback at the end of a shift, or prior to reallocating a point-of-sale device.

Transaction Differences in Fallback

In 2018.2, the Transaction Difference from Fallback field shows a value only if there is a difference between the sales transaction entered in Fallback and the final transaction created in NetSuite. This new field appears on the SCIS Fallback subtab on the final transaction.

The following table describes what you might see on the final transaction with corresponding values in the Transaction Difference from Fallback field.

Data on the final transaction in NetSuite

Values in the Transaction Difference from Fallback field

Sales Rep is missing from the final transaction.

  • The selected sales rep is disabled or does not exist.

  • The sales rep selected in Fallback is not associated with the location.

The amount on one or more transactions lines is different from the expected transaction line amount.

Transaction line was recalculated because of a different tax rate on the Fallback transaction.

The discount amount on the final transaction is not as expected.

Order discount was recalculated because of a different tax rate on the Fallback transaction.

See also, Cases when NetSuite Transactions are Different from Transactions Entered in Fallback.