A. Data Migration – Required Documents, Tables & Reports
1. Required Data / Reports
The following documents, database tables, and reports are required for the data migration, validation, reconciliation, and post-migration verification process.
| Table / Report | Type | What Should It Contain? | DB Query / Source | Purpose |
|---|---|---|---|---|
| FATAHTBL | DB Table | Complete voucher-level transaction detail data for the required migration period. | SELECT * FROM pms.FATAHTBL WHERE DOCDAT BETWEEN 20250717 AND 20260716 ORDER BY DOCDAT |
Primary source data for migration. |
| ARTRNTBL | DB Table | 1. Debtors/subledger transaction details<br>2. TDS transaction details<br>3. Other relevant information, if applicable | SELECT * FROM pms.ARTRNTBL |
To migrate debtor/subledger-wise transaction records and maintain the corresponding subledger records in Aegis. |
| Trial Balance | Report | Complete ledger-wise opening balance, debit, credit, and net/closing balance. Detailed information should be provided wherever available. | From UI – Trial Balance Report | To verify raw data, prepared/migrated data, and the final balance against the actual IDS report. |
| Debtors List with Code | List / Master Data | Complete list of debtors/receivables along with their unique debtor/subledger codes. | From existing system / DB | To create receivable/debtor profiles with the correct codes before transaction migration. These codes will subsequently be used for data mapping and migration. |
| Transaction Check List | Report | Detailed voucher-level transaction records, including applicable subledger/debtor details. | From existing system / report | To verify transactions at voucher level and recheck individual voucher-wise data where required. |
2. Detailed Requirement by Data Source
2.1 FATAHTBL
Type: Database Table
Required data:
- All voucher-level transaction details.
- Data for the period 17-Jul-2025 to 16-Jul-2026.
- Records should be extracted in a structured tabular format.
- The original database fields/columns should be retained wherever possible.
- No data should be omitted, merged, truncated, or manually reformatted in a way that changes the underlying values.
Query:
SELECT *
FROM pms.FATAHTBL
WHERE DOCDAT BETWEEN 20250717 AND 20260716
ORDER BY DOCDAT;
Purpose:
FATAHTBL will be treated as one of the primary raw-data sources for migration. The extracted data will be used for preparation, mapping, migration, and subsequent reconciliation against reports from the source and target systems.
2.2 ARTRNTBL
Type: Database Table
Required data:
ARTRNTBL should be provided as a complete and structured database extraction.
It is expected to contain:
- Debtor/subledger transaction details
- TDS-related transaction details
- Other relevant transaction information, if identified during the migration process
Query:
SELECT *
FROM pms.ARTRNTBL;
Purpose:
ARTRNTBL is required to support the migration of debtor/subledger-wise transactions and to ensure that the corresponding subledger records are properly maintained in Aegis.
The relationship between the ARTRNTBL records and the applicable debtor/subledger code should remain traceable throughout the migration process.
2.3 Trial Balance
Type: System Report
Required data:
The Trial Balance should preferably be provided in a detailed and structured format.
At minimum, it should contain:
| Field | Requirement |
|---|---|
| Ledger Code | Required wherever available |
| Ledger Name | Required |
| Opening Debit | Required |
| Opening Credit | Required |
| Debit | Required |
| Credit | Required |
| Net Balance | Required |
| Closing Debit | Preferably provided |
| Closing Credit | Preferably provided |
| Other identifying fields | Include where available |
Source:
Trial Balance report from the existing system UI.
Purpose:
The Trial Balance will be used for reconciliation at multiple stages:
- Raw data validation – confirm that extracted database data agrees with the source system.
- Prepared data validation – verify that transformed/prepared data retains the correct balances.
- Migration validation – compare migrated balances with the source data.
- Final verification – compare the prepared/migrated data against the actual Trial Balance report in IDS.
The more detailed the Trial Balance, the easier it will be to identify and resolve discrepancies.
2.4 Debtors List with Code
Type: Master List
Required data:
A complete receivable/debtor master list should be provided with the corresponding unique codes.
| Field | Requirement |
|---|---|
| Debtor/Customer Code | Mandatory |
| Debtor/Customer Name | Mandatory |
| Subledger Code | Required where applicable |
| Subledger Name | Required where applicable |
| Other identifying information | Include where available |
Purpose:
The debtor list will be used to create the receivable/debtor profiles in the target system.
The existing debtor/subledger code should be retained as the primary mapping reference wherever possible, so that transactions can subsequently be migrated against the correct receivable profile.
2.5 Transaction Check List
Type: Detailed Transaction Report
Required data:
The report should provide transaction-level details with sufficient information to trace each transaction back to its source voucher.
Where available, the report should include:
- Voucher number
- Voucher date
- Transaction date
- Ledger code/name
- Debtor/subledger code
- Debtor/subledger name
- Debit amount
- Credit amount
- Net amount
- Narration/description
- Reference/document number
- TDS details, where applicable
- Any other field required to identify the transaction uniquely
Purpose:
The Transaction Check List is required for voucher-level validation.
If a balance or transaction discrepancy is identified, the team should be able to trace the issue back to the individual voucher and then to the underlying database record.
Therefore, summary-level data alone is not sufficient for this purpose.
3. Data Quality and Formatting Requirements
3.1 Structured Data Is Mandatory
All extracted database data and reports must be provided in a detailed, structured, and machine-readable format.
Each row should represent a distinct record, and each column should represent a distinct field.
Data should not be provided in a format where:
- Cells are broken across multiple rows/columns.
- Cells are merged unnecessarily.
- Values overlap with other cells.
- Headers are mixed with transaction data.
- Multiple transactions are combined into a single cell.
- Amounts are split or visually formatted in a way that changes their interpretation.
- Important fields are hidden or truncated.
- Manual formatting makes the underlying value unclear.
3.2 Broken or Overlapping Data Will Not Be Accepted
Particularly for database-extracted data, broken or overlapping cells should not be accepted as final data.
The objective is not simply to obtain a file where the total figures appear to match.
The raw data must remain individually identifiable and traceable.
For example, if the total debit amount in an extracted file matches the source Trial Balance, that alone does not prove that the extracted data is correct. The same total amount can potentially be produced by multiple combinations of transactions.
Therefore:
A matching total is necessary for reconciliation, but it is not sufficient to establish data correctness.
4. Data Traceability Requirement
Every important migrated figure should be traceable through the following chain wherever applicable:
Source Voucher → Raw DB Record → Prepared/Mapped Data → Migrated Transaction → Target System Report
For debtor/subledger transactions, the traceability should additionally include:
Debtor/Subledger Code → Debtor Profile → Transaction → Ledger Balance
This traceability is critical for resolving discrepancies during migration and post-migration validation.
5. Validation Approach
The data team should perform validation at multiple levels rather than relying only on total balances.
| Validation Level | What to Verify |
|---|---|
| Record Level | Individual source records are extracted completely and correctly. |
| Voucher Level | Each voucher and its associated transactions can be identified and traced. |
| Subledger Level | Debtor/subledger transactions are mapped to the correct code/profile. |
| Ledger Level | Ledger-wise debit, credit, and balance agree with the source. |
| Trial Balance Level | Opening, debit, credit, and closing/net balances reconcile. |
| System Level | Final migrated data agrees with the actual target-system report. |
6. Acceptance Criteria
The supplied data should be considered acceptable only when:
- Data is complete for the agreed migration period.
- Database extracts contain the required records without unexplained omissions.
- Data is provided in a structured tabular format.
- No important information is lost due to merged, broken, overlapping, or truncated cells.
- Debtor/subledger codes are available for appropriate transactions.
- Voucher-level transactions can be traced and rechecked.
- Trial Balance data is sufficiently detailed for reconciliation.
- Source totals can be reconciled with the extracted raw data.
- Prepared/mapped data can be reconciled with raw data.
- Migrated data can be reconciled with the source-system reports.
- Any discrepancy can be traced back to the underlying voucher/transaction rather than only to a summary figure.
7. Key Principle
The objective of the data extraction is not merely to match the final figures. The objective is to preserve complete, structured, and traceable transaction-level information so that every figure can be independently verified.
A raw-data file in which the totals match but individual records cannot be reliably identified, mapped, or traced should not be considered acceptable for migration.
In short:
Complete → Structured → Traceable → Reconciled → Migrated → Re-verified
Documented By:
Sundar Mishra
Senior Implementation Support & Data Analyst Executive