Well, if you have multiple business units sharing the DimDate table, then you copy over 365 records (i.e.: one record per day indexing on the date key) for each client into that table with a business unit identifier (foreign key). Then you ensure that identifier is also present on the Fact tables so when you do JOIN the DimDate table and aggregate it, then you are only aggregating the date records for the specific business unit. This allows you to have different fiscal calendars for different clients where maybe January 1st is not Fiscal Week 1, but maybe Fiscal Week 2 or something
This isn't per the Kimball method. If you look at the diagram with which I opened the thread, you will see that it does not require the fact table to have the calendar key in it. The way you're proposing would require a separate fact entry for each separate calendar. I've read about this before, but it's generally discouraged because of the row count increases in the fact table. It would also mean that if you added a new calendar, you would then have to take each of the transactions and create a new set for the new calendar. The advantage of the Kimball approach (in theory) is that a new calendar would simply have to be added to the calendar record. Unfortunately I can't get the solution to work completely correctly as a practical matter, and I don't know what I'm missing. Surely someone has used this method as (supposedly) it is the method by which the Kimball team approached this problem.