The default order settings of a released product for a sales order should also apply to sales agreement lines. Currently, these settings are only applied when a sales order is released from a sales agreement. However, when creating a sales agreement line, the site and warehouse fields are not automatically populated from the default order settings. It would be beneficial if the default order settings were also applied to sales agreement lines.

Currently, when auto-reservation is enabled for batch-controlled items with FEFO logic, the system automatically reserves the batch with the earliest expiry date. This behaviour is expected based on the item model group setup and reservation hierarchy.

However, in real-world scenarios, warehouse workers may need to override this reservation — for example, if the reserved batch is under inspection, not ready for use, or if there's a business reason to pick a different batch. At the moment, this override can only be done via the Finance and Operations interface, which limits flexibility and slows down warehouse operations.

✅ Proposed Idea:

Allow warehouse workers using the Warehouse Mobile App (WMA) to remove the system-generated FEFO reservation and manually assign a different batch directly from the app. This would give frontline users more control, reduce dependency on back-office intervention, and improve responsiveness in time-sensitive situations.

In the current system, it is possible for users to create inventory transactions with excessively large quantities (e.g., 18 digits) through both the Warehouse app and On-hand quantity adjustments. While the system allows these transactions, they cause significant issues during inventory closing and reconciliation, as the system cannot process or correct these invalid values automatically.

We propose implementing stricter validation rules to prevent the creation of unrealistic quantities in inventory transactions, both in the Warehouse app and On-hand adjustments. This enhancement would:

• Prevent invalid or extreme quantity entries.
• Reduce the risk of data corruption.
• Avoid manual interventions, workarounds, or corrective scripts in both sandbox and production environments.
• Improve system reliability and user confidence during inventory closing and reconciliation.

This idea addresses a real-world scenario where currently, extreme quantity entries can disrupt business processes, and provides a proactive way to prevent similar issues in the future.

Flexible warehouse reservation policy is not supported for CW enabled items.. Its a great feature & needs to work for CW items as well.

We are creating a lot of Drop shipment sales order lines. PurchCreateFromSalesOrder::createPurchaseOrders generates the Direct delivery or Drop shipment Purchase order line. This is already somewhat slow. We however see that after Purchase order and Purchase order lines are created, PurchCreateFromSalesOrder::createPurchaseOrders calls PurchCreateFromSalesOrder::updateRelatedSalesLineRecords.

 This sets SalesDeliverNow to 0 for all Drop shipment.

   private void updateRelatedSalesLineRecords()

   {

       SalesLine relatedSalesLine;

       while select SalesLineRefRecId from tmpPurchLinePrice

               where tmpPurchLinePrice.Included

       {

           relatedSalesLine = SalesLine::findRecId(tmpPurchLinePrice.SalesLineRefRecId, true);

           if (relatedSalesLine.DeliveryType == TradeLineDlvType::DropShip)

           {

               relatedSalesLine.SalesDeliverNow = 0;

               relatedSalesLine.update();

           }

       }

   }

But in most scenarios, SalesDeliverNow is already 0, so there is no need to runs SalesLine.Update.

Due to additional custom extensions and ISV solutions, the additional sales line update may add more than 1 second for each drop shipment line insert:

ASK:

There is no need to set this field to 0 again. Because it is so time consuming, I would like to ask you to consider changing the code in PurchCreateFromSalesOrder::updateRelatedSalesLineRecords to:

   private void updateRelatedSalesLineRecords()

   {

       SalesLine relatedSalesLine;

       while select SalesLineRefRecId from tmpPurchLinePrice

               where tmpPurchLinePrice.Included

       {

           relatedSalesLine = SalesLine::findRecId(tmpPurchLinePrice.SalesLineRefRecId, true);

           if (relatedSalesLine.DeliveryType == TradeLineDlvType::DropShip

&& relatedSalesLine.SalesDeliverNow != 0)

           {

               relatedSalesLine.SalesDeliverNow = 0;

               relatedSalesLine.update();

           }

       }

   }

Reproduction steps

Demo company account USMF

1.     Open Released products and select item M0001

2.     In Fast tab Delivery, change Direct delivery to Yes:

3.     Save changes

4.     Open All sales orders form

5.     Create a new Sales order form customer US-004

6.     Add a line for item M0001

7.     Save the line

Actual result:

Sales order line is saved and automatically a Purchase order is created:

As part of the Purchase order creation, class method PurchCreateFromSalesOrder::createPurchaseOrders runs PurchCreateFromSalesOrder::updateRelatedSalesLineRecords:

This method changes SalesDeliverNow value for all new order lines with DeliveryType DropShip to 0:

In this scenario, this is not needed as SalesDeliveryNow is already set to 0.

Although impact on standard environment is small with around 100ms spent on the actual update:

On environments with some extensions on sales line updates, the impact might be much bigger. In our case, it adds around 1 second.

Expected result:

When inserting a new Sales order line with delivery type Drop shipment, SalesDeliverNow value is already 0 in most situations. Changing SalesDeliverNow might be required in some scenarios, but if it is already 0, there is no reason to update the sales order line.

