Data Migration – Required Documents, Tables & Reports

We need following Documents;

1. fatahtbl
2. artrntbl
3. trial balance
4. debtors list with code
5. transaction check list report

Table / Report	Report or Table	what contain?	db query	Purpose
fatahtbl	db table	All vouchers detail data	select * from pms.FATAHTBL where DOCDAT between 20250717 and 20260716 order by DOCDAT	to migrate data
artrntbl	db table	1. debtors details transaction data. 2. tds detail transaction data 3. other info added later	select * from pms.artrntbl	to migrate with debtors/subledger wise subledger record keep in aegis.
trial balance	report	all ledger opening dr cr and net balance	from ui trial balance	to verify with raw data as well as after prepared data vs actual report in ids
debtors list with code	list of debtors with code	receivable list with code	-	to insert receivable profile with code so, later using this code migrate data.
transaction check list	report	detailed transaction record with subledger.	-	if we have to verify data voucher level or need to recheck voucher wise that case we need voucher wise data.

some important note:

Data should detailed and structured. if cell broken or overlapping do not accept that data specially db extracted data. because that data after prepare very hard to verify or in my word waste of time. coz raw data level if figure matched it doesn't mean that is correct data coz same figure data can be multiple.

for trial balance as possible detailed form of data required.

--

1. Required Data / Reports

The following documents, database tables, and reports are required for the data migration, validation, reconciliation, and post-migration verification process.

---

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:

1. Debtor/subledger transaction details
2. TDS-related transaction details
3. 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:

Source:

Trial Balance report from the existing system UI.

Purpose:

The Trial Balance will be used for reconciliation at multiple stages:

1. Raw data validation – confirm that extracted database data agrees with the source system.
2. Prepared data validation – verify that transformed/prepared data retains the correct balances.
3. Migration validation – compare migrated balances with the source data.
4. 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.

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.

---

6. Acceptance Criteria

The supplied data should be considered acceptable only when:

1. Data is complete for the agreed migration period.
2. Database extracts contain the required records without unexplained omissions.
3. Data is provided in a structured tabular format.
4. No important information is lost due to merged, broken, overlapping, or truncated cells.
5. Debtor/subledger codes are available for appropriate transactions.
6. Voucher-level transactions can be traced and rechecked.
7. Trial Balance data is sufficiently detailed for reconciliation.
8. Source totals can be reconciled with the extracted raw data.
9. Prepared/mapped data can be reconciled with raw data.
10. Migrated data can be reconciled with the source-system reports.
11. 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