Emerald POS Release Notes v1.6.4
Learn what's new in the 1.6.4 version of Emerald POS software for retail customers.
Version 1.6.4
January 17, 2022
Release Overview
This release includes the following information:
- New Features
- Fixes
New Features
REF 515601: Sale: Display the Price per UOM to the Customer and Cashier when Selling/Returning Weight/Quantity/Volume Item (Phase 2)
In Phase 1 of this development, Emerald was updated to display the price per UOM next to the item on the item line in the Ticket Zone on the POS and Customer Display for sales of items sold by unit, weight, linked tare.
The Price/UOM is the net price of a unit. This enables the cashier and the customer to view the cost of a single unit of the item sold.
In Phase 2, Emerald added the following:
- Display Linked Bottle Deposit and Warranty Items with Price Per Unit on both the POS and Customer Displays.
- Display Returns (Return Item and Return Transaction) with Price Per Unit on both the POS and Customer Displays.
- Display Fuel Sale Items with Price Per Unit on the Customer Display. The display is controlled by configuration of the 'Display Price Per UOM On Ticket Zone' parameter in the CCM/Touchpoint Behavior module, which was added in Phase 1.
REF 515641: POS Report Tenders Expected Amount
Emerald was updated with the ability to print a report at the POS that provides the expected 'on hand' amount for all tenders for the lane. This enables the store manager to perform a spot check and validate that the correct amounts of each tender is in the specific drawer at that point in time, or when a cashier completes a shift and hands over the drawer to a new cashier, they can print the report to verify the amounts in the drawer are correct.
The feature is supported by a new function called 'Tender Amount Report' available at the POS.
At the POS, the new 'Tender Amount Report' command was added to the No Sale Mode.
A new Receipt called Tender Amount Slip was added to print the POS tender total amounts and counts. When invoked, it sends a request to a new service called TendersExpectedAmountsReport, which retrieves the POS Tender Total Amounts, activity count, and prints the information on a new Tender Amount Slip.
REF 420547: Tare: Provide the Ability to have Proportional Tare Weight for Individual Wrappers
There are items, e.g., candies that are sold in individual wrappers. Such items are typically sold by weight and not eaches. In addition, the candies in the individual wrappers may be sold by weight in a box.
Emerald currently supports calculating Tare weight for items with packaging, e.g., a box, container, etc.
The ability to calculate the Tare percentage of all the individually wrapped units was added. Emerald is then able to calculate the net weight after reducing the tares and the customer is only charged for the product and not the container or the wrappings.
To support this feature, Emerald receives a new field called Tare Percentage from the BSP/Catalog, which determines the Tare Percentage. The tare percentage is a predefined percentage by which the system calculates the percentage of the total weight of the individual wrappers of a weighed item, which is then reduced from the item weight to calculate the price.
If the individually wrapped items are sold in a container, the item can have two tares, the percentage tare for the individually wrapped items and the tare for the container. The calculated weight of the individual wrappers is displayed on the POS.
The option is supported in sales and returns.
REF 397738: Fuel/Tax: Support Fuel Tax for Canada (Inclusive and Exclusive in the Same Transaction – Phase 2
Today, Emerald already supports Canadian Taxes and complies with the Canadian regulations.
In phase 1of this development, Emerald was updated to support Canadian tax regulations for Prepay Fuel Sales taxation. Fuel item prices are tax included, whereas dry items are tax excluded. To support the Canadian Tax regulations for Fuel Sales, Emerald was updated to support tax inclusive and tax exclusive items in the same transaction. The transaction calculation supports a mix of both methods. The individual tax rates can be printed on the receipt and captured in the Tlog.
Items can be associated to more than one tax rate, however, the tax rates associated to an item can be either inclusive or exclusive. You cannot have a mixture of inclusive/exclusive tax rates on the same item.
In Phase 2, the functionality was applied and tested in the following flows:
- Canadian Fuel Tax in PAK mixed tax inclusive and exclusive items
- Canadian Fuel Tax in PAK mixed tax inclusive and exclusive items with Tax Exemptions
- Multiple inclusive Fuel percent taxes for Prepay transactions
- Multiple inclusive percent taxes for PAK transactions
- Multiple inclusive percent taxes for Manual Fuel Sales.
- Multiple inclusive percent taxes for dry items at the POS.
- Multiple inclusive percent and fixed tax rates
REF 444608: Fuel/Tax: Receive Taxes from Fuel Controller in PAP (Carwash and Fuel)
The interface between Emerald and the Fuel System was enhanced to enable Emerald to capture the correct tax information in the Tlog for Pay At Pump (PAP) flows when selling fuel items and carwash items at the pump.
This feature was done in conjunction with the development to support Canadian Tax regulations for Fuel Sales where the Fuel system needs to support tax inclusive and tax exclusive items in the same transaction.
The tax calculations are done in the Fuel System and only sent to Emerald to process the data, which is translated into an Emerald Tlog. The tax calculation done on the Fuel must not be altered.
A development was done in parallel for the RPOS based Fuel Forecourt Controller Ref # RPOS-35599.
If the taxable amounts are not supplied by the Fuel System in the buffer, it will be documented as the difference between the inclusive sale price and the taxes aggregated amount.
REF 520702: Fuel: Trigger Cents Off Discounts Promotion Using Dry Item for Supporting Zipline Tender Discount (Pay At Pump Only)
Emerald was updated to support 'Cents Off' discounts when customers use a 'Zipline' tender at the pump in a Pay At Pump flow.
Zipline is a 3rd party loyalty program with payment that provides customers with a card that provides discounts.
If the customer swipes a Zipline card at the pump, the Fuel Controller adds a trigger item, which is a dummy item (price is 0) used to trigger the 'Zipline' discount. Emerald then sends the query to the loyalty provider, e.g., LPRO or AMS via the Universal Loyalty Promotion (ULP) Engine including the triggering dummy item. The Promotion Engine triggers the applicable promotion and cents off discount, which is applied on the applicable fuel product.
After fueling, the fuel controller sends the fuel item, the trigger item and the promotion if included in the finalized transaction buffer.
PAP flows with a carwash item sold at the pump are also supported when using a 'Zipline' discount card.
Cents off discounts triggered by the dummy item support various promotion features as with current functionality, such as promotion limits, customer approval to get the discount, etc., and this is all determined by the Promotion engine.
Emerald processes the transaction and captures the fuel item, trigger item and promotion if included, and carwash item if included, in the Tlog.
REF 493370: Fuel: Support Disable Emerald FC Client as the Fuel Loyalty/Promotions Service for PAP
Currently, in Pay At Pump (PAP) transactions, and PAP to Pay At Kiosk (PAK) transactions, the Emerald ForeCourt (FC) client performs all communication between the Fuel System to the Loyalty provider via the Universal Loyalty Promotion (ULP) engine.
A new Fuel Controller called Epsilon Fuel Server (EFS), which will communicate directly with the loyalty ecosystem will be integrated with Emerald. (The EFS is also known as the RPOS – Radiant POS.)
A new configurable parameter called Provide Loyalty Services to Fuel was added to determine how loyalty services are provided, i.e., either Emerald supplies these services as is today, or the Fuel controller interfaces directly to the ULP.
If the latter option was selected, Emerald does not approach ULP, and the promotion and customer data is captured as received without any validations.
REF 493370: Fuel: Support Rewards as Tender
Emerald was updated to support Reward as Tender in Prepay transactions.
Previously, you could not add a reward as Tender Coupon, e.g., MFR, to the transaction if there was a fuel item already selected.
REF 465969: Fuel: Introduce Support for Manual Fuel Sales
Emerald was enhanced to support Manual Fuel Sales. A Manual Fuel Sale is a sale in which fuel items are manually entered. The cashier manually selects the pump and Fuel item, enters the fueling volume, adds additional dry items, if required, and closes the transaction. This ability is required by retailers for exceptional cases, such as, a customer pays for the wrong fuel transaction, or fuel was dispensed but the transaction was not loaded at the FuelPOS, the cashier can then perform a Manual Fuel Sale to record the fueling on the POS.
A single sales transaction can include a single manual fuel item with another fuel item. This is only supported for combinations of Manual Fuel Sale + PAK. In these scenarios, the TLog captures both Fuel Item sales.
A combination of a Prepay fuel sale and Manual Fuel Sale is not supported.
A new pump function called Manual Fuel Sale was added to perform Manual Fuel Sales and a Cancel Manual Fuel Sale to cancel the Manual Fuel Sale. Manual Fuel sales support discounts as with any other fuel transaction, floor limits determined by the Promotion Engine, as with any fuel sale.
A new Activity was added to the BRM of Type - POS Function called Manual Fuel to trigger a message prompting for Manager Approval when selecting the Manual Fuel Sale function at the FuelPOS.
The receipt was updated to display an indication of Manual Fuel items.
The Tlog was updated with a new attribute called FuelItemSaleType to indicate how the Fuel Items are sold, e.g., Manual, PAP, etc.
REF 508883: Fuel: Introduce POS Support for Fleet Card Payment
Emerald was updated to support Fleet Card payments for Post Pay and Prepay fuel transactions when using the NCREPS payment system only. NCREPS is the new name of the Epsilon group.
A Fleet Card, a.k.a. Fuel Cards, is a type of payment card used to pay for fuel at the gas stations. It allows businesses to manage expenses associated to their vehicles that they own and operate.
The retailer should configure the EPS item code by the 'nacs code' configuration in the catalog.
In the API with the NCREPS, the EPS item code is called 'gen code'. Emerald gets the 'nacs code' and transfers it to the NCREPS as the 'gen code'. The EPS can either approve / decline a payment/pre-authorize request if the items in the basket are not eligible to be purchased with the given card.
A new parameter called EPSDefaultItemCode was added to determine how the prepaid line is now represented.
In addition, as part of this development, Emerald added support for partial authorization when the transaction includes prepay line. As part of this development Emerald was updated to support partial authorization with prepay line with any EPS provider (Connected payments or NCREPS).
REF 354772: Fuel: Sound the Audio Alerts in the POS Lock and Welcome Screen
Emerald was updated to play an audio alert to allow the cashier to respond to fuel requests when not looking at the POS. Supported in logout or lock mode.
Details
REF 503874: Tender Check: Handle (capture and endorse) Shopper ID Details before Authorizing the Payment
Emerald was updated with the ability to capture Shopper ID details when paying with an ECC/Non ECC Check tender prior to authorization of the payment. Once the information is passed on to the authorization system, it improves their ability to identify shoppers with bad credit and to be able to decline payment if necessary.
Electronic Checks can be authorized as Electronic Check Conversion (ECC) or can be authorized as non ECC.
- When a Check is ECC authorized, the Shopper ID is automatically sent to the EPS provider system and the paper Check can be returned to the customer since it is no longer required.
- When a Check is Non ECC authorized, it is required to endorse the Shopper ID's details on the back of the Check and the paper Check is kept in the drawer for pickup and settlement at the bank. To support this option, Check Tenders were updated with a configurable option to determine that an Additional ID must be captured when an ECC/Non ECC Check is used. A new Shopper Identification Policy module was added to configure Additional Details per customer Additional ID types, for example, capture the First Name, last Name and Date of birth when a shopper presents a Driver license as the ID. During the payment flow, the POS was updated with a new screen to prompt a new Shopper ID flow to capture the Shopper ID and additional details relevant to the Shopper ID. Notes: NCR Personal Information (PI) Security Guild confirmed that there is no need to request consent from a Shopper to endorse the Check with their ID details. Once a shopper agrees to provide their ID, it is enough. Since Shopper ID details are PI, the details are not logged in any Emerald Logs. Any printable data used for endorsement is deleted after every transaction.
The new Shopper ID flow is available during regular Check payment, Tender Exchange flows with a Check, and Fuel transactions with Check payment. The new capability to capture Additional Details per Shopper ID was also implemented for the existing Pharmacy flow where Emerald already captures the ID of the person picking up prescription items. During a Pharmacy sale, once the acknowledgment process starts and the POS prompts for the pickup person ID, the new Additional Details screen will be prompted to capture additional information per ID type.
REF 504401: Tender Check, EPS (CP) Authorization Handle Check Type
Emerald was updated to capture the Check Type when a Check is used and to send the details to the Connected Payments (CP) EPS provider. This enables the payment processor to improve the authorization logic.
Currently, Emerald uses the Terminal Action Codes (TAC) configured in the CP/OpenEPS API and only sends a Personal Check hardcoded Check Type value to the EPS provider, i.e., CP.
In this development, Emerald was updated with an option to define the Check Type Code for the Check Tenders and a new list of Check Type Code values. On using a check at the POS (ECC Check, Non ECC Check, the Check Type code is captured from the Tender definition and is sent with the same current method (i.e., sent to the CP/Open EPS by the relevant Open EPS TAC/API), but with the relevant Check Type Code and not the hardcoded code that was previously sent.
The new Check Type Code is sent for Checks used in regular payment flows and Tender Exchange flows.
REF 497244: Tender, Check, EPS (Aurus) Authorization: Handle Shopper ID Details
In a previous development Emerald was updated with the ability to capture Shopper ID details when paying with an ECC/Non ECC Check tender prior to authorization of the payment.
Emerald also already supports integration with the Aurus EPS provider and now supports the ability to send the Shopper ID to the Aurus EPS provider to identify the shoppers with bad credit and the option to decline payment.
REF 504404: Tender, Check, EPS (Aurus) Authorization: Handle Check Type
Emerald was updated to capture the Check Type when a Check is used and send the details to the Aurus EPS provider. This enables the payment processor to improve the authorization logic.
REF 512244: Emerald Logs
Currently, when the Emerald Logs are configured to log in debug mode, the logs are overwritten every few minutes. This causes an issue where the logs are not available for the Professional Services/Support teams if needed for investigation.
The Log4Net configuration was changed to enable the logs to be available for a least 24 hours by increasing web logger configurations, which will reduce the disk size and prevent logs from being deleted too quickly.
REF 499659: Business Rules: Support Delayed Manager Coupon Limit BRMs
Currently, Emerald supports Delayed Business Rules (BRMs) requiring manager approval that are configured to be resolved after the cashier finishes scanning all the customer's items before payment. The following Business Rule types already support this option: Open Price, Price Override, Quantitative Limit, and Void Item.
In this development, Coupon Limit Business Rules can now be configured as delayed BRMs. When a coupon triggers the Coupon Limit Delayed BRM, the cashier is notified and can continue with the transaction. The business rule that is triggered is added to the Intervention List. On totaling the transaction after all the items are scanned, a list of all the delayed manager approval business rules/intervention is displayed in the Intervention List, and the manager can approve or reject each intervention as required, as with existing functionality.
Note:
The solution is based on the current Emerald Intervention mechanism, which is also used on recall transaction flows.
REF 488289: WIC EBT: Allow WIC EBT Card to Pay for Non-LEB (Least Expensive Brand) 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. LEB enforcement is not a requirement of a certified WIC EBT system. Item Selection practices reduce the unit price by restricting the brands, types, or package sizes allowed for purchase with WIC cards.
Emerald was updated to comply with retailers who request that most of the items paid for by WIC cards are the LEB (Least Expensive Brand) items.
LEB and Non LEB WIC items are items in the APL. Items not included in the APL cannot be LEB/Non LEB items.
A new parameter called LEBFunctionality was added to turn the Non-LEB functionality on or off.
The POS UI was updated to indicate Non LEB items via a dedicated icon.
Two new modules called WIC LEB Categories and WIC LEB Inclusions were added to the CCM to set specific Categories and Sub Categories as LEB Categories, and specify which items are included as LEB items in the categories.
A new BRM was added to prompt for manager approval if the cashier tries to add a Non-LEB item to a WIC basket.
Emerald supports selling non-LEB WIC items via the WIC card only when LEB items are out of stock. This is controlled via configuration of the new business rule.
REF 515151: Tender: Support Coins Dispenser Device for Change/Refund
Emerald was integrated with a Coin Dispenser to enable the system to dispense change at the POS, shortening transaction time and making sure customers receive the correct change.
The following transactions support using the Coin Dispenser to dispense change in coins:
- Sales Transactions
- Return Transactions
- Fuel Transactions (Prepay Balanced and Unbalanced Only) The Coin Dispenser device must be installed and configured for each POS terminal. The Coin Dispenser supports a range of error messages that are sent to the POS terminal via the interface between the Emerald POS and the Coin Dispenser device. These error messages can be prompted during POS startup, when enabling/disabling the Coin Dispenser at the POS terminal to notify the cashier of any problems. For example, an error is prompted on the cashier display if the Coin Device does not load during startup of the POS, or if there is not enough money in the Coin Dispenser's cannister, etc.
Note: The Coin Dispenser device's manufacturer settings are the retailer's responsibility. For example, some devices may support an option to set the 'maximum amount in coins that can be dispensed from the device. The retailer would be responsible for this definition.
To support integration with the Coin Dispenser, Emerald was updated with the following:
- A new Coin Dispenser Device and Device Type
- The POS 'Change' screen (in sales and refunds) was updated to display the change given in coins in addition to the total change/total refund.
- A new Coin Dispenser POS function was added to the POS commands enabling the Cashier to control when the Coin Dispenser is used. The new function supports toggling between a Coin Dispenser ON/OFF function to enable/disable the Coin Dispenser
- A new Activity was added to the POS Function BRM type called Coin Dispenser On/Off to enable the POS to prompt for manager approval when the cashier toggles the Coin Dispenser ON/OFF.
REF 493483: EPS, CP, Terminating OpenEPS (Reintialize EPS)
Today, when the Emerald POS starts a business day, it sends a request via the OpenEPS API (the client component of NCR Connected Payments (CP) to call the MTX_POS_CheckerSignOn. This process initializes the PIN pad during POS startup. At the end of the business day, when the cashier signs off, the POS sends a request via the OpenEPS API to call the MTX_POS_CheckerSignOff to terminate the OpenEPS. This process closes the PIN pad.
The OpenEPS API creates the Connected Payments (CP) journal files as well as downloads the configuration to the PIN pad.
Emerald recommends that retailers who do not work 24 hours a day should start up the POS daily to prevent problems on the CP, since the journals can become overloaded and cannot be handled. By restarting the POS, new device updates are downloaded.
Emerald was enhanced with the ability to execute the CP CheckerSignOff/CheckerSignOn process everyday with no regard to the POS startup flow after the End of Day process, by configuration.
Initializing the CP EPS will be implemented from both the POS side and the CP EPS side.
A new EPS Parameters module was added to configure when the EPS Initialization is run.
The CP EPS API was updated with a new command called EPS_Initialize.
This feature is only relevant to the CP EPS.
REF 493483: L&P Pass Transaction Sequence # and Store # to PE (AMS/UE)
Emerald was enhanced to send the Transaction Sequence # and Store # to the Promotion Engine to embed these values when printing messages on the receipt.
This feature enables retailers to support survey messages, which are typically printed on the customer's receipt and include data that is required by the 3rd party vendor to control the customers survey for the retailer. For example, the customer may take part in a survey online and the details required are printed on the receipt they received in the store.
This option is only supported when integrated with the ULP version 2.
REF 517768: Catalog: Emerald to Support 100 Characters in Group Names from Catalog instead of 40
Currently, the Catalog supports group names of up to 100 characters.
Till now, Emerald only supported Group ID and Product ID lengths of 40 characters.
All fields in the Data Transportation file were updated to support the Group ID and Product ID length of 100 characters.
REF 518713: Aurus Integration: Payment A/B Transaction Toggle
Emerald currently supports a dual output lane POS environment, where the cashier can process two customer's transactions at the same time on a single POS, toggling between Lane A and Lane B and vice versa to complete payment of each transaction.
The functionality is supported when the POS is integrated with the Aurus EPS provider.
The following flows are supported:
- All payment types (Full, Partial, Pre Swipe):
- Cash
- EFT
- ECC Check
- Gift Card
- Gift Card Activation
- WIC
- EBT Cash/Food Stamp
- Pay Roll
- Refunds
- Void Transaction
- Balance Inquiry
- Recovery
- Recovery after Pre Swipe Payments
REF 518697: sWIC: Support FiPay Integration Effort
Emerald's sWIC solution is now supported when integrated with the FiPay EPS provider.
The solution covers the following flows:
- Balance Inquiry
- Payment
- Void Tender
REF 523212: POS Lock Information Missing in the Tlog and TDM
Currently, when the cashier manually selects the Lock function on the POS, or in case of a POS timeout and the POS automatically locks, a Control Log is generated.
The Tlog was updated with new tags to capture the method by which the POS locked, e.g., automatic or manually, and if the POS Lock was performed in No sale or Sale Mode.
This information can be used in the cashier productivity reports, so that the time spent on ringing up items does not include the time during which the POS is locked, making the report more accurate. In addition, the retailers can track how many times the cashiers manually lock the POS.
This feature only relates to the Emerald Tlog side, the TDM parsing will be developed in a separate development.
REF 523213: Blind Pickup Transaction Type to be Recorded in the Tlog and TDM
The Emerald Tlog was updated to capture Blind Pickups as
REF 523214: Return Reason (Description) to be Captured in Tlog and TDM
Currently, Emerald captures the Return Reason ID at the item level during Return transactions.
The Emerald Tlog was updated to capture the Return Reason description to enable the retailer to view meaningful information in the reports. The field is captured in all types of returns, including transaction-level returns. In a transaction-level returns, the Return Reason description is inherited from the transaction level and kept at the item level.
This feature only relates to the Emerald Tlog side, the TDM parsing will be developed in a separate development.
REF 523215: Cash Office Account Details in Tlog and TDM – POS Accountability
The Emerald Tlog was updated to include Cash Office Account Information enabling the retailers to drill-down to view transaction level data as part of the Store Settlement Dashboard in the NCR Analytics application.
Whenever a Control Transaction or Retail Transaction is finalized in POS Accountability, the Account ID and Account Name will be captured.
Currently, this feature is only supported in Cash Office environments working in POS Accountability mode.
This feature only relates to the Emerald Tlog side, the TDM parsing will be developed in a separate development.
REF 524764: Add Rate Name to the Receipt Tax Summary Lines
Currently, for Receipts in the Base Configuration for both the Tax Summary lines and Tax Exemption Summary lines, the Tax Authority Name is printed under the Name column.
Emerald added the option to print the Tax Rate Name (description) on the receipt (instead or in addition to the Tax Authority Name).
REF 483870: Run RTIs Set on Spooky Using Command Line
Currently, when executing RTIs from the Spooky tool, the response from RTIs that failed are saved in the log files.
Emerald was enhanced to enable the same option when RTIs are run from the command line.
The functionality of logging failed RTIs when using the spooky tool was applied for RTIs executed with CLI.
REF 524764: POS Exception Handling Improvement
The POS exception handler was improved to be able to catch exceptions without POS crashes, for example, when an exception comes from unmanaged code, e.g., the mtx_pos.dll, OPOS, etc., the POS will not crash and the logs are logged in the POS logs clearly.
The following issues were handled:
- All data is now passed via the SET methods to mtx_pos
- The POS is able to handle new exception types and log all the necessary details for debugging
- A new exception type for wrapping the corrupted state exceptions along with additional data was created
- A HandleProcessCorruptedStateExceptions attribute was added to all methods in OpenEPSAPI class and throw the new exception from them
REF NTEP Certification: Update Certification Number on the POS
Emerald was issued with a new Certificate of Conformance for both Grocery and Fuel clients.
The new certification includes certification for both the scale and fuel controller and a new certification number.
The new Emerald POS Certificate number is 17-090A2.
The same number is displayed on every POS terminal. It only changes when another number is received.
The USA Certification Compliance Details is a strip of information displayed on every screen in all modes. This strip includes the following details:
- Manufacturer = NCR
- Model = Emerald
- Version number – the version number of the currently installed program
- CC# - the Certificate of conformance number.
Resolved Issues
The following defects were fixed in this version:
- Fixed TFS505284: UI Automation - Store Coded UI Performance Report - POS Start Up – took a long time.
- Fixed TFS517256: Override Amount Embedded on MSU Item - The new price was not for updated for all the MSU items.
- Fixed TFS518767: WIC EBT – Items covered by benefits could not be removed from the basket after trying to add items not covered by WIC benefits.
- Fixed TFS518838: Tender Amount Report - Tenders with foreign currency were displayed with a Dollar amount and the foreign currency currency sign.
- Fixed TFS519690: Customer Search by PIN pad sent the phone and mobile criteria even though the CustomerCapturePolicy AlternateId configuration did not include the fields.
- Fixed TFS520085: MTX Simulator – The Cashback field was not enabled after a Tender Exchange activity was completed.
- Fixed TFS520095: A Manager Approval message was prompted while adding items even though the manager approval was added at the time coupons were added to the transaction.
- Fixed TFS520314: UI Automation - RTIs failed in the Automatic Lab Installation (CCM Tier, Default Configuration).
- Fixed TFS520531: Tax Discount - The percentage Tax Discount amount in the receipt was displayed in different format to the other Taxes.
- Fixed TFS521419: Manuel Fuel was enabled on the pump, even though the command was disabled.
- Fixed TFS521430: Void Item from 'selling 3 * item warranty' – The amount of quantity of 2 was not refreshed and still displayed the amount of 3. The quantity was OK.
- Fixed TFS521619: UI Automation – A general error was prompted when recalling transactions, and the Transaction could not be voided.
- Fixed TFS521675: Prepay transaction were paid and closed as for regular transactions without option to Fuel.
- Fixed TFS521862: 'Void item' of Return Linked Item or Warranty item with quantity of more than did not void the linked/warranty item.
- Fixed TFS521872: An unhandled exception occurred when trying to pay for transaction that contained an item that was both sold and returned.
- Fixed TFS521983: UI Automation – The Electronic Journal displayed a VoucherS2 limit message.
- Fixed TFS522064: UI Automation - Unknown symbols were displayed on the Max Changed password error message.
- Fixed TFS522102: In the Office, the Receipt Default Layout contained a field with MAN WT text instead of MAN VO.
- Fixed TFS522120: In the Manual Fuel Form 'Fuel Volume' had only with 2 digits after the decimal point. (It should be the same as the Culture setting – Volume UOM Precision configuration).
- Fixed TFS522187: Warranty items were displayed at the POS with a 0 price. The price was displayed only after the warranty was selected.
- Fixed TFS522241: Fuel POS - Return All - Show Original Transaction - Not all the Item lines were displayed (Screen resolution issue)
- Fixed TFS522247: UI Automation – An unexpected message 'Partial Authorization' with 'Approved Amount' of 20 was prompted.
- Fixed TFS522350: UI Automation - Payment tender as Visa was not available.
- Fixed TFS522441: UI Automation - Gs1AmountAndWeightEmbeddedBarcode barcode 01002055510414213200005000 was not found.
- Fixed TFS522546: UI Automation - Selling: Online item – The wrong message was prompted.
- Fixed TFS522566: Amount Embedded on Weight MSU Item – Changes were required in the Action Zone.
- Fixed TFS522775: Return All - The Return Sign character for return items was not displayed for all the items.
- Fixed TFS523298: The Forecourt didn't update prices when not all graded products defined in the FCC were found on the server.
- Fixed TFS523365: UI Automation - Online Item Confirmation Window – The OK button could not be selected.
- Fixed TFS523369: UI Automation – The Tender Maintenance RTI failed.
- Fixed TFS523393: UI Automation – The POS did not run.
- Fixed TFS523634: UI Automation – The ProductMaintenance RTI gave an unhandled exception.
- Fixed TFS523693: sWIC - systemTraceAuditNumber in the canonical Tlog (=ReferenceNumber in Emerald Tlog) was 7 digits and not 6.
- Fixed TFS523861: Base Configuration – the AccountOpenAmountStrategy RTI was missing.
- Fixed TFS524186: UI Automation - VoidOlItemOfTypeCardErroneousCases - Online item – The wrong message was prompted.
- Fixed TFS524352: UI Automation – A general error occurred message was prompted for Gift Card Activation with a fixed service charge.
- Fixed TFS524366: CCM Client - Touch Point Behavior UI issues.
- Fixed TFS524445: UI Automation - Coldstart Tool did not work.
- Fixed TFS524645: Base Configuration - Permission for the "Add coins to ATM" activity was not removed.
- Fixed TFS524840: Fuel POS - Void Prepay Line – The Prepay line was not striked out as Voided.
- Fixed TFS524841: No actions on the Intervention List could be performed when recalling order with an Age Restriction on the POS.
- Fixed TFS524853: Fuel transaction could not deleted in specific scenarios.
- Fixed TFS525313: CCM 1.5.3 ProductConfig Build issue.
- Fixed TFS525412: Manual Fuel - The price of liter was zero in the Printer Receipt.
- Fixed TFS525437: UI Automation – An 'Error in EPS' was prompted in many tests.
- Fixed TFS525447: IDM - Barcode Authentication - After creating a new user as a cashier, the new user could not log in.
- Fixed TFS525549: Receipt with Voided Warranty item - The TV item and the Warranty item were not displayed under the Header of 'Item Canceled'.
- Fixed TFS525669: Manager Approval messages were not triggered when there were multiple BRMs in the transaction.
- Fixed TFS525876: UI Automation - Intervention list – The Solve button was not disabled.
- Fixed TFS526125: UI Automation – There was an error when sending BusinessUnit and TouchPointBehaivor RTIs at CCM level.
- Fixed TFS526138: UI Automation - NCREPS - Support NACS Codes -: EPS.log Gen prod expected value 200 but got 19.
- Fixed TFS526206: Emerald 1.6.3 and 1.6.205 Server Upgrade Faileds on Violation of PRIMARY KEY constraint 'PK_IDM_State' and 'PK_AppUser'.
- Fixed TFS526317: STS - Multiselect activity type picker on Cash office Audit – On sending the Declaration RTI to store - An unhandled exception has occurred error was prompted.
- Fixed TFS526516: UI Automation - Tlog changed -r10Ex:EpsMethodComplete</r10Ex:EpsMethod> was missing.
- Fixed TFS526801: Discount lines overlapped in the POS Action Zone.
- Fixed TFS526867: Login to POS - POS in stations ATH & ATM - The POS did not recognize any users.
- Fixed TFS526992: Drawer Accountability - New accounts for logged in users got stuck in the DMS.
- Fixed TFS527073: Fill up with partial Auth transaction could not be completed if the item in transaction had taxes.
- Fixed TFS527101: UI Automation - EFT Amount view screen was not displayed when add WIC items.
- Fixed TFS527106: UI Automation – The Void tender line screen was not displayed.
- Fixed TFS527119: Return, Fixed Tax and Multiple Inclusive taxes.
- Fixed TFS527158: Store Server Office Client – An error occurred due when the Installation User Password was changed.
- Fixed TFS527159: UI Automation – A general error occurred swiping a "Visa Decline".
- Fixed TFS527165: Card details were not included in the resumed transaction Tlog.
- Fixed TFS527183: CCM server Data Transportation - R1 Catalog download and R1 Coldstart failure due to SQL tables definition error.
- Fixed TFS527224: Fuel - Product Sell - After adding a Loyalty card and scanning item 299, clicking the EJ line displayed the customer data in the Action Window instead of Item Data.
- Fixed TFS527255: Inclusive Tax and Multiple percentage Inclusive taxes in quantity sales were fixed.
- Fixed TFS527302: Changing the LEBFunctionality of an agency in WicAgenciesConfigurationRequest RTI disabled the Agency in the CCM Office.
- Fixed TFS527329: WarmUp - Disabled warmup in configuration.
- Fixed TFS527429: Property "Quantity" was not added to IDryProduct and to all relevant mappers of GetRewards service in Device Manager.
- Fixed TFS527530: Un fuel EFT Prepay transaction - RequestedAmount in TLog contained the Partial Approve amount and not the Original Requested Amount.
- Fixed TFS527646: Shopper ID Details – Driver's License could not be scanned when there were promotions.
- Fixed TFS527704: An old pickup person identification was displayed in the flow instead of the new screen (shopper id ) in Pharmacy.
- Fixed TFS528010: Build of 1.6.4 Product Config is Red