Dynamics 365 Commerce

There is a need for smart rounding functionality when adjusting prices through 'Margin Component Price Adjustment' for at least 2 reasons:

• The "Get active price" data entity holds both ordinary prices and alternative prices, where 'alternative price' is populated by the result of the 'Margin Component Price Adjustment' functionality. If ordinary prices (i.e. trade agreements) are rounded off, alternative prices should also be rounded off.
• 'Margin Component Price Adjustment' can only be applied with 'Percentage' calculations. Calculating an adjusted price with a percentage will always create decimals. External sales prices with random decimals is not something retailers (or any business) can work with. Calculationg with 'Amount' is a work around on individual prices. But when calculating price adjustments on multiple (hundreds or thousands) of SKU's, this option is not feasible in the same way.

For retailers to work with 'Margin Component Price Adjustment' as a tool for campaigns, smart rounding is essential.

To support business operations and enhance accessibility for users—particularly those primarily working on mobile devices—we would like to propose the integration of Microsoft Teams add-ins with the Power Apps mobile platform.

It is highly desired and seems to be standard POS functionality to be able to handle processing Manufacturer coupons by simply scanning the coupon barcode and having the discount identified.

The GS-1 barcode format should be able to be parsed at the register level. Secondary to this the headquarters should have the capability to easily import vendor provided coupon details into the system so that they match the barcode specifications. So a simple discount of $2.00 off should be able to be imported and tied to the proper MFR coupon UPC.

It's not feasible to use system generated coupon UPCs in place of MFR issued barcodes or to manually create discounts for every MFR issued coupon when the UPC cannot be parsed by the POS.

avoid using Person-type Customer accounts. We’re requesting your input on the feasibility of an alternate solution that leverages GAB contacts.

We proposed an approach where each user accessing the Online Store would be associated with a Customer account (Type = Person). These Person-type accounts are linked to their respective Invoice Accounts (Type = Organization) via the Customer hierarchy. Delivery address, lead time, and auto-charge logic are driven by values defined on the Organization-type Customer account.

We do not want to create separate Person-type Customer accounts, as they believe this would:

• Introduce data clutter and confusion in their CRM
• Conflict with their existing customer/contact structure

They are proposing an alternative:

• Use contacts from the Global Address Book (GAB) linked to Organization-type customers
• Map these contacts to Commerce identities (based on email)
• Let users select a delivery address during checkout, and base lead time/charge logic on that selection rather than the user’s customer record

Idea:

1. Commerce Identity Mapping
2. Can GAB contacts be authenticated in D365 Commerce as B2B users without being Person-type Customer accounts?
3. Lead Time & Pricing Logic
4. Is it technically feasible to:

• Use delivery address selection at checkout (regardless of user record)
• Drive lead time and charges logic based on the selected address, not the logged-in entity

1. Commerce Limitations
2. What, if any, limitations would we face in using contacts instead of customer accounts for:

• Storefront login and access
• Order history visibility
• Address validation and delivery charge logic

Currently, D365 provides the option to generate the 'Channel Price Report Job' print archive only. It would be very beneficial to have the capability to choose a print destination for this report. This would enable users to send the generated report via email as part of a batch process. This report contains key information, such as price changes, that must be reported to product managers and the administration team, who can be notified via email.

Having the ability to manage barcodes for different purposes would help during the receiving process as well as the sale process. This would prevent the POS from scanning a barcode intended for product receipt during the sale process, and vice versa. For clarity, the following business process can be considered:

1. Create two barcodes for a product with the same unit of measure.

2. Identify the purpose of each barcode in the POS operation.

3. During receiving, if the sale barcode is scanned, it should not allow the receipt to be performed.

4. During the sale, if the receipt barcode is scanned, it should not allow the product to be added.

This way, receiving and selling can be controlled with different barcodes, avoiding scanning an incorrect barcode.

Currently, when creating alternative prices through 'Margin Component Price Adjustments' by percentage, the prices often include decimals. This can be problematic for retail and commerce customers who prefer rounded prices for better customer experience and operational efficiency. However, the existing smart rounding functionality is not applied in this scenario.

Integrate the smart rounding functionality into the margin component price adjustments process. This enhancement would make sure that prices are automatically rounded according to predefined rules instead.