Currently, when you create a new customer in the POS price groups are not defaulted from the default retail customer in the POS until the customers job is ran. I recommend that price groups should be defaulted upon customer creation from the default retail customer. Below is an example that demonstrates why this is needed:
1. A new customer is created in POS. No discount is applied, however there is an active trade agreement for the price group of the default retail customer.
2. If you view the created customer in D365, all price groups are populated with the same values as the default retail customer.
3. Run Customers job from distribution schedule.
4. Run the same transaction with the customer you created. You will notice a discount is applied.
This should be done when the customer is created, not when a job from the distribution schedule runs. Please up-vote to make this possible.
For retailers in Europe, it is very normal to sell to business via their regulair channels. A business can make purchases and request the paid VAT back in their tax declaration.
To enable this, the purchase has to be registered on a business customer with a VAT number set. Currently, you are not able to enter the VAT number on the customer account upon creation or update in the POS. This creates the need for retailer to have a back office process to append the customer record with the VAT number.
Please enable a sales clerk to set a value for the customers' VAT number when creating or updating a customer record from the POS.
Have the functionality to add family/extra cards for a loyalty member.
Adding a family card that uses the same points and tier as the main card. Today you can redeem from another card but the earning and tier level is still per card. Family members needs be be added on the same card as the tier calculation is based on, severals cards contributing to the same balance and tier calculation.
A common practise is that customers earns a value check or coupon from being a loyalty member, they earn a certain amount of points and they get converted to a coupon. At the time of sale the cashier can see the open coupons when adding the customer and when the coupon expire.
A functionality to meet this demand would be appreciated.
A redeem function and loyalty parameter to convert points to customer specific coupons, the ability to see them (value, expire) and easily choose the coupon at the POS.
When configuring and applying the Loyalty scheme, the system does not take into account a minimum treshold when redeeming earned loyalty points. Instead, it takes the ratio between the points and the currency.
For example, let's say you define that 1000 reward points gives you $10.
EXPECTED RESULT: Would be that for each tranch of 1000 points you'll get $10.
ACTUAL RESULT: Is that you can even pay with a couple of cents and the system will calculate the ratio between points/currency and deduct the points. So you are allowed to pay with $1 and the system will redeem 100 points.
Given the fact that there are already 4 decimals available in the redemption rules allows you to specify it on a really low quantity/currency level. So that should never be an issue.
The REQUEST is to make the functionality of the redemption rules similar to the earning rules where the amount/currency is seen as the minimum treshold.
Today, you cannot inactivate or a hide an affiliation from being visible in the POS. Retailers occasionally want to expire or retire affiliations so they are no longer added to customer records in the POS.
A toggle field that allows to hide or inactivate an affiliation so that is not visible in the POS would be very helpful. In this way, associates would not be able to add affiliations that the retailer no longer wants to offer.
OOB it will not let you remove affiliations if the affiliation exists on a sales order. So this requirement cannot be satisfied without new functionality.
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.
The client wants customer phone numbers on their receipts for Special Orders. The reason for this is so when the order is ready for pickup they can call them up from the receipt and not have to dig for a number.
Add field to enter a Sales tax group to use with Customer bases taxes when creating a new Customer in MPOSCashiers are creating new customers on the fly in MPOS when customers check out and do not have an account. There is no field to enter the Sales tax group and as such, no tax is being charged on the transaction. The Retail store is configured as Customer based sales tax.
Sales tax group should be saved and applied to the current transaction