t/fxtransaction/README.txt

   1 These tests are for handling of foreign currencies in the old bin/mozilla controllers.
   2
   3 At the time of this writing, the problems are a combination of the following properties:
   4
   5
   6 1. The old controllers accumulate data on each roundtrip, and user intend often gets lost before even saving, especially with:
   7   - tax included
   8   - foreign exchange
   9   - discounts/price
  10   - payment details
  11
  12   These information must be processed and rendered both when coming from the user (freshly input) and when coming from the database (when loading a posted invoice)
  13
  14 2. payment specifically has 3 paths that can create them:
  15   - directly in the bin/mozilla form
  16   - via bank import
  17   - with the new Payment helper
  18
  19 3. fx transactions are booked internally in the system currency, but displayed in the frontend in the foreign currency.
  20
  21 4. exchangerates are saved independantly for post date and payment date, which can lead to gains/losses when converting to system currency
  22
  23    example
  24      user buys for 1000$ (system currency €, exchangerate 1€ - 2$):
  25      purchase invoice shows 1000$, but gets posted as 500€
  26      customer pays 800$, which would be 80% of the invoice, 400€ at the initial exchangerate
  27      but exchangerate at payment date is now 1€ = 1$, so the payment ist actually 800€
  28      invoice still gets 400€ paid. the other 400€ get put into losses  from exchangerates
  29
  30
  31 5. a special case arises for invoices with foreign currency where the payment is exchanged by the bank and then imported in default currency into kivitendo:
  32
  33
  34 For a normal purchase invoice with foreign currency:
  35
  36   1. main transaction (in system currency)
  37     - -500 chart
  38     - +500 Verb.a.L.u.L.
  39   2. payment proportional to stated value in foreign currency converted into system currency: 800$ ist 80% of 1000$, so 80% of 500€ get cleared
  40     - -400 Verb.a.L.u.L. - payment clears 80% of the total amount
  41     - +800 Kasse         - the stated amount in dollar, which happens to also be the euro amount
  42     - -400 fxloss (fx_trasnaction) - the difference is lost
  43
  44 With an exchangerate of 1€ = 1.6$ (500€ = 800$) at payment time, the listing would be:
  45
  46   1. main transaction (in system currency)
  47     - -500 chart
  48     - +500 Verb.a.L.u.L.
  49   2. payment proportional to stated value in foreign currency converted into system currency: 800$ ist 80% of 1000$, so 80% of 500€ get cleared
  50     - -400 Verb.a.L.u.L. - payment clears 80% of the total amount
  51     - +800 Kasse         - the stated amount in dollar
  52     - -300 Kasse (fx_transaction) - to bring the amount down to the real 500€
  53     - -100 fxloss        - aghain, the difference is lost
  54
  55 For a bank transaction the payment is instead exchanged _before_ being added into the purchase invoice, so there is no fx_transaction
  56
  57   1. main transaction (in system currency)
  58     - -500 chart
  59     - +500 Verb.a.L.u.L
  60   2. payment proportional to stated value in foreign currency converted into system currency + fx correction
  61     - -400 Verb.a.L.u.L.
  62     - +400 Kasse
  63
  64 in this case there are no fx_transctions.
  65
  66
  67 6. Old controllers now need to display both of these cases as they find them in the database and preserve them through update(), post() and post_payment()
  68
  69
  70