Temporary workaround for multi currency

With v2 beta we will not have multi currency, I know, and I hope it will come in a near future version.

Any users who can assist me with a workaround, specifically for v2, as we are considering start using Inflow when v2 final comes out, dispite the absence of multi currency.
4 people have
this question
+1
Reply
  • Hi Bart,

    Here are a couple options that some creative people have come up with as workarounds for multiple currencies:

    1. Turn off the currency symbol display in inFlow at Settings -> Company Settings -> Pricing & Tax -> Currency and setting this to No Currency Symbol. Then use a custom field to mark down which currency an order is for. You can also consider changing inFlow's single currency display to the appropriate setting before printing off an order.
    2. For costing of POs, you can use Non-Vendor Costs to have costs be converted into your home currency. For example, a Canadian company buying from a US Vendor might create the PO (interpreting it as in US dollars) and then setting the Non-Vendor Costs to 6% if the exchange rate is 1 USD -> 1.06 Canadian Dollars. This way, the PO has the right numbers to be sent to the vendor and the product costs will be calculated reasonably.

    Adding explicit support for multiple currencies though is near the top of our priority list, and we hope to get to it over the next few months, but no promises.

    hope that helps,
    -Stephen
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly indifferent, undecided, unconcerned sad, anxious, confused, frustrated happy, confident, thankful, excited

  • Do you have a work-around for pricing in multiple currencies? I would want to work from my manually entered price, not a cost-based price.
    For example, if I could just tell it to divide the default price by the correct factor to convert from Danish Kroner to Euro, this would help.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly indifferent, undecided, unconcerned sad, anxious, confused, frustrated happy, confident, thankful, excited

  • To follow more up on that, how about complicated Non-Vendor costs?

    I need to convert from USD to DKK then add customs at a certain percent of the total and various import fees. I guess this is beyond anything possible in the near future?
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly indifferent, undecided, unconcerned sad, anxious, confused, frustrated happy, confident, thankful, excited

  • Hmm... yes, this is beyond what inFlow can automatically handle.

    One possibility you can experiment with for costing when entering a purchase order are to:
    1. Manually calculate the total cost (including currency conversion, customs, import fees, etc.) in DKK.
    2. Subtract the Subtotal and Freight listed in inFlow's Purchase Order.
    3. Set this amount to be the Non-Vendor Costs.

    We'll be looking into a faster way of setting up pricing schemes based on variants of another pricing scheme. Currently, one way is to:
    1. Create a backup of the database.
    2. Export the product information (which exports the default pricing scheme)
    3. Open the exported product information in Excel, and add a new column, setting it to e.g. cost * 0.134. Save this into another CSV file.
    4. in inFlow, change the default pricing scheme (under settings) to a new pricing scheme (e.g. Euro Price)
    5. Import the CSV file from step 3, setting the price to be the new column.
    6. Change the default pricing scheme back to the above.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly indifferent, undecided, unconcerned sad, anxious, confused, frustrated happy, confident, thankful, excited

  • We deal in PhP but buy in USD. None of our suppliers use the "Vendor Product Code". So we changed this label to "USD Cost" and enter something like "$3.95/set of 12" in this field. Of course, this does not enter into any calculation, but it both reminds us of the USD price and is printed on the purchase invoice.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly indifferent, undecided, unconcerned sad, anxious, confused, frustrated happy, confident, thankful, excited

  • I just downloaded the new version with multicurrency support and am excited to try it out. But before I start messing around with it, I need to know more about what will happen to my OLD data that used a workaround. In the past I no currency symbol. Then I used the value in USD as the vendor price (for the one vendor with whom I handle in USD). When I made a purchase order, I manually calculated the conversion and added all the other expenses (customs, handlign fees, etc.) to get a real total cost. I subtracted the amount on the purchase order and put the difference in "Non-Vendor Costs" so that the pricing system would still give me useful values.

    If I now start trying to set up this vendor with USD and an exchange rate, etc., will that impact the closed purchase orders? Do I need to modify anything before doign this? We're a small company off to a slow start, so I'm only talking about a few orders, but messing it up can get quite nasty with these exchange rates...

    Also what happens to previous values when you modify the exchange rate? For example, goods I imported a few motnhs ago do not have the same exchange rate as something I need to order today. If the exchange rate gets updated, will the costs continue to reflect the actual value at the time of purchase or does that get recalculated?
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly indifferent, undecided, unconcerned sad, anxious, confused, frustrated happy, confident, thankful, excited

  • Hi,

    The old orders shouldn't change -- they should stick with the old no-currency-symbol method that you already have. With the (clever!) trick you were using before though, inFlow won't know how to handle that, so the reports on that old data might come out weird.

    Each sales or purchase order keeps track of its own exchange rate, so your old orders won't change when you order something today at a different exchange rate (unless you manually change it).

    Costs (i.e. the Moving Average Cost, Manual Cost, or Last Purchase Cost that are used for profit calculations in inFlow) are always tracked in the Home currency. They don't get recalculated automatically. On the other hand, Vendor prices are always tracked in their own currency. If you enter a new PO, the updated exchange rate will be taken into affect when calculating the Moving Average or Last Purchase Costs.

    I don't expect you'd have major problems upgrading, but in any case it's a good idea to do a backup before updating; so you have the option of reverting to the old version if necessary. Please see more information on updating and how to revert here: http://www.inflowinventory.com/Knowle...
    (under beta version 2.2.1)
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly indifferent, undecided, unconcerned sad, anxious, confused, frustrated happy, confident, thankful, excited

  • EMPLOYEE
    I’m thankful and excited
    1
    Update: As of the release of version 2.2 in September, 2010, inFlow now has built-in multi-currency support, so these workarounds may no longer be needed. Thank you to everyone for your patience and support.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. kidding, amused, unsure, silly indifferent, undecided, unconcerned sad, anxious, confused, frustrated happy, confident, thankful, excited