Youssef Eissa

Title: 

Reconciliation of Devices in D365 with Microsoft Entra and Intune

Description:

Our customers need a way to reconcile or match devices in Dynamics 365 (D365) against the same devices registered in Microsoft Entra or Intune. Currently, there is no standard functionality to achieve this.

Scenario:

1. In D365, using the Warehouse App Devices Workspace, all connected devices are displayed.
2. Customers want to use the Device ID from the Warehouse App Device Workspace to search in Azure and match it with the Entra ID or Intune ID of the same device.

3.However, searching with the Device ID in Azure does not yield any results.

Request:

We propose adding a feature that allows for the reconciliation of devices in D365 with those in Microsoft Entra and Intune. This feature should enable users to:

1. Search for devices in Azure using the Device ID from D365.
2. Match and display the corresponding Entra ID or Intune ID.
3. Provide a unified view of device information across D365, Entra, and Intune.

Benefits:



• Streamlined device management across platforms.

• Improved accuracy in device tracking and reconciliation.

• Enhanced user experience by providing a single source of truth for device information.

Title: 

Automatically Propagate Supplier Details to Multiple Batch Numbers in Warehouse Receipt

Description:

We have a scenario where the warehouse team needs to handle the receipt of box items more efficiently. For example, if 20 boxes for a specific item are listed on a purchase order line, the warehouse team would like to receive all boxes at once by entering a quantity of 20. The system should assign a unique batch number to each box. However, the warehouse team needs to enter the supplier batch number, supplier manufacturing date, and expiry date only once for all 20 boxes, as these details are common to all boxes.

Currently, the system treats each batch number as a separate entity, which is why the supplier batch number, manufacturing date, and expiry date are not automatically propagated to all generated batch numbers for each box. This forces the warehouse team to receive each box one by one, manually entering the supplier details for each individual batch number, which is time-consuming.

Proposed Solution:

Introduce a standard function that allows the system to automatically propagate the supplier batch number, manufacturing date, and expiry date to all generated batch numbers when receiving multiple boxes at once. This would significantly improve the efficiency of the warehouse team by reducing the manual entry required.

Benefits:

• Streamlined warehouse receipt process
• 
  
• Reduced manual data entry
• 
  
• Increased efficiency and productivity for the warehouse team
• 
  
• Improved accuracy of batch information

Title: 

Improve Product Image Quality in D365 Warehouse Mobile Application

--------------------------------------

Description:

Issue: The current design of the D365 Warehouse Mobile Application (WMA) only supports displaying product images in thumbnail format. This results in low-resolution and blurry images, which can negatively impact user experience and operational efficiency.

--------------------------------------

Impact:

• Users are unable to clearly view product images, leading to potential errors in product identification.
• The overall user experience is diminished, affecting satisfaction and productivity.

--------------------------------------

Proposed Solution:

• Enhance the WMA to support higher resolution images without compromising performance.
• Provide configuration options to allow users to choose between different image quality settings based on their needs and network capabilities.

--------------------------------------

Benefits:

• Improved accuracy in product identification.
• Enhanced user experience and satisfaction.
• Increased operational efficiency.

--------------------------------------

Conclusion: 

Addressing this issue will significantly improve the functionality and usability of the D365 Warehouse Mobile Application, benefiting a wide range of users.

Description

Current Behavior:

An error occurs when trying to confirm an intercompany purchase order, stating "The state of the source document or source document line could not be updated," preventing further actions on the purchase order.

Impact:

This error blocks the completion of intercompany purchase orders, causing significant disruptions in the workflow and business processes.

Problem:

"The state of the source document or source document line could not be updated" occurs when trying to confirm an intercompany purchase order.

Request for Improvement:

We propose implementing an automatic handling mechanism for these virtual charges to ensure they do not interfere with the confirmation of intercompany purchase orders. This will improve the efficiency and reliability of processing intercompany transactions.

Title: 

Allow Editing of Packing Slip Date Through Shipment Form in D365.

Description:

Current Behavior: In Dynamics 365, the ability to modify the packing slip date differs across various scenarios:

1. Sales Order: When posting the packing slip directly from the sales order, the user can modify the packing slip date.
2. Sales Order Shipment: When posting the packing slip from a shipment with a sales order, the user cannot edit the packing slip date.
3. Item Requirement Shipment: When posting the packing slip from a shipment with an item requirement, the user can modify the packing slip date.

Justification:

The ability to modify the packing slip date varies due to the design and purpose of each process:

• Item Requirements: These are often used in project-based scenarios where flexibility in dates is necessary to accommodate project timelines and changes.
• Sales Orders: These might involve less rigid logistics, allowing more flexibility for users to adjust dates to reflect real-world changes.
• Sales Order Shipments: The system enforces strict controls to ensure consistency and accuracy in order fulfillment and financial reporting. Allowing date changes in this context could lead to discrepancies.

Proposed Solution:

We propose adding functionality that allows editing the packing slip date through the shipment form, even for sales orders. This would:

• Provide greater flexibility in managing shipment timelines.
• Align the behavior with other scenarios where date modifications are allowed.
• Improve user experience by offering consistent functionality across different processes.

Description:

In the "Warehouse Management -> Inquiries and reports -> Physical on-hand inventory" form in D365, tiles do not save when clicked with no filtered data on the table. Once refreshed, the tiles work as expected, but this is not an ideal solution.

