A fact table records events at a declared grain. Here, one Sales row represents one order record. Quantity and Sales Amount belong there because you can add them across those events. Product, Store, Customer and Date describe the events; their keys must be unique on the one side of a relationship.
Choose the grain before you join anything. Joining a monthly target to every daily sale repeats the target, even when the join succeeds. Likewise, joining on a product name can duplicate a sale if two products share that name. A stable key avoids that ambiguity. In a star, dimensions filter facts through single-direction relationships. Start there, then add a bridge or a second fact table only when the business question needs it.