Dynamics 365 Commerce

Master products without configured variants can currently be sold in POS, which later causes transaction validation failures and blocks invoicing.

There is no built-in validation to prevent this, leading to inconsistent data and manual fixes.

Currently POS allows selling such products, but they fail during validation and posting later.

What should be implemented is a validation layer to block selling master products that don’t have valid variants configured.

Problem Statement

When creating Virtual Tables using the Modern Power Apps Maker UI, the current experience introduces multiple limitations compared to the Classic (Advanced Settings) UI, making it unsuitable for enterprise and ALM-governed environments.

1. Connection Reference Reuse Limitation

In the Modern UI:

• Only connection references owned by the currently logged-in user are visible and selectable.
• Existing Virtual Table Data Sources created using a shared service account are not reusable by other developers.
• This forces each developer to create their own connection reference, even when the same backend SQL connection is already configured.

In contrast, the Classic UI:

• Surfaces Virtual Table Data Sources directly
• Allows all authorized users (e.g., System Customizers) to reuse existing data sources regardless of connection ownership.

2. Limited Control Over Column Definition and Schema Evolution

The customer also confirmed additional functional gaps in the Modern UI:

“The new UI for virtual tables is currently not fit for purpose and we will be continuing to use the classic UI for now.”

Specifically:

• The Modern UI provides very limited control over column data types during virtual table creation.
• It does not support future updates to Virtual Table schemas, such as:
• Adding new columns
• Modifying column definitions
• These capabilities are available in the Classic UI, where users retain full control, even if the process is more manual.

As a result, teams must continue relying on the Classic UI to:

• Properly model data types
• Maintain virtual table schemas over time
• Support evolving backend SQL structures

Expected / Desired Behavior

Enterprise customers expect the Modern Maker UI to reach parity with (or exceed) Classic UI capabilities:

1.Reuse Existing Virtual Table Data Sources

• Surface Virtual Table Data Sources directly in Modern UI
• Allow reuse regardless of connection reference ownership
• Respect environment-level permissions (e.g., System Customizer)

2.Full Column Control & Schema Maintenance

• Allow explicit control of column data types during creation
• Support updating Virtual Table schemas (e.g., add new columns)
• Enable safe, iterative virtual table evolution

Proposed Improvement

Align Modern Maker UI behavior with Classic UI for Virtual Tables

Surface Virtual Table Data Sources instead of restricting selection to user-owned connection references

Enhance the Modern UI to support:

• Column data type management
• Schema updates post-creation

When you click on "Withdrawal," "Deposit," "Initial Balance," "Cash Withdrawal," or "Cash Deposit," the cash drawer opens immediately after clicking the button, without this action being logged. Only then are the amount and receipt recorded or issued. From an audit and traceability perspective, this process is problematic because it allows physical access to cash without prior or accompanying documentation.

Proposed solutions:

(Preferred solution) Adjust the process sequence so that the cash drawer is opened only after another documented step has been completed.

Implement logging of cash drawer openings (time, user, context).

Auto charges and trade agreements both use the Account Code hierarchy (Table / Group / All) to determine which rules apply to a transaction. However, they resolve matching rules in fundamentally different ways. Trade agreements use "most specific wins" — if a Table-level price exists, Group and All are skipped. Auto charges use accumulative matching — if rules exist at both Group and All level, BOTH fire, causing double-stacking of charges on the same order.

This inconsistency is counter-intuitive for D365 practitioners, leads to unintended double-charging in common B2B/B2C scenarios, and forces workarounds (eliminating all "All" rules and assigning every customer to an explicit charge group) that increase configuration complexity and operational risk.

I propose aligning the auto charge Account Code resolution with the trade agreement pattern: most specific match wins, less specific levels are skipped. The AND logic already exists at the charge line level within a single header — it does not need to be duplicated at the header/account code level in my opinion.

The change is isolated to the ApplyAutoCharges method in the CRT Services layer, requires no database schema changes, and can be gated behind a configuration parameter for backward compatibility.

A detailed analysis with code-level evidence from the decompiled CSU V9.57/10.0.47 codebase is attached.