Showing posts with label payables. Show all posts
Showing posts with label payables. Show all posts

Wednesday, September 28, 2011

Hidden Gem- Check Distribution Report

Do you need a report to show you the invoices that were paid by a particular check?  How about viewing the distributions associated with the invoices that were paid by a particular check?  These are fairly common requests, and often lead to a bit of head scratching for users.  We look in SmartList, and there really isn't a great option (unless you have SmartList Builder-- but even then, you have to create it) since the relationship between a check and invoices can be one to many (one check can pay many invoices).

So when I get this question, and the client doesn't own SmartList Builder or they want a solution that is quick and easy, I point them to the Check Distribution Report.

Reports-Purchasing-Check Information-Check Distribution
Click New Option

When setting up the report option, you can restrict to a range of Vendor IDs, Dates, or Check Numbers.  You can also select to Include Dist Types, to include only PURCH type distributions for example.

Check Distribution Report


The report displays each check followed by each invoice paid.  The distributions appear directly below each invoice that is listed.  This report can be quite handy when trying to track back checks to their associated invoices. 

I know that similar information can be displayed using SmartList Builder, but this report is a great option when you need a quick solution and/or you don't own SmartList Builder.

Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a supervising consultant with BKD Technologies, providing training, support, and project management services to new and existing Microsoft Dynamics customers. This blog represents her views only, not those of her employer.

Friday, July 22, 2011

Zero Dollar Checks and Mekorma MICR

I recently had an interesting experience with zero dollar checks and Mekorma MICR.  But, let's start with a wee bit of background.  Dynamics GP generates zero dollar "checks" when an invoice is fully paid by a credit memo, manual payment, or other type of open credit.  This can occur in advance of a check run, or as the result of choosing to "automatically apply existing unapplied" documents during a check run (Transactions-Purchasing-Select Checks).

These zero dollar checks appear on the edit list after a check batch has been built, and serve as "placeholders" so a remittance can be printed as part of the check run as a record that the invoice was paid off using these credits.

So, consider the following scenario:
  1. Invoice entered and posted for $100 for Vendor ABC
  2. Manual payment entered and posted for $100, and applied to Invoice for Vendor ABC
  3. Transactions-Purchasing-Select Checks used to build check batch
  4. Regular checks picked up to be paid, as well as a zero dollar check for Vendor ABC
It is usually at this point in the process that you might panic, thinking, why is there a zero dollar check?  Keep in mind, it is merely a placeholder.  So if you continued with the process and chose to go to Transactions-Purchasing-Print Checks, this is where it gets interesting....

If you are using standard Dynamics GP, here is what happens:
  1. Transactions-Purchasing-Print Checks
  2. Only regular checks are printed, zero dollar check is ignored
  3. Post Payables Checks window appears
  4. Choose Post Checks, click Process
  5. Process Payables Remittance window appears so you can print the remittance for the zero dollar checks
  6. Choose Print Remittance Form, click Process
  7. Print the remittance
  8. Process Payables Remittance window reappears
  9. Choose Post, click Process
  10. Posting journals print
Pretty easy, right?  But guess what?  If you are using Mekorma MICR, the zero dollar check actually PRINTS with the regular checks.  Now the good news is, it is assigned a "REMIT" check number which means it will not post to bank reconciliation.  But it does confuse some folks when they see it print with the regular checks since it does not work that way with standard Microsoft Dynamics GP.

I just submitted a blog post to our new BKD GP Team Blog, http://dynamicsgpinsights.com/, with more detail on zero dollar checks and Dynamics GP-- so watch for it!

Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a supervising consultant with BKD Technologies, providing training, support, and project management services to new and existing Microsoft Dynamics customers. This blog represents her views only, not those of her employer.

Tuesday, December 8, 2009

Don't you go closing my year...

Just thought I would send out a gentle reminder of the major myths regarding year end closing in Dynamics GP. As I find they surface every year, even among users who have used the system for years. So here is my top five list, please post your comments and I will update the list accordingly.

