Learn what's new in the 1.8.2 version of Emerald POS software for retail customers.

Version 1.8.2

October 3, 2023

Release Overview

This release includes the following information:

• New Features
• Fixes

New Features

REF 25743: Cash Office - Auto-Populate Amounts for Bank Deposit and Safe Declaration

Emerald 1.0 was enhanced with the ability to auto-populate the expected amounts in the Bank Deposit and Safe Declaration screens per tender, via configuration. The user is able to edit the actual amounts on hand when the amounts do not match the expected amount, however, do not have to enter any amounts for the ones that do match, and can submit them for approval all at once.

This enables you to settle the safe without any human errors. For example, on performing a Bank Deposit and Safe Declaration, each tender will be automatically populated with the expected amount. The user will only have to enter an amount for the ones that do not match the actual amount. The CCM/Tenders module was updated with new restrictions called: Auto-Populate Bank Deposit and Auto-Populate Safe Declaration. The configuration is only relevant to manually reconciled tenders. If the exceptions are added to a tender that is configured as ‘Auto Reconcile’, the system prompts an error.

Negative deposit amounts and negative declaration amounts are not supported, therefore if there is a negative amount and it is not edited, the system prompts an error.

REF 26004: L&P - Aggregate the Same Coupon on ULP Call to Improve Performance

Emerald was enhanced with the ability to aggregate coupons when the same type of coupon is scanned multiple times in a transaction by configuration.

On scanning the same coupon a few times, the coupons are added to one line in the request sent to the Universal Loyalty and Promotions service (ULP), which improves performance.

A new parameter called SameCouponsAggregations2ULP was added to the PromotionPolicyMaintenanceRequest RTI.

• If set to true, the POS aggregates the same coupons scanned in a row, or by quantity in one line and sent in the request to the ULP. the counter is increased to show the number of aggregated coupons.

  The POS displays the aggregated coupons in a single line on the EJ and Customer Display. When coupons are not scanned sequentially, the last coupon scanned is shown on the bottom of the EJ with the updated counter.

• If set to false, the coupons are not aggregated (existing functionality).

On voiding a coupon, the counters are updated.

REF 28295: L&P - Support Manual MFR Coupon

Emerald 1.0 was enhanced to support assigning a manual Manufacturer (MFR) coupon to an item. For example, if the coupon barcode cannot be scanned/keyed-in, i.e., the paper is torn and the retailer wishes to accept the coupon, the cashier can select the item to which the coupon applies and manually enter the coupon.

To support this feature, a new Manual Coupon wizard flow comprising 2 new screens was added at the POS.

On configuring the Manual Coupon Function in the Command Menu, the new POS screens will be displayed by default.

Once a Manual MFR Coupon is added to the transaction, the details are sent to the Universal Loyalty and Promotions service. The reward calculation is done by CENTS_OFF.

A new command called Manual MFR Coupon is added to Sales Mode and Tender Mode.

Manual MFR Coupon Flow UI

On selecting the Manual MFR Coupon command, the first Manual Coupon screen is displayed with all the items that were added to the transaction.

• The Items are displayed in a list with option buttons next to each item.
• The Action Window displays step 1 of 2.

On selecting an item, the option button is filled with a green dot.

All items from the same barcode are aggregated (if configured), i.e., if there was an item in the transaction sold by Qty, on selecting the item, the POS prompts a message that includes:

• Title: Item Name
• Text: How many items to apply coupon?
• Plus/Minus buttons to increase or decrease the qty of items to which you are applying the coupon
• OK – to move to the next screen in the flow
• Cancel – to go back to sale mode

On selecting OK, the second Manual Coupon Screen is displayed:

• Coupon value – to enter the value of the coupon
• The Action Window displays step 2 of 2
• Back – to go back to the select item screen
• Finish – to close the screen and send all the coupon details to the ULP. The CENTS_OFF are sent to the ULP with the Coupon Value and Quantity.

Once the coupon is added, it is displayed as a manual coupon (without a barcode).

The Action Window displays the related item/s and the coupon value.

REF 25959: L&P - Use the Numeric Value of a Touchpoint Group to Trigger Promotions

Currently, Emerald sends the Touchpoint Group ‘name’ to the Universal Loyalty and Promotions (ULP)/Promotion Engine in the ‘getPromotions’ request. In this version, Emerald was enhanced to send the Touchpoint Group ID as a numeric number instead of the group name.

Based on the Touchpoint Group ID, different promotions can be given by Touchpoint group.

REF 22027: L&P – Multi Cashing of Coupons and Vouchers Testing

In a previous version Emerald was enhanced with the ability to enable customers to cash in coupons and to cash multiple customer vouchers in the same transaction. For example, swap the coupon or voucher for cash.

The POS was updated with new Multi Cashing flows: cash in coupons, cash in voucher, and cash in coupons and vouchers in the same transaction. During the first phase of the requirement, the Multi Cash flow with coupons was only supported by entering the value of the coupon, even if the coupon has a predefined value since the integration for this on the ULP was not yet developed.

The NCR Advanced Management System (AMS) was updated and is now able to return the value of the coupon via the ULP eliminating the cashier prompt on the AMS.

Following the enhancement, the development, integration and testing was completed.

All business flows were validated:

• Cash in Coupons by Scanning the Coupon
• Scanning an invalid coupon – the POS does not accept the coupon and prompts a message to the cashier
• Scanning a coupon that has no value – the cashier can then enter the value of the coupon, restrictions may be prompted
• Cashing in Coupons via the Manual Coupons Option
• Scanning regular items in a multi cashing flow – the items are rejected
• Cashing in Vouchers with/without a predefined value
• Cashing in Vouchers – Manually add the Vouchers
• Cashing in both Vouchers and Coupons in the Same Transaction

REF 21479: L&P – Support Promotion on Demand using Local Segment PE (LPRO)

Emerald was updated with the option to initiate a ‘Promotion on Demand’ for specific customers (groups/segments). For example, give 10% to senior citizens, or policemen uniforms, etc.

