Thinking about retail reporting
Today I’ve been thinking about retail reporting and trying to conceptualise an approach that demonstrates how separate from the Product Catalogue the Reporting Suite should be, even though they may share a lot of the same data.
The fundamental unit of reporting is the transaction. Whereas the fundamental unit in the product catalogue is the product, which is a physical object, in reporting a transaction is ‘an action that occurred at a point in time’. Reports are a snapshot of a point in time that shows related transactions grouped together.
The product catalogue has a hierarchical structure of units of product with depth added to the structure via attributes. The reporting suite uses a network model with nodes and connections. Generating reports is a case of selecting the nodes for that report, e.g. Refunds and Area, and then defining the connection, e.g. Last trading week. The nodes are fixed and the connections are variable.
Nodes
Transaction Type
- Purchase
- Refund
- Replacement/exchange
- Return
- Movement
Transaction Location
- Display
- Store
- Facia
- Area
- Region
Transaction Content/Quantities
- Product
- Quantity
- Value
- Margin
- Budget
- Category
- Department
- Season
The more nodes selected the finer level of reporting is achieved, e.g. The margin achieved by a single product in a single area. And the fewer nodes selected the courser the report, e.g. All purchases in all departments.
Connections
Current time frame
- Day
- Week
- Month
- Year
Comparison time frame
- This week vs. Last week.
- This year to date vs. Last year to date.
Selecting the connection between the nodes provides the window through which to view the snapshot of the state of the system at the point the report was generated. A report with the same nodes and same connections generated at a different time could show a different view as the state may have changed through transactions such as returned items.