Dynamics 365 Commerce

Orders paid via on-account payment method from call center, when returned in POS, do not show any refundable payment methods.

This is addressed in LCS issue 866741:

https://fix.lcs.dynamics.com/Issue/Details?bugId=866741&dbType=3.

However it is marked as Postponed, with workaround that the end user can use the Manager override option to see all the refund options.

In some scenarios, retailer doesn't want to grant manager privilege to store users which would cause more concerns.

Please support this scenario and allow POS user to refund the call center order which paid by customer account.

There should be a link between the method of payment defined in the accounts receivable module vs the payment methods defined in the commerce module. This would allow for automatic banking fees to be posted for specific payment methods at POS.

Currently, when paying a "deposit" for a customer order, a customer payment journal is posted but the method of payment field on that form is blank.

An example where this will be able to be used will be if a specific payment method charges a bank fees to the business on each transaction. With a link to the AR method of payment, this should populated on the customer payment journal. During the posting process the fees for the payment can automatically be posted in the correct account so that the business does not have to do manual journals and reconciliations on each of the transactions.

Submitting a new copy of this request as Boyce Zhu declined the original Idea with a comment that does not address the original suggestion.

"DOM gives preference to shipping orders completely from one location. Therefore, if a whole order and its lines aren't available from a location that has a priority of 1, DOM will try to fulfill it from a location that has a priority of 2."

In certain cases, the business would prefer that the order split ship between a priority 1 and priority 2 location instead of consolidating the entire order to a priority 2 location but there's no option to configure DOM this way. In our business-case, priority 1 is our DC and priority 2 contain our brick-and-mortar stores.

Take for example an order for 10 items. 9 out of the 10 items are available at a priority 1 DC location. All 10 items are available at a priority 2 store location. DOM will route all 10 items to the priority 2 store location. But we would prefer that the DC location fulfills 9 of the 10 items and the store location fulfills the last item. We'd prefer the store not wipe out that inventory that could have shipped from the DC.

There are multiple ways customers can create sales orders and place them, some through the website and some through call center. Orders can be placed on different accounts either on behalf of organization or when someone calls in it is placed on the organization website which cannot be seen.  This leads to the customer not being able to see every order they have placed so they cannot see indication of spending trends or what items have been purchased when going back to review past purchases.

Our clients would like out of the box functionality that allows orders from each of the different platforms to be viewed.

To use when 'financial reconciliation in store' and 'cash traceability' are both enabled, this idea allows store managers to modify (update) or revert (remove) a cash movement event during the reconciliation process. The store manager can review blind-closed shifts and make adjustments as needed to help correct erroneous entries (due to entry mistakes by the shift owner). Scenarios may be:

• Shift A has done a Safe drop, Bank drop, Float entry, or Tender Removal but has a typo in their amount
• Shift B or Safe entry has failed to record money received from Shift A
• Start amounts can be overridden to account for mistaken count or declaration

This idea also suggests reviewing potential for differential journal/voucher posts for an adjustment pattern, so that financial postings follow balancing patterns (with either differential post or balancing total amounts needed to correct for mistaken entries).

Customers encountered challenges while using the Store Commerce application during inventory counting processes.

The issue arises when scanning items for inventory counts; the application requires the user to manually define the location for each new item being scanned.

While the app automatically associates previously counted items with their existing locations, it mandates a manual location input for each new item added to the inventory count.

This operational requirement significantly slows down the inventory process, especially in scenarios where multiple new items need to be scanned and added.

It disrupts the workflow and increases the likelihood of input errors due to the repetitive nature of the task.

Suggestion: 

The implementation of a feature that allows users to set a default location for inventory counts within the Store Commerce application.

Having a default location would streamline the inventory counting process, reducing the need for repetitive manual entries and thereby enhancing efficiency and accuracy.

Can you add an option/feature to restrict the ability to zoom in and out on a touch screen device within the Store Commerce app/POS.

Currently it tries to reshape the POS and causes issues with visibility. re-opening the POS resolves this but is not a desired resolution, especially when you're in a middle of a task such as store transaction or any other POS process.

Merchandizing is not handling product selection gracefully when some variants combinations are not added to HQ.

If a product master doesn't release all combinations of product dimensions as variants, on e-commerce there is a chance after selecting product dimensions, the other product dimensions will disappear and cause users not able to select all variants.

For example, create a new product that has 2 colors (Black and Brown) and 2 options for Style (Wide Size 9 and Regular Size 10)

The product contains 3 dimensions with values:

Color - Black and Brown

Style - Wide and Size - 9

Style - Regular and Size -10

The released product variants are:

Black Wide 9

Brown Wide 9

Black Regular 10

Brown Regular 10

On e-commerce, when you select 10 - Regular - Brown, the size 9 and style Wide disappear, so the user cannot select size 9 variants anymore when the color Brown is selected.

In addition, With the 10 - Regular selected, the only option for this color is Brown so you are unable to change the color to Black.

It is expected that you should be able to go back and select the other Dimension (for example Black) and then show the available style (Regular 10.

Reference issue 879750 in Life Cycle Services:

https://fix.lcs.dynamics.com/Issue/Details?bugId=879750&dbType=3&qc=3

For POS devices equipped with dual display screen, the corresponding window appears on the main screen's task bar when the Store Commerce application is open.

This allows the POS user to close the dual display window from the main screen by clicking on it via the task bar. This should not be allowed at all.

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.