Using and Customizing Retail Pro Reports

The ability to view and manipulate sales, inventory, and customer information in real-time is one of the core strengths in Retail Pro. But if you’re not taking advantage of Retail Pro reports to look at your data after the fact, you may be leaving money on the table.

Over 160 Retail Pro Reports Out of the Box

Out of the box, Retail Pro comes with over 160 reports that you can quickly access to help you analyze your business operations. These reports are available in the Retail Pro Report Viewer. In order to access these reports, you must install Report Viewer. It’s a separate application from Retail Pro.

Once you install Report Viewer, you will notice that Retail Pro reports are divided into several different categories including some of the following:

  • Audit Reports
  • List Reports
  • Journal Reports
  • Merchandise Reports
  • Summary Reports

Each of these sections holds basic reports that can provide you with a wide variety of information. For example, there are reports for customers, inventory, and sales.

Behind the Scenes: How reports work

For all of our non-technical readers: Your key takeaway in this section is that each report is limited to the kind of data it already displays.

For the tech aficionados:

Each report is based on a subset of data contained in the Retail Pro Oracle database. The best way to think about this is that a report can be based on a certain type of data: customers, inventory, sales, etc.

Structured Query Language (SQL) is the programming language we use to make requests to the database. A SQL statement allows us to select certain pieces of data from a database table. We can also use SQL to join tables together.

For example, information about customers and sales are contained in different tables and are linked by a key field. In this case, the customer ID is recorded in the sales table every time a customer makes a purchase. Although the data is not located in the same place in our database, it’s easy to use a SQL statement to join the tables so we can see a list of every sales order made by a particular customer.

When we design reports, we create the SQL statements that will provide us with the data we need for that report. If it’s a sales report, we can access data about the customer and about their sales transactions. This gives us tremendous flexibility because we can specify exactly what data we need for a particular report.

However, each report has a limited number of fields it can display, because it wouldn’t make sense to show every field from every table in the database on every report. There’s just no practical use for that kind of reporting. Instead, we define exactly what type of information we may need and build it into the SQL statements for that report.

Translation:Each report is limited by the fields it can display. If a field is not included in the report’s underlying data set, it cannot be displayed on the report.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.