I am currently building a Ruby on Rails invoicing application that is multilingual and supports a range of currencies. In the dashboard view all invoices a user has produced are totalled.
Now it would be nice if a user could choose the currency for each invoice.
But how can those invoices be totalled if different currencies are used?
E.g. if these three invoices were created today:
Invoice No. 1: $1000.00
Invoice No. 2: $2000.00
Invoice No. 3: €1000.00
Total: $4333.60
----------------------
The dollar-euro exchange rate would have to be based on each invoice's date of course.
How can this be achieved in Rails and does it even make sense?
Thanks for any pointers.
The sum of of multiple invoices using different currencies is not a single number, it's a collection of numbers. If you have a 20 USD invoice, a 15 EUR invoice, and a 20 EUR invoice, the sum is "20 USD + 35 EUR".
At the time when a payment is made from a single account using a single base currency, then a conversion will be performed to determine how much will have to be paid in that currency to cover the total converted costs. Presumably, there will also be currency conversion fees added at that time.
It would be convenient if you change the currency to a single one, either euro or dollar right when the user makes an invoice. That is, you save the 'converted' value in your database. In this way you won't have to lookup for past day rates.
Eu_central_bank provides exchange rates.
Related
I have changed this question and the correct working answer to reflect explicitly the solution for my exact problem.
This is for accounting purposes. I'm trying to create a debit and a credit table so that I can keep track of payments and have balanced books for my business partner.
I thought to try =if(1, value) in the credit and debit tables however I will get a whole lot of cells of FALSE return values when it discovers values of 2 and vice versa which is not practical.
I have rows of information which I designate a type either 1 or 2. For example:
type
description
amount
date
comment
2
cable
50
12 May
1.0mm flat
1
payment 001
30
24 May
2
plugs
10
8mm size
2
bits and pieces
15
1
payment 002
20
30 May
I have a debit and credit columns in another sheet so what I want to happen is I want each line of the first table and any new line added thereafter sorted into a credit column and a debit column automatically.
Description
Date
Comment
Credit type
amount
payment 001
24 May
1
30
payment 002
30 May
1
20
Description
Date
Comment
Debit type
amount
cable
24 May
50
2
1.0mm flat
plugs
10
2
8mm size
I understand that there must be formula in the credit and debit type cells.
I need some kind of sorting system.
Many ways to do that.
If you need just one table use
=SORT(A2:C8,1,1)
OR EVEN
=QUERY(A1:C8,"where A is not null order by A",1)
If you need two tables just use it twice
One can also use
=QUERY(A1:C8,"where A=1 order by A",1)
AND
=QUERY(A1:C8,"where A=2 order by A",1)
(Do adjust the formulae according to your ranges and locale)
Credit to #marikamitsos and theartsnettutors with the earth for giving me confidence to resolve this problem and giving me the tools to figure it out for myself.
The best tool to use is QUERY using the SELECT function and then selecting the columns from the RAW data table in the order that you want the data printed:
RAW data:
Solution for CREDIT table:
Solution for DEBIT table:
The best approach to understand what i need is taking a look at the sample spreadsheet
https://docs.google.com/spreadsheets/d/1AyqCMvbjUt3nlqvE2ZLbmPfixwh_i1nIl9HMTn4pETY/edit?usp=sharing
What i need is unpivot the data:
1st date payment
xx months depending on the months entered in Col G (here i need to round the amount of the monthly payments, and in the last payment adjust the amount, so i don't get cents in the monthly payments divided)
last date payment
i believe the best way is generate a data base ordered correctly, from there know in which date every client has a due date for his payment
The way im entering the data is as the sample sheet shows from A:J
And my expected result is in range L:P
any help on this please will be very much appreciated
This is probably best handled by breaking the problem in 2 parts. Monthly payments and First/Last Payments. I've laid out one possible solution on your sheet in a tab called MK.Idea.
I used a SPLIT(FLATTEN( technique to generate both sets of cashflows and then a simple query to stack and order them.
This formula generated the monthly flows:
=ARRAYFORMULA(QUERY(SPLIT(FLATTEN('S1'!A2:A&"|"&'S1'!B2:B&"|"&MROUND(('S1'!D2:D-'S1'!E2:E-'S1'!I2:I)/'S1'!G2:G,100)&"|"&EDATE('S1'!H2:H,SEQUENCE(1,MAX('S1'!G2:G),0))&"|"&EDATE('S1'!H2:H,'S1'!G2:G)&"|"&"Monthly "&SEQUENCE(1,MAX('S1'!G2:G),1)),"|",0,0),"select Col4,Col1,Col2,Col6,Col3 where Col4<Col5"))
I'm using Google Sheets to organize data from my global royalty statements. Currently I'm querying several tabs (one for each country) to produce a single table with results from all countries. As you can imagine, I don't want 125 Japanese Yen showing up in my charts and graphs as $125 USD (125 Y is equivalent to about $1.09 USD).
Since I receive my royalty statements in their respective currencies, I'd like to apply average conversion rates either during the query operation or after the fact. Since the table is being generated dynamically, the values won't always be the same, so I need some way to apply the conversion by searching the list of currencies on the fly. I've got a separate table on the same tab containing all the average conversion rates for each currency. Here's a sample of how this is set up:
So basically I just don't know how to say, in coding terms, "If this line item comes from the UK, divide the royalty amount by the UK exchange rate. If it comes from Canada, divide by the Canadian rate, etc."
Anyone have any insight as to how I might pull this off (or whether it's possible)? The actual table includes over 500 line items from a dozen different countries, so doing this by hand is something I'd like to avoid.
I believe you are looking for the GoogleFinance() function. You may want to set the Country to a pick list of the valid country entries so you could create the string for the conversion. I have not looked at many, but this will take a value in CA & and apply the exchange rate to convert it to the US $ Equivalent. The exchange rate in this case is an average of, I believe, the past 30 days.
=C2 * GoogleFinance("CURRENCY:CADUSD" , "average")
For your use, you can get the country code from row M if you change it to match what the formula is after, such as CAD for Canadian Dollars."
=C2 * GoogleFinance("CURRENCY:" & M2 & "USD" , "average")
Another option would be to create a lookup table and use VLOOKUP or some other function, depending on how you set up your table.
I am writing a rails app that deals with product inventory. I would like to include the following features, and am struggling with developing an efficient algorithm:
View stock history (how many were in stock on each date)
Quantity removed from warehouse, and quantity added to warehouse over specific periods of time
Amount of time the product was out of stock in any given period
My questions are as follows:
What is the best way of tracking changes? In addition to my Products
table, should I create another table called
HistoricProductQuantities, and insert a new record each time there
is a change in the quantity?
What number should I track? The historic stock quantity (i.e. 50 in
stock on this day, 24 in stock on that day), or the CHANGE in stock
quantity i.e. -5 (5 sold) or 15 (15 added to inventory)? Or do I
track both in separate tables?
Thanks for your help.
First of all I recommend implementing Date Dimensions on your application, as it seems like you will be doing a lot of Time related calculations. Search on Google for date dimensions as it's beyond the scope of your questions. That said, I believe it will be of great benefit for your app to implement and use date dimensions.
As far as your direct questions go:
What is the best way of tracking changes? In addition to my Products table, should I create another table called HistoricProductQuantities, and insert a new record each time there is a change in the quantity?
Yes you could do this, I would probably call it HistoricProductSnapshot and keep track of the product activity in there on daily basis. With this information as well as time dimensions you could do calculations such as "how many of Product X Did we have 5 days ago or a month ago etc etc."
What number should I track? The historic stock quantity (i.e. 50 in stock on this day, 24 in stock on that day), or the CHANGE in stock quantity i.e. -5 (5 sold) or 15 (15 added to inventory)? Or do I track both in separate tables?
I do not have experience writing inventory control software but I believe with the Snapshot table I mentioned on the question above you would only have to keep track of quantities per day. The Change in product counts could then be calculated from your snapshot table. You could for example have a function that will output the product amount in a given time range as an array. Example: From March 1 to March 7 these were the stock amounts for Product Y [45,40,39,27,22,45,44].
Hope that helps. As I said I am not a product inventory guy but I have worked with Point of Sales Systems and the procedure above should give you a could enough start for what you are trying to do.
This gem could be usefull for tracking changes in models https://github.com/collectiveidea/audited
Keep the data raw. I would personally create a new data entry every day, displaying how much items you have in stock per day. Or you can make the interval much shorter, such as every 12 hours.
For our particular use case:
We had a table called Days, which had a many to many relationship with products, and each "relationship" will have a value called quantity (to keep track of quantity of product per day). Additionally per relationship, we had another value for the relationship with transactions (a one to many relationship) that has the entries for the time of transaction and remaining stocks.
I would personally advise you to use the quantity of stock as the raw data, as it will enable you to gather the data such as how much items were removed during a certain transaction, when the item was out of stock and when it became in stock, all through the data. When you have data in which you need to perform statistical calculations on, it's best to store this data as raw values (quantity of the item).
What's the best strategy for storing e-commerce product information (i.e. product price, current price) in a localized-currency environment?
I came across an issue in Spree, an e-commerce engine for Ruby on Rails regarding the display of currency using localization, delimiters, precision digits, etc.
However, resolving the display of price became more complex, when we had to figure out if the storing of values in the database should include the localization delimiter / precision digits or be normalized. The solution involves localizing both the display of the value as well as potentially normalizing the stored value in the database. But I'm not sure if that's the standard practice (scrubbing the data to fit a "standard" precision and delimiter OR modifying the model to take in a "currency" field, and keeping the input standard.
CASE STUDY:
If a product from the USA (using "en" localization file) is priced at 2.99, then it is stored in the database as 2.99.
If the site updates to be localized for Germany (using "de" localization file), then it is priced at 2,99.
But should updates to that price (and cost_price) value be stored as 2.99, or 2,99? If they're stored at 2.99 and the value is returned back to the view from the model, then the localization will modify the value to be 2,99.
I'm hesitant to standardize user input without their knowledge. Is standardizing currency values normal, or should the model change to handle multi-currency formats?
An extra issue to note is that even though the Spree engine can change localization, I don't believe it can flip by user-demand yet. So it's not technically a "multi-currency" environment, I believe? I'd like to pick a choice that can scale.
RELATED QUESTIONS:
database design: accounts with multi currency
Currency modeling in database
The issue is that you have a product, selling in different exchange-regimes with different cultures. Say it's $1,450.00 USD in America, and €1111,11 in Germany. There are two main factors:
A. There are different prices in different currencies
B. There are different ways to display a money amount in different cultures
Regarding A, you could
store in one price/currency, and adjust to different exchange rates on the fly
or adjust nightly
or just have different prices in different countries
I would go with a table of prices, segregated by currency. updating nightly is probably reasonable:
ProductId Currency Price
1 EUR 1111.11
1 CAD 1436.65
1 USD 1450.00
These values should be numbers, so that you can easily do math on them if necessary. Use decimal(10,2) in your database
Regarding B
You should format the selected price to a given culture upon display. Imagine an American paying in Euros. What do they want to see? Your output would look like this, depending on the selected culture:
Say it's 1,111.11 Euros
Culture Price Long Name
de_de 1.111,11 (German)
fr_ca 1 111,11 (Quebec)
en_us 1,111.11 (US English)
It's all the same amount, just formatted differently, depending on the user's preferences.
If users are entering in different amounts, you will also have to parse their values based on the selected culture. Check out Yii's (sorry, PHP) L10N and I18N features.
Notes:
Whatever you do, don't store it as a float, or you will get subtle errors over time. Use the decimal type
Consider using 4 digits after the decimal place for fields that are the result of calculations