EEX 9.1+: VISA Card Transaction MONETARY_AMOUNT Recalculated When Defaulting From My Wallet Into An Expense Report
Last updated on AUGUST 23, 2017
Applies to:PeopleSoft Enterprise FIN Expenses - Version 9.1 to 9.2 [Release 9]
Information in this document applies to any platform.
Should VISA International provide in their flat file a Credit Card Transaction with the Monetary Amount calculated, and an Exchange Rate provided, the system re-calculates the Monetary Amount when the transaction gets defaulted from My Wallet into a new Expense Report. In some occasions, if the decimal values of the exchange rate is not accurate enough due to an 8-digit limitation, the Monetary Amount can be modified from the original by several cents, specially if the Transaction Amount is very high. This causes problems later on when a payment is generated to the VISA Credit Card Vendor, as they expect a specific amount, and the payment is not for the same.
The delivered codeline within Record Field PeopleCode Action EX_TRANS_WRK.PB_FETCH.FieldChange, is the cause of this re-calculation behavior. However, it seems that the codeline is not activated if the transaction loaded in question is from MasterCard or American Express. Why then it should be triggered by VISA?
If &transdata(&i).EX_TRANS.RATE_DIV.Value > 0 And
((&transdata(&i).EX_TRANS.DATA_SOURCE_EX.Value <> "MC" And
&transdata(&i).EX_TRANS.DATA_SOURCE_EX.Value <> "AMX") Or
&transdata(&i).EX_TRANS.MONETARY_AMOUNT.Value = RoundCurrency(((&transdata(&i).EX_TRANS.TXN_AMOUNT.Value / &transdata(&i).EX_TRANS.RATE_DIV.Value) * &transdata(&i).EX_TRANS.RATE_MULT.Value), &transdata(&i).EX_TRANS.CURRENCY_CD.Value, %Date);
A similar scenario was raised for AMEX Credit Card Transactions, whose Monetary Amounts were being re-calculated at the time of Approvals, overriding the original value provided in the flat files. This was raised under Defect # 17576943 (Expense Report Is Incorrectly Calculating The Monetary Amount On An AMEX Item Loaded From My Wallet), and whose fix got delivered in FSCM 9.1 ESA Bundle #29.
- In an SQL Developer query tool, connect to an FSCM DEMO environment with delivered sample data, and execute the below SQL Update to have the proper data for this test:
SET TXN_AMOUNT = 16264124.000,
TXN_CURRENCY_CD = 'INR',
MONETARY_AMOUNT = 1547.680,
CURRENCY_CD = 'USD',
CUR_EXCHNG_RT = 0.00009515,
RATE_MULT = 0.00009515
WHERE TRANS_NBR = '74168678153413068666409'
AND EMPLID = 'KU0005'
AND DATA_SOURCE_EX = 'VIS'
- Log into the FSCM Online Application as User ID EXS1
- Navigate to: PeopleTools > Security > User Profiles > User Profiles
- Open existing User ID EXS1
- In the ID tab, make sure to link it to Employee ID KU0005
- Navigate to: Employee Self-Service > Travel and Expenses > My Wallet
- Review the VISA Credit Card transaction previously SQL updated, and confirm that the Reimbursement Amount is 1547.68 USD (PS_EX_TRANS.MONETARY_AMOUNT)
- Navigate to: Employee Self-Service > Travel and Expense Center > Expense Report > Create
- Enter Employee ID KU0005, and click on ADD button
- At the Quick Start drop down list, select the value of 'Entries From My Wallet', and click on GO
- Find the VISA Credit Card transaction, and confirm how the Reimbursement Amount displayed is different by several cents: 1547.53 USD
- If the Credit Card transaction is defaulted and saved into the Expense Report, the system will override the new value and save it into PS_EX_TRANS.MONETARY_AMOUNT
To gather more information concerning this scenario and its related problem, refer to the available Replication Steps Word Document here linked containing the complete configuration and the replication steps necessary to reproduce the issue.
When the VISA Credit Card transaction gets defaulted and saved into the new Expense Report, the system overrides the new re-calculated value and stores it into the Record Field PS_EX_TRANS.MONETARY_AMOUNT, overriding the uploaded value from VISA flat file. Upon sending the generated payment to the VISA Credit Card Vendor, they will be expecting a different amount (more or less, depending on the exchange rate provided), and this will cause reconciliation issues at their end, with the potential of denying the payment received.
If the VISA International flat file provided already contains and successfully uploads the Reimbursement Amounts into the Record Field PS_EX_TRANS.MONETARY_AMOUNT, the system should not recalculate the value again with any provided exchange rates. This would be for both at the time of defaulting the transaction from My Wallet into the Expense Report at the time of creation, or when an Approver is acting on the submitted Expense Report transaction. The provided value from VISA International should prevail at all times, as this is the one the Credit Card Vendor will be expecting in the payment from the company.
Sign In with your My Oracle Support account
Don't have a My Oracle Support account? Click to get started
My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms