0
Category:
STATUS DETAILS

Comments

Thanks for this idea Maria! We and a lot of other implementation partners and customers all still have the same issue and I had created the following post in Viva Engage lately and was told to create an idea, which, as I found out, is already existing. Therefore I create this comment with the detailed info from my Viva Engage post.Weber, Jürgen on Viva Engage: "Multiple usage of the same operation in one route" Posted in Manufacturing on Jan 7, 2026Multiple usage of the same operation in one routeWe have again the issue that we can not use one and the same operation multiple times within one route, because if we do that fields and setups like the run time and the resource are always the same for each of the operations.This restriction however only applies when we setup the route under "All Routes" or directly from the released product. Here the following underlying tables are involved - Route, RouteOpr, ProdRoute, Once we have the production order created the behavior for the individual route of the production orders is different! We can e.g. enter further new operations with the same operation ID and indicate different run times and resources. Now we would like to get rid of this limitation already with the setup of the base data. The workaround to name the operation IDs with a pre- or suffix Number is suboptimal. Are there any other workarounds that we are not aware of or have any of you customized that behavior already? Or is perhaps MSFT thinking about improving this behavior in a future release?Thank you very much!

Category:

Praticamente todas as empresas já estão recebendo entrada de notas modelo 62. É essencial que o sistema permita a entrada desses documento e que esse documento possa ser escriturado no Fiscal Books e enviado no SPED Fiscal / SPED Contribuições.Dener.

Category:

Related issue: https://fix.lcs.dynamics.com/Issue/Details?bugId=348301&dbType=3&qc=6bfbed47897bba28238d809b4dc4afb8f4255175f29800bb51c097fad96ba93c

Category:

Opening pages in Read mode by default helps prevent accidental changes and keeps data accurate, while still allowing edits when intentionally needed. I've already witnessed a couple of instances where a vendor or customer name has been changed accidentally.

Category:

This feature would help my organization protect data from accidental mistakes. Allowing a developer to modify the default behavior on a page is helpful, but it limits who can use this feature. I believe this should be a configurable setting that is available as a personalization. That would enable each user to turn it on/off as needed for their work or to be used as part of a Profile (Role). Enabling this feature in a Profile (Role) would be how we implement it on our key master data pages.

Category:

This will improve our Shop Floor module by allowing an operator to select the actual machine they are running the product on.

Category:

This will improve our Shop Floor module by allowing an operator to select the actual machine they are running the product on.

Category:

This will improve our Shop Floor module by allowing an operator to select the actual machine they are running the product on.

Category:

Would make them truly advanced if we can import the notes!

Category:

We have also received this request from our customer. Without the ability to filter by record identification, it is difficult to find a specific purchase order, for example when reviewing changes.

Category:

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 500