C. artrntbl — Understanding Data & Similarities with fatahtbl

1. Purpose of `artrntbl`

artrntbl appears to contain AR (Accounts Receivable) transaction-level information. The table can contain different types of AR transactions, identified through the DOCTYP column.

For the purpose of sales voucher migration, we should identify the records representing actual invoices and exclude other AR transaction types such as receipts or TDS-related entries.

2 Important `artrntbl` Columns

Column	Observed Meaning	Migration Relevance
`DOCTYP`	Document/transaction type	Important for filtering
`OUTLET`	Outlet/transaction location; can be treated as a cost-center-related field	Useful for identifying transaction source
`COMCOD`	Company code; observed to correspond with the ageing/receivable profile code	Important for matching
`BILDAT`	Bill date	Relevant to invoice information
`RECDAT`	Transaction/record date	Important for matching
`DESCRP`	Transaction narration/description	Important for matching
`TRNAMT`	Transaction amount	Relevant for amount validation
`EXCAMT`	Transaction amount in exchange/base currency context	Potentially relevant for matching

Note: The exact accounting meaning of some columns should be validated against the source application's business rules before the migration is finalized. The mappings below are based on observed data relationships.

3 `DOCTYP` — Transaction Type

The observed values in DOCTYP are:

I — Invoice

R — Receipt

A — Appears to represent an additional/accounting entry, with observed examples indicating TDS-related entries.

Therefore, if the objective is to migrate sales vouchers, the primary filter should be:

DOCTYP = 'I'

Records with:

DOCTYP = 'R'

should not be treated as sales invoices because they represent receipts.

Similarly, DOCTYP = 'A' should be excluded from the invoice migration unless a specific business rule confirms that a particular A transaction must also be migrated.

Recommended rule

Sales voucher migration should initially consider only DOCTYP = 'I'.

4. Similarities Between `fatahtbl` and `artrntbl`

Based on the observed data, several fields appear to represent the same business information across the two tables.

`fatahtbl`	`artrntbl`	Observed Relationship	Matching Priority
`DOCDAT`	`RECDAT`	Document/transaction date	High
`PRJCOD`	`COMCOD`	Project/company/receivable-profile-related code	High
`PRTCLS`	`DESCRP`	Narration/description	High
`AMOUNT`	`EXCAMT`	Transaction amount	High, requires sign handling

The proposed correspondence is:

fatahtbl.DOCDAT   ↔ artrntbl.RECDAT
fatahtbl.PRJCOD   ↔ artrntbl.COMCOD
fatahtbl.PRTCLS   ↔ artrntbl.DESCRP
fatahtbl.AMOUNT   ↔ artrntbl.EXCAMT

5. Proposed Record-Matching Logic

These similarities can be used to identify whether a transaction in artrntbl corresponds to a transaction in fatahtbl.

A basic matching condition would therefore be:

fatahtbl.DOCDAT = artrntbl.RECDAT
AND
fatahtbl.PRJCOD = artrntbl.COMCOD
AND
fatahtbl.PRTCLS = artrntbl.DESCRP
AND
ABS(fatahtbl.AMOUNT) = ABS(artrntbl.EXCAMT)

Why use `ABS()` for the amount?

The same accounting transaction may be represented with opposite debit/credit signs in different tables.

For example:

fatahtbl.AMOUNT = 5000
artrntbl.EXCAMT = -5000

Although the signs are different, the underlying monetary value may represent the same transaction.

Therefore, for the initial reconciliation/matching stage, it is safer to compare:

ABS(AMOUNT) = ABS(EXCAMT)

rather than requiring:

AMOUNT = EXCAMT

However, the sign should not be discarded permanently. It should be investigated separately because the debit/credit direction may be important when constructing the final migrated voucher.

6. Recommended Matching Hierarchy

I would not rely on all four fields equally from the beginning. A better reconciliation approach is to progressively narrow the candidates.

Level 1 — Transaction Type

First filter artrntbl:

DOCTYP = 'I'

This removes receipts and other non-invoice transactions.

Level 2 — Date

Match:

fatahtbl.DOCDAT = artrntbl.RECDAT

Level 3 — Company / Receivable Profile

Match:

fatahtbl.PRJCOD = artrntbl.COMCOD

Level 4 — Narration

Compare:

fatahtbl.PRTCLS = artrntbl.DESCRP

Level 5 — Amount

Finally validate:

ABS(fatahtbl.AMOUNT) = ABS(artrntbl.EXCAMT)

This gives us a strong candidate match based on date + profile/company + narration + amount.

7. Important Observation: `BILDAT` vs `RECDAT`

One thing should be kept separate during analysis:

artrntbl.BILDAT
artrntbl.RECDAT

They may represent two different dates:

BILDAT → actual bill/invoice date

RECDAT → transaction/record/accounting date

Therefore, we should not automatically assume RECDAT is the invoice date merely because it matches fatahtbl.DOCDAT.

For reconciliation, RECDAT currently appears to be the better candidate because of the observed relationship:

fatahtbl.DOCDAT ↔ artrntbl.RECDAT

But BILDAT should also be analyzed to determine whether it corresponds to another date field in fatahtbl.

8. Current Working Conclusion

Based on the current observation, artrntbl can potentially be used as a supporting AR transaction source for validating/matching sales invoice transactions from fatahtbl.

The strongest currently observed relationships are:

┌──────────────────────┐       ┌──────────────────────┐
│      fatahtbl        │      │          artrntbl       │
├──────────────────────┤       ├──────────────────────┤
│ DOCDAT               │ ────► │ RECDAT               │
│ PRJCOD               │ ────► │ COMCOD               │
│ PRTCLS               │ ────► │ DESCRP               │
│ AMOUNT               │ ────► │ EXCAMT               │
└──────────────────────┘       └──────────────────────┘
                                      │
                                      ▼
                              DOCTYP = 'I'
                              Invoice records only

Proposed reconciliation key

DOCTYP = 'I'
AND
DOCDAT = RECDAT
AND
PRJCOD = COMCOD
AND
PRTCLS = DESCRP
AND
ABS(AMOUNT) = ABS(EXCAMT)

This should be treated as the initial matching rule, not yet as the final migration rule. Before implementing the migration, we should test for:

Duplicate matches.

Date differences between DOCDAT, RECDAT, and BILDAT.

Narration formatting differences.

Amount rounding differences.

Multiple artrntbl records matching one fatahtbl record.

One artrntbl record matching multiple fatahtbl records.

Whether EXCAMT or TRNAMT is the correct amount field.

Whether the sign difference has accounting meaning.

That distinction is important: first prove the reconciliation relationship, then turn it into migration logic.

Documented By:
Sundar Mishra
Senior Implementation Support & Data Analyst Executive