Kevin,
I'm going to list some items I hope can be helpful on base currency conversion topic:
1. It's extremely important to understand the functional / legal background of the exercise you are going to play with your JDE environment. Standard UBEs from JDE are going to convert data at a specific fixed date with a specific fixed currency rate. Here in Europe you sometimes have to maintain the history untouched, that means you would have either to duplicate you company (example: historical company 00030 will be converted into 00300) or to duplicate the environment / datasource (this is important to maintain the same company code and related setup, like AAI / DMAAI).
2. As far as I can remember (it's a long time I'm not working with them) standard programs are covering almost all standard tables and maybe you have to spend some time for custom or localized tables. Again: it's IMHO important the business logic is driving your process. For example you can use the conversion process to clean-up (archive) some tables and starts with a smaller set of data like you are used to when you move from a different software into JDE. This is extremely important for small currency rounding issues you cannot fix completely using standard programs (even with integrity report with update mode) and can lead to inconsistencies in your final database.
3. The timing of your project mainly depends on the skill of your team, and secondly from the number of modules / tables implemented. Your team should be aware of table structures involved and how JDE is handling currency and decimal places.
Example 1: it's much more difficult to change base currency when the new base currency has a different number of decimal places (for example from 0 decimal places to 2 decimal places).
Example 2: it's much more difficult whether the new base currency code needs a different currency conversion logic (see currency constant from multiplier-Y to divisor-Z or the other way round).
Example 3: most (finance) tables are pretty straight forward and the base currency follows the CO-Company field (see for example F03B11.RPAG field following F03B11.RPCO into the currency trigger logic). There are few exeptions like the sales order detail where for example F4211.SDAEXP follows F4211.SDKCOO and not F4211.SDCO (because in this table the Company field follows the Branch-MCU field, that's different within intercompany sales orders).
Kind regards,
Carlo