The discount is triggered by a local segment promotion. A Local Segment is a Segment on which a promotion is given to eligible customers ‘on demand’, for example, the senior citizens. Whereas, a loyalty Segment is a segment on which the promotions are given to customers who are associated to the specific segment, for example, a customer may belong to the gardening club segment and will get promotions on all gardening equipment.

The use of a Local Segment is similar to the existing Store Coupon feature, which is activated via a ‘Trigger Code’, however, a Local Segment is not a coupon, it is displayed as a promotion on the cashier display and receipt, and not as a coupon.

The system supports ‘Local Segments’ when integrated with the NCR LPRO promotion engines.

AMS – currently, supports sending a Store Coupon as a ‘Trigger Code’ to the Promotion Engine (PE) to get the discount. It is invoked via a Command menu button on the POS, and handled as a Coupon. On selecting the button, the Trigger Code is sent to the PE, which identifies it like a Store Coupon in order to add the promotion discount. On the Emerald side, a coupon Data Pattern must be created that recognizes the coupon, i.e., Trigger Code.

LPRO – supports Promotion on Demand using the Local Segment. The Universal Loyalty and Promotions service (ULP) was enhanced to receive Local segments similar to a coupon with the special indication. On the Emerald side, the coupon Data Pattern type must be configured with the specific parameter ‘couponType = LOCAL_SEGMENT’ and a new parameter, which was added to Coupon Type data patterns called ‘Use Decoded Coupon Data’ must be set to true.

At the POS: On selecting the dedicated Command menu button, the POS sends a predefined barcode of a coupon with the couponType attribute to add the coupon via the ULP (couponType= LOCAL_SEGMENT). The ULP is then able to identify the barcode as a coupon and trigger the local segment promotion. E.g., the Command menu button to add a ‘Senior Citizens’ discount to the transaction will be linked to a barcode based on the Local Segment Coupon Barcode. Another option is to exclude discounts for 3rd party shoppers by adding special Local Segments dedicated to it.

The coupon type is displayed on the cashier display (Action zone).

A Local segment coupon cannot be added more than once in a transaction.

The option to turn on or off Local Segments in the transaction is supported via void of the coupon code (the local segment code).

NOTE:

The ULP/LPRO does not treat the local segment as a coupon, therefore, the coupon related BRMs do not support the Local Segment CouponType. It is the retailers responsibility to remove the associated coupon types from the following BRM types:

• Unused BRM condition.
• Coupon limit BRM calculation (Coupon qty)

In addition, the retailer is required to handle the following:

• Deletion of unused coupons at transaction finish.
• Remove them from the ‘Return Coupon to customer’ message at the end of transaction.
• Translation of the COUPON_SEGMENT term to the local language: e.g., ( LOCAL_SEGMENT -> Local Segment )

REF 25669: L&P – Display Shopper Points on the POS (LPRO)

Emerald was enhanced to display the correct customer icon and points balance on the POS.

Whenever a Loyalty customer is added to a sales transaction (either at the beginning or during a transaction, either as a first entry or as part of a customer switch), the correct points balance is presented on the cashier and customer display.

In cases where the points balance cannot be retrieved from LPRO, no error message is displayed and the POS continues as usual without presenting the balance.

The correct points balance is now recorded correctly in the Emerald TLog and in TDM.

REF 22764: L&P – Digital Coupon Integration with 3rd Party (Inmar)

