It also depends on how the data is used. If you display this value for informational purposes then it doesn't matter too much which rate was used. But if you use it for actual charges then this will matter significantly. If you're purchase is charged against US dollars the value will change for the foreign customer no matter what until the time the charge is made or the check is deposited or whatever causes the actual money transfer (unless you actually are the bank <g>)...

+++ Rick ---

>>Realistically an application has to take a snapshot. If you have continuous change of the exchange rate you never get a stable price and that would be bad <g>...
>>
>>Imagine somebody sticking an item into their shopping cart and the price changing before the order is complete because of the rate change.
>>
>>Typically you'd have to grab the rate at the beginning of a session and then at stick with it and use that same exchange rate for future calculations on orders. SO it'd have to be stored with the order data itself in some form.
>
>It depends on the type of design. In one I am working on right now, there is no shopping cart. A purchase is done on an item and that's it. Also, the site is built on US prices, so it is better from a international perspective, and only at the purchase time the exchange rate is used to built the invoice for the client local currency as it is not in US.
>
>As you mentioned, an exchange rate field is present at the invoice level to be saved for reference purposes.
>
>When the client pulls the invoice later on for viewing purposes, the US cost of the item is still displayed on the description of the item line with the exchange rate. Then, the amount column includes everything in local currency, the item amount, the discount, if applicable, the taxes if applicable, and the total.