Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

multi-currency

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • multi-currency

    You will find that your database will have to accomodate the extra decimal places even if your output does not. Precision in determining currency conversion is often measured out by many decimal places. Summary reports are particularly troublesome. Converting at the detail level and summarizing, will invariably give different results than summarizing, and then converting. Dave

  • #2
    multi-currency

    You might want to consider; there might be a requirement for multiple currency fields. Base currency, payment currency, settlement currency, etc. You might need to include a currency symbol field in addition to the currency code. Make the fields as big as you can afford. During the early days of Carlos Menem's (Argentina) administration (1988) inflation was 12%/day. Interest calculation and balance fields needed to be very large to accommodate the Peso with a new and rapidly deflating currency named the Austral. (Monthly interest calcuations ranged from 75%, to 98% on outstanding balances, depending on the institution and customer's credit rating.) Too, revalution of currency needs to be accommodated such as happened to the Chilean Peso in 1989 (14%).

    Comment


    • #3
      multi-currency

      The shop that I am working in is starting a project to enable them to use multiple currencies. The first thing that they want to do is to increase their currency field sizes to a size that will accommodate a multi-currency format. Is there any standards or best practices for this? I have gotten suggestions of anything from 13.2 fields to 19.9 fields. Note 1: We will also be adding a currency code along with the dollar amounts.

      Comment

      Working...
      X