Point of Sale Upload

File Format - Transaction

Filename: Begins with “TransactionInfo_” and ends with “.csv”. Files are often named for the time period they cover, eg: “TransactionInfo_YYYYMMDD_HHMMSS.csv”.

^{* required column}

Example - Transaction

In this example, we’re uploading a transaction file for a cash return transaction performed by Justin at Store ID: RNP and at the POS terminal 13. All transaction file fields are included up until the currency code.

Download the example CSV file

File Format - Line Item

For each period of transaction data, the system requires a Line Item file in addition to a Transaction file. Although the Line Item file must be present, it may be empty if line item data is not available.

Filename: Begins with “LineItemInfo_” and ends with “.csv”. The custom identifier in the filename between “…Info_” and “.csv” must match up exactly with the custom identifier used in the corresponding Transaction filename, which is recommended to be the timestamp of the transaction; e.g. “LineItemInfo_YYYYMMDD_HHMMSS.csv”. Note that duplicated filenames will result in issues with line item matching - each transaction and line item pair must have a unique name versus other pairs.

^{* required column}

Example - Line Item

In this example, we’re uploading a line item file corresponding to the transaction with ID: AR0502218090. The line item information includes the details of the voided Brown Winter Jacket item, the only item pertaining to this transaction with no associated discounts.

Download the example CSV file

Combined Example

In this example, we’re uploading the transaction file as well as the corresponding line item file for the sale and return of the Red Ball item.

Transaction File

Download the example CSV file

Line Item File

Download the example CSV file

The sale and subsequent return of the Red Ball item will result in two respective transaction entries in the system, with a net combined sales value of $0.00.

Keeping with the above example, let’s assume a scenario where the POS system is set up to list sales and returns/discounts in separate lines using the same transaction ID value.

Transaction File

Download the example CSV file

In this scenario, the system will consider the transaction as a Return and will just show a sales value of -$16.92 for the transaction because the system simply overwrites line1 entry with line2.

Validation

When uploading POS files (transaction and line item), you will receive feedback about any errors that were found during validation. If a file fails validation, even just for a single line, it will not be processed. You can review previously uploaded files and any related errors by navigating to the POS tab at Admin Settings > File Upload Status.

The possible errors are listed below that will result in failed validation.

In other cases, warnings will be listed when there is data in a POS file that appears incorrect and may not be processed as expected.  Files with warnings will validate and process, but in some cases the offending line(s) will be skipped.

Missing/Invalid Files and Lines

The points below describe how the system handles a few additional scenarios when uploading POS files that have missing information.

• If there is a file TransactionInfo_x.csv, there should be a corresponding file LineItemInfo_x.csv (where x is a consistent value) along with it in order for the system to process those transactions. If the files are empty (0 bytes), they will be ignored.

• If there are line item lines with a Transaction ID that is not present in the transaction file, those lines will be ignored as “orphan item lines of tx Id:x” and the file will be processed.

• If there is a transaction line with no line items with the same transaction ID, the transaction will be processed with an empty receipt.

Additional Details

Re-uploading and Updating Transactions

If the same transaction is uploaded more than once in separate files, the new file transaction data will always overwrite the existing transaction data, meaning that you won’t get duplicate data. In order for a new transaction to update an existing one (versus creating an additional transaction), they must have the same Store ID, Terminal ID, Timestamp, and Transaction ID.

Currency Code Handling

Organizations that only transact in a single currency won’t need to include the Currency Code column in transaction files. In that case, a default currency must be configured in Admin Settings > File Upload Configuration > POS prior to uploading POS files, whereby all transactions are allocated to the specified default currency.

Organizations that transact in multiple currencies must specify the Currency Code value in each transaction file line to ensure that the correct currency gets allocated for each transaction. Note that a store can only have one currency code across all its transactions. By default, files containing a transaction with a currency that doesn’t match the store currency will be rejected. Alternatively, you can select the Change incompatible currencies to store currency option, which will update the currency for the offending transaction to the store currency, however it will not convert the values.

Direct POS Integration

If your organization uses a third party POS vendor like Lightspeed, Shopify, Vend or Square; you can easily integrate your transactions without needing to upload files from an automated system as described throughout this page.

To connect one of the listed POS vendors with your RetailNext account, navigate to Admin Settings > File Upload Access > POS. Visit File Upload Access for more setup instructions.

Additional Notes

• If you use Shopify and have enabled POS Store ID in RetailNext, load Shopify IDs as per the store's POS Store ID.  You should only need to enable the POS Store ID if you need to use a different Store ID for other integrations.

• If you use Square, you must enable and use POS Store ID in RetailNext

• RetailNext starts pulling all historical POS transaction after connecting to the third party POS platform. Note that it may take several days to catch up with current transactions.

• You may notice differences between the sales data reported in RetailNext and the sales data reported in other dashboards, like the one provided by your POS vendor directly.  There can be several causes for this, including:

  • RetailNext displays sales data for the configured store hours by default.  If transactions are processed before the store opens or after it closes, these may not be included.  Change your data query to 24 hours to compare more effectively.

  • RetailNext does not include tax when calculating sales metrics.  Some other systems may include tax.

Transaction-Level Discounts

There is currently no explicit support for specifying transaction-level discounts, but they can be inferred from the difference between the transaction total and the line items total plus tax (labelled as Adjustments in the cloud interface).

POS Exception Requirements

In order to make optimal use of the Asset Protection Dashboard, you’ll need to provide some additional transaction and line item fields that aren’t necessarily required for standard POS reporting.

The Asset Protection Dashboard analyzes three different POS exception types, where certain fields are required in uploaded POS files for each exception type and for the overall usage of the dashboard, as listed below.

General Requirements

The risk scores on the Asset Protection Dashboard, assigned to the relevant cashier, are based on the percentage of exception sales (voids and cash refunds) to total sales. It follows that the transaction file fields listed below are required to calculate all exceptions for this dashboard.

• Transaction Total

• Cashier ID

Post-Void Exceptions

A post-void is a transaction that cancels, or voids, a previously completed transaction. While post-voids may occur in the usual course of business from time-to-time, they may be worth investigating as suspicious activity, especially when occurring frequently at a store or more often with certain cashiers than others.

Post-void transactions must be indicated in the relevant transaction file’s Transaction Status column, using a case-insensitive value of post-void or postvoid. The transactions must have matching transaction ID, Store ID, and Terminal ID to be considered a valid post-void.

In the example below, the original transaction will be retained and its status will be set to post-voided.

Cash Refund Exceptions

Cash refunds are when previous transactions are partially or wholly refunded in cash. For the system to identify cash refunds and calculate those exceptions, you must specify valid values for Payment Type (in particular, cash) and Transaction Type (Sale or Return) when uploading transaction files.

Line Item Void Exceptions

Line item voids are when one or more items within a transaction, but not the entire transaction, get voided by a cashier.

Line item voids are indicated in the Void column. This column must be included and with a correct value in line item file uploads to calculate exceptions. Although required for standard POS reporting, the Item Price column must also have a correct value for accurate risk score calculations.

Appendix

Supported Payment Types

?i = case insensitive
.* = ignore anything before or after (.* represents any 0 or more characters)