ArcherPoint Dynamics Developer Digest - vol 137

ArcherPoint Dynamics Developer Digest - vol 137

The NAV community, including the ArcherPoint technical staff, is made up of developers, project managers, and consultants who are constantly communicating, with the common goal of sharing helpful information with one another to help customers be more successful.

As they run into issues and questions, find the answers, and make new discoveries, they post them on blogs, forums, social media…so everyone can benefit. We in Marketing watch these interactions and never cease to be amazed by the creativity, dedication, and brainpower we’re so fortunate to have in this community—so we thought, wouldn’t it be great to share this great information with everyone who might not have the time to check out the multitude of resources out there? So, the ArcherPoint Microsoft Dynamics NAV Developer Digest was born. Each week, we present a collection of thoughts and findings from NAV experts and devotees around the world. We hope these insights will benefit you, too.

Adjust Cost and Post Cost in Microsoft Dynamics NAV

Greg starts the conversation with this question:

“Has Microsoft made changes to the Adjust Cost/Post Cost since Version 5 which allows it to continue processing if it encounters an error or does it still error out and roll back to the beginning?”

Michael took a quick glance at R795 Adjust Cost – Item Entries and C5895 Inventory Adjustment and noted they reveal no COMMIT. “A large process without a periodic COMMIT at just the right points causes large overhead on the SQL Server to track the total transaction. I don’t think it would take much time to write a batch process for the Job Queue that would add a COMMIT for every item.”

Rick adds one minor update to this discussion: “A new concept was added in 5.0 (I believe) called Inventory Periods. One of the most common Adjust Cost error issues was the user did not have the ability to post back to a previous period, so the job would stop because of the posting date error.

With Inventory Periods turned on, this is no longer an issue. If Adjust cost needs to update a transaction in a previous periods (where G/L Setup does not allow the user to post to), then NAV will post the adjustment on the first day of the first open period.

This greatly reduces the number of errors that occur when running adjust cost. Most posting group/dimension related issues should have been dealt with when the transaction posted originally, so would only be an issue if someone has deleted that setup since the original transaction was posted.”

Later, Rick provides an update: “I am following up with Microsoft. I just tested in 2017, and inventory periods is not working the way it has historically worked. I created a receipt in 08/30/18, closed the Inventory Period. I then walked through the persons example where I left the posting open in August and posted the invoice in September. I received an error saying the inventory period was closed.

I then set my posting on both G/L and user setup, and tried to post in September, but got the posting date not in range (because it was trying to post back on 08/30. So I have sent in a support request to MS asking if they have changed Inventory Periods because what it is doing now is not good. I would have to open it up so it would let me post back into August, which defeats the purpose of Inventory Periods.”

And finally, Jon gets to the bottom of it. “In 2013R2 and greater, I’ve experienced results which suggest that Commits are happening after each Item is processed. I proved that by adding errors after each item for testing purposes on long running items (unrelated project). The item in question took hours to process. I was surprised to find that, when running the same item again, it took seconds. An error would typically result in rolling back all DB inputs, unless a Commit occurred, implying here, that a Commit indeed does occur during the Adj. Cost process.

I tracked it down to a Commit buried somewhere in one of the codeunits. The Commits are not obvious and are not in the usual Adj. Cost reports or codeunits, i.e., ‘R795 Adjust Cost – Item Entries and C5895 Inventory Adjustment.’

Also, I didn’t note the codeunit that had the Commit as I wasn’t concerned about it at the time. My intention was to ADD a Commit after each xx items, but, it turned out to not be necessary, since, MS has obviously already added them somewhere in the process.”

Leadership Lines

Consensus? No, Good Decisions Require “Respectful Disagreement”

At Toyota, “respectful disagreement” is one of the tenets of the Toyota Way. Toyota’s goal is to foster a culture in which diverse views get freely expressed, because they consider every worker’s own individual perspective to be an important ingredient for strengthening corporate decisions. The saying at Toyota is:

If two workers always agree, then one of them is redundant.

Stay abreast of what is new in the Microsoft Dynamics NAV community and at ArcherPoint by subscribing to our monthly newsletter, Better Business, by completing the form in our Resource Center.

And, if you are interested in NAV development, be sure to see our collection of NAV Development Blogs.

Trending Posts

Stay Informed

Choose Your Preferences
First Name
*required
Last Name
*required
Email
*required
Subscription Options
Your Privacy is Guaranteed