Comments
Another reason for changing the current state in BC is the situation with renaming a user specified in Job Queue Entry via Codeunit9800 User.RenameUser. Even though the original user ID (already renamed) remains the same in Job Queue Entry, after renaming, the task starts running under a different user—the one who performed the renaming. I have already added my voice to this, there are already many applicants, so please: Change your behavior in this area. Thank you.
I am reaching out to kindly request a reconsideration of the previously rejected feature proposal related to Microsoft Dynamics 365 Business Central.In our customer projects, we regularly face the need to procure external resources and allocate them accurately within the project cost and billing structure. This is a recurring requirement across multiple implementations. The absence of this capability in the standard solution forces us to rely on workarounds, customizations, or manual processes. These approaches introduce additional effort, increase the risk of inconsistencies, and reduce transparency for both partners and customers.Enabling this feature would significantly improve project accounting, enhance the usability of Business Central in service-oriented scenarios, and reduce the need for extensions that solve a common and recurring business need. From our perspective, this functionality is not a niche request but a core requirement in modern project-based businesses.We would highly appreciate it if you could re-evaluate this request and consider including the feature in an upcoming release of Business Central.Thank you very much for your time and for continuously improving the product. Please let me know if additional details or use cases would be helpful.
hi, This is a highly needed feature for us today. We are managing 10 live environments with potentially more to come. We need to be able to easily rollback deployments when something goes wrong during a monthly release.Currently, Business Central SaaS does not support direct rollback of extensions or environments after a failed deployment. Downgrading an app version requires manual uninstall and reinstall steps, and environment restores create new instances rather than reverting in place. This makes recovery slow and operationally complex for large organizations managing monthly release waves.It is a critical subject for enterprise customers managing frequent updates and customizations.
Below are the steps and settings required to reproduce the situation described above (images are not included, so the example is less detailed).We use three items:S00016 – Bicycle brake (rear)S00017 – Bicycle brake (front)W00008 – Bicycle brake (final product)Step 1: Item SetupOn the item card for S00017, the Reserve field is set to Always, so the system automatically reserves available inventory.Step 2: InventoryWarehouse PODSTAWOWY has 94 units of S00017.Step 3: First Prod. OrderCreate a Released Production Order for 94 units of W00008 and refresh. All 94 units of S00017 are reserved, confirmed in Reservation Entries.Step 4: Second Prod. OrderCreate another Released Prod. Order. No reservation for S00017 occurs because all units are already reserved.Step 5: Posting Without ReservationAssign lot/serial numbers and post consumption/output for the second order. A warning appears:“Reservation entries exist… Posting may result in negative inventory. Continue?”After confirmation, posting succeeds. The order shows 1 unit produced, and Item Ledger Entries confirm consumption.Step 6: Finish StatusChange the second order status to Finished; system confirms.Step 7: Impact on First OrderThe first order still shows reservations for 94 units, but only 93 units are available, and remaining quantity is 0. Despite reservations, inventory was consumed by the second order, making full execution of the first order impossible.