Actual Result:

Tiles do not save when clicked with no filtered data on the table.

Manual refresh is required for tiles to work as expected.

Expected Result:

Tiles should save from the last view to the expected outcome per the last saved tile, without needing a manual refresh.

Proposed Solution:

Ensure tiles save correctly even when no filtered data is present on the table.

Improve the functionality so that tiles reflect the last saved view without requiring a manual refresh.

Benefits:

Implementing these improvements will enhance user experience, streamline operations, and ensure that saved views function as expected without additional manual steps.

Introduction: 

encountered a significant issue affecting the operations when using the Czech legal entity in Dynamics 365. This Issue impacts the creation and updating of purchase orders, leading to errors that disrupt our business processes.

Problem Description: 

When attempting to create a purchase order and update any field within the PO header, users receive the following error message: "Cannot create a record in Purchase order header information for Intrastat (PurchTable_Intrastat). Reference: xxxxxxxxxx. The record already exists." This issue has been identified as a bug by the Product Group.

Workaround: 

The Product Group has suggested the following workarounds:

1. Refresh the newly created purchase order before making any updates.
2. Create purchase orders from All Vendors > Choose Vendor > Procurement > Purchase order.
3. If the error occurs, duplicate the current browser tab and reopen the purchase order.

While these workarounds provide temporary relief, they are not ideal for long-term use and can be cumbersome for users.

Request for Consideration: 

We understand that the Product Group has determined that this bug does not currently meet the criteria for an immediate fix. However, we believe that addressing this issue is crucial for improving the overall user experience and ensuring smooth business operations. We kindly request that this bug be reconsidered for a future fix, taking into account the impact on users and the availability of a valid workaround.

We appreciate your attention to this matter and look forward to seeing improvements in future updates.

Introduction: 

We have encountered an issue where product attributes cannot be assigned via product categories. This issue is documented in the LCS article Details for issue 602885. The current design restricts the assignment of category attributes to products, which has caused significant inconvenience.

Problem Description: 

The issue arises when creating a category hierarchy and adding a category attribute to it. When a product is added to this category, the attribute is not assigned to the product, meaning the product attributes form does not display any product attributes. According to the LCS article, this behavior is by design, as category attributes are different from product attributes and are not expected to be assigned to the product. 

Proposed Solution: 

allow product attributes to be assigned via the commodity code hierarchy without requiring commerce licenses. This change would align with the expectations of our customers and provide a more flexible and user-friendly experience. By implementing this solution, we can avoid forcing manufacturers to purchase additional licenses for a single feature, thereby improving customer satisfaction and adoption of the platform.

Description: 

-------------

We have identified an issue with the explosion view in Dynamics 365 Finance and Operations, specifically when dealing with demand forecasts. The explosion view shows incorrect planned production orders due to a missing link between the "calculated delays" form and the explosion view. This results in incorrect information being displayed when using Planning Optimization.

Problem: 

-------------

When there are multiple demand forecasts (or any other demand without RefId), the base record in the explosion form always defaults to the first of the similar records, regardless of which forecast demand has the focus in the net requirements form. Although the pegging information in the net requirements is generated correctly, it is not possible to get the explosion form to show the breakdown for the second demand forecast.

Impact:

-------------

This issue affects the accuracy of production planning and can lead to inefficiencies in managing demand forecasts. The current workaround involves selecting the demand forecast in the net requirements, identifying the order that the forecast is pegged against, and then opening the explosion view with this order selected. While this workaround is functional, it is not ideal and can be cumbersome for users.

Request: 

-------------

We propose enhancing the explosion view to correctly display planned production orders for all demand forecasts, ensuring that the link between the "calculated delays" form and the explosion view is established. This improvement will streamline the planning process and enhance the accuracy of production orders.

Remarks:

-------------

We understand that this issue has been acknowledged by the D365 Product Team but has not been prioritized for a fix at this time. We believe that addressing this issue will significantly improve the user experience and efficiency for all customers using Planning Optimization in D365 Finance and Operations.

Title: 

Improve Overview Costing Accuracy After Changing Indirect Cost Rate for Production Orders

Description:

an issue in Dynamics 365 Finance and Operations where the overview costing becomes incorrect after changing the indirect cost rate for production orders. This issue has been acknowledged by the D365 Product group engineers and marked as "by design" (Issue 793402). The problem arises because the system recalculates costs based on the most recent price during inventory closing, and it is unable to distinguish the actual price used at the exact historical time point.

Problem:

When the indirect cost rate for production orders is changed, the overview costing does not reflect the accurate costs. This discrepancy can lead to incorrect financial reporting and decision-making, as the recalculated costs do not match the historical prices used at the time of production.

Remarks:

The current design recalculates costs based on the most recent price during inventory closing, which does not account for the actual price used at the historical time point. This limitation affects the accuracy of cost reporting and can cause confusion for users relying on precise cost data.

Proposed Solution:

propose an enhancement to the costing mechanism in Dynamics 365 Finance and Operations to ensure that the overview costing accurately reflects the historical prices used at the time of production. This could involve storing and referencing the actual prices used at specific historical points, rather than relying solely on the most recent price during inventory closing.

Benefits:

• Improved accuracy in cost reporting
• Enhanced financial decision-making based on precise cost data
• Reduced confusion and errors in financial statements