Dynamics GP

When generating approximately 1,250 emails through Dynamics GP, the application exhibits a memory leak behavior. Memory is allocated in 16MB batches and continues to accumulate until the 2GB memory ceiling is reached, which is a limitation of 32-bit applications. Critically, this memory remains reserved even after the email generation process completes successfully. The only way to release the memory is to terminate the dynamics.exe process.

This issue leads to:

• Application instability and potential crashes in high-volume scenarios
• Inefficient memory utilization
• Increased support overhead due to required process restarts

Proposed Enhancements

1. Implement Post-Process Memory Cleanup
2. Introduce a mechanism to explicitly release memory once the email generation task is completed. This would prevent memory from remaining unnecessarily reserved and improve long-term process stability.
3. Enable Large Address Aware (LAA) Flag on dynamics.exe
4. Modify the executable to support the Large Address Aware flag. This would allow the 32-bit process to access up to 4GB of memory on 64-bit systems, effectively doubling the available memory and reducing the likelihood of memory exhaustion during large batch operations.

Note: This is a widely adopted best practice for legacy 32-bit applications running in 64-bit environments and can be implemented with minimal risk.

1. Long-Term Consideration: Transition to 64-bit Architecture
2. While enabling LAA is a short-term mitigation, transitioning Dynamics to a native 64-bit architecture would eliminate the 2GB memory constraint entirely and align the platform with modern system capabilities.

Impact

• Improved reliability during high-volume email operations
• Reduced manual intervention and support escalations
• Enhanced scalability for enterprise deployments
• Better alignment with modern Windows memory management standards

In the Build Payment Batch window, add Batch Number as a selection criteria in the Select drop down. This would allow users to enter different types of invoices for one vendor and pay only the invoices they put into specific batches. Or users could select only the invoices they had entered. Many uses.

Recently when a client was running the YE close routine in GL, a message appeared that the retained earnings account did not exist. She knew that the account in the YE close window did indeed exist so she closed the error message and thought the process would continue. The post to divisional RE accounts. However the YE close window did not close and remained on step 1 for hours before she contacted support. Meanwhile all other users were out of the system.

Because the box did not close, she thought it was still working. If a cleared message could appear or if the YE close window would close after this message it would prevent the user from thinking the YE close was still running.

Thanks,

Lisa

Working with a Customer who goes through extensive auditing due to SOX compliance. We found that Batch Approvals are only available for other modules. Would like to see either an option for Batch approval on the Sales Side so they can Automatically post when approved. Or make the Automatically post when approved option available on the Sales Transaction Approval workflow.

We want to use an SMPTP relay for a high volume of workflow related email notifications for a client. As soon as we configure an Application ID in the company email setup the workflow SMTP functionality stops working - prompting the end user to authentication using Modern Authentication - and erroring out with an MSgraph API error.

Give an option to remove inactive accounts from the look ups.

• Email column remains editable despite read-only settings
• Email column is not showing the updated value when using the setValue() method in JavaScript.

During the Select Checks process, when a user un-checks a selected voucher on the Edit Payment Batch window, GP does not automatically update the GL distributions, resulting in incorrect accounts and amounts. GP allows the batch to post with these incorrect amounts. This quality issue is not fixed in GP 18.8, and we would like it fixed in future versions.

I am using parallel sequences at the beginning of a lot of routings. As things change we have to add sequences and like to keep sequences in increments of 10. We have named our routings with "primary" or "alternate" as instructed by Microsoft consultants. We have found that the renumber program does not look at item/routing name combination, rather it updates all our "primary" routings and randomly changes the parallel "next" sequences. The next sequences are typically sequence 30 but the "flawed program" changes the next's to 40 sometimes, 50 sometimes, 60 sometimes. Our 600+ routings are messed up anytime we try to update the sequence of one item/name combination. Our company advisors Heartland Business Systems worked with Microsoft support for over 2 months and said it was not a bug but how the software was written. I was advised to submit this "enhancement" because it is a change being considered. I was not given the support case # but a lot of data was shared about this issue.We intend to use this software several more years and don't want to have to pay consultants to constantly fix this issue

.

User would like to have the option to sort by the date in the scrolling area of Inventory > History (Item History) window. Currently, in the scrolling area, the date is sorted from oldest to newest. The user would like if they could sort by date, so that the most recent date shows at the top of the list, and oldest date shows at the bottom.