Release notes for 2025 is moved to POS Management release notes in egretail.cloud |
Reason codes for logging out of POS can be configured in POS Management.
When reason codes for logging out have been configured, the cashier in POS has to supply the reason for logging out.
ProfilePriceStoreNumberMask has been added to system parameters. This is used to configure the format of the store number to be used when importing profile prices.
System parameters that affect behavior of data transfer via POS Import to the POS Master database can be maintained in the POS Management module.
When a parameter value is changed, the changes are exported to a blob and imported to staging.FlatJSON table in POS Master. Then they are processed into the configurationkeyvalue.
A problem caused by time zone has been fixed so the main view and the sub view for a specific import table show the same and the correct lines.
The system parameters view in POS Management can be used to configure POS Server applications. (Previously, this configuration was set in the legacy POS Manager application.)
Import of data in cloud POS Master database can be monitored in POS Management.
The main view shows the number of rows per status in each staging table:
The number in the failed column can be clicked to open a sub-view that shows the reason why the import of the rows failed.
Example from cashier import:
When user has access to one store, there is no Store field in POS Units and Price Validation. This one store is set automatically.
POS Units:
POS API price validation:
When user has access to more than one store, there is Store field available with store list possible to choose.
POS Units:
POS API price validation:
Existing default POS Units are exported automatically when a new store is created and imported from Store Service.
Angular has been updated to version 16 in POS Management.
Reason codes for transaction/subtotal discount can be configured in POS Management.
EG POS version 4.0.0.146 or later is required to use these. |
Missing data in some columns in the monitoring of POS Master data import has been fixed. All columns are filled with data except when the column in the staging table has the value NULL.
The POS API Price Validation tool can use used to verify that future campaigns has been transferred correctly and updated in the POS API database.
To calculate prices, the user needs to specify:
The result of the price calculation will be shown after clicking "Calculate", and it is also possible to download the cart content to view the data in detail.
Adding new and editing existing POS units can be done in the POS Management module.
There are 2 types of POS Units that can be added:
Default POS Units are virtual POS'es used by the POS API. These are common for all stores.
POS Units are physical cash registers deployed in stores. These are created per store.
To add a new pos unit in a store, specify the store, pos unit number, etc.:
Existing POS units can be seen in the table and they can be deactivated if they are permanently of temporarily out of use.
Import of POS units in Chain Web from POS Management is not yet implemented. POS units must therefore be created both in Chain Web and in POS Management. The export job for POS units in Chain web should be disabled when using POS Management to maintain pos units. |
Reason code configuration, including optional support for multiple languages can be performed in POS Management.
User roles "View Reason Codes" and "Manage Reason Codes" control which users have permission to see and edit these reason codes.
In a multi country setup, texts for all defined languages will be exported from POS Management and imported in POS.
POS will use the language for the country configured on the the store's profile in Store Management.
Example: If store X belongs to profile Y, and profile Y is set to country "Norway", then the cash registers in this store X will show reason codes in Norwegian.
When migrating from reason codes in Chain Web, existing reason codes defined in Chain Web should be deactivated. Codes with matching numbers should be created in POS Management.
User roles can be defined with permissions for viewing/editing POS Units and Default POS Units.
Maintenance of POS Units is not yet fully released
Default POS units can be viewed, added, edited and activated/deactivated. Adding and editing new default POS Unit is restricted by validation: number must be between 900 and 999, and has to be unique; also host name must be unique across all stores. All data regarding default POS Units is stored in the EG POSModule database (in the Chain.PosUnit table).
Default POS units is automatically created per store.
Maintenance of POS Units is not yet fully released