A booking is not a row. It is a history.
Reconstructing fair performance from bookings, cancellations, deletions, rebookings and orders.
Explore the approach, code and outcome
The hidden problem
Counting records would reward duplicates, erase deleted production, place cancellations on the wrong date and sometimes credit the wrong agent. The data model stores mutable events; management needs a stable commercial history.
The decision
Group chronologically by customer, split sufficiently separated activity into project-configurable commercial cycles, then emit normalized credit and debit events. The original booking retains its owner and date; later fallout receives its own date.
What had to be understood
- Customer identity across multiple process records
- Difference between deletion and historical non-existence
- Ownership through booking-to-order conversion
- Reporting-window boundaries and downstream aggregation
foreach (var customer in bookings.GroupBy(x => x.CustomerId)) {
var history = customer.OrderBy(x => x.CreationTime).ToList();
var cycle = new List<SalesProcessShortDto>();
for (int i = 0; i < history.Count; i++) {
var current = history[i];
var next = i + 1 < history.Count ? history[i + 1] : null;
cycle.Add(current);
if (next != null &&
next.CreationTime.Subtract(current.CreationTime).Days
>= current.ClusteringDays) {
clusters.Add(cycle);
cycle = [];
}
}
clusters.Add(cycle);
}The rules that make the loop meaningful
// Preserve an active booking credit.
if (bookingCycle.Exists(x => !x.IsDeleted.GetValueOrDefault()))
result.Add(addedBooking);
// A fully deleted history did exist: emit both sides of history.
if (bookingCycle.TrueForAll(x => x.IsDeleted == true))
result.AddRange([addedBooking, removedBooking]);
else if (bookingCycle.Exists(x => x.OutcomeType == Cancelation))
result.Add(removedBooking);
// Preserve originating ownership through conversion.
order.UserId = bookingCycle.Count != 0
? bookingCycle[0].UserId
: orderCycle[0].UserId;
// Order deletion/cancellation follows the same historical rule.
if (orderCycle.TrueForAll(x => x.IsDeleted == true))
result.AddRange([order, orderCancelled]);credit at creation
debit at modification
credited to booking owner
October 2026 · Testing the model against connected history
I clarified why the activity-gap rule exists: repeated cancellations, postponements and rebookings should stay in one commercial cycle, while a later independent sale should count again. A chain can extend beyond the gap threshold overall. Changing the report window must not change its original booking date or owner.
I extended this reasoning to order identity, ownership, value and cancellation dates, using concrete records and counterexamples to challenge the behaviour.
Basis: service implementations, developer handoff examples and release history through 14 October 2026. Earlier implementation was delivered by a developer under my direction. The excerpts illustrate the historical model.
I designed and verified a model that coordinates temporal semantics, identity, attribution fairness, mutable records and reporting behaviour, then carried it through implementation, refinement and acceptance.
