So I'm trying to change to currency on my local drupal site (with room module) from USD to INR. The unit price gets converted just fine but when is comes to the order total, it's just wrong. For instance:
I booked a single room that costs 1000 INR
I booked a double room that costs 1200 INR
But when it comes to the order total, it sums up to be something like 141200 INR instead of 2200 INR. I can't seem to solve this.
You have provided no information about how you are handling your converting but the problem is pretty clear.
You are converting the price twice, thats the issue. Somehow in the current situation the system thinks the 2200 total price is in USD, and calculates it to IND.
Related
I have the following problem: I have a dataset with over 1million entries (shown below), that includes the variables company (=Name of the company (string)) and reviews (=amount of reviews a company received) and company1 (assigns numeric to specific company name). Now I want to calculate the average amount of reviews a company in the dataset receives. But if I just do sum reviewsthen it will count the amount of reviews of company 3 two times, the amount of reviews of company five 23 times etc. (as often as they are listed in the data). How do I avoid this and only count them once?
Your image is not readable (by me on a laptop). The Stata tag wiki gives detailed advice on how to give data examples and the command dataex bundled with recent versions of Stata is easily used for SE.
The flavour of your request is easier to follow. Here is an analogue. With the Grunfeld data we can calculate a mean investment for each year.
webuse grunfeld, clear
egen mean = mean(invest), by(year)
Now we might want to know how many years had mean invest above 200 (in the units used)?
su mean if mean > 200
or
count if mean > 200
returns the number of observations (not years). If you try it, the result is 30. In the Grunfeld data, there are 10 companies each measured for each year, so dividing by 10 is an easy answer. For more complicated datasets, it would better to tag each year just once, and then look only at tagged observations:
egen tag = tag(year)
count if tag & mean > 200
It would be more common to tag panels, not years, but the principle is the same. See the help for egen.
collapse and contract offer other routes, with or without using frames.
i need your help for a task that i have undertaken and i face difficulties.
So, i have to calculate the NET amount of sales for some products, which were sold in different cities on different years and for this reason different tax rate is applied.
Specifically, i have a dimension table (Dim_Cities) which consists of the cities that the products can be sold.
i.e
Dim_Cities:
CityID, CityName, Area, District.
Dim_Cities:
1, "Athens", "Attiki", "Central Greece".
Also, i have a file/table which consists of the following information :
i.e
[SalesArea]
,[EffectiveFrom_2019]
,[EffectiveTo_2019]
,[VAT_2019]
,[EffectiveFrom_2018]
,[EffectiveTo_2018]
,[VAT_2018]
,[EffectiveFrom_2017]
,[EffectiveTo_2017]
,[VAT_2017]
,[EffectiveFrom_2016_Semester1]
,[EffectiveTo_2016_Semester1]
,[VAT_2016_Semester1]
,[EffectiveFrom_2016_Semester2]
,[EffectiveTo_2016_Semester2]
,[VAT_2016_Semester2]
i.e
"Athens", "2019-01-01", "2019-12-31", 0.24,
"2018-01-01", "2018-12-31", 0.24,
"2017-01-01", "2017-12-31", 0.17,
"2016-01-01", "2016-05-31", 0.16,
"2016-01-06", "2016-12-31", 0.24
And of course there is a fact table that holds all the information,
i.e
FactSales_ID, CityID, SaleAmount (with VAT), SaleDate_ID.
The question is how to compute for every city the "TAX-Free SalesAmount", that corresponds to each particular saledate? In other words, i think that i have to create a function that computes every time the NET amount, substracting in each case the corresponding tax rate, based on the date and city that it finds. Can anyone help me or guide me to achieve this please?
I'm not sure if you are asking how to query your data to produce this result or how to design your data warehouse to make this data available - but I'm hoping you are asking about how to design your data warehouse as this information should definitely be pre-calculated and held in your DW rather than being calculated every time anyone wants to report on the data.
One of the key points of building a DW is that all the complex business logic should be handled in the ETL (as much as possible) so that the actually reporting is simple; the only calculations in a reporting process are those that can't be pre-calculated.
If your CITY Dim is SCD2 (or could be made to be SCD2) then I would add the VAT rate as an attribute to that Dim - otherwise you could hold VAT Rate in a "worker" table.
When your ETL loads your Fact table you would use the VAT rate on the CITY Dim (or in the worker table) to calculate the Net and Gross amounts and hold both as measures in your fact table
Does anyone know how Bittrex calculates the market change (shown in the image) and which values i can use to replicate it
Using the "Last Price" from https://api.bittrex.com/api/v1.1/public/getmarketsummary?market=btc-fsn gives me a different value
It looks that "PrevDay" field in API response reflects the price exactly 24 hours ago. Same for some other exchanges and data providers.
Actually % change on website should be based on same, but this may depend on how often data is refreshed in browser.
This percentage sign shows how much % market has been chnaged in last 24 hours
Like prev btc price=8000 and new btc price =8500
so market change 8500-8000=(500/8000)*100=6.25%
Consider an ecommerce site like istock, envato, etc.
Users can purchase items directly, or via pre-purchased credits which are sold at a discount (all relative to US dollar).
The credit discounts are variable, however. They can change based on quantity, strategy changes, coupons, there can be short-term sales, etc. For example, 25 credits might cost $22.50 (10% discount) while 100 credits might cost $75 (25% discount).
Assume we have a past history of all previous purchases so that the average cost of all credits is attainable by the following formula:
AverageCost = (p1.costPer * p1.numberBought) + (pn.costPer * pn.numberBought) / (p1.numberBought + pn.numberBought)
How can the spending history be used to calculate the current real value of credits in the user's account?
If the user has never bought any credits before, or has never spent any credits, then the value of a credit is exactly AverageCost (as demonstrated above)
However - if they have spent some credits previously, and bought new credits - how does the previous spending shift the average value of current credits?
Use case is a revenue share, where revenue split must be calculated based on money value, even when paid via credits sold in this manner.
Therefore, it could very well be that another relevant variable is knowing what has already been paid out (and any data which comes along with that)
Here in South Africa we have Value Added Tax (VAT) which is pretty much identical to Sales Tax and is currently fixed at 14%, but could change at any time.
I need to include VAT on invoices (which are immutable) consisting of several Invoice Lines. Each line references a Product with a Boolean property, IsTaxable, and almost all products are taxable.
I don't want to store pre-tax prices in the database, because that just makes it hard to read the real price that the customer is going to pay and everywhere I display those prices, I then have to remember to add tax. And when the VAT rate does change, for this particular business, it is undesirable for all prices to change automagically.
So I reckon a reverse tax calculation is the way to go and probably not uncommon. The invoice total is the sum of all invoice line totals, which includes any line discounts and should be tax-inclusive. Therefore the invoice total itself is tax-inclusive:
TaxTotal = InvoiceTotal / (1 + TaxRate),
where InvoiceTotal is tax-inclusive and TaxRate == 0.14
Since invoices cannot be changed once issued (they are immutable), should I:
Store a single Tax amount in my Invoices table that does not change? Or...
Store a tax amount for each invoice line and calculate the invoice tax total every time I display the invoice?
Option 2 seems safer from a DBA point-of-view since if an invoice is ever manually changed, then Tax will be calculated correctly, but if the invoice has already been issued, this still presents a problem of inconsistency. If I stick with option 1, then I cannot display tax for a single line item, but it makes managing the tax total and doing aggregate calculations easier, though it also presents inconsistency if ever changed.
I can't do both since that would be duplicating data.
Which is the right way to go? Or is a reverse tax calculation a really bad idea?
Store the pre tax value in the data base, you can also store the with tax value and use that for most use cases.
Th big problem I forsee is the rounding rules for VAT on invoices.These (at least in the UK) are really strict and there is no way for your reverse calculation to get this right.
Also you need to store the tax item by item as the VAT dragons will expect you to refund exactly the tax paid if an item is returned. You really need to get hold of the local sales tax rules before you start.
My experience is that you can get dragged over the coals if your calculations are out by as little as a penny, and, if you are audited you need to be able to show how you arrived at the VAT figure so not storing anything used in your calculations will catch you out.
I totally agree with James Anderson! In Germany the rules according VAT calculations are as strict as in the UK.
We have to accumulate the net value by VAT percentage (we have three types: 0, 7 and 19 percent) rounded by two digits. On this rounded value we have to calculcate VAT.
VAT has to be rounded by two digits and has to be showed at the invoice.
But nonetheless you can store prices including tax. It depends whether the net prices or the end prices stay unchanged when tax rises. In Germany usually B2B net prices stay unchanged but B2C end prices stay unchanged - it depends.
You can calculate it this way:
with cPriceIncludingVAT as (
select InvoiceNo, VATPercentage,
PriceIncludingVAT = cast(sum(amount * price) as decimal(12,2))
from InvoiceLines inner join VAT on VAT.VATID=InvoiceLines.VATID
group by InvoiceNo, VATPercentage
),
cVATcalculated as (
select InvoiceNo, VATPercentage, PriceIncludingVAT,
VAT = cast(PriceIncludingVAT * VATPercentage /
(1+VATPercentage) as decimal(12,2))
from cVATcalculated
)
select InvoiceNo, VATPercentage, PriceIncludingVAT, VAT,
NetPrice = PriceIncludingVAT - VAT
from cVATcalculated;
If you save this as a view you should be able to reprint a dynamically calculated VAT value exactly. When there is an accounting system you can (and should) export exactly the same data you printed.
Usually you should save values like these as field values within the database - but I understand if you'd like to have a more dynamic approach ...
The other answers are good, but as idevlop mentions, it's almost a certainty that at some time in the future, you'll start having different rates for different categories of products. Adding that capability up front will save you a ton of heartache later on. Been there, done that.