Halldor DUNGAL Senior Develper

In the legacy SDK there is an example for extending the linedisplay functionality. In our case we need to override some of the text before it is shown on the linedisplay, and it works Ok for the legacy SDK way of doing things. But now when we are moving over to the new sealed way of doing things it would be nice to be able to do the following:

- Write a trigger for the DisplayTextLineDisplayDeviceRequest instead of having a write a INamedRequestHandler to override the standard functionality. So the logic would simply be in the OnExecuting method, to override the line values to be displayed on the linedisplay.

For this to work the trigger has to be able to "set" the value for the lines, before the standard handler displays it. As of now the we can only "get" the value for the lines and not "set" it.

The AlphanumericNumPad seems to have two modes. It starts up in a read-only mode. The read-only mode does not allow pasting of text into the input field when using cut/paste. To get into the mode were the user can paste in text into the input field, the user has to press the "abc" button on the numpad first.

It would be nice if the AlphanumericNumPad could have an option, that could be set in code, so it would start in the "non read-only" mode to allow for paste of text to work without needing to press the "abc" button first.

The Manage Shifts screen in POS, needs be redesign from the usability point of view.

From version 10.0.35 the user now selects a shift then clicks the "Drawer icon" to declare either start amount, bank drop or tenders.

When the user finishes entering for example the start amount, it ends up again in the "Manage Shifts" screen were the line highlight follows the mouse cursor. The user gets often confused about what shift it was working with when it goes back the "Manage shift" form, as shift line is no longer selected.

Following changes could make things easier for the user:

• The user goes from the "Manage Shifts" screen to a "Drawer" screen where the user can enter all the different information for the drawer instead of having to go back and forth between "Manage Shift" and three different screens for the drawer. So, one screen instead of three.
• Would be nice to have some amount information in the "Manage Shifts" form, so the user can get an overview of the all the different total amounts for the drawer for each shift in the list. Thereby making it easier for the user to see what has been done.

In version 10.0.36 a new feature was introduced were "Product data is now cached in POS" to improve the scanning performance.

It would be great if the Commerce SDK would have general caching support to cache some frequently used data that does not change often to imporve the prerformance.

But this framework would have to be able to make sure it does not eat up all memory on the servers and thereby make everything slow down. And it would have to be some configuration on when to update the cache and how many objects a cache could hold.

The idea is a framwork, that developers could create a cache for data that they feel could benefit being cahced in extensions they build..

After trying to use the attributes to extend some products data, we gave up due to slow performance in POS. The attribute code in Retailserver was/is complex and slow.

As SQL Server has some great support for querying and using JSON data, would it be possible to handle the attribute data or extended data for products as JSON documents?

So when a POS solution needs to extend the product information a JSON document could be a field in the product table. That JSON information could then be handeld by extension code to display it or use in it any extension logic.

This could open up a very flexible and fast way of extending product information were no new ext.InventTable is needed and replication does not need to be extended as the extended information is all in one JSON document column.

Same thing could be done around customers if needed..

The performance should be much faster than the current attribute solution.

Today when a receipt is printed out, then code is run to query and create the receipts based on a setup. If the receipt setup is changed then the original receipt will not be shown but the receipt based on the new setup.

Would it be possible to save the receipt information as JSON document to keep a copy of the receipt that is printed and thereby avoid re-creating the same receipt each time it is displayed or re-printed.

This could save some RetailServer - CPU time in the long run although it will use some extra disc space to store the information..

Not sure how this will fit with future plans on archiving old Retail transaction data.

Release pipelines in Azure Devops can be used to update extension for the different CSU, but it is not possible to update the Microsoft version of CSU using the Azure Devops.(according to Microsoft)

As our Prod environment needs to be updated during the nighttime, it would be nice if the Microsoft version of CSU could also be scheduled in Azure Deops just like the extension. Like going from versjon 10.0.n to version 10.0.n+2 So both the Microsoft code and the extensions could be scheduled at the same time.

When looking at the performance for CPOS here in Norway, I can see that it can take a bit of a time to complete a transaction.

After the last payment is registered then the following happens:

• HardwareStation/LineDisplay/DisplayText
• RetailServer/Commerce/GetFiscalIntegrationTechnicalProfilesBySearchCriteria is called from the POS
• RetailServer/Commerce/GetFiscalIntegrationServiceStatus is called from the POS
• RetailServer/Commerce/Carts()/Checkout is called from the POS
• HardwareStation/PaymentTerminal/Unlock
• RetailServer/Commerce/GetFiscalIntegrationFiscalDocument is called from the POS
• RetailServer/Commerce/SubmitFiscalIntegrationDocument is called from the POS
• RetailServer/Commerce/SaveFiscalIntegrationRegistrationResult is called from the POS
• RetailServer/Commerce/SalesOrders()/GetReceipts

Would it be possible to avoid all this ping <-> pong and make it more like this?

• HardwareStation/LineDisplay/DisplayText
• RetailServer/Commerce/Carts()/Checkout is called from the POS
• HardwareStation/PaymentTerminal/Unlock

Where the "Checkout" does all the heavy lifting and returns the cart info and also the receipt info. So, one call instead of seven (1 instead of 7).

Benefits:

• Fewer web calls and less data flowing over the wire
• Less code needed to run in the client.
• Better checkout performance times