Halldor Dungal Developer

To make it easier to browse the transaction journal in POS it would be nice to have the possibility to filter on different fields like the transaction types, register, operator id, etc. It could make easier for example to filter on "Safe drop" to get an overview of the "Safe drop" transactions or type "Sale" where total is negative to see all the returns.

Sometimes our customer asked for us to extend the POS to show external web pages, that the POS user uses for registration of information into an external system. This could be in realtion to guarantee information or customer credit check. A standard POS operation for this would helpful, that can take in URL as a paramter. This could also if a POS user needs to into a specifc form in D365 like https://someserver.dynamics.com/?limitednav=%22true%22&cmp=USRT&mi=SalesTableListPage

A customer asked about the possibility of using Single Sign On for MPOS/CPOS The business case is: The customer has POS and other single sign on application the user uses installed on the PC. The customer wants all user to have their own Windows logon and not a common user logon into Windows for all POS users. The customer wants to have a single sign on for applications and a fast switch in Windows to switch between POS users. Looks like there are fundimental things that need to be changed regarding MPOS/CPOS, so this can work, like the activation process. The idea regarding the activation, would have to be changed from being activation per userprofile per device, over to one activation per device. That could make it possible to run more than one instance of MPOS, with the same teraminlId. Could maybe also be a fist step over to a easier switch between environments for developers if the activation would be changed to make it possible to change the config in the DLLHost.exe.config file to allow the developers to switch environments.

No POS position permissions are found for the funcationality create or edit of customers. Business case: Not all retailers do want allow POS users to create or edit customers via POS.

As of now, the items on the receipt are printed in the same order that they are scanned. When the POS writes out a long receipt, with many items, it can time consuming for the customer or an employee to scan through the whole receipt to find and item on the receipt. It would be preferred behavior, in some cases, that the items are ordered alphabetically. Can we get a sort order option in the Receipt Formats setup?

This is just a general discussion around the loyalty system in D365FO. As I have now been doing several integrations to other loyalty systems here in Norway, I find the loyalty system in D365FO is not following the general trend here. The focus is still on accumulating points and using that as a payment later and having a loyalty card to identify the customer. It's more or less the same thing I was seeing more than 20 years ago. - Waiting for a reward, is something that people are less and less interested inn. It's more about here and now. - Knowing the customer - (Machine Learning) is more and more important. Have offers that are specially for that particular customer/group of similar customers to attract the customer into the store again. Often as coupons for specific items connected to a specific customer. - Discounts that stresses over several transactions (really a variations of a M&M were thing happen in the same transaction). Buy 4 and get the 5th free. - First time loyalty registration offers, to attact the customer to join the loyalty program. - Identifying the customer - Avoid plastic loyalty cards that the customer has to carry around. Identify either by an app, phone numbers or by a "token" that is linked to a payment card. - Employee discounts - handeld as part of the discounts in the loyalty systems. - Electronic receipts. Giving the customer to have an electronic overview of the customers receipts. Is also connected to guaranties and returns. Seeing the receipts journal in POS based on the customer and not all customers.

Name: ShoppingApp. The name is limiting – Rather called it Microsoft Retail App or MR App for short or something else. Business cases: 1) Self-service app for supermarkets and store for specialist like electricians and plumbers. a. There are all-ready stores here in Scandinavia that have large numbers of hand held android devices with built in barcode scanners with a simple user interface. First the user walks to a screen with a built-in scanner for scanning a barcode either on a card or on a mobile. One of the devices is then unlocked showing the name of the customer on the device. The customer then walks around the store, picks the items, scans the item by pressing a button, were the barcode is scanned with a built-in barcode scanner. The user can delete the item by pressing a delete basket on the app and then scan the item to confirm the item to delete. The transaction is completed by going to a check-out POS were the device is put into a docking that locks the device. The customers barcode Is scanned, and the transaction is retrieved into the self-service checkout POS for payment. The payment is completed, and a receipt is written out and the barcode on the receipt can be used to open a gate, so the customer can leave with the items. b. Specialist stores. Similar kind of a scenario, but with manual routines regarding checkouts as most transactions are registered to customer account and need a manual signature or verifcation. 2) Self-service – outside of the store. a. Done by customers in the field that have a regular re-accruing purchases for the retailer. Could be done by starting with a shopping list or manually browsing or by scanning barcodes with a camera or a Bluetooth barcode scanner. Could be in relation specialist like electricians, farmers, service people, etc. People that are in the field and not like always close to a PC but, do a lot of re-accruing purchases and in some cases also returns. b. Sales people in the field, that go from customer to a customer. c. Store employees that are servicing customer outside the store and selling limited range of products or bulky items that are kept in a closed area outside the store. 3) Customer loyalty app – Coupons a. Show and activations of customer coupons b. Show information about offers c. General information for the customer d. Customer verification – A customer barcode/customer id 4) Retail app for the store employees a. Clocking in/out of the store, when GPS says the location is in the store. b. Reports for the storemanger c. Price-checks d. Receiving and transferring goods e. Ordering print out of price labels f. Making manual purchase orders g. Stock-count with offline capabilities. h. Picking and packing, for pick-up in store orders i. Messages/notification to the stores j. Quick access/links to internal documents and websites. k. Registration/handling of defected items l. Stock information. Availability in store and nearby stores, and expected date of next delivery. The code: The code in the 8.1 SDK is an excellent start. Follows many good practices and patterns. The code is readable and has unit tests. Though even almost all of unit tests failed, out of the box, they gave a better understanding of the code, and its easy to make them work. Over all the code is a very good basis for the future and looks like the code is open for all kinds of extensibility. Would be nice to see a further development of the app so some of the business cases above could be fulfilled. Would be nice to see the app follow the newest version Xamarin, .Net Standard 2.0 Lib. and other components. Open source the project, so other developers could to accelerate the product and make it more current to everyone. Configuration: If more of the business cases are fulfilled, then more configuration parameters are required to turn on/off modules and functionality. Would also be nice to have a settings form to set/update information that now is configured in the configuration file. And setting to define start page, as different there are different needs. Make it possible to hide the menu button for example for the self-service in case 1. Caching of data into a SQLite, for a quicker start and offline/semi-offline support would be nice. Documentation: Looks like there is a bit of things to be completed about authentication and activation. Would be good to have everything documented around these things when completed. Would also be nice to have a read.md document that tells what is new in the version. Documentation around logging and logging configuration. Document the ideas behind the app, what is supposed to solve and how it can used. Other: Don’t let the user select a style when there is only style available or select color when only one color available.