Forum Discussion
Advocate IForecast V Actual Comparison Table
If this is more than a once-off analysis, I suggest stepping back briefly and deciding what you want to measure and visualise, and how flexible for future change it needs to be. Then re-organise tables to suit - e.g. if you're only going to ever want monthly comparisons (not fortnightly, or drill down to individual Actual records), you might consider summarising Actual records to monthly granularity for your measures. If you do decide on that, Charlie's v-caliao-msftsuggestion about joining the tables could then make for a simpler model to analyse.
Advocate IAnonymous v-caliao-msft
Thanks again guys for input...Yes i need to look at table design...i came up with this but i think the FORECASTPF table needs to be linked via ACCOUNTNUMBER to the ACTUAL table...at the moment i have linked the FORECASTPF transaction date to DATEDIM.
I will have other FORECAST excel spreadsheets to add too.
The structure above wont work that well for example if I want to compare the forecast [AccountNumber] against the Actual [AccountNumber]....How should i format the forecast table? The actual table is fine with this setup. I will have other forecast tables as mentioned like FORECASTCC, FORECASTSL, FORECASTEMW, etc....all with similar fields from an excel cashflow as shown in the FORECASTPF table above.
here is a sample of FORECAST spreadsheet i am using as the source. I have to manipulate a little to convert top row to headers and then unpivot the date/values.
Currently, FORECASTPF is connected to JOBS (via Jobnumber) and DATEDIM (Calendar Date). I think it needs to be connected to AccountNumber but i cant get that relationship to connect.
Garry,
This is getting more complex with extra columns for Job and Account, and different types of Forecast. I'm not sure what CC and PF and SL and MW are?
From your original model, I agree that linking Account to Forecast seems to make sense. You'll probably need to use a Cross Filter Direction of Single from your Account table to both Forecast and Actual to avoid an 'ambiguous relationship' error. And the same may be required from Jobs as well.
Do you want to analyse Actual vs Forecast by both Job AND Account?
- TheG
Anonymous
Hey steve, the forecast table is made up of Professional Fees (PF), Constructions Costs (CC), etc its for a property development. It will be in one spreadsheet actually but i split it for reporting purposes...The accountantlinkcode will indicate the group.
I am thinking I could merge the FORECAST and ACTUAL table into 1 fact table as advised before...The only unique fields in the forecast is the cashflow description (which i can do without if i can get the account name), transaction date and Value.
Yes there is a requirement for different jobs and account ranges...
I guess i have two fact tables ACCOUNTS from accounting system and FORECAST from Excel which have similar fields.
Given that Actuals (not "ACCOUNTS"?) from the accounting system and Forecast from Excel are imported separately, I'd suggest you start wiith:
- Import Forecast and Actuals as separate fact tables
- Extract out unique Account and Job dimensions, and create your Date dimension table as you've alrady done
- Create relationships from your 3 x dimension lookup tables down to Actuals and Forecast, using "Single" for Cross Filter Direction as needed to avoid ambiguity
- Use the FiscalMonth column on your Date table in measures to join related Actuals with their monthly Forecast
You could collapse it all into just a couple of big table. But doing the above steps up front should give you the foundations of a readable, maintainable model from which to most simply create measures and reports. There's also a good discussion by Matt Allington on creating Lookup/Dimension tables per above at http://exceleratorbi.com.au/create-lookup-table-power-pivot/ thats work a read.
Cheers,
Steve.