V
Vic
A discussion with one participant convinced me that I need to put in a
little more detail on my problem. Here it is
I have a financial forecast DB with 12 identically structured tables, one
corresponding to each month. Each table contains 28 records (rows),
corresponding to a different product family. There are 9 columns; each
corresponds to a sales source.
1) I would like to create a total monthly forecast by product family (sum
across each row) and a total monthly forecast by sales source (sum down each
column). Next, I would like to sum three tables together to get a quarterly
forecast by product family and a quarterly forecast by sales source.
If this proves successful, the complexity will grow but will be manageable.
Each monthly table will actually have multiple siblings: forecast
transactions, forecast revenue, actual transactions, and actual revenue. So
rather than 12 monthly tables, there will really be 48 plus a 49th --
product name table.
2) I can get IT to create the actual transaction and actual revenue tables
each month and just down load them monthly. That will have a major impact on
my workload.
3) I will need to compare actuals to forecasts to create deviation analyses.
4) I will need to use revenue data and transaction data to get revenue per
unit.
I was hoping to stay with the structure of the data because it fits the way
our company operates.
Ideas for solving the issue in 1)?
Vic
little more detail on my problem. Here it is
I have a financial forecast DB with 12 identically structured tables, one
corresponding to each month. Each table contains 28 records (rows),
corresponding to a different product family. There are 9 columns; each
corresponds to a sales source.
1) I would like to create a total monthly forecast by product family (sum
across each row) and a total monthly forecast by sales source (sum down each
column). Next, I would like to sum three tables together to get a quarterly
forecast by product family and a quarterly forecast by sales source.
If this proves successful, the complexity will grow but will be manageable.
Each monthly table will actually have multiple siblings: forecast
transactions, forecast revenue, actual transactions, and actual revenue. So
rather than 12 monthly tables, there will really be 48 plus a 49th --
product name table.
2) I can get IT to create the actual transaction and actual revenue tables
each month and just down load them monthly. That will have a major impact on
my workload.
3) I will need to compare actuals to forecasts to create deviation analyses.
4) I will need to use revenue data and transaction data to get revenue per
unit.
I was hoping to stay with the structure of the data because it fits the way
our company operates.
Ideas for solving the issue in 1)?
Vic