Lesson Learned- Importing Tax Details

Last week, a client asked if they needed to manually set up 100 tax details in Dynamics GP.  We are in the testing phase, so I knew it wasn't a matter of setting these up once...but twice if we did it manually (for the live database and for the test database, which couldn't be restored at that point due to other dependencies and testing).  So I did what I shouldn't have done.  I said, "Sure, we can do a quick table import".  Now, to be clear, the issue is not using table import.  It is that I used the work "quick".  (For those of you not familiar with table import, Mariano Gomez has a great blog post on the subject.)

So I took a "quick" look and imported the tax info to the Sales/Purchases Tax Master (TX00201).  When importing to this table (first lesson learned), first set up a record manually so you can see the proper settings for all fields (there are many that are not obvious and need to have the correct defaults set in the import).  Well, that was quick.  One table, check links (Microsoft Dynamics GP, Maintenance, Checklinks, Company), done.

Well, not so quick.  When users entered transactions using the tax details, all went fine.  But when they tried to post (even though there were no errors on the edit list), the posting journal would return "detail" errors and the batch would be sent to batch recovery.  And when we tried to manually delete the tax details through GP, we would get "record locked" errors.  Ugh.  Ugh.  Ugh.

Hunting.  And berating myself for not being more measured about it.  And then I found the Sales/Purchases Tax Summary Master (TX00202).  Ah-ha.  For every record saved in the TX00201, a record is also created in the TX00202.  So I needed two table imports, not one.  The TX00202 is a rather simple table storing historical summary information.  Easy to populate, but again, check an entry that has been made directly in GP to determine how to correctly populate the fields with defaults in the TX00202 table.

Good luck, hope a few of you can learn from my mistake!

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.

Table Import is not always the ugly stepsister

I shy away from table import whenever possible. I prefer integration manager, or using SQL directly, or eConnect if I can. But sometimes I am reminded of how simple things can be done simply.

For the past few weeks, I have been working on an implementation that goes live Monday 12/28. We have had a fairly tight timeframe, so I have been trying to avoid manual data entry whenever possible. However, I have run up against more than a few things that I needed to import but could not do so with Integration Manager. Table import to the rescue with imports in to some simple tables like...

• Direct Deposit Header and Lines for Payroll
• Shipping Methods
• Customer Items

All of these table structures are fairly friendly to table import, and result in simple file uploads. Shipping methods even came up late in the game, and it took less than 10 minutes to build and load the file.

So why am I writing about this? Well, I know I could use the reminder that older tools that I regularly dismiss can actually come in quite handy :)

Please share any of your table import success stories, and I will be happy to update the post to include.

A few other uses courtesy of Steve Chapman and Frank Harnelly:

• High volume imports even if the destinations are available in Integration Manager, like Customers (1,000,000+ records in minutes) or Chart of Accounts
• Fixed Assets General Info