PL-300 Model the data Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  CALCULATE(SUM(Sales[Revenue]), DATEDIFF(Sales[OrderDate], Sales[ShipDate], DAY) <= 7)

  Why this is correct

  This expression is syntactically and functionally identical to the other correct option, and its presence as a duplicate answer choice is a common exam design to test your ability to recognize a valid pattern when it appears more than once. The DATEDIFF function with DAY computes the number of day boundaries between the two dates, returning an integer that does not depend on any time portion, so the filter condition in CALCULATE correctly identifies all sales where the ship-date-to-order-date span is exactly seven days or less. Since CALCULATE applies its filter arguments as a row-level condition over the current filter context, the SUM of Revenue is computed only for that subset, yielding the desired total. Recognizing that this version is correct, despite being repeated, reinforces the key rule: use DATEDIFF for date-difference comparisons, not arithmetic subtraction on datetime columns.

• ✗

  SUMX(FILTER(Sales, Sales[ShipDate] - Sales[OrderDate] <= 7), Sales[Revenue])

  Why it's wrong here

  This iteration-based approach uses SUMX to compute revenue row-by-row after FILTER applies a predicate based on direct date subtraction. In DAX, subtracting two DATETIME values yields a duration that can include fractional days from time-of-day components, so an order placed at 14:00 and shipped at 15:00 six days later evaluates as approximately 6.04, which still passes the <=7 test, but a similar subtraction with different times could produce a value like 7.04 and incorrectly exclude an order that shipped on the seventh calendar day. Moreover, using SUMX when a simple aggregated filter is needed introduces unnecessary iterator overhead and obscures the intent; the CALCULATE with DATEDIFF is the more reliable and efficient pattern.

• ✓

  CALCULATE(SUM(Sales[Revenue]), DATEDIFF(Sales[OrderDate], Sales[ShipDate], DAY) <= 7)

  Why this is correct

  This correct expression first computes a whole-number count of day boundaries crossed between OrderDate and ShipDate using DATEDIFF with the DAY interval, which ignores any time-of-day information in the datetime values. The predicate DATEDIFF(...) <= 7 is then used as a filter condition inside CALCULATE, so the context is restricted to only those sales rows where the shipping duration is at most seven days. Because DATEDIFF returns an integer for the specified interval, the comparison is deterministic and consistent, and the SUM of Revenue in the first argument is correctly aggregated under that filtered context. This is the recommended approach because it explicitly states the day interval and avoids the pitfalls of implicit duration conversions.

• ✗

  CALCULATE(SUM(Sales[Revenue]), Sales[ShipDate] - Sales[OrderDate] <= 7)

  Why it's wrong here

  Placing the direct column subtraction Sales[ShipDate] - Sales[OrderDate] inside the CALCULATE filter argument is problematic because DAX interprets the subtraction of datetime columns as a duration in decimal days, not a whole number of days. For example, if OrderDate is 2019-01-01 08:00 and ShipDate is 2019-01-08 09:00, the difference is 7.04, which fails the <=7 predicate even though the order shipped on the seventh calendar day; conversely, a difference of 6.96 might pass but still represents an order that crossed seven day boundaries when times are considered. This behavior makes the logic dependent on the precise time components stored in the datetime values, leading to inconsistent and often incorrect results. The proper way to measure elapsed calendar days is DATEDIFF, which counts completed day intervals and provides a trustworthy integer for the comparison.

Go deeper

Related to this question