I have to wait until I have ALL my adjusting entries before I can close the GL
This is the biggest myth of all. You can actually have your cake and eat it too. GP allows you to post to the most recent historical year. So, for example, if I close 2009 I can still post adjusting entries to it. I just can no longer post adjustments to 2008. The two requirements to post to the most recent historical year are that you must mark "allow posting to history" in GL setup (Tools>>Setup>>Financial>>General Ledger) and the fiscal period must be open in Fiscal Period Setup (Tools>>Setup>>Company>>Fiscal Periods).

I am running my general ledger year end close, and it is stuck
I promise you the odds are that it is not stuck. The year end close is a pretty intensive process, so it is fairly common for a workstation to show as not responding. Please be patient. Using Ctrl-Alt-Delete to cancel out of the process is NOT recommended, and will REQUIRE you to restore a backup. And if you don't have a backup, well, that is just not fun...and will involve a nice little database fixing service from Professional Services at Microsoft. So, two lessons: have a backup and be patient.

I can view all my audit entries because I set up an audit period
This is a popular trick, to set up a 13th period in your Fiscal Period setup with the same date range as the December period. You then close December, and with the 13th audit period open, transactions will post in to that audit period. Sounds brilliant right? Well, it is...as long as you never run financial reconcile (Tools>>Utilities>>Financial>>Reconcile) on that year. As it will reattribute the postings to the earliest period with the same start date (assuming both periods were closed when you ran reconcile) or all postings (including your original Dec postings) will be attributed to the open period (if the 13th is open, and the 12th is closed). Ugh. Better choice? Set up a source document code (Tools>>Setup>>Posting>>Source Document) called AJ for Adjusting Entries and select it whenever you enter an adjusting entry instead of GJ. Then use the Cross Reference by Source Document report to view your AJs for a time period (Reports>>Financial>>Cross Reference>>Source Document).

Fixed Assets year end is so easy, I just change the year on the book right?
Nooooo! You must run the fixed asset year end closing routine (Tools>>Routines>>Fixed Assets>>Year End) in order to close the year properly. Changing the year directly on the books themselves is not recommended and will require you to restore a backup if you process transactions in the new year if you do so. Also, keep in mind, Fixed Assets is one module where you must complete all activity for the prior year and close the year BEFORE you can process activity in the new year.

I can close Receivables and Payables whenever I get around to it
Unfortunately, the payables management and receivables management year end closes are not date sensitive. This means that you need to run them as close to the actual end of year (after posting as much of the prior year activity as possible, but before you have posted to the new year) to get the most accurate close as possible. Now, the good news is that these closes only impact the "Amounts Since Last Close" summary figures for current year -vs- last year that are tracked for reports, inquiries, and Smartlist. The close will move all posted transactions to last year (regardless of their actual date) for the summaries. And the current year bucket will start over with any transactions posted after the close, again regardless of their actual posting date.

For example, let's say that on 1/1/2010 I post an entry of $500 to payables and date it 1/1/2010. I then close the year for payables on 1/2/2010. That $500 will be moved to the last year column in the "Amounts Since Last Close" summary figures even though it was posted to the 1/1/2010 date simply because it was actually posted BEFORE the year end close. By that same logic, let's say on 1/3/2010 you enter another payables entry for $1000 and post it back to 12/20/2009. Since the close has already been performed, that $1000 will be tracked in the current year column for the "Amounts Since Last Close" summary figures.

For most folks, these amount to minor differences that they generally do not notice. However, keep in mind that if you are looking at a vendor or customer summary field in SmartList, it will be using the "Amounts Since Last Close" summary figures. And if you are looking at current year -vs- last year, there may be discrepancies for the actual detail.

Well, there is my mythbusting. Please share your own myths, and how you like to bust them :) Not sure how many more blog posts I will make before the little one arrives (January 7th is coming quick) so I will go ahead and wish everyone happy holidays!