There are several possible ways to look which objects exists and where they are.
If it only relates to the sheet-level you could see the objects within the document + sheet properties in which you could also filter + sort in some degree and also export the structure. Within the most scenarios this is quite handy. But you won't get any overview to report-items on this way.
To get an overview to the report-items you could export the reports as xml-files from the report-editor which you could load in QlikView again. Quite similar - but with a lot more of information - would be to load the qvw as xml-file. At the begin it may not be very easy to comprehend the logic of the meta-data and it may cost some efforts but often it's done once and used for all applications and for years.
Another approach would be to read/write all these properties per vbs-macros. The APIGuide.qvw would be a good starting point for such tasks.
Within the most scenarios such measures aren't really needed else they could be considered as "nice to have" but not as must. The essential aspect is not to come in situations in which you loose the control/overview what's going on within the applications. This means simplifying everything and slicing ETL-tasks + applications + objects and their usage (directly as well as exports + prints) in appropriate logically/hierarchically parts.
The more complex and complicated an environment is designed the more efforts are needed to track and control all the meta-data and the more expensive becomes the documentation. In the end the above mentioned simplifying might be the more practically way because the administering and maintaining of the environment are already planned before an application is developed (it's not only Qlik related else true for all tools).
