iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
The JCars Logistics Power BI project shows how to shape operational records into an executive dashboard—but its charts should be treated as investigation signals, not verified company results. The author describes a workflow spanning data cleanup, a fact-and-dimension model, DAX measures, and report pages that move from an overview to detailed analysis. Public write-ups about similar JCars data report different totals, so the results are not interchangeable or established company performance.
What the dashboard is designed to help managers decide
Boaz Wangai’s project article, published October 1, 2026, describes JCars Logistics as a Kenyan vehicle importer, seller, and delivery operator. Its stated goal is to replace raw transaction logs with a structured view of sales, profitability, logistics costs, and customer behavior. The described executive page brings together revenue, gross profit, units sold, revenue trends, and top performers, with slicers for region and sales representative. Read the project article on DEV Community.
That overview is most useful when each metric connects to a management question: Are sales changing over time? Which regions, representatives, or vehicle categories contribute to the result? Are delivery time and logistics expense changing alongside sales? A dashboard can reveal where to investigate; it does not, by itself, explain why a result changed or prove that one factor caused another.
The project write-up documents an intended solution, not independent evidence that JCars officially deployed or adopted the report. Treat its descriptions as a case study of dashboard design rather than a verified account of company operations.
#1 Best Overall
Begin with the records, not the visuals
Before choosing charts, establish what one row represents. It might be an order, a vehicle, an order line, or a delivery event; those are not interchangeable. If one sale can produce multiple rows, summing revenue or counting rows as transactions can overstate results. Write down the grain and confirm it against source records.
The related project materials describe a deliberately dirty 276-record file and a broad set of fields and measures, but a repository description is not an audit of the underlying data. The write-ups identify issues and analytical dimensions such as unusual IDs, future dates, apparent duplicates, missing values, cancellations, returns, and incomplete deliveries. These should be flagged and checked, not silently deleted or automatically treated as confirmed errors.
Keep an audit trail for cleaning decisions
Use Power Query or another controlled transformation step to standardize values, while retaining enough information to trace every material change back to its source. Document decisions for:
Recommended Free Tools
Rank #2
- Dates: identify the date field used for reporting, the reporting period, and how future or invalid dates are handled.
- Currency: confirm the currency of each value and define any conversion rate, conversion date, and reporting currency. The project is framed around a Kenyan business, but that alone does not establish how every source amount was stored.
- Categories and identifiers: standardize spelling and category labels, and investigate suspicious IDs rather than assuming they are mistakes.
- Missing and unusual values: distinguish genuine zeroes from blanks, and record how outliers are reviewed.
- Order status: define whether canceled, returned, partially delivered, and incomplete orders are included in each metric.
- Duplicates: check for repeated source records against the transaction grain before removing anything.
Model the data so comparisons mean what they appear to mean
The project describes a model built from fact and dimension tables. In practice, a fact table should capture the agreed event grain, while dimensions provide consistent ways to group it—for example by date, vehicle category, branch or region, customer, and sales representative. Delivery and logistics details can support operational analysis if their relationship to each transaction is clear.
Set relationships deliberately and test that filters flow as expected. A many-to-many relationship, repeated dimension key, or mismatched date field can produce totals that look plausible but change unpredictably when a slicer is applied. Validate row counts and key totals between the source and model, and test representative filters before publishing.
Comparison requires consistent populations. Revenue by region is not comparable to delivery time by region if one calculation excludes canceled orders and the other includes them without explanation. For every rate or average, document its numerator, denominator, filters, and excluded records.
Define the measures before interpreting them
The project describes average delivery time and a profit calculation that subtracts inventory cost and logistics expense from recorded revenue. These are design choices, not self-defining business facts. A measure name such as “gross profit” does not settle which costs belong in it or which transactions count.
- Revenue: specify the source amount, date scope, currency treatment, and handling of discounts, cancellations, and returns.
- Profit and margin: define which inventory and logistics costs are included, how missing costs are handled, and whether margin is profit divided by revenue for the same included transactions.
- Units sold: clarify whether units are counted from order lines, completed sales, or another event, and how returns affect the count.
- Average delivery time: define the start and end timestamps, whether incomplete deliveries are excluded, and whether the average is calculated per order, vehicle, or delivery event.
- Return or cancellation rate: state the eligible population and denominator. A rate based on orders is different from one based on vehicles or order lines.
These definitions should be visible in documentation or metric descriptions, not left implicit in DAX. If the business changes a rule, version the measure or note the change so a trend does not quietly combine unlike calculations.
Build an executive overview with a route to investigation
The described top-level page uses headline figures, revenue trends, top performers, and region and representative slicers. Keep the page focused on a small number of measures tied to real decisions. Revenue alone can make growth look healthy even when costs are rising, so show profit and margin alongside it when their definitions and source coverage are reliable.
Rank #4
Provide paths from the summary into breakdowns for vehicle category, branch or region, representative, customer activity, delivery, logistics, returns, and cancellations. A user who spots a change should be able to determine which segment and records contribute to it. Use filters consistently and make the selected date range and inclusion rules easy to find.
These breakdowns help locate patterns and exceptions; they do not establish causation. A region with longer delivery times, for example, may merit review, but the dashboard alone cannot show whether distance, vehicle availability, incomplete records, or another factor explains the difference.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Why published JCars totals should not be combined
Public analyses of similarly described JCars data disagree. An iTechGuides analysis dated October 4, 2026, reports approximately KES 1.94 billion in revenue and a 27.44% gross profit margin; another iTechGuides case study dated October 5, 2026, discusses 276 transactions and reports a different revenue figure. These are separate analyses, not audited company results or an established benchmark. Their underlying data versions and calculation rules have not been reconciled. See the October 4 analysis and the October 5 case study.
Do not merge those figures into one dashboard narrative or infer that either represents official JCars performance. Differences in transaction inclusion, date scope, currency handling, cleaning assumptions, or measure definitions can change the result. The figure of 276 records described in the project repository also does not establish that every public analysis used the same file or grain. The related DEV Community write-up covers further dashboard breakdowns but does not resolve those discrepancies.
Reconcile the report before using it for management action
Before a dashboard result drives a target, staffing decision, or operational intervention, check that the source data and calculation rules are reproducible. A practical review should confirm:
Quick Recap
- Grain and source: identify the source file or system, its version, and what each record represents.
- Data preparation: retain documented cleaning steps and a review path for suspicious, missing, duplicate-looking, or anomalous records.
- Definitions: publish the inclusion rules and formulas for revenue, cost, profit, margin, units, delivery time, returns, and cancellations.
- Time and currency: confirm date scope, date field, reporting currency, and any conversion method.
- Validation: reconcile key totals against source records and test them under the report’s filters.
- Interpretation: use segment differences to identify questions for follow-up, not as proof of cause or company-wide performance until the underlying results are reconciled.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →
