web
You’re offline. This is a read only version of the page.
close
  • Purchase order, Purchase requisition workflow escalation follow the position hierarchy.

    Business process required to have approval from multiple level of management,


    Set up as below on D365:

    Position Hierarchy: A > B > C > D > E

    Signing limit for each level of management:

    • Greater 1000 required approval from: B only. 
    • Greater than 10.000 required approval from: B and C.
    • Greater than 50.000 required approval from: B, C and D.
    • Greater than 250.000 and so on required approval from: B, C, D and E.

     

    Scenario 1: A submit PO with amount 55.000 required final approval from D

    • Actual result on D365: A submit > B time out > escalate to D > D approve > route to C > C time out > D approve > final route to D for final approval
    • Expectation: A submit > B time out > escalate to C > if C time out then auto reject - if C approve > route to D for final approval

     

    Scenario 2: A submit PO with amount 300.000 required final approval from E

    • Actual result on D365: A submit > B time out > escalate to E > E approve > route to C > C time out > escalate to E > E approve > route to D > D time out > escalate to E > E approve > route to E for final approval. 
    • Expectation: A submit > B time out > escalate to C > if C time out then auto reject - if C approve > route to D > if D time out then auto reject - if D approve > route to E for final approval.


    From the actual result, we can see that the person with signing limit privilege have to approve the same PO multiple time, since the workflow always route to that person based on the signing limit, we would like to seek for development that workflow escalation path will escalate the workflow based on the position hierarchy that set up.

  • Auto update Marking quantity through related orders.

    Scenario:

     A production order was initially set for 10 units, and this production order have Marking with a transfer order with the same quantity > Marking for 10 quantity.

     

    Later on, the production order report as finish quantity for 11 units, reflecting real-world scenarios where the final product may exceed the planned specifications in weight, length, etc.

     

    Expectation:

    We are looking for a feature that would automatically adjust the marked quantity in the transfer order to match the reported finished quantity.

     

    This means, if the finished quantity is reported as 11, the transfer order should also reflect 11 units, ensuring the marked quantity is updated automatically accordingly.

     

    Current design:

    The system currently maintains a marked quantity of 10 for the transfer order. While the additional quantity can be found on the production order, it requires manual adjustment to mark the additional quantity.

  • Add option for user to return or skip the Wi-fi signal error in warehouse application.

    Issue description:

    Occasionally, users may experience a Wi-Fi signal error in the warehouse application when transitioning to areas with weaker Wi-Fi signals. Currently, the error messages do not provide an option for users to bypass the error or return to their previous task.


    Work-around:

    User have to close the application then re-open and start the task from the beginning.


    Idea propose:

    On the Wi-fi signal error, there should be an option "return" or "skip" for user to get back to their last task, this would allow users to either go back to their previous task or bypass the error and attempt to connect to a stronger Wi-Fi signal to finish their ongoing task.

  • Cost amount calculation for inventory movement journal need to be consistent.

    Cost amount calculation for inventory movement journal need to be consistent.


    Using moving weight average item model group,


    This particular issue arises only with costs that have decimal representation values. Please review below example for clarity:

     

    Consider two items with the same moving average setup scenario:

    - For Test1 item: Purchase 5 units at a unit price of 3, resulting in a net amount of 15.

    - For Test2 item: Split into two purchase order lines - the first line with 5 units at a unit price of 3, and the second line with 5 units at a unit price of 0. This results in a net amount of 15 for 9 units.


    The average unit cost for Test1 item is 3, 

    The average unit cost for Test2 item, it's approximately 1.67 (rounded up from 1.666666666666667 = 15 / 9).


    When issuing out 4 units from each item through a movement journal:

    Test1 item shows a cost price of 3 and a cost amount of -12.

    Test2 item shows a cost price of 1.67 and a cost amount of -6.68.


    Post the movement journal > go to Inventory Transaction to review:

    Test1 item > -4 QTY > Cost amount -12

    Test2 item > -4 QTY > Cost amount -6.67


    Seem like the cost amount calculation on journal line level and inventory transaction level didn't match.

  • Planning optimization need to run for Gross forecast only.

    Actual result:

    Currently when run planning optimization, planning optimization will always include safety stock quantities, transfer requirement (Doesn't have any option to disable in master plan set up)


    Therefore, after execution, planned order will include the safety stock quantity, transfer requirement quantity and demand forecast quantity in the required quantity.


    Expectation:

    We would like planning optimization to generate planned order required quantity for the demand forecast quantity only.


    We need to have master plan's set up or parameter to exclude safety stock quantity, required transaction quantity, so that we can see the planned order result for the demand forecast quantity only.


    Business requirement and impact:


    Business operates primarily on a make-to-stock basis and has limited raw material storage, often only covering 1-2 days. Our replenishment and site teams depend on forecast visibility of raw material usage to notify suppliers accurately, aligning with production needs and storage constraints. Currently, the settings are incorrectly inflating short-term raw material requirements, impairing visibility and the replenishment officer's ability to estimate the necessary raw materials accurately.


    The result planned order of planning optimization impacting replenishment team and the ability to foresee the required quantity for multiple operation sites.




  • Rebate management deal not consider for movement journal quantity.

    When a new customer migrates to Dynamics 365, they often need to add their available stock to the D365 environment. Typically, customers use movement or counting journals to add on-hand inventory, which is still considered for rebate deals.


    After setting up a rebate deal and running the rebate workbench, an error occurs for items added using the movement journal. The error message states: "The inventory quantity or item %1 is zero, so the rebate amount will be zero."


    This error originates from the TAMRebateJournalTransSalesInvoice class, specifically in the calcAmoutPurchLastest method. A code review indicates that the rebate calculation only validates amounts from the VendInvoiceTrans table, which is based on the latest vendor invoice transaction from the purchase order invoice journal. Since the customer uses the movement journal to add on-hand inventory, no vendor invoice journal is created.

     

    This issue occurs only for new customers migrating to Dynamics 365. Therefore, we seek new development to calculate rebates that consider movement journals or counting journals as well.


    Thank you!

  • Consolidate replenishment work.

    Currently when execute replenishment mix/max, D365 will generate multiple work headers as below example:


    • Work ID 1: pick product 1
    • Work ID 1: put product 1
    • Work ID 2: pick product 2
    • Work ID 2: put product 2
    • Work ID 3: pick product 3
    • Work ID 3: put product 3


    However, this setup requires each work ID to be picked and put individually, which is not an efficient way to perform work in a warehouse.


    We would like to seek for an option to consolidate the works, for example:


    • Work ID 1: pick product 1
    • Work ID 1: pick product 2
    • Work ID 1: pick product 3
    • Work ID 1: put product 1
    • Work ID 1: put product 2
    • Work ID 1: put product 3


    This change would significantly improve efficiency in the warehouse by reducing the number of individual pick and put actions required.

  • Resource time on planned production order not getting recalculated after split

    This is happening on Planning Optimization


    When split quantity of a planned production order, the resource time on the original planned production order remain the same, with less quantity, the resource time should be recalculated, not remain the same resources time of the original quantity before getting split.


    Only the resource time on split planned production orders got recalculated correctly.


    This behavior causes incorrect forecasting and disrupts labor, happen every time we try to split planned production order.


  • Sales Order Header v4 - Number Sequence issue during Data Import using auto-generate sales order number field

    Currently, unable to import sales orders using Sales Order Header V4 entity in Data management.


    When enable auto-generate for SalesOrderNumber staging field, and try to import, encounter error:


    "Issue exist in generate staging data

    issue exist in auto generation of number sequence

    Number sequence is not set"



  • Option to review all the records moved in Archive with Dataverse long term retention job.

    Currently, after a archive job completed, it's showing in Result column that how many records moved, but, if we go to View history data, less records showing.


    For example, create a archive job to store all Sales order for the last 2 weeks > archive job completed > showing on result column 11 records moved > when go to View history Data > only 2 sales order showing.


    We need an option to view the information of the Result column, why it's calculated as such records, and which tables are the records coming from.