EPC - Why Does The Pricing Engine PC_PRICING Recalculate Foreign Transactions And Where Does It Get The Currency Rate Type From? (Doc ID 659455.1)

Last updated on JUNE 14, 2017

Applies to:

PeopleSoft Enterprise FIN Project Costing - Version 8.9 to 9.2 [Release 8.9 to 9]
Information in this document applies to any platform.
*** Reviewed for currency 14-JAN-2014 ***

Goal

The various interface processes into Project Costing (PC) all call the PC_MULTI_CUR multi-currency program.  The methodology behind PC_MULTI_CUR is to only accept the “foreign” amount and currency fields in the integration staging tables from the various other modules.  PC will then compare the currency to the incoming PC Business Unit’s base currency, and if it differs, convert it to the base currency using a defaulted rate type, as defined in PC Business Unit (BU) setup.  PC does not accept the “converted” amount, because that could still be in a currency that differs from the PC BU’s base currency.  So the consistent way to handle it is to always use the “foreign” amount, and convert if needed.  

The defaulted rate type used depends on the configuration of the "Incoming Transaction Rate Type:" value on the Project Costing BU Definition (Set Up Financials/Suppy Chain > Business Unit Related > Project Costing > Project Costing Definition).  If that setting is "Source", the default rate type is taken from the incoming transaction rather than the PC BU default.  Otherwise, the default rate type will be that defined on the PC BU definition.  However, in the case where a user overrides the exchange rate entering a value explicitly, for example on a GL journal or AP voucher, the rate type is blanked out on the source transaction (i.e. the journal) and the process falls back on using the default rate type from the PC BU regardless of the configuration.

A possible workaround to this is to grant users access to the market rates table, where they can enter in SPOT rates (instead of using user-defined rates).  PC can be configured to access these rates (instead of “CRRNT”, for example) and then convert consistently.  However, that workaround isn’t the best solution as granting access to this table can be undesirable in certain cases.

Solution

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