Comments
Thank you for the response. I understand the recommendation to use over/under delivery on the existing order line.The issue I am trying to raise is that, in practical intercompany scenarios, using over/under delivery does not eliminate the creation of additional intercompany supply/sales order lines. The variance can still result in extra system-generated order activity that then needs to be managed separately, which is the operational complexity this idea is intended to avoid.The value of the idea is to allow intercompany over/under variances to be resolved against the original intercompany order relationship, without creating additional intercompany supply orders or related sales order lines for the over/under quantity. This would keep the process cleaner while still supporting controlled over/under handling.If there is a supported configuration or process that prevents those additional intercompany lines from being created, I would be happy to review it. Based on the current behaviour, this remains the gap I am asking Microsoft to consider.
It would be essential for Outlook to be integrated into the CRM without having to use two different calendars to sync, which brings huge technical complexities and various glitches. The strength of the Microsoft ecosystem compared to other solutions lies precisely in the native integration of its components.
This request aligns with our requirement.In addition to bulk duplication, an important requirement is that the duplicated security objects should be created as new custom Roles, Duties, and Privileges without modifying or impacting the original OOB security objects.The solution should also preserve the full security hierarchy and relationships, including Role > Duty > Privilege relationships and the underlying privilege references.In our scenario, the volume is significant, around 73 Duties and 700 Privileges, so the current one-by-one duplicate option is not practical.The duplicated custom security configuration should also be exportable and importable between environments using a supported Microsoft approach, such as DMF or another supported mechanism.Please consider relationship preservation, custom object creation, and environment migration support as part of this enhancement.
Hi all,I just wanted to bump this once more, because I also believe that this feature is basically mandatory when doing any kind of performance tuning where blocks between different processes are involved.Without it, it is extremely cumbersome to identify the process that holds a lock on a ressource and makes analyzing it a huge timesink.I also wanted to mention that via Application insights, this feature is.. kind of there still? You can get the Callstack of the blocking process, but only if the process that runs into the lock timeout is on the same service tier as the blocking process.In an environment with multiple service tiers this is useless, as we do not know the process that holds the lock, and the sql tracing allowed us to quickly identify the process by simply turning it on and activate the "Debugger.EnableSqlTrace" for all sessions.Best regards,Stefan