Thanks for the input.
I do have some data that are only at the Order level (Tax Amount, Payments), but they may not be essential to reporting.
Primarily, I thought I'd have the table to permanently store some relatively complicated calculations on cross-selling/up-selling activity.
I am working through the cube design now and will check out the aggregation functionality.
So in reference to my original dilemma, regarding having InvoiceNumber as a degenerate dimension or putting into its own dimension, Kimball says:
A surrogate key is necessary if the transaction control numbers are not unique across locations or get reused. For example, the retailer’s POS system may not assign unique transaction numbers across stores. The system may wrap back to zero and reuse previous control numbers when its maximum has been reached. --Kimball
In my case, the InvoiceNumber is not unique and requires Store Number. Is the DimInvoice dimension recommended? Even though you can make a degenerate dimension combining InvoiceNumber and StoreKey from the FactRetailSales table?