Archiving open items @ L.V. Expertise X3

Prerequisite

SEEREFERTTO Refer to documentation Implementation

Tab Entry screen
Update technical principles for the open item Historization Table.

Screen management

The two checkboxes Resynchronization and Deletion are used to retain one or the other operating modes used to update the HISTODUD table.
The checkbox Detailed log file is used to display a list of the records impacted or created via the resynchronization.

Potential combinations and impacts

Resynchronization:	Deletion	Detailed log file:	Impacts	Examples of information displayed in the log file
No	No	No	Log file listing the anomalies in the existing records. No correction or creation.	Accounting document FAC FCRHDU10102VEN00001 Line 1 Open item 1 (151016) / / : Incorrect date => 10/02/11	With the information of the archived open item number ([F:HDU]NUMHDU) as well as the nature of the anomaly (like an incorrect DATEVT).
Yes	No	No	Correction of the anomalies detected on the existing records. Log file listing the corrected anomalies.	Accounting document FAC FCRHDU10102VEN00001 Line 1 Open item 1 (151020) 15/09/11: Incorrect date => 10/02/11
No	Yes	No	Log file listing the records that the utility might create if it is launched in real mode (without considering those already existing).	Journal FAC FCRHDU10102VEN00001 Line 1 Open item 1 Journal creation FAC FCRHDU10102VEN00001 Line 1 Open item 1 12/02/11 Accounting document FAC FCRHDU10102VEN00001 Line 1 Open item 1 10/02/11	With at last the information of the DATEVT applied if the utility is launched in real mode.
No	Yes	Yes	Log file listing the existing records that will be deleted if the utility is launched in real mode. Log file listing the records that the utility might create if it is launched in real mode (without considering those already existing).	*** 150983 10/02/11 Journal FAC FCRHDU10102VEN00001 Line 1 Open item 1 Journal creation FAC FCRHDU10102VEN00001 Line 1 Open item 1 12/02/11 Accounting document FAC FCRHDU10102VEN00001 Line 1 Open item 1 10/02/11	The record to delete is identified via its [F:HDU]NUMHDU and its DATEVT. With at last the information of the DATEVT applied if the utility is launched in real mode.
Yes	Yes	No	Deletion of the existing records and creation of new records for the open item archiving. Log file listing the new records created by the utility.	Journal FAC FCRHDU10102VEN00001 Line 1 Open item 1 Journal creation FAC FCRHDU10102VEN00001 Line 1 Open item 1 (151017) 12/02/11 Accounting document FAC FCRHDU10102VEN00001 Line 1 Open item 1 (151018) 12/02/11
Yes	Yes	Yes	Deletion of the existing records and creation of new records for the open item archiving. Log file listing the records deleted and the new records created by the utility.	Accounting document FAC FCRHDU10102VEN00001 Line 1 Open item 1 *151017 / / *151018 / / Accounting document FAC FCRHDU10102VEN00001 Line 1 Open item 1 (151019) 12/02/11 Accounting document FAC FCRHDU10102VEN00001 Line 1 Open item 1 (151020) 12/02/11

Entry screen

Fields

The following fields are present on this tab :

Header

Company (field CPY)

No help linked to this field.

Criteria

All sites (field ALLFCY)

No help linked to this field.

Site (field FCY)

All BP types (field ALLTYPBPR)

BP type (field TYPBPR)

All BPs (field ALLBPR)

From BP (field BPRSTR)

To BP (field BPREND)

All control accounts (field ALLSAC)

Control group (field GRPSAC)

Control (field SAC)

Block number 3

Resynchronization (field RECUP)

The resynchronization is only carried out on records with status DUDSTA set to value 'two'. It corresponds to an open item linked to a posted document (as opposed to open items linked to unposted invoices, for instance).

A certain number of fields in table HISTODUD are not updated:

key NUMHDU,
CREDAT and CREUSR traceability fields,
those fields used to establish a link to the reference table GACCDUDATE: TYP, NUM, LIG and DUDLIG,
other fields, such as FLGPAZ, DUDDAT, PAYDAT andTYPDUD.

Some fields are resynchronized by applying a rule, i.e.

field Closed: this field characterizes the open item with respect to its closing and it can take the following values:

'0' or '1' when the open item is not closed or only partly closed,
'2' when the open item is permanently closed (AMTCUR open item amount = PAYCUR and AMTCUR posted paid amount<>0; or AMTCUR=0 and open item amount AMTLOC = PAYLOC posted paid amount),
'3' when the historized open item has been deleted,
'4' when the open item is permanently closed (AMTCUR open item amount = PAYCUR posted paid amount+ paid amount not yet posted TMPCUR and AMTCUR<>0; or AMTCUR=0 and open item amount AMTLOC = posted paid amount PAYLOC + paid amount not yet posted TMPLOC).

The value of this field is controlled and possibly corrected only for the cases where it is different from '3'.
The historization records that have a field Closed different from '3', the fields Open item amount in currency (AMTCUR), Local currency amount (AMTLOC),Paid amount(PAYCUR), Company paid (PAYLOC), Temporary amount paid (TMPCUR) and Provisional company payment (TMPLOC) are read to re-evaluate the field value Closedaccording to the rule defined above.

