Posts Tagged ‘Backup’
Hello all, I would like to provide you with some information on what to look when Dynamics GP seems to be working slow. As you may already know Dynamics GP is a process driven application and you may experience slow performance when specific processes are performed in GP please take a look:
· While posting might be due to the PJOURNAL table as you know checks post too or remittance is being printed separately
· Client workstations should have a default printer setup and online, remove invalid printers
· While opening windows, the autocomplete feature may cause performance issues and if not used can be turned off
· While login into Dynamics GP or utilizing 3rd party dictionaries as well if Menu Master table (SY07110) became too large.
· The location of the modified dictionaries other than local workstation
· Certain Smartlist reminders might interfere with login into Dynamics GP
· You may have shortcuts to network locations that are no longer mapped or available
· Printing to file directly into the client/remote computer instead of the hosted server user folders
· OLE Notes path in Dex.ini
· SQL AutoClose and AutoShrink options not set to false
· Virus scanner setup not excluding the following extensions (CNK, DIC, CHM, SET, INI, DAT, IDX, VBA, LOG, LDF, MDF)
· The Dynamics GP homepage smartlist favorites
· The Dynamics GP homepage outlook integration
· Enabling tracing options in DEX.ini
· Bad user defined triggers in SQL
· Bad configuration of SQL server memory allocation
· SQL server or Dynamics GP server available disk space
· SQL server log file is full and is not set to Autogrow
· TNT*.* files, your %TEMP% folder has not been cleaned
· Non-compliant SQL server/GP Server/Client hardware
· Different DB owner than DYNSA
· Little or no SQL server maintenance (Table Fragmentation)
· You might be missing table indexes or statistics
· When exporting a budget, thru the budget wizard it seems locked (if you are using the excel wizard to export, make sure the “save as” dialog is not on the background, Alt-Tab to it as it must have been opened and its behind your main GP windows.
· Too much history (You can archive historical years, specially if you have large tables like Item Master, Customers, Vendors) Believe me I ran reconcile one time and it took 6.5 days on a company with more than half a million SKUs and 5 years of sales.
I have witnessed how few administrators that in order to preserve enough disk space they have a tendency of running SHRINK on the SQL server, this obviously will fragment tables affecting performance. I have a post that covers that here.
If you want us to take a look at your environment don’t forget to contact us, and as always when troubleshooting record answers for the following questions:
1.- Can you replicate the issue? write down steps that let you reproduce the issue.
2.- If its related to posting, please note the module( s ), how many transactions are in the batch, how long does the process last? how long did the process last before?
3.- On a Server/Client install, can you replicate on the server?
4.- Can you reproduce on all or other clients?
5.- Are there any 3rd party products running on the same SQL/GP server or together with Dynamics GP?
6.- Are there any customizations in GP?
Until my next post and let us know if we can help!!
Francisco G. Hillyer
So just like every year we go thru similar steps, I am providing some help along the way, many of the processes described here belong to a published KB from Microsoft as well links to posts from other resources but I wanted you to have them all in one place.
Please note that some of the links require you to have access to Customersource/Partnersource.
Difference between Year End Update and Payroll Tax Table Updates
The Year End Update download contains software changes to allow you to comply with 2012 filing requirements as well as the most recent fixes for your Dynamics application.
The 2013 Payroll Tax Table Updates contains updated rates and tax changes as well it might contain FICA/Medicare changes to be applied when processing 2013 payrolls.
Here is the link for the 2012 US Payroll Year End Update: Click Here
Here is the link for the US Payroll Tax Updates: Click Here
It is important to mention that you can install the Year end update prior to your last payroll for 2012, however do not install the Tax table updates before your last 2012 payroll as you might end up with a wrong calculation.
Always backup your data, your .DIC files as well.
Setting up / Adjusting Fiscal Periods in GL
Microsoft provides a KB article number 871679 KB871679
Closing Dynamics GP GL
STEP 1: CLOSE ALL OTHER MODULES
Complete the posting/closing procedures for the modules in the suggested order prior to closing GL, please note that if you are not using a particular module, just skip it:
Follow the instructions provided in each KB
Inventory: KB 872713
Receivables Management: KB 857444
Payables Management: KB 875169
Fixed Asset Management: KB 865653
For Microsoft Dynamics GP 10.0 Service Pack 2 and greater, functionality was added to consolidate balances for dimensions in Analytical Accounting. Please review KB 960356 to make sure you have properly marked the dimensions that you want to be consolidated during the year-end process. Please note that there is no separate year-end process that needs to be run in the Analytical Accounting module. When the year-end close process is run for General Ledger, it will automatically consolidate the balances and move the transactions in Analytical Accounting for dimensions that were properly marked.
PAYROLL year end procedures are independent of the procedures in other modules and are usually performed at the end of the calendar year. Please see this KB 850663
STEP 2: POST FINAL ADJUSTING ENTRIES
Adjusting entries are considered most of the time as entries that allow you to correct errors that were made when transactions were recorded as well they might be utilized to assign revenues or expenses to period or periods in which revenues were earned or expenses incurred.
If you need to in setup or adjust your fiscal periods in GP, please review the section “Setting up / Adjusting Fiscal Periods in GL” at the beginning of this article.
STEP 3: VERIFY ACCOUNTS POSTING TYPE
The posting type helps Dynamics GP determine whether an account will be closed to the retained earnings account or if the account balance will be brought forward to the next fiscal year.
Follow these steps to print an account list:
- On the Reports menu, point to Financial, and then click Account.
- In the Reports list, select All Accounts, and then click New.
- In the Option box, type all accounts.
- Click to select the Inactive Accounts check box. (if you want to delete inactive accounts)
- Click Destination to specify a report destination, and then click OK.
- Click Print.
STEP 4: CLOSE FISCAL PERIODS FOR 2012 (OPTIONAL)
Use the fiscal periods setup window to close all fiscal periods open for the 2012 year. This will prevent transactions from posting to the wrong period or the wrong year.
NOTE: If you still use Microsoft FRx, keep one period in the most recent historical year open to prevent the error: “FRX Print Engine Failed to Load the Company Calendar” see this KB 874932
STEP 5: PERFORM MAINTENANCE ON FINANCIAL SERIES (OPTIONAL)
Run the check links procedure on the financial series group of modules.
Make sure that you always have a backup and that you can confirm you can restore from it.
STEP 6: VERIFY SETTINGS IN GL SETUP WINDOW
If you are like me and always want to keep historical records, you must enable the checkbox next to Accounts and Transactions in the Maintain History area of the General Ledger Setup Window.
NOTE: If for some reason you have the checkbox enabled for “Close to Divisional Segments” and you are no longer closing to Divisional Segments or by mistake someone else enabled it and not using it pay attention:
I have discovered in the past a BUG in dynamics GP that is still there as I reported in this blog in August 14, 2012, if you would like to read more about this important step please click here: YEAR END CLOSE BUG 64711
STEP 7: MAKE ANOTHER BACKUP (OR BACKUP IF YOU HAVE NOT)
Make sure all users are out of the system
Remove stranded user sessions, you can follow this post Removing Stranded Sessions
Backup DYNAMICS database
Backup all company databases if you are unsure which databases to backup you can query the company master table (SY01500) and retrieve the names, the following script can help you determine that information.
select INTERID, CMPNYNAM from dynamics..sy01500
Make sure to backup as well the Dynamics GP code folder
STEP 8: PRINT A TRIAL BALANCE REPORT (OPTIONAL)
Use the Trial Balance report window to print a year end detailed trial balance report. Even when this step is optional it is highly recommended to be followed.
STEP 9: PRINT YEAR END FINANCIAL STATEMENTS (MR, FRx, Other)
Print any year end financial statements that are required. The most common are:
- Balance Sheet
- Profit and Loss Statement
- Statement of Cash Flows
- Statement of Retained Earnings
STEP 10: SETUP A NEW FISCAL YEAR
Before you can perform the year end closing routine, you must setup a new fiscal year, please follow the instructions on the section at the top of this article to Setup or Adjust Fiscal Periods.
STEP 11: CLOSE THE YEAR
- Click on the Microsoft Dynamics GP Menu > Tools > Routines > Financial > Year End Closing.
- If its not specified, you can key in the Retained Earnings Account.
- Optional: Specify the Starting Journal Entry
- Click on Close Year
STEP 12: BACKUP YOUR SYSTEM
Make another backup of the Dynamics DB and all the company Databases.
Thank you for reading I would like to mention that this post enhances Microsoft KB 888003
Until my next post
Francisco G. Hillyer
A client called yesterday and were in a bit of a tizzy. They processed payroll last month and in the middle of things GP crashed. They said a few cuss words, logged back into GP then continued processing. When they went to do their period end reports they were a little taken back because gross wages was off by $13,000,000. I had to write that out just to see how many zero’s that is.
A few questions came out of the CFO’s mouth such as:
- How could this be?
- Did they really send a check out to an employee for that amount?
- Is our bank reconciliation off?
- Is our GL amounts off?
We discovered an employee with the below information:
They chuckled a bit but I don’t think they found my comments to helpful.
The payrun that caused this was of course two weeks ago so restoring from a backup was not really an option. This made me pull out my SQL skills and go to work. I used tech doc 948268 to resolve the issue but here are the basic steps:
- Backup Company databases
- Make sure you backed up the correct company database
- Delete the payrun in question from the following tables using these scripts. Replace XX with the correct Audit trail code. delete UPR30100 where AUCTRLCD=’XX’ delete UPR30200 where AUCTRLCD=’XX’ delete UPR30300 where AUCTRLCD=’XX’ delete UPR30400 where AUCTRLCD=’XX’ delete UPR30401 where AUCTRLCD=’XX’
- Delete the employee’s summary information by using this script, replacing YY with the employee ID and ZZZZ with the year in question. delete UPR30301 where EMPLOYID = ‘YY’ and YEAR1 = ‘ZZZZ’
- Run Reconcile in payroll – Point to Tools on the Microsoft Dynamics GP menu, point to Utilities, point to Payroll, and then click Reconcile.
- Deal with bank reconciliation module and GL as necessary
I ended up deleting one table that had 450,000 rows duplicated for one transaction. Thus the 13 million dollar employee card.
Now the real question is should a backup be done before processing a payroll batch? The answer is a resounding YYYYYYYEEEEEEESSSSSSS!!!!! Does that mean everytime? Let me be clear. Everytime you process payroll you are at risk of having your payroll module blow up. The above was a fairly easy fix compared to what can happen. I wish I could be more upbeat about how great GP is and how solid payroll is as a module.
Another thought. We have a couple of clients that all they do is payroll. They process thousands of transactions a week and in any given day they have several people posting payroll batches. To back up their database takes 10 to 20 mins. To do a backup each time is not really feasible. So after explaining the situation clearly they have decided to risk a days worth of work for irregular event of having the payroll module messed up with a posting interruption.
Talking with Mike from our office about this event and he told me how he fired someone when he was a controller when they processed payroll without doing a backup. The one and only time they didn’t have a backup resulted in heartache, gnashing of teeth, Mike flying off the top ropes with a 10 key….you get the drift.
Here is a link to backing up your GP system.
Please consider making a backup before processing your payroll. One time in a thousand you’ll actually need it but you’ll thank your lucky stars when you do.
I’ve been a lazy blogger the past month or so. Seems like my writers block coincided with our move to our new blogging location on RoseBizInc.com so hopefully this entry will get me back in the spirit. If I fail miserably to excite, inspire, inform or educate anyone who reads these blogs please don’t tell me so. I’d rather live in a spirit of happy ignorance than to really hear your true opinion.
Had an interesting happening a few weeks ago. Had a client that has project accounting, purchasing etc. We were seeing some rather interesting results in the POP module so we ran check links on the purchasing transaction table. No problem. We then ran it on the purchasing historical transaction table and let it run during the night. Looked at it in the morning and noticed a check links report that had 4500 pages of removed historical transactions. Yikes. If you don’t know GP:
1. Why are you reading this blog
2. That is not a good thing
3. Check links is sometimes refered to as “Break Links”. It’s a tool used to verify data in the tables and will either say it’s all good, add back in info that’s missing, or remove data not needed.
So no sweat, lets restore to last nights backup. System guys says, cool, I’ll let you know when it’s restored. Now in this situation what would be the worst possible thing that you could hear when you pick up a call from the systems guy. In my case it was “uh, we got a problem.” Turns out they have been doing backups to the same tape drive for the last month. Each night it wrote over the previous nights backup. And when they went to restore the backup some how they managed to delete their one and only backup for the last month and a half. Turns out the guy responsible for backups was in Costa Rica on vacation for another week so…. It’s funny now that I look back on it.
There’s more to the story but I’ll leave this post with a moral:
When in doubt (or even if you are not), BACKUP, BACKUP, BACKUP your Dynamics GP system. Here is an older post I did about backing up GP in case you want to make sure you are backing up all aspects of your GP system.