Today’s #TipTuesday is a feature that was introduced in GP 2013 R2 and it’s an alternate way to assign multiple sites to an item quickly as well as some other Item-Site attributes.
Today’s #TipTuesday is a “back to the basics” tip. I wanted to cover off a few areas in G/L Account Maintenance that are often overlooked or that users are unaware of.
The first one, Allow Account Entry, is a favourite of mine because too often I’ve seen organizations with reconciliation issues that were caused by “rogue” journal entries posted directly to accounts that shouldn’t ever be posted directly to.
This #TipTuesday discusses the feature introduced in GP 2013 R2, the ability to reverse a Fiscal year-end close (i.e. re-open a closed fiscal year).
Generally speaking, there should be very few reasons why this is necessary in the first place, as you have the ability to post to the previous (most recent) closed year already, which I hope most people are aware of. However, there are a couple of situations where I can see this occurring:
- Some event requiring restatement of a year prior to the most recent closed year. Other than adjusting opening retained earnings, you could re-open the year to post exactly where you want this entry done and then re-close.
- Fixing issues where GL accounts were set up with the wrong posting type!
Hey, will you look at that? The community has been begging for updated documentation for Dynamics GP for a while now and who gets some love first? Canada! Woot! Woot! Ya baby…
Today’s #TipTuesday is a simple one that was introduced in Dynamics GP 2010. Recurring batches have been around forever, but the tiny, nearly unnoticed feature added in GP 2010 was the ability to clear recurring amounts, once the batch is posted.
Today’s #TipTuesday post is around writing off small customer balances. Year-end is a great time to perform some clean-up tasks if it’s not something you do in your normal monthly or quarterly processes. This post will cover off the default Dynamics GP “Write Off Documents” process that makes this one very easy.
Hey there, Dynamics GP Canadian Payroll clients! Welcome to January and the rare occasion where we have a hotfix for our payroll! Here is the link to the official Microsoft Dynamics GP blog with the details, I encourage you to read what is fixed in case it affects you!
I started this a year ago, after finally having a full year + of Google Analytics tracking on my site. This year, I moved my blog in early November to this new domain and website but I was smart enough to remember to turn on the Analytics from the beginning. What do they say about old dogs and new tricks?
I took a look back at what posts were the most popular through 2017, combining viewership from both kuntzconsulting.ca and this domain. 6 of last year’s top 10 return to make appearances in this year’s top 10, including a nearly 7-year-old post about ROEs in Canadian Payroll.
Here’s what I found:
Today’s story starts with a SQL trigger, and a Dynamics GP service pack which dropped the trigger, unbeknownst to me. Fortunately, I had planned ahead, not wanting to rely on my (or anyone’s) memory to remember to check for issues after installing service packs!
A few months ago, I had posted about the issue that led to this particular trigger in the first place. The short version is its sole purpose is to correct an issue in Dynamics GP that may or may not be a bug! This post is less about why the trigger exists in the first place and more about how to identify when a trigger has been dropped from a table.