Emerald 1.0 was enhanced to support integration with a 3rd party provider (such as the Inmar program) enabling customers to redeem digital coupons at the store after identification of their ID (phone # or loyalty card).

Inmar is a program supporting digital coupons (external coupon supplier).

NOTE:

This feature is supported when Emerald is integrated with NCR AMS/ULP (Universal Loyalty and Promotions) service and the 3rd party provider (Inmar). LPRO is out of scope. Testing of this feature is the responsibility of the PS at the customer’s site. See also, additional Known Issues, further on.

Customers must be associated to the Inmar program. All promotions that come from the 3rd party provider (Inmar) are not automatically applied to the basket. The POS sends them to the Universal Loyalty and Promotions (ULP) service for analysis (in Tender mode (total status) only) and according to the ULP response, the applicable promotions are applied. Emerald / 3rd party provider (Inmar) flow:

• The customer adds their ID to the transaction (Loyalty ID, Alternate Id (Phone).

• The POS sends an additional lookup request with the actual customer ID to the 3rd party provider (Inmar).

• Once the customer is identified, they are added to the transaction (a new dedicated icon on the POS distinguishes the addition of the customer) and they are then applicable for the 3rd party provider (Inmar program) rewards.

• The cashier scans the customer’s items and on moving to Tender mode, if the customer associated to the 3rd party provider (Inmar) is found, the following requests are sent:

  • Emerald POS sends a request to the ULP with the item basket data to get all the promotions. The response from the ULP includes all the promotions identified by the ULP.

  • Emerald POS sends a separate request with the item basket data to the 3rd party provider (Inmar) to get all the promotions. All the 3rd party provider (Inmar) promotions are returned in the response.

  • A third request is then sent with the Inmar promotions in a service called Total Recap to the ULP. The Total Recap response includes the final list of promotions to apply.

    The 3rd party provider (Inmar) can override the promotion applied by the ULP, but the final response from the ULP in the Total recap can override them again. The POS will apply the final discounts received from the ULP.

Once the POS gets the final list of promotions, the POS will send the ‘Finalize’ call to the ULP (as it works today) and an additional ‘Finalize’ call to the 3rd party.

On moving back to Sale Mode, a void request is sent to the 3rd party provider (Inmar).

3rd party provider (Inmar) promotions are captured in the Tlog as with existing promotions/coupons with a tag for the source of the promotion to distinguish between regular promotions that came from the ULP/AMS and 3rd party promotions.

Customer Lookup

Searching for a customer associated to the 3rd party provider (Inmar program) is supported as with existing functionality: Search by Alternate ID/Phone/PIN pad.

The POS sends a lookup request via the CDM (Customer Data Management) PE (Promotion Engine), and then a second request to the 3rd party provider (Inmar) using the ‘Get Promotion’ request.

A customer lookup via the 3rd party provider is based on configuration in the Customer Capture Policy).

In the CCM/Customer Capture Policy screen a new field called ‘Search customer in 3rd party systems’ was added:

• If set to Yes, the customer lookup is performed in the 3rd party system
• If set to No, the customer lookup is performed as with existing functionality, i.e., via the CDM/Promotion Engine only.

REF 25006: Sale - Ability to Key Quantity for Item Requires Quantity with Linked Item

Emerald was enhanced with the ability to capture the quantity and an item with its linked item when scanning a Deposit Linked Item type by the item code or by scanning the Deposit Linked Item barcode.

In case of a barcode linked to a linked item, e.g., a Deposit linked item type defined with a quantity greater than 1, the system restricts adding it to the transaction.

If the item is configured with the existing ‘Require Quantity Key Flag (supported by the Catalog and the POS), on scanning the barcode, the POS prompts the cashier to enter the quantity of items.

For example:

In the CCM/Product Maintenance module define a Bottle Deposit Item Type with the Restriction Type ‘Manual Quantity’ set to Yes.

At the POS:

Deposit Linked Item Scenario:

• Scan the item code. The Quantity Required screen is prompted.
• In the Item’s Quantity field enter 2 and select Approve. The item is added with the quantity of 2 and linked items with the quantity of 2.

Deposit Linked Item (Barcode) Scenario:

• Scan the item barcode. The Quantity Required screen is prompted.
• In the Item’s Quantity field enter 1 and select Approve. The item is added with the quantity of 1 and linked item with the quantity of 1

REF 28254: Sale - Calculate the Quantity Based on Amount Embedded Barcode

Emerald was enhanced with the ability to calculate the item quantity when selling or returning an item by scanning an Amount Embedded Barcode based on configuration.

The calculated item quantity is displayed on the POS and Customer Display.

Currently, Emerald supports calculating the item weight from amount embedded barcodes. When a promotion based on item weight was triggered, the Promotion Engine (PE) calculated the promotion reward based on the calculated item weight.

With this development, on scanning an amount embedded barcode and a promotion is triggered based on the item quantity, the PE will calculate the promotion reward based on the calculated item quantity.

A new parameter called CalcQtyBaseOnEmbeddedPrice was added to the SpecialPriceConfigurationMaintenanceRequest RTI.

REF 25890: Sale - Enhance the Display of Price per UOM for Embedded Price Barcodes (EJ, CD, Receipt)

The ability to display the item price per Unit of Measure (UOM) for weight items with price embedded barcodes is now determined by configuration.

Configuration is supported via the CCM UI and RTI mechanism.

This applies to the display on the POS EJ and Customer Display, in the Action Window, and how it is printed on the receipt.

The CCM Office Client/Touchpoint Behavior module was updated with a new parameter called ‘Display Embedded Price Per UOM On Ticket Zone’ to determine if the price per UOM is displayed when a weight item with a price embedded barcode is scanned.

• If set to Yes, the price per the UOM is displayed (existing functionality)
• If set to No, the price per the UOM is not displayed.

The parameter was also added to the existing TouchpointGroupConfigurationMaintenanceRequest RTI.

In the CCM/Receipt Template module, two new receipt templates were added to the Items section with the following line definitions:

• Weighted Item Barcode Embedded UOM Line Definition
• Price Override On A Weighted Item Barcode Embedded UOM

The Templates are part of the Default Layout Template.

This is supported in both sales and return transactions.

REF 26061: SCO, LEB - Add Sequence ID for Items

Least Expensive Brand (LEB) policies is one of the ‘Item Selection Practices’ used by WIC agencies to control the costs of WIC food items.

Emerald was enhanced to support selling LEB items on the Self Checkout (SCO).

Currently, when a customer swipes a WIC Card at the POS, the POS sends the item codes of all the LEB and NON LEB items in the transaction in the PreTenderAdd response. Only after an item is selected as a LEB, the POS sends the item Sequence Id for the selected item in the PreTenderAdd response.

The SCO requires the Item Sequence Id of all the items in the PreTenderAdd response, and not only the selected items.

A new element called ‘SequenceNumber’ was added to the RedemptionItem element in the PreTenderAdd Response and the value is the item's sequence number in the transaction.

REF 25220: Fuel - Support Customized Deferral Message for Using Loyalty Points – Prepay, Postpay and P@P

Emerald was updated to display an enhanced message for customers before they decide to use their loyalty points to redeem discounts with their loyalty points that are about to expire.

Currently, Emerald supports displaying deferral messages, displayed on moving to Tender mode. Till now, when customers had available points that entitled them to fuel Cents Per Gallon (CPG) discounts, the message was a simple Yes/No – “Would you like to use your loyalty points to receive CPG discounts”.

With the development, the message is more specific for each customer. It will contain dynamic values according to the specific customer rewards and discounts.

Three changes were made to support this feature:

• Emerald FuelPOS - Emerald is now able to display the deferral popup message with a ‘Dynamic Message’, i.e., it can include the number of points and the points that are about to expire.

  The content of the message is taken from the response sent by the ULP under the 'Notifications' Value.

  It is the responsibility of the ULP/AMS to define the message. The POS displays the text ‘as is’.

  This applies to Prepay and Postpay transactions.

• The NCR AMS/ Universal Loyalty Promotions (ULP) was enhanced to create a dynamic message

  NOTE: Emerald is dependent on the completion of development on the NCR AMS/ULP.

• The data for the new dynamic message is sent to the Fuel Server. It is the Fuel Server’s responsibility to display the message on the pump during the Pay at Pump transaction once a loyalty card is added.

REF 23307: Fuel - Support Using Loyalty Alternate ID (Phone Number) at the Pump Terminal

Emerald was enhanced to support the option to enter an ‘Alternate Id’ at the pump to apply a loyalty account without having to present the loyalty card.

The Fuel POS sends a request to look up the Alternate Id.

For example:

• The customer approaches the pump to perform at Pay At Pump (PAP) or PAP to PAK.

• The customer selects the ‘Use alternate ID’ soft key on the pump terminal.

• The customer then enters their alternate ID (E.g. phone number) and approves. The Fuel Server sends the alternate ID to the Emerald Forecourt client.

• Emerald sends a request via the ULP with the ‘alternate ID’.

  If the customer is identified:

  • Customer account is applied by the Promotion Engine (AMS / LPRO).
  • Loyalty discounts are applied to the transaction as with current functionality.

  If the customer is not found:

  An applicable message is displayed on the pump terminal for invalid customer (not found).

NOTE: It is the Fuel Server’s responsibility to add the soft key, which triggers the screen to enter the loyalty alternate ID on the pump terminal and for sending the Alternate ID under the ‘rewardServiceRequest’.

REF 28203: Fuel POS – EPS Timeout to be Handled by S&F Mechanism

Emerald was enhanced with the ability to clear Prepay transactions that were closed as unbalanced transactions and were not able to be completed back at the Fuel POS. This enables the cashier to proceed with the next transaction.

With this enhancement, after a failure, the following occurs: the POS is released from the unclosed transaction, the POS sends a ‘Clear’ request to the Pump to release it, the pump on the FuelPOS shows as free, and the unclosed transactions are handled by a new internal process.

The internal process supports a new transaction ‘State’ for failed transactions with the action ‘Prepaid On Failure pending for resolving’ called ‘Pending for Retry’. The system tries to solve the issue 5 times (configurable).

The existing ‘Schedular’ that handles all transaction states in the Forecourt/FuelPOS was updated with new parameters to handle the new ‘Pending for Retry’ state:

• #Limits – defines the number of times the system will try to close the failed transaction
• #Next Time Running – defines the number of times the schedular will run.

Once the Schedular runs a request is sent via a new RTI called PendingForRetryLookupRequest.

This service retrieves the failed transactions from the Retail database with the state ‘Pending for Retry’ and a Counter with less than the defined value in the #Limit parameter and tries to finalize the transaction again.

• If the ‘Finalized’ transaction fails again, the counter is incremented by 1. A reason is added to the ‘Additional Data’.
• If the ‘Finalized’ transaction succeeds, the Tlog is created, and the transaction state is updated to Finished.

REF 25221: Fuel – Receipts for Loyalty Transaction Needs to Show Additional Loyalty Information (Prepay, POST pay)

Emerald Fuel receipts (Pay At Pump, Postpay, and Prepay) were updated for loyalty customers to include additional information, such as beginning point balance, earned point balance, etc.

The information is added to the loyalty receipt information buffer returned from the AMS (promotion’s application) using the ULP (Universal Loyalty and Promotions) API, printed on the POS receipt, and also sent to the Fuel Controller for it to be printed on the receipt at the Pump terminal.

A new receipt template called Member Account Details was added and includes the following parameters:

• Title text : Member account details
• Member name ( from printabledata)
• Beginning point balance ( from ReceiptMesages)
• Earned point balance (E.g. points earned as a result of the current transaction being printed)(from ReceiptMesages)
• Points redeemed – Points that were redeemed as part of the transaction being printed. For example as a result of utilizing points to be redeemed as CPG discount( from ReceiptMesages)
• Points Total – Total number of loyalty points in the applicable account( from ReceiptMesages)
• Expiring DD/MM – Points to be expired by end of the current calendar month( from ReceiptMesages)
• Member ID ( from Printabledata)

REF 25734: Fuel – Prepay Preauth Completion when No User is Signed in to the POS

Emerald was enhanced to enable prepay transactions that were paid for with cards to be closed, i.e., payment complete, even if there is no user signed into the POS.

The ability to complete a preauth even in cases where there is no user signed in to the POS terminal was added.

Till now, when integrated with the Connected Payments EPS, fuel prepay transactions paid with cards are settled by the POS terminal that created the preauth.

The preauth is closed automatically using a scheduler whenever the POS has a user signed in to the POS and the POS is in one of the following states:

• POS is in idle mode (between transactions)
• POS is locked but a user is signed in (E.g., locked, but not signed out).
• Before EOD

Whenever there is no user signed on to the POS (having an open shift) the prepay closing scheduler does not process transactions and the transactions with an uncompleted preauth wait in the queue until a user signs into the POS.

This scenario can create a delay, for example, if a card prepay transaction is being fueled after the POS EOD and when the user signed out and left the shift. In this case, the transaction is settled and the preauth is only completed when a new cashier signs in to the POS on the following day.

With this enhancement, the POS scheduler will render the preauth completion with the EPS using the cashier ID that opened the transaction and for which the preauth was recorded.

REF 28175: Fuel – It is Required to Perform Changes to Fuel Base Configuration RTI as per Customers Feedback

The Emerald Fuel Base Configuration was updated.

In the FuelConfigurationMaintenance RTI (035.FuelConfig) the following changes were made: The value of the following element was changed from Forecourt to POS, since most customers use Connected Payments and the most common automatic completion domain is POS and not forecourt: POS.

The value of the following element was changed from ‘Empty’ to a default off 33, and customer’s now no longer need to update the Tender Id individually: 33

The Tenders were updated with a new TenderMaintenanceRequest RTI with a new Tender ID 33.

The Tender name is set to ‘Pump Overrun’ and set as auto-reconciled under the Tender type: cash.

REF 25916: Tender, Check, BRM - Enhance Soft Decline to Display Error Codes in the Velocity Report

Currently, Emerald supports an option to view check payment velocity at the POS. Based on this information the manager can decide if to approve or reject the acceptance of a Check in the case of a soft decline. When a Check is soft declined by the provider, the response to the authorization request is No, and the BRM is triggered. If there is Check velocity information returned from the provider, the Additional Info button in the BRM prompt is active. On selecting the Additional Info button, the velocity data is displayed on the POS.

The Additional information screen was updated to now display the error codes and messages received in a Tender Soft Decline response received from the Check Validation service.

This feature enables the manager to review the error codes and messages in the Tender Soft Decline response before deciding to approve or reject the BRM.

REF 25773: Tender Exchange – Gift Card Cashout

Emerald was updated with the ability to limit the cashout amount of Gift Cards.

The Tender Exchange module supports a Cashout option and a Minimum Amount and Maximum Amount field for Tender Exchange limitations. Till now, when a Gift Card was configured to allow Cashout, the Minimum Amount and Maximum Amount fields were disabled.

The Minimum Amount and Maximum Amount fields are now enabled for Cashout enabling the system to validate the balance of the Gift Card against the limitations.

To support this option on configuring the min/max limitations, during a Gift Card Cashout flow, a Balance Inquiry is run and a validation is performed behind the scenes.

• If no limitations are defined, the full amount is cashed out.
• If the limitations are defined, and the maximum amount is higher than the Gift Card balance, the POS will cash out the Gift Card balance.
• If the Gift Card balance exceeds the limitations, the Gift Card cannot be cashed out.

REF 28195: Certify Infrastructure .NET Framework 4.8

Emerald was certified with Microsoft .NET Framework 4.8.

REF 25808: Supportability - Ability to Export Store Configuration

Emerald was enhanced to support exporting store configuration. Till now, only CCM configuration could be exported.

The Store configuration is exported as RTIs in the same format (CSV Files) and naming convention as the exported CCM configuration. Once the export is successfully completed, a zip file containing the RTIs is created and saved on the Store server.

This enables retailers and support teams to compare the exported Store and CCM configuration more efficiently, especially when checking for configuration changes that may cause issues, for example, if the retailer has modified the configuration for a specific touchpoint in the store.

The Store Office client was updated with the Export Configuration module.

REF 26142: Tax Exemption - Trigger Exemption by Barcode

Emerald was enhanced with the ability to exempt tax by scanning a tax exemption barcode.

The CCM/Data Patterns module was updated with a new data pattern type called Tax Exemption. When a taxable item is added to a transaction and a tax exemption barcode is scanned, the system validates the barcode, and if valid the tax is automatically exempted.

The tax exemption barcode can be scanned in both Sale and Tender mode.

If a valid tax exemption barcode is scanned in Tender Mode, the POS moves back to Sale Mode and the tax is automatically exempted.

If the tax exemption barcode is invalid, e.g., the barcode has expired, an error message is prompted ‘Barcode Expired, Please scan a valid one.’

The Tlog was updated to capture the customer’s tax exemption details.

REF 28193: Map IsDepartment and IsDepartmentSale Columns in CAT_Hierarchy from CAT_Department - Upgrading to 1.7.2

Emerald was enhanced to map the IsDepartment and IsDepartmentSale columns in the CAT_Hierarchy and CAT_Department tables when upgrading to version 1.7.2, to allow retrieving departments when a Department Lookup is performed.

The mapping is based on matching the Id column in the CAT_Hierarchy table with the Department_Id column in the Cat_Department.

• The CAT_Hierarchy's IsDepartment column is set based on the CAT_Department's record with the Cat_Hierarchy Id.
• The CAT_Hierarchy's IsDepartmentSale column is set based on ‘Disable’ set to 0 (i.e., enabled) in the Cat_Department column.

NOTE: The mapping is executed during an upgrade when the IsDepartment and IsDepartmentSale columns do not exist.

REF 26243: Catalog Subscription Integration

A proof of concept was proposed to avoid frequent polling of the catalog by listening on the catalog notifications regarding batch ingest completion.

The idea behind it is that by waiting for a notification, Emerald will only send a request for a snapshot after the batch is fully processed. See the details in the Price Notification Service integration feature below.

REF 26242: Price Notification Service Integration

Emerald 1.0 is currently integrated with the Catalog and updates are handled via a polling approach. The snapshot API is called periodically with the last received nep-snapshot-version to obtain any new updates. The provided snapshot specifies a "snapshotVersion" that should indicate the "last" document updated, however, it is not guaranteed that all updated entities that are below this version are actually returned. The end result is that some times many updates are missed and do not get to the stores, which is critical for prices.

Emerald 1.0 was enhanced with a new solution for item price updates only. Once a batch update is fully processed, the Catalog sends a notification to Emerald, which calls for a snapshot version. The polling of the catalog will no longer be defined to run frequently, instead, it will be pre-defined, i.e., every 3 hours. And, a ‘look back’ will be run based on a new lookback policy. The lookback policy enables the Catalog to provide any missed updates. The lookback functionality is an update up to the last timestamp moved back by 20 minutes.

For each new snapshotVersion, a one time snapshot with the timestamp moved back by 20 minutes (configurable) is performed. This is done only once, to prevent sending data over and over again.

For example:

For each new snapshot version, the system takes the version, e.g., 1686628438520 last updated on ‘2023-06-13T03:58Z and performs a one time snapshot with the timestamp moved back by 20 minutes.

For each 3 hour snapshot API polling, the look back is performed from the last time stamp - comparing between the last timestamp and the current one.

REF 26043: Catalog: Increase Catalog Poll Timer to Reduce Calls (Base Configuration)

Emerald supports a Catalog refresh mechanism, which is activated according to a Poll timer. The Poll timer is used by the CCM/StoreServer to check if there are new prices in the catalog ready to be downloaded to the store.

The Poll timer is controlled via a system parameter in the DataTransportationConfigurationMaintenance Request RTI called DownloadDelay. The Base Configuration was updated to include the parameter.

This is only relevant to the Store Server and CCM.

REF 25877: Update Transactions TDM Upload Mechanism to Prevent Unlimited Uploads of the Same Transaction

The TDM upload mechanism was reviewed and improved to avoid situations in which the same transaction gets uploaded to the TDM more than once.

In some cases, failure to upload transactions to the TDM causes unlimited attempts to upload the same transaction again. The Cloud TDM has the ability to ignore duplicate requests, but it creates unnecessary loads and increases Cloud costs.

To solve this issue, the TLOG is now uploaded to the TDM upon successful completion of a Unit Of Work.

REF 24799: Compliance with Changes with WIC EBT Operating Rules [Oct-2023]

Emerald now complies with WIC EBT Operating Rules 2023. No changes were required.

REF 25843: Tender, Check: Enhance Check Cashback API on Payment and Tender Exchange

The Cashback API for check payments for Cashback and Tender Exchange was updated to enable the POS to send the correct Merchandise, check, and cashback amounts to the iEPS.

This feature is supported by Connected Payments, FiPay, Epsilon, and Aurus.

Till now, when paying with a check in a Cashback or Tender Exchange flow, Emerald reported the cashback amount in the Merchandise amount field sent to the EPS. As a result, the cashback amount was not recorded correctly.

A new parameter called EccCheckOverTenderAsCashBack was added to the existing EpsConfigurationMaintenanceRequest RTI.

• If set to true, when performing check payment with over-tender (amount higher than the amount due), the POS sends the payment amount and the Cashback amount to the iEPS.
• If set to false, when performing check payment with over-tender (amount higher than the amount due), the POS sends only the check amount to the iEPS (existing functionality).

Based on the configuration, Emerald now sends both the check purchase amount and the cashback amount in the cashback request sent to the iEPS.

• On performing a Tender Exchange for a check payment, the POS sends the purchase amount is 0, and the check/Cashback amount (check amount=cash back amount) to the iEPS.

  If a ECC check is used in the Tender Exchange, and the ECC conversion fails, the POS processes the check with the correct amounts received from the iEPS.

• On performing a Cashback, the POS displays the Cashback amount in the message prompted when closing the transaction.

• On endorsing a non-ECC/Manual check, the correct Tender and Cashback/Change amounts are printed on the check.

The iEPS report and Tlog were updated to capture the correct Purchase and Cashback amounts.

REF 26106: Support Multi Tender Exchange with Coin Dispenser

Emerald supports the option to perform a Tender Exchange with multiple tenders using a coin dispenser. For example, the customer can cash multiple coupons and/or vouchers in the same transaction and receive cash in return. The change can be dispensed via a coin dispenser.

Till now, a Multi Tender Exchange Transaction was supported without a coin dispenser. Once the coin dispenser is configured, when the target tender is Cash, the POS dispense the coins change from the Coin Dispenser. The Coin dispenser supports dispensing change in coins when a Multi Tender Exchange transaction is performed for all supported tender types, i.e. Multi-coupon, multi-vouchers, and more.

The Tender Exchange message prompted at the end of a transaction now supports display for multiple tenders being exchanged for Cash, as opposed to a single tender.

As with other flows when using a coin dispenser, in a flow with a malfunction on the dispenser, the change can be given from the POS drawer.

The existing Tender Exchange configuration is supported (CCM and RTI mechanism).

REF 28463: WIC – Enhance Selection of Items when the Basket is Over the Size Limit

Currently, Emerald 1.0 supports the WIC limitations to limit the number of WIC items in a transaction. If the transaction contains more items than the defined limit, on swiping a WIC card, an error is prompted with a generic message prompting that items must be voided to complete the transaction. On closing the message, the WIC eligible items are displayed on the POS with a green checkbox and the least expensive items are automatically displayed unmarked.

In this development, on scanning WIC items and swiping a WIC card, if the WIC limitation is exceeded, once the error message is prompted, all the eligible WIC items that were scanned are now displayed on the POS marked with a green checkbox, but the least expensive items are no longer unmarked. The cashier can then manually select the items that are not wanted and can void them.

REF 28592: Tender, Check – Shopper Details - Add the Ability to Disable Manual Entry of a 'Driver License'

Emerald was enhanced with the ability to disable the ‘Driver’s License’ button on the Shopper ID screen on the POS.

A new system parameter called DisableDriverLicenseManualEntry was added:

• When set to true, the Driver's license button is disabled on the Shopper ID screen.
• When set to false, the Driver's license button is enabled on the Shopper ID screen.

If the parameter is not set, the Driver's license button is enabled on the Shopper ID screen.

REF 28210: Supportability – Enhance Log Collector

The Log Collector is designed to auto detect all Emerald applications that are installed on the system and allow customer support teams to manually retrieve logs pertaining to specific issues within a certain time window. The user can select the applications from which logs are collected, the time duration for collecting logs, capture screenshots from any open application, collect Event logs, etc.

The Log Collector can integrate and execute remotely through a script, operating inconspicuously in the background. It compresses the logs into a zip file, incorporating the date, time range, and machine name, while offering the option to automatically upload logs to the NCR cloud storage.

In the first phase of this development to enhance the log collector, the current log collector was enhanced with an option to run it in ‘Silent Mode’ by a remote user and then be able to send the zip file to be uploaded to the server.

The Log Collector Tool must be part of the installation and it can only be run exclusively.

To verify that the log collector is running exclusively:

The Log Collector project is located in the following workspace: C:\Workspaces\STS_Trunk\Tools\LogCollectorTool\Emerald.Tools.LogCollector

• If an instance is already running, another instance is not allowed.
• If the user tries to open another instance, an error message is prompted: ‘Another instance is already running’

Locking

Logs are collected even when the POS application, server and office are running in the background. There should be no locking issues.

Executable Inclusion

Verify that (LogCollector.exe + dll) are included as a part of the CCM, STS and POS msi.

The executable must be available under the following path:

• CCM - C:\NCR\CCMWebServices\Server\PosService\Tools\LogCollector
• STS and POS - C:\NCR\StoreServices\Server\PosService\Tools\LogCollector

The user is able to access the tool after the CCM, STS and POS installation.

NOTE: The Assembly name was changed to "LogCollector.exe" from "Ncr.Emerald.Tools.LogCollector.App.exe". Due to this change in the application type from Windows to the console, a command prompt will be opened at the backend when the tool is launched. It will be auto hidden at the back of the tool.

Running the Log Collector Tool in Silent Mode

Once the log collector run, the logs are saved in a zip format.

The following commands are supported (see Commands Example further on):

• Sample Arguments - LogCollector.exe /s components: All duration:48 eventlogs:true file:Filename
• s - Runs the application in silent mode.
• components - Specifies which component logs is to be collected. By default, all components will be included. The possible values are: All, CCMManager, CCMServer, StoreManager, StoreServer, POSClient.
• duration - Specifies time interval. By default, 48 hours (about 2 days).
• eventlogs - Contain logs for Application, System and Emerald. Each will have its own file.
• file - Enables the user to select their desired file name.

Command Example c:> LogCollector.exe /s components:All duration:48 eventlogs:true file:Filename

NOTE: LogCollector output type will be changed to Console application from windows application. By default, file name will be LogCollector. User can change to desired file name. Example - file:LogStoreCollection.

The log zip file is available at C:\Users\%USERNAME%\LogCollectorArchive\filename.zip.

For Example: C:\Users\qa\LogCollectorArchive\LogCollector_22-08-2023_09-56-23_Duration_1920mins.zip

The logs are collected in silent mode even when the POS application, server, and office are running in the background to make sure that there are no locking issues.

Once the log collection file is successfully completed, the command prompt displays a success message:

0 – Logs collection successful, file name and location.

For example: Successful message - Logs collection successful. LogCollector_22-08-2023_09-56-23_Duration_1920mins.zip available at C:\Users\%USERNAME%\LogCollectorArchive

If the log is not successfully created, an error message is prompted: ‘Logs collection unsuccessful. Please visit help section.

If an invalid component (Ex-StoreServerrr) is passed, an error response of 1 is sent and the logs collection unsuccessful message is prompted.

REF 28550: Business Rules – Service to Purge the Intervention List

Emerald 1.0 was enhanced with a new service on the POS Server to purge the Intervention List for items that were approved resolved or canceled. The service is called DeleteScoInterventionsService.

This was done to prevent the delay detected on reenabling the scanner and moving back to Sale mode after selecting the ‘Close’ button in the Intervention List view.

REF 28568: Business Rules – Refactor Delayed Coupon BRM to Improve Performance

The Delayed coupon Business Rules (BRMs) was refactored to improve performance. On selecting the Resolve all option to resolve all delayed coupon BRMs at once, the response time is now quicker.

REF 28551: Add Entry Method with Shopper Details Call

Emerald currently supports a Shopper ID flow, during which the shopper’s details must be captured.

A new entry method was added to pass the ShopperDetails to the EPS provider.

• When the driver's license is scanned, entry method is Scanned.
• When the details are entered manually, entry method is Manual.

Resolved Issues

The following defects were fixed in this version:

• TFS28743 Log Collector – the build server was not able to execute post build events.
• TFS28725 The image was not displaying the customer icon in the CCM office.
• TFS28723 The Local Segment was voided in the Tlog, and crossed out at the end of the transaction on the POS.
• TFS28715 Print label was not working and the price was not updating correctly for weight items on the customer scale touchpoint.
• TFS28707 The Emerald POS did not send the Inmar adjustments that were applied with Inmar Coupon Ids in the Finalization Request to the Transaction Orchestrator. Therefore the coupon redemptions were not getting finalized in Inmar.
• TFS28704 The unit test failed in Trunk ExecuteManualCouponCommand()
• TFS28700 If the POS returned from ‘Payment’ to Itemization and a pre-swipe was done, it displayed the previous balance in the ‘Payment Card Confirmation’ screen.
• TFS28682 Scanning of a paper Gift Card was not working in a Gift Card Cashout with limits.
• TFS28651 In the Login screen, when pressing 'Enter' after applying the User Name, the active field did not move to 'PIN'.
• TFS28650There was an Unhandled Exception on scanning an alphanumeric Alternate ID.
• TFS28647 The Promotion was not showing on the POS client even though it was in the response of the TransOrch.
• TFS28646 OrderTotals were not sent in the interface request to the 3rd-party.
• TFS28634 Totaling a transaction with a customer lookup using an AlternateID (phone number) showed a deserialize exception in the interface response.
• TFS28628 An unhandled exception is occurred when the loyalty card details were entered for an Age verification BRM.
• TFS28624 GS1 barcodes were not working with the amount embedded feature.
• TFS28566 The POS did not display a deposit item price separately in the Price Query screen when a price query was set as Splitted(Splitted)
• TFS28565 On scanning an amount embedded barcode embedded item for which the quantity should be fractional, the fraction should have been rounded up to the nearest whole number and should have been displayed in the ticket zone and action zone.
• TFS28564 On scanning an amount embedded barcode embedded item for which the quantity should be fractional, the fraction should have been rounded up to the nearest whole number and should have been displayed in the ticket zone and action zone. (Sale and Returns)
• TFS28554 It was not possible to perform a Gift receipt scenario by customer details on the POS.
• TFS28538 The Loyalty Server was off while scanning a loyalty card at the Pump.
• TFS28536 The Total Amount and Total Amount values were wrongly printed on the ECC check endorsement.
• TFS8526 It was not possible to add an MFR coupon in a multi cashing and coupon cashing screen (tender exchange).
• TFS28506 Emerald services failed to restart due to an IISRESET.
• TFS28505 The Cold Start execution on Store server failing was fixed.
• TFS28496 Emerald 1.6.416: there was no way to exit the transaction/void the transaction when refund tenders were used out of order.
• TFS28480 It was not possible to perform a return with a TBR for Price embedded weight items.
• TFS28479 UI automation coverage.
• TFS28478 Cash out of a Gift card in fuel was fixed.
• TFS28475 Emerald Logs Collector tool – there were exceptions during log collection.
• TFS28472 UI automation test for 28295.
• TFS28464 In a Fuel-Prepay Transaction with change, the finalize tenders were calculated incorrectly.
• TFS28439 FCL Emerald 1.6.416: the PIN pad showed 'REFUND' in an Exchange transaction where there was a balance due (i.e., positive amount).
• TFS28423 After a void of a sale item, the Sale' starburst icon was still displayed.
• TFS28422 Emerald v1.8.100 vs v1.7.204 – Cold start failed between the Upgraded CCM server to Store server 1.8.101, which was installed from scratch due to a new column order scratch.
• TFS28415 Fuel – the Forecourt loaded with the default Port 8888 of the Epsilon EPS, but did not read the configuration from the POS.config.
• TFS28374 sWIC did not work on the Fuel POS Touchpoint. It prompted a ‘General error occurred’ message when tendering.
• TFS28372 UI Automation coverage.
• TFS28368 There was a 'Communication Failure' on the Fuel POS when trying to pay a Prepay for more than the balance due (Change).
• TFS28358 Loyalty Member details were not displayed on the receipt when we added loyalty at the Pump.
• TFS28352 Tender Exchange transactions were stuck in the TenderExchangeRefundView after a POS reboot or lock.
• TFS28334 T-Log – the embedded price per UOM was not reflected in the Tlog.
• TFS28311 While all BSL Services were down (specifically the CDM), there were some lanes at which it was not possible to scan items.
• TFS28294 Item / bag was not getting added to the cart after entering a qty in the popup for items with an additional code.
• TFS28292 The Cashier Message Reward was not displayed on the POS.
• TFS28291 Weight Items and Qty Required Items were printed twice on the Return Receipt.
• TFS28285 The cashier was not informed that the Promotion Engine was not available in 1.7.301.
• TFS28261 FCL Emerald 1.6.413: a Gift Card that was activated with Cash prompted an "activation failed" error message, even though the gift card was activated.
• TFS28253 FUEL POS – An incorrect item quantity message was prompted when the customer was using the PIN pad.
• TFS28247 The Cash tender suggested amount was not appearing.
• TFS28232 Loyalty and Non Loyalty info was not displayed on the Receipt when we configured Loyalty or Non Loyalty Prices for weight items.
• TFS28227 There was a POS Unhandled Exception error after the 1.7.301 CCM Upgrade.
• TFS28224 Fuel : the Account Number was missing in the RewardServiceResponse for a Pay at Pump transaction with an Alt-ID as the entry method.
• TFS28204 MenuConfigurationLookup was running every 15 minutes and caused the ClientBusinessFlows log files size to increase drastically (17mb each)
• TFS28199 UI automation coverage.
• TFS28196 1.7.3 – UI Automation – a new Department sale was not showing.
• TFS28190 UI Automation - a Special item test case was included under the performance server.
• TFS28185 The Emerald Server Log Level was Debug, but should have been Error.
• TFS28184 Emerald Client Logs were not saved after a rotation, which left only several minutes of log available for the entire working day.
• TFS28182 The Emerald Log file Retention Policy was not running according to the config file.
• TFS28181 Emerald ClientBusinessFlows Logs had missing time gaps intermittently.
• TFS28180 Emerald ClientBusinessFlows Logs had missing time gaps intermittently
• TFS28179 The Total WIC balance amount was incorrect when a partial weight LEB item was added to the Transaction and the WIC basket was triggered.
• TFS28176 A Pre Price Override caused duplicate BRMs (PriceOverrideMaxDiscount) to be triggered.
• TFS28116 The Sidecar 'Tab' button did not work in the manual check screen entry.
• TFS26263 The Pos Client was stuck with a "Processing ..." message after the error message of the "Max Allowed Amount" BRM for the check tender was closed.
• TFS26257 Emerald logs were not saved for more than a single day.
• TFS26239 It was not possible to add a partial tender to a prepay transaction in a fuel pre-pay causing the tender amount to be set to $0.
• TFS26162 There was an unhandled exception in a Prepay while trying to pay more than the Total amount by Visa and the configuration of the Visa was Open Amount without Change definition.
• TFS26161 In a Prepay that was paid for by Cheque and Cash was given as change, the Paid Out cash amount should have been created in addition to the Paid In of the Cheque (when configured: 'false'
• TFS26160 In a Prepay paid by EFT with an amount that was greater than the Total amount (i.e., Cash Change was returned to the customer ), the Paid In / Paid Out should have been created with the tender ‘cash’ and the correct amount.
• TFS26139 UI Automation – For the Deposit item (item 20) the Price Query description was wrong.
• TFS26133 It was not possible to Perform a receipted return for an amount embedded item with $off per LB.
• TFS26119 In a split Prepay of Visa and Cash, the change was recorded on the Visa instead of the Cash.
• TFS26117 UI-Automation - Fuel POS – (display price per UOM /Sale transaction/New promotion display) The Chocolate Chip Cookies line data was missing from the customer display.
• TFS26086 1.8.1 – UI Automation: the ‘Description’ was missing when performing an ItemLookUp.
• TFS26083 LEB Support “TouchPointType=SelfCheckOut
• TFS26060 Fuel Pos – during testing on the POS, the Tender menu did not allow the user to navigate tenders and we could not continue with the payment.
• TFS26041 An additional Age verification was not working as expected.
• TFS25750 CCM - Export Configuration did not export all the configurations.
• TFS25704 From 1.7.1 to 1.7.3, there were Emerald upgrade issues.
• TFS25126 The unit test failed on DateTimeDataPatternExtractorShould (on both the CCM and Store)
• TFS25037 Tender - Age verification - Tlog - the field PolicyRule with attribute EntryMethod was not constant.