Field help (HDUDEL) @ L.V. Expertise X3

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.