Keystone Data Conversion

Data Conversion Guidelines:

KEYS: Identify Data

Master Tables:

• GL Accounts
• Customers
• Products
• Jobs
• Prices
• Employee Header
• Employee Setup Detail (if possible)

RULES: Convert for Preinstall Customer responsible for maintaining both updates

Transaction Tables

• AR Balances
• GL Transactions
• AP Invoices
• Cash Transactions

RULES:

• Establish firm cutover date.
• Convert after all transactions finished on old system.
• Generally OK to start using new system before converting/transferring data.
• Set imported flag to Y
• Verify Balance on old system
• Verify Balance on new system
• Establish with customer:
  • Cutover date
  • Ending Balance
  • Responsibility to use new system for all trx after new transfer date.

AP Invoice Sliding Transfer (method that reduces the number of AP invoices to a point where they shouldn't need conversion) Two Cutover dates

• Invoice Cutover Date: Date where you stop entering invoice in old system and only in new.
• Cash Payment Cutover Date: Date where you stop paying old invoices in old system.

With Sliding Transfer, all new invoices dated on/after the Invoice Cutover Date are entered in the new system. Any payments on New Invoices are also made from the new system.
In the old system, payments for invoices are still made for a limited period, typically 1 month. At the end of this period, there will be a small amount of data that will need to be carried forward to the new system:

• The open invoices still not paid.
• G/L activity created by the payments: A simple Cash (Credit) and A/P (Debit) for the total amount of the checks created.
• C/M transactions: A list of all checks written for the sliding transfer period. If these are entered manually, they can be offset to the AP account taking care of the G/L entry above.

Example: A company starts using CC on 9/1/6:
On Dec 15th preinstall

• Transfer master files, custs, prods etc.
• Customer modifies master files.
• Customer adds new master recs on both systems

On Sep 1-4:

• Customer finishes a/r trans in old system up to 8/31/06
• Customer Creates new activity in new system 9/1/06 and after
• Customer Adds new a/p invoices in new system
• Customer Pays old a/p from old system

On Sept 5th follow up:

• A/R Transfer invoices from old system
  • Verify old system a/r balance vs. new system
  • Customer stops using old system a/r
• Customer