Currency - No. of Decimals
Date: Wed, 24 Mar 1999 10:21:30 -0500
Date: Wed, 24 Mar 1999 10:51:22 EST
Date: Wed, 24 Mar 1999 12:14:21 -0500 Currency - Translation
From: Steve Bradley sbradley@sprynet.com
Date: Wed, 17 Mar 1999 04:08:28 PST
Date: Thu, 18 Mar 1999 16:49:11 -0500 MRC - Invoices & Exchange Rates/Dates
Date: Thu, 29 Apr 1999 15:40:51 +1000 Translation Balance Tables
From: Mehra, Varun (CAP, GECSI) [SMTP:Varun.Mehra@geind.GE.com]
Date: Fri, 30 Apr 1999 14:57:01 -0400 Change of Functionnal Currency
Date: Mon, 27 Jul 1998 14:43:32 EDT
De: Pascal Lambert Pascal_Lambert@fr.ibm.com [mailto:Pascal
Lambert Pascal_Lambert@fr.ibm.com]
Date: Wed, 30 Jun 1999 08:47:50 -0500
Date: Wed, 30 Jun 1999 18:19:12 +0200
Date: Thu, 01 Jul 1999 00:35:26 PDT GL Translation running for Feb not for Jan
From: seetha raman seeethu@hotmail.com
Date: Tue, 6 Jul 1999 08:51:02 -0400
From: seetha raman [mailto:seeethu@hotmail.com]
Date: Wed, 7 Jul 1999 14:05:35 -0500 Cross Currency pmnts/10.7
Date: Wed, 07 Jul 1999 22:55:08 PDT
Date: Wed, 11 Aug 1999 19:33:29 +0700 Recalculate amounts after correcting the currency rate
Date: Sat, 14 Aug 1999 02:11:06 PDT
Date: Fri, 20 Aug 1999 08:49:56 +0700 Configuring MRC - EURO
Date: Mon, 29 Mar 1999 07:42:48 -0600
Date: Fri, 26 Mar 1999 09:16:30 -0800 Euro Compliance for 10.7NCA
Date: Mon, 02 Aug 1999 17:36:38 +0100
Date: Mon, 2 Aug 1999 11:39:46 -0500
Date: Tue, 3 Aug 1999 08:59:08 +0100
From: "Joe Maliszewski"
Subject: Currency: Number of Decimals
Here is a question affecting (or is effecting?) all the modules. We are
11.02 - GL, AP, AR, CE, WIP, SM, SC, INV, PO
The client wants to have the display to be 5 decimals for USD. This has to
do with a requirement in Inventory and their pricing and costing. I am not
an Inventory person so I cannot talk through any workarounds. I am a
Financials guy.
Other than looking different on the screens, can anyone think of the
ramifications of changing the display for USD from 2 to 5? The client wants
to do this and is even willing to change all the programs/reports necessary
where a 5 decimal place value will not be acceptable (i.e. Check printing,
Invoices, Statements, Purchase Orders, etc., etc.)
I have tried to talk them out of this scenario but this is the direction
they want to take.
If anyone can think of additional programs/reports which are effected by
this please forward them also.
Joe Maliszewski
Consultant
jmaliszewski@csi.com
From: JanLCooper@aol.com
Subject: Re: Currency: Number of Decimals
Joe,
Under currencies there is two places to change the decimal point. If you
change the alternate to 5 places you should be able to keep financial
functionality at 2 decimal places.
Jan Cooper
From: "Joe Maliszewski"
Subject: RE: Currency: Number of Decimals
Jan,
I do not think that is the answer to my question. I am aware of the
Extended Precision functionality available. But for some reason that is not
going to work for the Inventory module. Again I am not familiar enought
with Inventory to make the call.
Thanks for the suggestion though.
Joe Maliszewski
Consultant
jmaliszewski@csi.com
Subject: RE: Error in Translation
Date: Tue, 16 Mar 1999 09:34:05 -0500 (EST)
You left out an important step in your process - Revaluation.
You must always run revaluation prior to translation (or any
reporting).
Revaluation must be done to adjust the functional balances resulting
from
foreign currency entries. The revaluation rate for your transaction
will
likely be the same as the translation rate (depending on account type).
Translation converts functional balances only regardless of the
original
entry currency. You should get the desired $4,187.50 if this is done.
With your process (translating only function entered transactions),
what
would happen to any other currencies used for entry if only functional
currency entered amounts were translated? How would French Francs be
translated to USD?
Respectfully,
Steve Bradley, CPA
OASIS Consulting Group, Inc.
Office 404-352-8387
Fax 404-609-9856
Pager 888-912-2569
From: "Kaushalya Madhavan" price_hss@hotmail.com
Subject: RE: Error in Translation
Hi Steve
I ran revaluation, before running translation and got the desired results
- but this was only for my Balance Sheet Accounts. What about the Income
Statement Accounts ?
To continue with the example assume the following :
Period - Jan-99
01/01/99 - Sales Booked (Account Code 9999) - USD 1000@41 (Converted INR
41000).
15/01/99 - Sales Booked (Account Code 9999) - USD 1000@42 (Rs. 42000)
25/01/99 - Sales Booked (9999) - INR (Rs. 17000)
Period Avg . Rate for Translation - 0.025
When I run Translation I get the following result -
100000*0.025 = USD 2500 i.e. (41000+42000+17000)*0.025
To get the Correct figure which is :
$1000+$1000+(17000*0.025) = $2425
I tried a workaround whereby I ran a Revaluation for the Account 9999 using
the Period Avg. Rate i.e 40(1/0.025). Though principally this is wrong as
you never revalue Income Statement Accounts.
I got the desired result, however this process works fine only in a
particular month, I tried doing it for the next month Feb-99, using a
different Period Avg. Rate, but it did not give the correct result.
Is there anyway we can get the desired/correct results for Income
Statement as well as Balance Sheet Accounts.
An early reply would be highly appreciated.
TIA
From: Steve Bradley sbradley@sprynet.com
Subject: RE: Error in Translation
Kaushalya,
Sorry I'm late getting back to you. As I mentioned in my original
response, "The revaluation rate for your transaction will
likely be the same as the translation rate (depending on account type)".
This is true for most balance sheet accounts and may be true for current
period P&L accounts - depending on how you use the exchange rates during
the period and define the Historical rate. P&L, equity and some other BS
accounts are translated at Historical rates. How you define your
Historical rates and exchange rates during the period may cause a
difference between the enter US$ amount and Translated US$ amount at the
end of the period.
The correct amount is $2,500 if you are going to define the historical rate
to be 0.025. Remember, translation translates the converted functional
balance and ignores the entered currency.
It can get very complex, trust me.
Respectfully,
Steve Bradley, CPA
OASIS Consulting Group, Inc.
Office 404-352-8387
Fax 404-609-9856
Pager 888-912-2569
From: Peter_McMahon@gecfa.com.au
Subject: RE: MRC - Invoices & Exchange Rates/Dates
Mohan (and all), thanks for the interest.
Let me give you a run down of what has happen at the site I'm currently at
and try to answer your questions and explain some of the "problems" that
the client has with MRC and Accounts Payable
Upgraded to Rel 11 at begining of April. No EURO - using MRC to report in
USD
Functional Currency invoices are only allowed in the AP system - the
Payables Option "Use Multiple Currencies" is not enabled. Because this
option is not enabled the fields in the primary book for Gain, Loss and
Rounding a/c's cannot be entered/defined.
Problem 1 - Gain/Loss/Rounding Accounts in AP
In testing we ran into problems with payments where an invoice was entered
in period 2 and paid in period 3. The exchange rate to our reporting
currency changed between these to periods, so a gain/loss occured - but
because the Gain/Loss a/c's were not defined in AP the system could not
create the correct G/L distribution for the payment and so the payment
failed. Logged with support etc....the work around that we came up with was
to manually set the gain,loss and rounding accounts thru SQL*Plus. This
means that the payables option "Use Multiple Currencies" is still disabled,
the gain/loss/rounding accounts still disabled (greyed out), but they now
contain values!!!!
(BTW, more recent investigations point to it being possible to set these
Gain/Loss/Rounding accounts at the bank/bank account level - further
research required here though!)
Problem 2 - The MRC Exchnage Date (original mail message)
As outlined below - standard functionality for MRC is to use the exchange
date from the primary book (if available) and if not available to use the
invoice date (or transaction date as you called it).
In our setup the payables option "Use Multiple Currencies" is disabled -
therefore we cannot enter in exchange date/rate information against any
invoices (not that we would want to as they are in the functional
currency). So MRC uses the invoice date to pick up the exchange date.
Client has a couple of problems with this.
Firstly - what if entering an invoices dated last April (12 months old - we
have just had that - don't ask why) and no exchange rate exists for the
particualr invoice date....
Secondly, the AP option "GL Date Basis" allows you to decide how to default
the GL date for your invoices (from the manual "The date you want Payables
to use as the default accounting date during invoice entry. ") We have that
set to 'System' (I have been to several other sites where system is used).
Client feels that if you can decide when you want to recoginse the invoice
(i.e. the GL date) and configure the system to do that for you, surely you
should be allowed to decide what exchange date to use when converting to
your MRC book. So instead of MRC deciding either the exchange date, or the
invoice date if the exchange is not available, a system option should be
available to determine which date to use (like GL Date Basis).
Thirdly, if foreign currency invoices were allowed ("Use Multiple
Currencies" enabled), the exchange date field defaults to the value of the
GL Date (as far as I can remember - not the invoice date!) so why should
MRC be different (i.e. why should MRC not default the exchange date to be
the GL date if there is no real exchange date?)
Problem 3 - Multiple OLD invoices on a single check
confirm payment batch kept failing with no decent error message. So
manually went thru the payment batch, creating QUICK Checks for weach
checque listed on our Preliminary Payment Register for the payment batch.
Worked ok for the first few checks. However it fell over when I tried to
pay 3 OLD invoices on a single check. By old I mean that the invoice date
was back in Jan. In a test environment we copied from production we could
pay these invoices individually - i.e. one invoice per check. However when
I tried to create a check with more then 1 OLD invoice it fell over with
the following error message displayed on screen
"APP-10000 ORA-00001 UNIQUE CONSTRAINT
(AP.AP_MC_PAYMENT_DIST_ALL_U1) Violated.
ORA-06512 *"apps.ap_mrc_payment_dist_bid" line 880
ORA-4088 error during execution of trigger 'apps.ap_mrc_payment_dist_bid'
occured in ap_create_pay_dists_pkg.distribute_payment
apxawkb with parameters check id40300, invoice payment id
While performing the following operation insert cash line."
What I think is happening here is that the trigger and/or package is trying
to create a Gain/Loss MRC Payment distribution line for each invoice to be
paid by the check and is not handling it properly. This is currently with
OWWS.
So that is about it for the moment - hope that explains where we are with
MRC -
Thanks
Peter
Sent: Friday, April 30, 1999 12:16 PM
Subject: Translation Balance Tables
Hi everyone
The client also wants to customize a report which would require picking
translated EXPENSE account balances (our functional currency is INR, and
we
translate to USD) post-translation run every period. There is also a
requirement that the same report should also be able to pick these
translated balances for a period, say April-99, even if executed two
months
down the line. Could you please share as to the table from where GL picks
up
these details of the translated balances. I checked the GL_balances table
and have obviously missed something as I report a lack of understanding.
Please do write in to share your thoughts.
Many thanks
Varun Mehra
Consultant-Oracle Applications
GE Capital, India
From: "Jagannathan, Ravi" RJagannathan@prcnet.com
Subject: RE: GL-two queries
Varun,
The main tables to be connected/queried for getting translation balances for
Expense Type accounts are :
GL_BALANCES
GL_CODE_COMBINATIONS
GL_TRANSLATION_TRACKING
GL_PERIODS
Thanks
Ravi Jagannathan (MIS)
Tel : (305) 816 4831
From: Dany Paradis DParadis@teleglobe.ca
Subject: Change of Functionnal Currency
Bonjour,
We want to change the functionnal currency From Canadian to US.
We know that we can create a new set of book and migrate. Is there
other alternatives?
1. We would like to know if somebody have already made this kind
of change.
2. How did you process.
Your help will be very appreciated.
Dany Paradis, Teleglobe Canada Inc.
Date: Tuesday, July 28, 1998 4:52 AM
Objet: RE : Change of Functionnal Currency
Hi Dany,
Your need is very close of 100% EMU users. All of French, Dutch, ...
users have to change functional currency (From FRF to EURO, from DM to
EURO, ...) from 01-JAN-1999 to 31-DEC-2001.
Oracle France says that Oracle EMEA will deliver scripts to do that
in next release of 11. No date is announced.
We suppose that this programs will not be available until last
quarter 1999 so we began to work on that on the release 10.7.
We are very interested to share experience on that.
Pascal LAMBERT
IBM Global Services - Paris - France
From: "Logan, Ernie" Ernie_Logan@bmc.com
Subject: RE: RE : Change of Functional Currency
One alternative is to use MRC (Multiple Reporting Currencies). It will
handle both the EMU and the Canadian issues. The MRC is finally supposed to
fully delivered with 11.0.3.
From: Victor Chang vchang@obaps.com
Subject: Re: RE : Change of Functionnal Currency
Hello
Multi Reporting Currency (or socalled Minipack) in R11 can be considered to meet
your requirement.
EFC utility can be used to make a reporting SOB the Primary SOB.
Victor Chang
O.P.E.N. BUSINESS APPLICATIONS B.V.
Businesspark ARENA
Olympia 1A-1B
1213 NS Hilversum
Netherlands
tel : +31 (0)35 646 2650
fax : +31 (0)35 646 2725
mobile : +31 (0)653 303 522
E-Mail : vchang@obaps.com
From: Thomas Kuglen tkuglen@hotmail.com
Subject: RE: Change of Functional Currency and MRC
For countries switching to the euro as part of EMU, the path to changing the
functional currency is well defined. It is:
1. Upgrade to R11, presumably with the primary functional currency still
the legacy or NCU currency (ITL, FRF, DEM, etc.) (MRC was available for
10.7 but it is no longer available to new users.)
2. Enable and initialize a euro MRC book using the initialization utility.
This gives you two books: a primary in the NCU and the MRC in the euro.
(From a system standpoint, this is very similar to having two "functional
currencies" although there are a few limitations on the MRC book.) This
initialization utility is well-tested and in release.
3. Run the EFC (Euro as the Functional Currency, Oracle's name not mine)
utility. This will switch the euro to the primary functional currency and
the NCU to the MRC. This utility is currently under test and is expected to
be released this fall.
The key to this conversion strategy is that completing the upgrade and then
running the two utilities can be done at any time independently of each
other. If you want a "big bang" you can complete all three steps at the same
time. If you'd rather phase the transition, then you can complete each step
over a period of weeks, months or even years. Also, at some point you will
want to disable the MRC and archive and purge since it adds about 60% to
your database. There are also process dependencies between an MRC and the
primary while it is enabled.
We've been using R11 and MRC since last summer and through 11.0, 11.01, and
11.02. We were a new implementation and we went right to the euro as the
primary functional currency so we didn't need the initialization and switch
utilities, but for the most part we have found that MRC works.
As far a switch from CAD to USD, that's not what the utilities were designed
to do but I can't think of any reason why the same process could not be
followed. (One reason why there might be a problem is that the CAD/USD
exchange rate varies while the EUR/NCU rates are fixed.)
Subject: GL Translation###
Hi All,
I have a problem on translation.
We are multi-company set up with one set of books.(No Multi Org). We have 10
companies in the set of books and 6 of them have already into oracle apps.
Implementation is on for others.
We have been running translation for 6 companies since jan-99 with out any
problem for these cos.
We have imported Journals for the new companies in jan-99. We get a TB in
the Functional currency for jan-99, feb-99.....
But we are able to run translation from Feb-99 only. ie In the LOV for
Periods in the Run translation form I get periods from feb-99 only. I have
specified Period end,avg rates for Jan-99 also.
After running translation for feb-99, we do not get any TB in USD
(Translation-Trial Balance). Through sql we found out that translation is
not taking place.
The problem is for the new companies only and remember we have TB in
Funtional currency for these companies since jan-99.
Where did I miss. Advance Thanks for the help.
Thanks
seetha
From: MAS GOPAL KRISHNA GKRISHNA@FAMILYDOLLAR.com
Cc: "'seeethu@hotmail.com'" seeethu@hotmail.com
Subject: RE: GL Translation###
Seetha,
In order to run translation for a period, at least one previous period needs
to be defined. That is, in your case, if January 99 is the first period that
you have set up, you ought to have defined at least December 98 to be able
to run a translation for January 99.
Go through the "Prerequisites" under General Ledger - Multi-Currency-
Translation in your Help or User's Guide.
Gopal
Sent: Wednesday, July 07, 1999 12:04 PM
Subject: RE: GL Translation###
Hi Gopal,
1. I have been trying to run translation for feb-99.
2. I am able to run translation for 6 companies perfectly with out any
problem.
thanks for your reply
seetha
From: "Logan, Ernie" Ernie_Logan@bmc.com
Subject: RE: GL Translation###
Did you confirm the existence of the required currency translation rates?
From: ravi chandran johnny_ravi@hotmail.com
Subject: Croos currency payments
Hi!
Cross currency payment feature is available i ver11.0. we have a client on
10.7 & this feature is not available. Any workarounds?
Thanks,
Ravi
From: Argon Usman argon@newmail.net
Subject: Re: Croos currency payments
You have to convert the payment to base currency before receiving a
payment.
Any gain/loss have to be entered either in GL or by misc. receipts.
From: "moses rajasingh" mosesrajasingh@hotmail.com
Subject: CURRENCY RATE PROBELM
Hi
Entered the currency rates wrongly in the currency rate capture screen,
entries happened in AR and transfered to GL. Can anybody tell me, Is there
any way to recalculate the amounts with right currency rate? Give me some
ideas, in case you have faced the same problem.
Regards
Moses
System Analyst
Olam International Ltd.
Singapore.
From: Argon Usman argon@newmail.net
To: oraapps-l@cpa.qc.ca
Subject: Re: CURRENCY RATE PROBELM
Hi Moses,
I think you can do Adjustment (Adjust Exchange Rate) from the Special
menu.
Hope you can find it.
--
Argon I. Usman
Consultant
From: "Gandla, Ravi" RGandla@usa.capgemini.com
Subject: RE: Euro and MRC
Hi Peter,
I have configured MRC (Euro currency) for various financial modules for
a client in France.
I will be glad to share my experience with you. Write to me or call me.
Cheers,
Ravi
716-596-3903
From: "Peter Manning" pmanning@transport.com
Subject: Euro and MRC
Does anyone have experience configuring R11 MRC functionality
with Euro
requirements? I am looking for experiences, pros and cons etc.
I am
looking at potentially configuring MRC for several European
countries. I
want to weigh my options beforehand.
TIA
From: c073 c073.bbs@btinternet.com
Subject: Euro Compliance for 10.7NCA
Hi everyone,
I understand that 10.7 NCA is not Euro compliant.
We use GL, AP, PO, CM, FA and are looking at Euro strategy.
1. Does anybody know what extra features 11 or 11i have with regard to
the Euro
2. Are any of you Euro users at the moment
3. How much work is involved in adding Euro functionality to 11
I hope that some one out there can offer me some advice.
Kind regards
Ian Gardner
Britannia Building Society
From: "Logan, Ernie" Ernie_Logan@bmc.com
Subject: RE: Euro Compliance for 10.7NCA
There are several excellent white papers on this topic available from
MetaLink, if you have access.
From: Graham Duggan gjduggan@mail.com
Subject: RE: Euro Compliance for 10.7NCA
Depends on what you mean by Euro compliant. The core functionality,
fixed rated and triangulated calculations (I think) are provided by way
of Euro patches for 10.7. There are two PDF documents which were in
Metalink somewhere. As the search engine now officially sucks I can't
find them even when searching for "euro 10.7".
The documents are
The Euro in Release 10.7
Oracle Financials Euro Extension Users Guide.
There are three patches to apply and a bit of setup
757859 Server Backport R11 euro currency support to 10.7. 2145343.1
792066 Client Backport R11 euro currency support to 10.7. 2145343.1
752208 Server Euro rates utilities for release 10.7 with R11 Backport
2145343.1
Our French users seem happy with the outcome. I think you will find some
bespoke development will be required for things such as invoices if you
want to show amounts in both the indigenous currency (e.g. FF) and
Euros.
Graham.