Ahmed Abdelaal

We would like to add the functionality in the report to display the margin as percentage as well as the actual value being displayed.

Currently, for every transfer order, we create a Load to pick the necessary Items. Once the Load reaches the "Loaded" status, we proceed with the action Ship and receive > Outbound shipment. Following this, we go back to the Transfer order and print the Delivery Note from the Transfer order history.

We would like to add a possible implementation to be able to select "Ship and receive > Outbound shipment" from the Load and have the corresponding document (Delivery Note) printed simultaneously.

I'm creating this idea on behalf of my customer Delaware.

Customer is using KANBAN for their raw material replenishment in production. However, the items produced are weighted average cost controlled, hence once she uses the kanban rule, the system triggers the error message "The item must be standard cost controlled".

As per the KanbanItemCheck, generally, all items that are used with kanbans must be standard cost controlled. The exception is a withdrawal kanban that updates inventory on issue and receipt.

Basically, the business scenario is that someone scans an item and then, this should create a trigger in warehousing to bring the goods.

However, the customer is unable to do so and we need to know if the mentioned scenario would be supported in the future releases or not.

Over production is not supported in D365 unless "accept error" is enabled.

Error message will always be thrown unless the accept error is enabled, however, for shortage, it works fine.

The issue was found before in AX2012 where "Accept Error" was added as a fix, however for business reasons, the option is not feasible with our clients.

Client business impact:

“There are many operators working at the same time on the batch orders on the customer site. Accept error allows a wide range of mistakes like:

• Not posting the picking list or route card journal
• Report as finish the amount much more than the started quantity (simply by adding one 0 to the end of the number or any other mistakes)
• Report as finish the amount much less than the started quantity (even like 1).

That is why the customer declared that the Accept error option is completely out of their solution.

The customer does QC during operations for every batch order and based on specific criteria they might add some more substances (like water). That is why a small percentage of surplus should be possible.

The only remaining work around would be that they Report the same quantity as start and do the counting. But this will be a lot of effort since the number of productions they should do every day is a lot. Also, the costs related to production won’t be accurate.

BUG#964015 was raised where PG added the following:

• Quantity validation is PFE (MES) specific settings, which are not taking effect in the standard production order flow.
• Integrating those validations would be quite a bit of work for us, and we are not sure if other customers would want this functionality. 
• For the customer, it would be easier to develop customization to integrate the validations into the standard flow.
• The setting is under Production order defaults, under Manufacturing Execution tab, which means, it's MES (Manufacturing Execution) specific, and is not designed to be working when you use "All production orders" form.
• Currently, in the standard production order flow with using 'All production orders' form the only way to do overproduction (that's essentially what they are trying to do: to produce more than they started) is only possible by using Accept Error = Yes.

Therefore, we are logging this idea for considering a design change in the future releases.

• Using Adjustment function in T&A we want to adjust pay category on weekly basis.
• Setting up Adjustment line on the pay agreement with period code week. But when doing so, there is an error when transferring the day form Approve form when the day have a negative pay item that’s also used in the adjustment lines.

• Error: It’ ALWAYS make an adjustment with the exact negative number but reversed to a positive value.
• Code snippet from D365 shows that the class is calculating based on MAX which will always neglect -ve adjustments.

If a user starts production order from all production orders and then start it again from PFE, quantities reported in BOM journal will be doubled.

PFE will show that the quantity specified for the route operations is zero, even if they are displayed in BOM in the production order form.

This leads to discrepancy in cost valuation for quantities and machinery and will also cause variance between estimated and reported quantities.

Referencing work item 734127 as product group has added that it is a product limitation.

Users have issue with using production floor management interface as they are unable to properly release production order lines to warehouse.

Issue lies within the available quantity in the inventory.

Each time a production work or wave has been cancelled/amended or any time a production order is released to warehouse really meaning all the time.

Proposed workarounds were resetting status of production orders which is not always feasible as the items might be reserved or work might be closed. User has to do that manually for each order, while users are RAF orders in using batch and manually adjusting the orders after RAF.

We were advised to collect business impact and votes and based on this; product group can consider the need behind adding a design change request.

Customer has extended at a customer our ItemIdBase data type from 20 to 60 characters.

It all goes fine within D365FO until we try to Release a sales order to the warehouse for an item number with a length of 60 characters.

However, as this is a platform kernel issue, PG concluded that it is less likely to be changed from code point of view.

Customer posted on Yammer to raise awareness in case multiple users can benefit from this additional functionality and we have raised this idea for the same to be tracked internally.