Today’s #TipTuesday is a short one. Did you know you can multi-select Serial Numbers in Dynamics GP?
Today’s #TipTuesday post is a small tip, something to watch for if you have a G/L Account in Dynamics GP that is revaluing month after month despite having a zero balance in your functional currency.
Today’s #TipTuesday is not an application tip but a technical one.
Most Dynamics GP clients have one or more test companies or test environments. I’d be willing to wager that many have some standard scripting that is run when a test company is refreshed and may even automate it in a SQL stored procedure or job. There are at least 2 standard Microsoft scripts that should be run all the time: changing the db_owner to ‘DYNSA’ and the standard script to update company database references in the refreshed company db.
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!
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.
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.