Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →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
Alex Majale’s JCars Power BI project shows how a report can move from inconsistent transaction data to useful sales and operations views without treating every repeated Order ID as a duplicate. The author describes examining the data’s row-level meaning, preserving uncertain records, cleaning and modeling the dataset, then building three report pages. The dashboard figures below are Majale’s reported results from this dataset—not independently verified company-wide performance.
Start by deciding what one row means
Majale says the JCars dataset had 276 transaction records and 46 columns covering customers, vehicles, locations, sales, payments, delivery, and costs. The project treated each row as one transaction or order record. That decision matters: counting rows as transactions is meaningful only if the row grain is understood and consistently represented.
The project article’s guiding questions are practical for any transaction analysis: “What does one row represent?”, “Can I trust this identifier to be unique?”, “Is this really a duplicate, or just a repeated value?”, and “What does this missing value mean?”
Recommended Free Tools
Investigate repeated IDs instead of deleting them automatically
The source contained repeated Order IDs, including ord1020, CAR1086, and ord1174. Because those records differed on other attributes, Majale did not infer that identical IDs proved duplicate transactions. Instead, the project retained the records, assigned each fact row a unique Transaction Key, and kept the original Order ID as a source reference. As the author puts it, “A duplicate value is not automatically a duplicate record.”
#1 Best Overall
| Choice | What it protects | Risk to manage |
|---|---|---|
| Delete every row with a repeated Order ID | A smaller table if the rows truly are duplicate copies | Potentially distinct transactions may be lost without evidence that they are duplicates |
| Retain records after investigation, with a unique row key | Potentially distinct transactions and traceability to the source Order ID | Counts can be overstated if analysts later treat the repeated business ID as a unique transaction key |
The project chose retention because the records differed and their identity was not established. For analysis, that means row count, distinct Order ID count, and distinct Transaction Key count are different measures; the intended meaning should be explicit in each visual or calculation.
Clean inconsistent values while preserving uncertainty
Majale reports inconsistencies across customer type, region, county, city, branch, lead source, vehicle make, fuel type, transmission, vehicle year, discounts, prices, costs, delivery dates, and delivery status. The issues included blanks, N/A and NULL placeholders, inconsistent capitalization and spelling, Excel serial dates, invalid dates, and values that needed numeric validation.
Rank #2
Power Query work described in the project included standardizing text and categories, handling missing and placeholder values, assigning data types, validating numeric fields, investigating dates, creating calculated fields, and checking the transformed results. Toyota capitalization variants were standardized. By contrast, the author did not merge sales-representative names such as “Faith” and “Faith Achieng” absent evidence they named the same person. This distinction avoids turning a plausible match into an unsupported fact.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsThe author reports retaining all 276 records and reaching zero technical Power Query errors after transformation. That result describes the transformation process; it does not establish that every source value was correct or that every ambiguity was resolved. The project’s approach was to investigate and disclose uncertain records rather than silently remove or combine them.
Build a model that reflects the questions
The reported model used a star schema: a central Fact Sales table connected to customer, vehicle, location, sales, payment, delivery, and date dimensions. A dedicated Date table covered 1 January 2025 through 15 July 2026.
Order Date had the active relationship to the Date table, making it the default date context for ordinary time-based analysis. Delivery Date had an inactive relationship, available for delivery-focused calculations when explicitly invoked. This choice changes what a date slicer means: by default it filters orders by order date, not by delivery date.
Reported DAX measures included total revenue, units sold, cost, profit, profit margin, average delivery days, average discount, delivery fees, logistics cost, revenue per unit, transaction count, average units per transaction, and profit per transaction. For total cost, Majale describes calculating units sold multiplied by unit cost rather than simply summing a pre-existing total field. The article does not provide the full formulas or enough detail to reproduce every measure independently.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →What the three report pages showed
The report had an Executive Overview, Sales & Profitability, and Delivery & Operations page. The following values are figures reported by Alex Majale in the 2026 project article; they should be read as this dataset’s project results, not audited business results. Read the project article.
| Reported view or finding | Project result | How to interpret it |
|---|---|---|
| Executive Overview | $1.273B revenue; $455.46M profit; 36% profit margin; 452 units; 276 transactions; 16.76 average delivery days | Top-level results shown in the author’s report; the source does not independently validate the calculations |
| Vehicle performance | Toyota: about $540.8M revenue from 137 units | A reported make-level result for the dataset, not a broader market claim |
| Vehicle performance | BMW: about $50.9M revenue and a margin around -2% | The author presents the negative margin as a reason to examine acquisition cost, selling price, discounts, and transaction records; the project article does not establish its cause |
| Delivery status | Held records averaged about 25 days; Delivered records averaged about 15.4 days | A comparison in the analyzed records, not evidence of why one status group took longer |
Handle delivery dates as data-quality evidence
The project identified negative calculated delivery periods for LCL-1080, CAR1219, ord1229, and LCL1236. Majale retained these as visible data-quality issues rather than removing them without explanation. That is useful because a negative interval can point to an incorrect, misinterpreted, or mismatched date; hiding it would make the resulting average harder to assess.
The dataset reportedly mixed valid dates, blanks, placeholders, Excel serial values, and invalid dates. The article does not establish the correct dates for the four records, so their negative intervals should not be treated as valid delivery durations or as proof of a particular cause.
What this case study can—and cannot—tell you
The case study illustrates a sound analytical sequence: establish row grain, investigate identifiers, make cautious cleaning decisions, model around the questions, and distinguish the default date relationship from an explicitly selected one. It also demonstrates why a dashboard’s polished metrics depend on choices made before visualization.
Its numerical findings remain specific to Majale’s account of the JCars dataset. The project article does not provide Power BI or Excel version numbers, independent validation of the source dataset, reproducibility evidence, or an audit of the calculations. A reader can use the described workflow as a model, but should not cite the reported figures as independently verified business performance. Project source: Alex Majale’s JCars Power BI article, published 29 September 2026.
Quick Recap
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.