Event date field:

if the value of field Amount paid is greater than '0', the utility resynchronizes the event date with respect to the maximum accounting date of the matching group: the utility is able to find the entry line at the origin of the open item using the ACCNUM account number in the accounting document table GACCENTRYD. Since the line contains a letter (the 'MTC' Amount line in table GACCENTRYD is not empty), the utility takes into account the amount of the maximum matching accounting date 'MTCDATMAX' of the line in table GACCENTRYD.
if the open item is not closed (the value of field Closed is smaller than 2), l'the utility resynchronizes the event date with respect to the accounting date ACCDAT on the accounting document (the date is traced back via the account number ACCNUM in table GACCENTRYD).

SEEINFO Those fields linked to the amounts are not resynchronized:

the amount fields of the open item (AMT*),
the paid amount fields (PAY*),
the temporary paid amount fields (TMP*).

Deletion (field DEL)

The "Deletion" option is used to create historization records. The file data of the open items are the starting point of this creation.

for a DUD open item without any link with the table of the GACCENTRYD posting lines, the history created will be:

only one record with [F:HDU]DUDSTA = 0 (original document not yet posted) and with [F:HDU]DATEVT initialized with the open item date [F:DUD]DUDDAT,

for a DUD open item with a link with GACCENTRYD and without matching ([F:DAE]MTC left empty), the created history will be:

only one record with [F:HDU]DUDSTA = 0 (original document not yet posted) and with [F:HDU]DATEVT initialized with the open item date [F:DUD]DUDDAT,
only one record with [F:HDU]DUDSTA = 2 (original document not yet posted) and with [F:HDU]DATEVT initialized with the open item date [F:DUD]DUDDAT,

for a DUD open item with a link with GACCENTRYD and with matching ([F:DAE]MTC left empty), the created history will be:

only one record with [F:HDU]DUDSTA = 0 (original document not yet posted) and with [F:HDU]DATEVT initialized with the open item date [F:DUD]DUDDAT,
only one record with [F:HDU]DUDSTA = 2 (original document not yet posted) and with [F:HDU]DATEVT initialized with the open item date [F:DUD]DUDDAT,
only one record with [F:HDU]DUDSTA = 2 (posted original document) and with [F:HDU]DATEVT initialized with the maximum accounting date of the [F:DAE]MTCDATMAX matching group.

LIMIT no. 1

The resynchronization with deletion is not based in the module flows upstream of the Financials module but on the matching.
Therefore, for a group of matched journals, the completion update cannot be noticed as it goes along but only at the maximum accounting date of the matching group ([F:DAE]MTCDATMAX).

For instance:
In the case of a lowercase matched invoice with two payments A and B of different accounting dates A and B, the new records created will record the completion of the invoice at the time of the latest accounting date of the two, B, rather than successively and gradually on the date of these two payments.
At the A payment accounting date, the aged balance will restore the invoice for its original total amount, as well as the A payment, for its total amount too, which is the global balance (net amount).
At the B payment accounting date, the aged balance will only restore the invoice for its net balance (deducted of the amount of the A and B payments).

LIMIT no. 2

The resynchronization with deletion does not allow to manage the case of a payment cancelation that would intervene after this resynchronization.
A group made up of at least two payments of different accounting dates has been deleted with resynchronization. If an accounting cancellation is then recorded on one of the payments of the group (other than the one of the latest date), the cancellation historization update will not allow the cancellation detection; the intermediary situation recorded in the aged balance will not take into account this cancellation.

For instance:
Posting of a 10.000 invoice with 01/03/11 as accounting date.
Posting of an A payment of 500 with 08/03/11 as accounting date.
Posting of a B payment of 600 with 14/03/11 as accounting date.
Followed by a resynchronization with deletion.
Followed by an accounting cancellation of the A payment with 08/03/11 as accounting date.
Aged balance dating from 08/03/11: the invoice is displayed for a 10.000 balance and the payment for -500, that is to say a balance of 9.500. The cancellation has not been taken into account.
Aged balance dating from 14/03/11: the invoice is displayed for a balance of 9.400.

By relaunching the resynchronization with deletion on the concerned BP, the new data of the history are reconstructed without this limit.

Detailed log file (field TRC)

If the detailed log file is requested, the log file is enriched by the list of the records HISTODUD likely to be deleted during the deletion phase (with or without resynchronization).

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).

SEEWARNING 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.

SEEINFO 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.

Batch task

This function can be run in batch mode. The standard task ACCRECHDU is provided for that purpose.

Generic messages

Error messages

In addition to the generic error messages, the following messages can appear during the entry :

Some fields that are directly linked to the reference table GACCDUDATE are updated. Then the error messages are identical to those used on resynchronizing the open items, that is:
- ACCNUM: Internal number incorrect
- CPY: Company incorrect
- FCY: Site incorrect
- CUR: Currency incorrect
- SNS: Sign incorrect
- SAC: Collective account incorrect
- BPR / BPRTYP / BPRPAY: BP incorrect

Tables used

SEEREFERTTO Refer to documentation Implementation