E9.2 Daily Exchange rates

Neil

Active Member
Hi, we are in the process of getting every country on to a common instance of E1 9.2 and were going to automate the loading of exchange rates from a single data source on a daily basis.
However, some countries say they need to use their own countries bank exchange rates which means we can't load from one source. How do other people deal with this?
Any advice would be greatfully received.

Neil
 
Hi Neil,

when using the same JDE instance for multiple countries the most tricky issue on currencies' perspective is usually linked to "currency conversion method" (see Y=Multiplier vs Z=Divisor). Don't know why but "no-inverse rule" setup, which is IMHO the correct approach, is not so common.

Regarding your question on "daily exchange rates" stored into F0015 table: I think the only chance to avoid customizations is to have different OCM mapping by country so that you can maintain different copy of the same table.
Please consider the main goal of F0015 table would be to default your daily exchange rate while entering a foreign currency transaction (Sales Order / Purchase Order ... etc.).
Once currency rate field (CRR) is populated at transaction level there are only few programs using again our F0015 table (for example R42950 reprincing / recosting UBE).

Other input on present topic are welcome.

Kind regards,

Carlo
 
Hi Neil, I just was working on the problem of requiring specific exchange rates from specific sources using orchestrator. It's not easy!

In my case, one source was the free exchange rates API (rest output) and another is a national bank (XML output). I ended up having to create Groovy parsing scripts for each so that I could map specific "addresses" in the return file to specific form request inputs on the JDE side. It's not simple and it requires some coding to do. I did figure it out by myself with lots of Google help, but I'll say that JSONSlurper, JSONBuilder, XMLSlurper, and XMLBuilder should become your friend really fast :) Learning these objects within groovy will pay dividends. Exchange rate is a perfect entry into that pool because of how few fields you need to "map".

For each source, I am doing an API call, returning the API dataset (XML or JSON) to an API-specific groovy script where I parse the return, extract the data I need, and then format that into JSON for JDE to consume via form request.

In this orchestration I'm doing it for 2 different exchange rate sources. The orchestration calls are the identical, and are just a single form request component that involves loading exchange rates into the z file frontend grid. Rather than merge the datasets and have all rates go into a single Z file batch # this is a "lazy" implement meaning we'll have n number of batches each day for n number of exchange rate sources. If we need to consolidate later that would be another custom script.
1669066223797.png

Hope this is somewhat helpful!
 
Hi,

Companies I've worked at have usually used an external EDI or other Transformation tool to handle getting the rates from the different sources. That tool maps each different source into a common format. That one format is used to load the F0015Z1 then we use the standard z file process to finish loading the rates.

That's a fairly common pattern for exchanging any kind of data. Kudos to Dave for figuring out how to handle the mapping in Groovy. Having a tool designed to map file formats is much easier. If your company is as big as it sounds, you probably already to some sort of EDI in place to exchange other data (orders, invoices...). If so, I'd work with them to bring the data in from the different sources and map it to a common format for sending to JDE.

Regards,
Ellen
 
Reading the last two answers I understood I did probably misinterpret initial question.
I thought the initial question was: how to maintain two different exchange rate for the same day and for the same courrencies couple if two companies are using different sources providing different rates ?

i.e. official exchange rate in country A can be different from official exchange rate in country B (same day same currencies).

Kind regards,

Carlo
 
Hi,

Companies I've worked at have usually used an external EDI or other Transformation tool to handle getting the rates from the different sources. That tool maps each different source into a common format. That one format is used to load the F0015Z1 then we use the standard z file process to finish loading the rates.

That's a fairly common pattern for exchanging any kind of data. Kudos to Dave for figuring out how to handle the mapping in Groovy. Having a tool designed to map file formats is much easier. If your company is as big as it sounds, you probably already to some sort of EDI in place to exchange other data (orders, invoices...). If so, I'd work with them to bring the data in from the different sources and map it to a common format for sending to JDE.

Regards,
Ellen
I previously worked with Boomi which made this stuff trivial, but was quite expensive :) I'd love if Orchestrator gained a mapping component that could translate btwn edi/xml/json.
 
Back
Top