Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Hello guys and thank you again for all your help!
As for the solutionstalwar1 presented, it work perfectly until we had to move up one "notch".
On the January problem, we had one table with a one-to-one relationship between productcode and market.
Now we have grouped Products and for each ProductGroup it's possible to have more than one Product and More than one Market.
The expected result shoul be somthing like this:
Like in January, the main objective is to to have a table where, for the stores that have soled each ProdCode we will have the Sum(SalesUnits) for the Sub-Markets (Categories) where this ProductCode belongs to.
Once again I thank you for your help!
Pedro Freire
Message was edited by: Pedro Freire
Avoiding the synthetic key in the attached example.... but will take slightly longer to run....
I do check your FACT excel. There showing only this, What was the logic behind on it? Can you check your excel whether the values are corrupted or same
Prod_BMV | 10000963 |
Prod_DUCATE | 22425 |
Prod_ONDA | 20631 |
Hello Anil,
The FACT Excel has 2 sheets:
The FACTS sheet has the Data that is loaded into the example3.qvw.
The Expected Results sheet has some Pivot Tables with the expected result for each Product (BMV, DUCATE, ONDA).
The Logic behind the calculation for BMV, for example, is as follows:
Hope this helps.
Thank you
I started looking at this yesterday and it seems fairly complex.... but having said that, I am still looking at this and will revert back if I find something.
Ok. Thanks Sunny.
Pedro
May be there is a better way to do this and this might not be 100% correct.... but look at the attached
Prod_DUCATE isn't matching, but the Excel did not select all the Stores?
Lisboa and Nazare were not included, is there a reason why they were not included for Prod_DUCATE? Once I include them, the number changes to 10043269 which matches with the output I am getting above.
The reason is that Lisboa and Nazaré haven't sold Prod_DUCATE (any of its Packs) and they shouldn't be considered for its calculation.
Check SalesUnits for Prod_DUCATE in this stores =0.
The SContrib qualifier sets in Fact-table if the product was soled or not.
Nevertheless, you are allmost there.
Check now....
I think you got it!
I'll see if this synthetic table will not impact on dashboard performance, as it's another big issue on the original app,
but as far as the model goes, it works fine!
Thank you once again Sunny!
Avoiding the synthetic key in the attached example.... but will take slightly longer to run....