| Errors Encountered During the Merge Process |
Error Overview
If an error is encountered in a transaction, the rejected transaction is not merged into Tabs3 Billing. (Note: As an exception, a transaction with an error code of 35, 36, or 37 is merged as indicated.) Since each transaction that is successfully merged is marked as such, any transactions that were successfully merged from that file will not be merged again.
You can correct rejected transactions using one of the following methods:
|
|
Re-enter the rejected transaction in Tabs3 Billing. |
|
|
Re-enter the rejected transaction in Tabs3 Billing Remote. |
|
|
Resolve the reason for the rejected transaction and then remerge. For example, if a transaction was rejected because the client does not exist in Tabs3 Billing, you may want to consider adding the client in Tabs3 Billing and then re-merging the files. When remerging the files, the transactions that were successfully merged originally will not be merged again. |
|
|
Edit the transaction in Tabs3 Billing Remote and remerge. To edit the transactions in Tabs3 Billing Remote, copy the "RMT*.*" files from the host computer back to the remote computer, edit the transactions in Tabs3 Billing Remote, transfer the files back to the main computer and rerun the Merge Tabs3 Remote Data utility. When remerging the files, the transactions that were successfully merged originally will not be merged again (provided the "RMT*.*" files were transferred from the host computer before editing on the remote computer). |
Careful: If you correct the transactions in Tabs3 Billing Remote by editing the transactions, make sure you transfer the "RMT*.*" files back to the remote computer before editing. Otherwise, the transactions will be merged twice.
Caution: Copying the "RMT*.*" files back to the remote computer will overwrite any files currently existing on the remote computer.
Tabs3 Billing and Tabs3 Billing Remote data do not match
If the installed Tabs3 Billing and Tabs3 Billing Remote applications do not match, an error message will be displayed when selecting to merge Tabs3 Billing Remote data. This message indicates that the data cannot be merged without changes made to the Tabs3 Billing Remote application. Information on how this error occurs, and steps to resolve it, can be found on our Internet Knowledge Base in Article R10794 - Sending Tabs3 Billing Remote Data Files to Tabs3 Billing.
The Tabs3 Billing error codes that can be received during the merge are listed below:
| Code | Description of Error/Warning |
| 10 |
Client Not Found in Tabs3 Billing client file or Secure Client. Indicates one of two situations:
|
| 15 | Inactive Client. Indicates the client in Tabs3 Billing is set to an Inactive status. This error is corrected by re-entering (in the case of an incorrect Client ID) or by re-merging after editing the client's inactive status. (You need to determine why transactions were added to an inactive client.) |
| 20 | Timekeeper Not Found in Tabs3 Billing timekeeper file. Indicates the timekeeper does not exist in the main Tabs3 Billing data files. This error can be corrected by re-entering or editing the transaction in Tabs3 Billing Remote and re-merging, or by adding the timekeeper into Tabs3 Billing and then re-merging. |
| 30 | Invalid Tabs3 Billing Transaction Code. Indicates the transaction code is invalid. This error can occur if a fee transaction code was used to make a cost transaction, if a payment transaction code or client funds transaction code was used, if a positive amount was entered for a transaction with a finance charge credit transaction code (Type 9), if a Type 6 (progress fee) transaction was entered for a non-billable client or if the transaction code does not exist in the Tabs3 Billing transaction code file. This error can be corrected by re-entering or editing the transaction in Tabs3 Billing Remote and then re-merging, or by adding the transaction code into Tabs3 Billing and then re-merging. (Task Based Billing Note: This error can also occur if a transaction was entered in Tabs3 Billing Remote using a task based billing code but the client in Tabs3 Billing is not set up as a task based billing client. In this situation, the client can be changed in Tabs3 Billing to be a task based billing client and then re-merge. Or, it can be corrected in Tabs3 Billing Remote and then re-merged.) |
| 31 | Invalid Task Based Billing Code. Indicates the Task Based Billing Code specified is invalid. |
| 35 | Amount or Hour for a Description Only Transaction. Indicates that a Type 4 (description only) transaction has a non-zero number in the Amount or Hours field. This transaction is merged with 0 in the Amount and Hours fields. |
| 36 | Hour for a Progress Fee Transaction. Indicates that a Type 6 (progress fee) transaction has a non-zero number in the Hours field. This transaction is merged with 0 in the Hours field. |
| 37 | Task Based Billing Code Not Provided. Indicates a transaction was merged with a transaction code for a task based billing client. Transactions for task based billing clients require a task based billing code instead of a transaction code. The merged transaction must be edited in Tabs3 Billing. If this error is not fixed, the next time the Data File Integrity Check is run in Tabs3 Billing, it will report an error 81. Editing can be accomplished by using the appropriate file or by using the Change WIP Transactions program to change the tcode to a valid task based billing code. If the client was set up as a Task Based Billing Client by mistake, clearing the client's Task Based Billing Client check box will resolve the problem. If the transaction was entered for the wrong client, you can use the Transfer Transactions program to move the transaction to the correct client. If applicable, GLS journal entries were also created and merged using the GLS accounts assigned to the transaction code. |
| 40 | Category Not Found in Tabs3 Billing category file. Indicates the category does not exist in the main Tabs3 Billing data files. This error can be corrected by re-entering or by editing the transaction in Tabs3 Billing Remote and re-merging, or by adding the category into Tabs3 Billing and then re-merging. |
| 60 | Fee Hours To Bill are too large. Indicates that the Hours to Bill field being imported is greater than 9,999.99 or less than -999.99. |
| 61 | Fee Hours Worked are too large. Indicates that the Hours Worked field being imported is greater than 9,999.99 or less than -999.99. |
| 62 | Fee Rate is too large. Indicates that the Rate field being imported is greater than 9,999.99. |
| 63 | Fee Amount is too large. Indicates that the Amount field being imported is greater than 9,999,999.99 or less than -999,999.99. |
| 65 | Cost Units are too large. Indicates that the Units field being imported is greater than 99,999.99 or less than -9,999.99. |
| 66 | Cost Rate is too large. Indicates that the Rate field being imported is greater than 9,999.999. |
| 67 | Cost Amount is too large. Indicates that the Amount field being imported is greater than 9,999,999.99 or less than -999,999.99. |
| Key Type Mismatch | If the Tabs3 Billing Key Type does not match the Key Type in the Tabs3 Billing Remote data, the error report will include a message indicating a Key Type mismatch. In this situation, no data will be merged into Tabs3 Billing. The Key Types must match before the data can be imported. It may be possible to fix the error using the following procedure. To fix this error, transfer the remote files back to the remote computer. Using Tabs3 Billing Remote, change the Key Type in Customization. Then, using the Fee program in Tabs3 Billing Remote, retrieve a fee entry (or add another fee entry) and save it. This procedure saves the new Key Type to the fee file. Repeat this process using the Cost program. After these changes have been made, transfer the files back to the host computer and run the Merge Remote Data program again. |
If an error is encountered when Tabs3 Billing attempts to create the General Ledger journal entries, the transaction is merged into Tabs3 Billing but the journal entries are not created. These entries need to be entered manually in GLS. The GLS reject codes are listed below:
| Code | Description of Error/Warning |
| 10 | GLS Account not found (an invalid GLS account is present in GLS Integration Setup) |
| 11 | Unassigned GLS account (blank GLS account is present in GLS Integration Setup) |
| 20 | Unbalanced Debit/Credit mappings |
| 21 | Tabs3 Billing amount and GLS Journal Entries amount do not match |
| 30 | Invalid GLS journal |
| 40 | Date for GLS journal entry out of valid range |
GLS Warnings
Warnings that can be received during posting are listed below. Warnings indicate that GLS journal entries were posted but may need to be reviewed.
*** WARNING: The following entry was posted using today's date ***
This warning is displayed when journal entries are posted with a date prior to the Date through which books are closed specified in the GLS Date Restrictions.
*** WARNING: This entry was posted beyond the Date Restrictions ***
This warning is displayed when journal entries are posted with a date outside of the Restrict Journal Entries to xxx Days in the Future or Restrict Journal Entries to xxx Days in the Past specified in the GLS Date Restrictions.
*** WARNING: The following entry was posted into a prior year ***
This warning is displayed when journal entries are posted with a date prior to the current year.
*** WARNING: The following entry was posted to an inactive account ***
This warning is displayed when journal entries are posted to an inactive GLS Account.
Note: Only one type of warning will be displayed for each journal entry posted. The warnings listed above are listed in order of priority. For example, if warnings for both "posted using today's date" and "posted to a prior year" are encountered, only the warning for an entry posted using today's date will be displayed for that journal entry.