Dynamics,Payroll,Data,Repair,N computer Dynamics GP Payroll Data Repair Notes and Recommendations pl

----------------------------------------------------------Permission is granted for the below article to forward,reprint, distribute, use for ezine, newsletter, website,offer as free bonus or part of a product for sale as longas no changes a Gone are those times when the companies and the organisations didn't need a hi-tech system to handle them. Owing to the considerable increase in the business sector and thus, an enormous increase in the complexity of the organisational struc

Data may become inconsistent when user posts large batch and all the sudden her or his computer crushes and restarts.  In this small paper we would like to concentrate on data repair technique in US Payroll module:1. Batch Posting Interruption.  First of all we would like to recommend you posting server as alternative to handle posting from potentially unreliable user workstation.  Or if you think that it is too complex, then consider closing other applications prior to hitting Post button and simply do not touch your computer until process is complete.  And here are typical side effects if payroll batch posting crashes.  941, FUTA and SUTA summaries and details might be off or some of them might take a long time to process and print.  When report generation takes unreasonably long time it is relatively simple to catch the table where data inconsistency happened.  Simply open Dex.ini file and enable logging.  These three lines should be set to True: SQLLogSQLStmt=TRUESQLLogODBCMessages=TRUESQLLogAllODBCMessages=TRUE2. Then log off GP and login with your user ID.  Rerun report and when it goes into limbo phase open file DEXSQL.LOG.  Scroll all the way down and try to make the judgment on what is going on.  Typically you see repeating cycles with the same employee ID.  Table where data is inconsistent might be recognized by Z prefixed stored procedure recorded in the log file.  Very popular table to become corrupt in posting crushes is UPR30300 named Payroll Transaction History3. How to do repair?  Of course if you are not considering yourself as experienced GP technical consultant it is good idea to find the one and have him do the job.  If you would like to try on your own risk then here are the steps.  First make table backup.  Then watch status window and log file as they should indicate employee number, date and other information about transaction.  Then design Select query in SQL Server Management Studio 2008, 2005 or Enterprise Manager Query Analyzer 2000 depending on your DB platform version.  If you are able to locate crushed payroll transactions then you are on the way to remove them.  When you have corrupt records removed go ahead and do check links as orphan records might be now residing in related tables4. Other popular data fixing questions.  As you know in 2011 Congress approved employee FICA contribution rate decrease to 4.2% while keeping employer portion the same at 6.2%.  If you are running Dynamics GP version which is currently supported by Microsoft Business Solutions the solution is simple as you just need to contact your VAR and have them apply recent Payroll Tax Update.  Please note that tax update requires also code update especially when you are on versions 10.0 and 2010 as original code accrues employee and employer contribution from the same record FICAS in UPR43102 table.  Historically here in the United States we had Social Security match principle and it was broken in January of 20115. Is it possible to update Payroll Taxes if we are on old version and do not have active annual enhancement plan with MBS?  This question has nuances.  You should understand that the fix requires code update and the code update which treats employee and employer contribution as separate rates was introduced in January of 2011 for the following versions: 2010, 10.0 and 9.0.  If you are on older version or one of these: 8.0, 7.5, 7.0, 6.0, 5.5, 5.0 or 4.0 then you should reduce your FICAS to 4.2 percent to make W2 accurate and then do GL entry level adjustment for employer FICA portion.  However it is possible to update your Payroll Tax tables from the system where recent Tax Update was applied assuming that you are on MS SQL Server DB platform6. What if we are on Pervasive SQL 2000/Btrieve or Ctree DB platform?  Tax Update could be done via ODBC connection in ODBC compliant tools, such as Microsoft Access or SQL Server Linked Server.  However the job is more complex comparing to SQL Server and it is unlikely that you have the budget considering the fact that you are on the old version which was phased out at least five years ago7. What if we are on Great Plains Accounting for DOS or Windows 9.5, 9.2 or earlier release?  It might sound funny, but all you need to do is to open payroll tax setup screens and update them as you probably do every December8. For additional information, please feel free to call us 1-866-528-0577 or 1-630-961-5918 (this number works for international customers) or email us [email protected] We serve you USA/Canada nationwide via remote support (web sessions and phone/Skype conferences). Local service is available in Western Michigan, Chicagoland, Southern California (LA, Orange County and San Diego), Houston area of the state of Texas