Reports don't create SQL views.

I'll caveat what I'm saying: it's entirely possible for a developer or Business Partner (or even the end user) to create a view in SQL, build a data model extension to expose the view to the Report Designer and then create a custom report which uses that view. But it happens in that order - the view comes first and the report last.

It doesn't work the other way around. When you add the tables and joins in a report there's nothing that persists to the database - it doesn't create a corresponding SQL view. This is largely because the Report engine isn't querying the database directly; the data model which I alluded to earlier is a layer that sits in between the raw SQL and the reporting engine. For the most part this is a pretty direct representation of the underlying SQL tables, but it also contains certain 'tables' (or even some fields in otherwise mapped tables) that don't map directly to the database and instead are calculated within the data model - StockValuations being a good example.

If we assume the latter scenario - that your report isn't already coming from a custom-written view - then you'll need to create a view which approximates what the report is doing. If you edit the report joins and click the 'use raw text editor' option you'll have a reasonable starting point. It won't translate directly. Table names are pluralised in the data model- the model will refer to SLCustomerAccounts whereas the database table is just SLCustomerAccount, for example. Also you might see something called a STATIC JOIN, which is kind of like a CROSS JOIN in SQL but isn't something you'd really need, so best to remove any STATIC JOINed tables when porting it over to SQL.

Or you could be lazy (like me! - I've used this trick before) and use SQL Server's Extended Events (or Profiler) to capture the actual SQL statement that ultimately gets issued when the report executes and use that as the basis for creating a view.