Are you sure it is taking system operation date? In my experience it takes the MPL voucher date as that is what the “transaction based” option refers to - the original transaction date, not the date the invoice is recevied.

This is a known issue and below are 2 solutions, along with R&D’s response.   You are correct, it is taking the system date and not the voucher date of AP Invoice; and this is by design.  Therefore, any change to this functionality would require a modification.  

**Solution# 178264: The Date Applied in correction posting should be the voucher date used during the final posting. 

Per R&D,  “The same issue has been discussed in the solutions 169648, 170799, 154558 The system is not adding the new postings with the same date as the original postings. Here it should be emphasized that it is the Date Applied that is of interest since that is the date that will appear as Voucher Date in GL, not when then transaction itself was created.

According to the About Cascade Update of Cost on Inventory Transactions, the following is mentioned: Additional Postings The variance/additional postings described in the sections above will be added to the existing transactions. That means that the original posting will not be affected or changed. Additional postings could be added to the transaction, independent of the status of the original postings on the transaction. The original postings could be transferred to IFS Financials, or included in the inventory statistics update.  The additional postings will be added with the system date as the date applied, and the status of the additional postings could differ from the original postings.

During the investigation for bug 72620 it was investigated if the Date Applied could be set to the same date as the voucher date of the invoice. But this was found impossible to handle, and hence the only principle that can be applied is to use the system date (sitedate).”

**Solution# 170799 - Impact of price difference on inventory value.

Per R&D, “The voucher date or invoice date of the supplier invoice has no impact on the date of the added postings, which seems to be an assumption. Using sysdate as the date for the new added postings is the existing design, and there is no other option available, which was e.g. investigated for the previous bug 72620, where the following clarification has been done:

After some evaluation of possible solutions, it has been found that setting the Date Applied to any different date than site date cannot be handled within the scope of a bug. Considering that the date when the inventory statistics have been updated currently also limits which Date Applied that can be set, there would still be a need for a different solution to handle the Received - Not Yet Invoiced report

The existing design is also clearly described in the user documentation for About Cascade Update of Cost on Inventory Transactions as follows:

Additional Postings

The variance/additional postings described in the sections above will be added to the existing transactions. That means that the original posting will not be affected or changed. Additional postings could be added to the transaction, independent of the status of the original postings on the transaction. The original postings could be transferred to IFS Financials, or included in the inventory statistics update. 

The additional postings will be added with the system date as the date applied, and the status of the additional postings could differ from the original postings.”

In short: revaluation transactions are created when PO receipt is matched with AP invoice. This happens either during initial invoice entry or delayed (between invoice preliminary and final entry). Invoice can be matched, in particular, when original I voucher period (invoice reception date) is closed already, so we should not create any inventory postings in closed period. And using supplier invoice workflow, we do not know what will be the date of J voucher. That’s why current system date is the best option to use and trying to change this behavior by customization requires strong consideration effort.