qliksense: measures are not showing the right numbers - pivot-table

Qliksense measures issue:
I have a report basically containing a table with data coming from purchase invoices with the following fields:
creation_date
expect_Rcpt_date
buy_From_vendor
quantity
Unit_cost
amount
project_Nbr
I have added a pivot_table and a graph next to it to display a measure of summaries on amount (calculated using quantity X unit_cost). I want to visualize by year and vendor, but however all vendors show up the same number, being the total number.
Any help please??

You need to include a term to aggregate the information
if this is your existing code
quantity * unit_cost
change it to
sum(quantity * unit_cost)

Related

How to get the value once only from the blended data, when the left dataset makes it repeat in Google Data Studio?

I have blended 2 datasets, joining them by a couple of keys. The left dataset contains data for most of the dates, while the second one has monthly sales goals for each salesman.
So, I'll have the daily sales, which when summed up, they give me the total, but when I sum the sales goals from the right dataset, it gets repeated for each sales person occurrence in the left one, giving me the wrong result.
If I put it on a table visual and set its calculation to Average, it gives me the correct sales goal for each person, but the total is wrong and if I put it on a KPI visual, the total is also wrong.
Any help is appreciated.
Thank you!
Sorry, it is not possible to have the same field aggregated as average first and in the next step sum over these average values.
For the total of the "sales goal" can be extracted from right dataset.
If your data comes from Big Query, you could do following steps:
add an "empty" record for each month and sales person to the left dataset
join the two datasets in BigQuery
add a calculated column "goal per order", which is the "monthly sales goals" divided by the number of orders this salesmen had this month. This count number is count(orders) over (partition by salesmen, month_column)
In Data Studio the aggegated sum of the "goal per order" is the value for "goal per salesman"

How to calculate the tax free amount of sales, based on date fields?

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

Calculating dynamic pricing on Google Sheets

I have imported data from a trading exchange listing sellers of a particular cryptocurrency.
From this data, I want to create dynamic pricing to display an average cost on an order based on given order size.
I will give an example of what I am looking for:
Example dataset
Within this example, we would be purchasing the cryptocurrency 'SINS'. As per the data showed on this table, if 29.06 SINS was purchased, that would fill the first order, and the total BTC paid would be 0.00459 BTC.
If an order was placed for 145 SINS, it would fill the orders up to row 12 and partially fill the order in row 13. By calculating that manually, I know that would cost 0.02293365 BTC (calculated using col D) at an average price of 0.00015816 per SIN.
What I would like to achieve is if a number is entered in a cell, it confirms the average price of an order based on the number entered and the orders imported from the trading exchange.
=INDIRECT(ADDRESS(MATCH(VLOOKUP(O2,F2:F,1),F:F,0),7,4))+(
INDIRECT(ADDRESS(MATCH(VLOOKUP(O2,F2:F,1),F:F,0)+1,4,4))*(O2-
INDIRECT(ADDRESS(MATCH(VLOOKUP(O2,F2:F,1),F:F,0),6,4)))/
INDIRECT(ADDRESS(MATCH(VLOOKUP(O2,F2:F,1),F:F,0)+1,3,4)))
spreadsheet demo

Calculate number of full time equivalent employees using DAX measures

I am able to calculate how many employees are working using DAX measures:
Number of employees started := CALCULATE(COUNTA([Emp from]);FILTER(ALL(tDate[Date]);tDate[Date]<=MAX(tDate[Date]))) -
Number of employees quit := CALCULATE(COUNTA([Emp unitl]);FILTER(ALL(tDate[Date]);tDate[Date]<=MAX(tDate[Date])))
Number of employees working := [Number of employees started] - [Number of employees quit]
But I have not managed to calculate how many full time equivalent employees are working. Each employ has a workload from 0% to 100%.
How can I calculate the number of full time equivalent employees?
I have tried the following for number of full time equivalent employees started, but in contrast to the measures above it doesn't accumulate over time. It just shows the results for each individual month:
Number of full time equivalent employees started:=CALCULATE(SUMX(tEmployees;tEmployees[Workload]*Not(ISBLANK(tEmployees[Emp from])));FILTER(ALL(tDate[Date]);tDate[Date]<=MAX(tDate[date])))
Do you have any suggestion for how I can solve this?
You might try something like this. In your Emp table have the start date and end date for the employee. In your measure you would use the calculatetable function to create an in memory table that has one row for each date in your date table and each employee id. This same in memory table would take the work percentage and create a column that that represents the number of hours worked by that employee on that day. Then you just need to express number of 'equivalent' employees as: sum of number of hours worked/(number of hours in a 'full time work day' * count of days in period). This should give you a measure you can use along with your dates to find the number of full time equivalent employees in on any given day or over any given period.
See my sample table structure in this TechNet forum post. This is a modelling problem first, and a DAX problem second.
Once you've created your headcount fact, all of this becomes trivial.

Implementing a sales tax strategy for Invoices

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.

Resources