Since we cannot extend PurchCreateFromSalesOrder code, we are requesting to consider changing PurchCreateFromSalesOrder::updateRelatedSalesLineRecords to only update the sales order line if SalesDeliverNow field is actually set to something else than 0:

   private void updateRelatedSalesLineRecords()

   {

       SalesLine relatedSalesLine;

       while select SalesLineRefRecId from tmpPurchLinePrice

               where tmpPurchLinePrice.Included

       {

           relatedSalesLine = SalesLine::findRecId(tmpPurchLinePrice.SalesLineRefRecId, true);

           if (relatedSalesLine.DeliveryType == TradeLineDlvType::DropShip

&& relatedSalesLine.SalesDeliverNow != 0

)

           {

               relatedSalesLine.SalesDeliverNow = 0;

               relatedSalesLine.update();

           }

       }

   }

Risk is minimal and it would reduce number of database calls considerably.

Business impact:

Although impact of this unnecessary SalesLine.Update on demo environment is minimal with around 100ms of execution time

on environments with ISV solutions and customizations, sales line updates are regularly taking much more time. In our case, this extra update takes around 1000ms:

In some of the companies sales workers are creating almost exclusively sales order lines with delivery type Drop shipment. Due to this, sales workers are spending considerable time waiting for this unnecessary sales line update.

Inventory visibility features -timeline for Mandatory state since in Version 10.0.45 the State = On by default. Enablement and interdependencies of inventory visibility features, whether individual features can be enabled or disabled independently for the below features -

Enable warehouse items in Inventory Visibility

Inventory Visibility transaction integration

Inventory Visibility integration with ATP

Inventory Visibility integration with inventory adjustment offset

Inventory Visibility integration with inventory adjustment posting

Inventory Visibility integration with soft reservation on sales order lines

Enable warehouse items in Inventory Visibility

Inventory Visibility integration with reservation offset

Inventory Visibility integration

The Production floor execution interface doesn't allow us to specify which parent serial is to be scrapped on the operations prior to the final operation. The only time the interface asks for the parent serial being scrapped is on the final operation, but we need to know this information at each operation stage.

Not being able to do this impacts costing and factory visibility on which serials are the good/bad ones whilst they are on the shopfloor and could cause lots of confusion, especially on jobs with lots of operations.

Currently, when a purchase order line is cancelled, any markups or charges that were previously associated with that line remain included in the purchase order totals. This leads to an incorrect total value, as the markup from a now-irrelevant (cancelled) line still contributes to the PO total calculation.

This behavior can cause confusion and inaccurate financial reporting, especially when users rely on the purchase order totals for cost validation or approval processes.

Expected Behavior:

When a purchase order line is cancelled, any markups or charges linked to that line should be automatically excluded from the purchase order totals, ensuring that the total value accurately reflects only the active lines.

Business Impact:

Prevents incorrect financial totals on purchase orders.

Reduces manual effort needed to review or remove markups after cancellations.

Improves accuracy and transparency for users handling large or complex POs with multiple lines and charges.

Description:

Currently, the Customer/Item statistics report in Dynamics 365 Supply Chain Management retrieves data only from the InventTrans table. When inventory consolidation or archiving is performed, detailed transaction records are moved to InventTransArchive, and summarized entries are created in InventTrans.

As a result, when users run the Customer/Item statistics report for periods that have been consolidated, cost amounts appear missing or incorrect, since the report does not read from the archived or consolidated data. This leads to incomplete or misleading figures, especially for items or customers affected by consolidation.

Proposed Improvement:

Enhance the Customer/Item statistics report (or its underlying data model) to:

• Include data from InventTransArchive for relevant periods.
• Optionally, detect when the selected reporting range includes consolidation periods and alert the user.
• Ensure consistent cost figures across reports such as Inventory value report and Customer/Item statistics.

Business Impact:

This limitation causes reporting discrepancies that can confuse end users and require manual reconciliation or custom reporting solutions. Including archived data or adding a system notification would greatly improve accuracy and transparency in post-consolidation reporting, reducing support incidents and custom development needs.

‘Over tolerance’ field doesnot have 'Error' option in Mobile device menu item (WHM > setup > Mobile device) where ‘Work creation process set to ‘Good in transit item receiving’

System allows to proceed ‘Good in transit’ with the warning message (Warning message – you are about to complete an over receipt of 1 pcs) when user over receive PO quantity (instead 1 qty, updates 2 quantities) through Mobile devices against landed cost process since setup in Mobile device menu item (WHM > setup > Mobile device) has ‘Over tolerance’ field set to ‘Warning’ where ‘Work creation process set to ‘Good in transit item receiving’.

Expectation: Since only ‘Warning’ option available in ‘Mobile device menu item’s form for ‘Goods in transit item receiving’, expectation is to introduce ‘Error’ option, so that user will get blocked and will not be able to process Over receive PO quantity.