Sql schema design advice
The third option is to keep a transaction log of points transactions.  

Use the schema from your first option to record the "going rate" for points.  Whenever you have a transaction that either gives or takes points away from a user, write a record (or multiple records) into a points transaction log table.

The transaction log table will have a FK to USERS and a date/time to indicate when the transaction took place.  It could also have FK's to the items which generated the points, such as FK's to your TRANSACTIONS and REPORT_DETAILS tables, that's up to you.

Most importantly, the transaction log table will have a column for the number of points awarded(+) or spent(-).  To get a user's point balance, you run a sum of all transactions for the user up until the current time.  The important thing is to keep a record of how many points were given or taken for that user, at that time regardless of what may happen to other users or at other times.

If performance becomes an issue, you can keep the user's current point total on the USERS table, but this should be denormalized data based on the transaction log details.  If you do this, then you need to have controls in place to make sure you're managing this redundancy appropriately.