Fact table without unique key ?

I would like to know if it's OK to design a transnational fact table without unique key(s) meaning there are no column(s) in the fact table which gives you a unique record. so you can't say 1 row by this by this....
Grain is commission transactions and unfortunately there is nothing in the source system which tracks the transaction.
It's kind of violating the 4 step process as you can't identify your grain as 1 row by ...
I know this makes this table as either inserts only or truncate and reload every time with all history and also it's not easy to join to this fact table to drill across table.
Is this method accepted in the kimball methodology ?
What are the other problems we might have with this approach ?

Thanks

No, this is fine. There is no reason a fact table requires a primary key other than to update rows.

I would add a surrogate key. I always find the need to get to one row.

ngalemmo - So, We don't need to define the grain of the fact table with 1 row by column(s) statement and we can simply say 1 row by business process ?

BoxesAndLines - We can add SK but it won't be useful to identify a unique row based on the business.

Thanks

Grain is best described in business terms, not technical columns.

For your example, the fact grain can be described as "one row for each commission transaction".

As ngalemmo said, there is no need to have a primary key on a fact table.

Boxes and Lines : Can you give me couple of reasons why we need SK in the fact table ?

Ngalemmo already gave you one, the need to update a row. Additionally, if the grain of my fact table cannot be defined by dimension relationships, then my grain is too low. In your case, I would aggregate all transactions to the lowest grain accessible by defined dimensions. I also have been known to join fact tables, especially ones at the same grain and a single unique column can come in handy. I also like to capture data quality metrics and publish them on a dashboard. Here the users can drill down to find the actual offending rows in the fact. The design is much simpler if I can access any fact table via a single column surrogate key.

Boxed and Lines:

I don't know how you update a row in a table without natural key by using just SK ?

Thanks

If you are updating a fact row, something has gone wrong. And when you are fixing the bad rows, you won't be using the SK to access the row. OTOH, if you want someone to "look" at a specific row for some reason, you can provide that person with a unique row identifier.