Sign in to run and submit your work
Reading is open to everyone. Running code and saving drafts need an account so your work is yours and comes back on your next visit.
or
CODE WORKSPACE
You are on the retail finance team. Every order has line items in amazon_order_items and can be refunded more than once in amazon_refunds. Finance needs gross, refunded and net revenue per customer, and the number they publish has to survive an audit.
Return one row per customer, ordered by customer_id.
Result columns · in this order
customer_id | The customer. |
orders | Orders they placed. |
gross | Total value of the items on those orders. |
refunded | Total refunded against those orders. |
net | Gross minus refunded. |
How to approach it
Run the starter and count the rows order 5001 produces before you sum anything.
Sample input
| order_id | customer_id | placed_on | order_total |
|---|---|---|---|
| 5001 | a1 | 2026-01-08 | 240 |
| 5002 | a1 | 2026-01-19 | 90 |
| 5003 | a2 | 2026-02-02 | 310 |
| 5004 | a2 | 2026-02-14 | 55 |
| 5005 | a3 | 2026-02-21 | 180 |
| 5006 | a3 | 2026-03-03 | 120 |
| 5007 | a4 | 2026-03-09 | 200 |
| 5008 | a4 | 2026-03-15 | 65 |
8 rows — all rows shown.
| item_id | order_id | sku | item_amount |
|---|---|---|---|
| 1 | 5001 | SKU-KB | 80 |
| 2 | 5001 | SKU-MS | 80 |
| 3 | 5001 | SKU-HD | 80 |
| 4 | 5002 | SKU-CB | 90 |
| 5 | 5003 | SKU-TV | 200 |
| 6 | 5003 | SKU-ST | 110 |
| 7 | 5004 | SKU-CB | 55 |
| 8 | 5005 | SKU-KB | 60 |
| 9 | 5005 | SKU-MS | 60 |
| 10 | 5005 | SKU-HD | 60 |
| 11 | 5006 | SKU-ST | 120 |
| 12 | 5007 | SKU-TV | 150 |
| 13 | 5007 | SKU-CB | 50 |
| 14 | 5008 | SKU-MS | 65 |
14 rows — scroll inside the table to see them all.
| refund_id | order_id | refunded_on | refund_amount |
|---|---|---|---|
| 901 | 5001 | 2026-01-15 | 80 |
| 902 | 5001 | 2026-01-20 | 80 |
| 903 | 5003 | 2026-02-10 | 110 |
| 904 | 5005 | 2026-02-28 | 60 |
| 905 | 5005 | 2026-03-01 | 60 |
| 906 | 5007 | 2026-03-12 | 50 |
6 rows — all rows shown.
Expected output
| customer_id | orders | gross | refunded | net |
|---|---|---|---|---|
| a1 | 2 | 330 | 160 | 170 |
| a2 | 2 | 365 | 110 | 255 |
| a3 | 2 | 300 | 120 | 180 |
| a4 | 2 | 265 | 50 | 215 |
4 rows — all rows shown.
Constraints
orders is how many orders the customer placed — 2 each here.gross is the sum of item_amount for those orders. refunded is the sum of refund_amount. net is gross minus refunded.refunded of 0 rather than NULL.customer_id.Worked example
Customer a1 placed orders 5001 (240, three items) and 5002 (90, one item), and was refunded 80 twice on 5001. The truth is gross 330, refunded 160, net 170.
Join orders to items to refunds and 5001 becomes six rows. SUM(item_amount) then reports 570 because each of the three items is counted twice, and SUM(refund_amount) reports 480 because each of the two refunds is counted three times. COUNT(DISTINCT order_id) fixes the order count and does nothing for either total — which is what makes this dangerous.
What this tests
That COUNT(DISTINCT ...) is not a cure for fan-out. When a parent has two independent one-to-many children, the only correct shape is to collapse each child to the parent grain first and join the summaries.
Submit for review to find out what your query gets right, what it gets wrong, and how it compares with the best working query for this exercise.
This scenario runs a full workspace — editor, canvas and results side by side. It needs a laptop or desktop to be usable. Open this page on a bigger screen to start building.