December 31, 2010

Happy New Year Everyone!!

Wishing everyone a happy, safe and prosperous New Year!!  May we all see great things happen for Dynamics GP in 2011.  Hope to see you all at Convergence this year.

December 28, 2010

GPTip42day - Victoria Yudin's new book - Microsoft Dynamics GP2010 Implementation

What a way to start the New Year!  Our good friend and fellow MVP has a new book out called Microsoft Dynamics GP2010 Implementation.  Victoria is extremely knowledgeable about Dynamics GP and has been a GP MVP for longer than I've even known what an MVP is.  She has taken her vast knowledge about GP and used it to create a step-by-step guide to implementing GP2010.  I'm going to read the book in the next couple of weeks and post a review here on the blog but I wanted to give you all advance notice that the book is available here - https://www.packtpub.com/microsoft-dynamics-gp-2010-implementation/book.

I'm really looking forward to reading the guide and whether you're getting ready to implement GP2010 or just want to learn more about it, I'm sure this will be a must-have for your GP library.

December 23, 2010

Merry Christmas, Happy New Year and Happy Holidays to Everyone!

May your holidays be safe, serene and restful and may your New Year bring you health, wealth and wisdom.  My best to each and everyone!

December 16, 2010

GPTip42day - Should I remove Discontinued Items when closing the Inventory series?

One of the options presented when performing year end close in the Inventory series is the removal of Discontinued Items.

Inventory>Routines>Year-End Close 

* click image to enlarge

Should you choose this option?  That depends.  Making this selection will remove the items from your Item Master.  It will also remove ALL TRANSACTION HISTORY from the Inventory tables for the items removed.  While you could still have access to some item history from the SOP and POP tables, that history would be limited compared to what's available from the Inventory tables.

Consider carefully, before making the decision to check this box, whether giving up the historical data is a fair trade-off for cleaning up your Item Master.

December 8, 2010

GPTip42day - Reversing the effect of erroneous PO Receipts

People must have their minds on the holidays right now.  There seems to be a rash of forum posts where users are asking how they 'undo' a PO Receipt gone wrong.  There are at least two answers to this question, depending on the GP version you're on.  If you're on GP10 and prior, then the solution is to perform a Return Transaction to undo the bad receipt.  Then, either add a new line to the PO, enter a Receipt without PO and notate the heck out of it to provide an audit trail back to the original PO, or enter a new PO, again with all the required notation.

However, if you're on GP2010, you're in luck!  When performing your Return Transaction, click the little check box under the Currency ID field that says 'Replace Returned Goods'.  Now when you post the transaction, the original PO quantity will be updated to reflect the quantity returned and now can be re-received.  Cool huh?  Works just like it always should have . . . 

 Purchasing>Transactions>Returns Transaction Entry

*click image to enlarge

December 6, 2010

GPTip42day - Why can't I see the Batch ID in SmartList after I post a GL batch?

This little quirk has to do with GP allowing you to use the same Single Use (as opposed to Recurring) Batch ID multiple times.  If GP stored the Batch ID (BACHNMBR) in the Open or History tables after the batch is posted, as it does in the Work table prior to posting, this could prevent use of the same Batch ID again.  Some (like me) might say this is a good thing because it would provide a solid audit trail between the batch and its transactions.  However, the current behavior does offer more flexibility in batch naming.

At any rate, if you need to see the Batch ID for a posted batch in a Financial Transactions SmartList, add the 'Originating Source' column to your SmartList.  That is where the Batch ID is stored permanently.