Comments
Until MS provides an alternate option. As a workaround, you can default a dummy dimension on Netting Journal. Because the netting transactions are reversed in this process, so there is no impact on dummy dimension and original invoice is settled with same dimensions which are there on invoice.
We have the same issue too with multiple clients. The clients have no requirement for catch weight but do want to be able to export on hand information by inventory status. It is particularly annoying that this entity requires catch weight when there is a separate set of entities specifically for outputting on hand information with catch weight.
There are other issues as well, like the revision number mismatch between the Agreement Booking Setup and the Booking Dates, which I am not sure why it's happening, but that's stopping WO generation, too. The workaround I followed was to change fields like pre/post flexibility date that trigger the booking dates generation.
Voting for this and adding a potential bullet point;I've had numerous process manufacturing clients that wish to validate 'built in quality' on production operations. Many of these also use PFE. A quality association where a result must be validated Before a job can be started would be a huge benefit for this configuration. In this case there is no inventory blocking, but only action blocking on the associated order/job (can't start). If this could be setup and then results input from PFE for the job it blocks, this would be a slam dunk.
MANY clients have subcontracted tasks that require additional fees (just as a typical receipt would) that need to be included into the cost of the manufactured items. Subcontracted manufacturing lines feel like an after thought in BC and should carry same options, functions and costing capabilities than your typical receipt lines so the costs and be properly rolled into the manufacturing costs.
We would like the default behavior of Event Registrations in Dynamics to be altered. Currently, when no existing contact match is found, the system automatically creates a new contact. This allows anyone to register and gain access to events that are intended solely for existing clients, which compromises access control and data integrity. A preferred solution would introduce a triage step, allowing registrants to be reviewed before a contact record is created and registration is confirmed. This mirrors the logic already available in marketing forms, where the creation of new contacts can be disabled if no match is found. If feasible, this functionality should be incorporated to Event Registration forms as a configurable option to support scenarios where stricter access control is essential.