Archived Aged Transaction Balance (ATB)

Prerequisite

In case where this report must be compared to the print of the auxiliary general balance of the auxiliary ledger, the 'non validated payments' criterion must be set to 'No'.

 The journals in active simulation are systematically taken into account, the journals in inactive simulation are never taken into account.

List of criteria

Parameter	Parameter title	Type
societe	Company	CPY
sitedeb	Site range	FCY
coldeb	Range of control accounts	SAC
grpcol	Control group	GSC
tiersdeb	Range of business partners	BPR
borne1	No. of days 1	C
borne2	No. of days 2	C
borne3	No. of days 3	C
borne4	No. of days 4	C
borne5	No. of days 5	C
ecrisim	Simulated entries (Local menu No, Yes)	M1
datref	Reference date	D
sens	Sign (Local menu Debit, Credit)	M626
detpce	Detail by open item (Local menu No, Yes)	M1
tri	Sort order (Local menu Number, Title, Short title)	M676
impselections	Print selections (Local menu No, Yes)	M1

Update technical principles for the open item Historization Table.

The historization table for open items HISTODUD is used by the inquiry functions of aged balance at date (CONSBAH and CONSBAHF) and by the report of the aged transaction balance BALAGEHIST.
This table is updated at each open item creation, and then at each open item update.

Not all fields defining an open item, are historized. Actually, updates for the payment method, the PA level and the data linked to reminders are not traced.

In the HISTODUD table, the main fields to be used are:

• the event date (DATEEVT) that corresponds to the accounting date at which the event took place.
• the open item status (DUDSTA) which specifies whether an open item is linked to a posted document or just to an entered document (for example, an entered invoice that was not posted).
• DUDSTA=2 if the open item is associated with a posted document,
• DUDSTA is different from 2 if the open item is associated with a not-posted document. the BP and the open item control accounts (BPR and SAC) that include the BP and the control account on which the open item is posted.
• The Closed field (FLGCLE) defining the open item with respect to its closing, can take the following values:
• if FLFCLE=1 or 0, the open item is not paid/closed or partially paid/closed,
• if FLGCLE=2, the open item is permanently paid/closed (AMTCUR open item amount = PAYCUR and AMTCUR posted paid amount<>0; or AMTCUR=0 and open item amount AMTLOC = PAYLOC posted paid amount),
• if FLFCLE=3, the archived open item is deleted,
• if FLGCLE=4, the open item is temporarily paid/closed (AMTCUR open item amount = PAYCUR posted paid amount + paid amount not yet posted TMPCUR).

Details on the Event Date area

A - Regarding invoice posting, the event date corresponds to the invoice accounting date.

B - Regarding partial or complete matching of open items (via the direct posting of open item payment or the accounting matching), for the paid open item(s), the event date corresponds to the most advanced accounting date of the group documents at the time of matching.

Example:
Let us consider:

• a prepayment occurred with T1 as accounting date,
• the posting of an invoice with T2 as accounting date,
• the posting of the prepayment recovery on the accounting date T3.

The group documents will be regarded as closed on DATEVT= most advanced accounting date of the group documents, hence T3.

Regarding partially or totally closed open items (hence associated with an entry line using lower or upper case matching code), the event date kept for each matching, corresponds to the most advanced accounting date of the group documents at the time of matching (hence on MTCDATMAX of GACCENTRYD).

 Depending on the matching method, the updates of the HISTODUD table and of this event date can vary.

Example:
Let us consider a 1.000 € invoice posted on T1 date, followed by two payments on T2 and T3 dates:

• one payment for 600 € with T2 as accounting date,
• an other payment for 400 € with T3 as accounting date.

Two different cases should be considered:

• the invoice is first partially paid for 600 (payment posted on T2), then closed with the 600 payment (posted on T3),
• the three documents are separately posted and matching is performed later on, via the accounting matching (LETTRAGE or LETTRAUTO functions).

In the first case, the history mentions the matching processes:

• for T1 reference date, the invoice is displayed with its total amount,
• for T2 date, the invoice is displayed with a 400 € balance,
• on T3 date, the invoice is not displayed.

In the second case, since it is manual matching for three accounting documents, the event date is also the most advanced date, but the result is slightly different:

• for T1 reference date, the invoice is displayed with its total amount,
• on T2 date, the 1000 € invoice with its total amount, as well as the 600 € payment are displayed,
• on T3 date, the invoice and payment do not appear anymore.

  The outcome of the first scenario is the same via the accounting matching, if the invoice and the 600 € payment are matched in a first step.The matching group of two documents with the 400 € payment are then matched in a second step. 
These steps are made possible as the matching history can be retrieved by the user via the hierarchy of manual matching steps.

C - Regarding control account transfers, no record is created, since the previous ones are updated for the control account code and that the event date remains the same.

D - Regarding BP fusions, the principle is the same as for the control account transfer: no record is created in the HISTODUD table, but the existing records are simply updated and the event date remains the same.

Description of the report