valid point. Your call. There would only be there additional columns, and maybe users would only fill them in if dates differed from forecast? The beauty of having it in seperate columns is that it makes it easier to filter on say the color red and/or pivot the data so you can only look at things that are say past forecast date, while still being able to see what the original date actually was.
Whereas if they are on seperate rows, as soon as you filter on 'past forecast date' then you filter out what the actual forecast date was in the first place. Might not be an issue to you.
Thoughts?
You could always put the extra 'Actuals' columns side by side, and group them so that a user can expand/contract them if they are/are not relevant.
Is it only the dates that will change, or financial figure too? i.e. you just need to track date slippage, not financial slippage?
Ahhh. Two rows it is, then.
Sorry Han, this slipped off my radar. Thanks for your prompt. Will take a look today.
Hi again, Han. I take it that when the data is amalgamated, you still want to be able to see what tab each bit of data was pulled from? Also, to match up the forecast and actuals for each item, you really need a unique ID that they both share.
I'll put something together that addresses both of these, and also fix the tabs so that they are the same size and don't move around when you make changes to the worksheet.
Also, will every row ultimately have a 'forecast' and 'actual' component? Or do you just put in the ones that have slippage?
Bookmarks