Transit snapshots

The problem

When operational data changes through successive processing steps, the current state is not always enough. Investigating an anomaly often means rebuilding the sequence: which version came first, what changed, which payment or related object belonged to that moment, and whether a later correction altered the picture.

Doing this manually across several tables is slow and easy to get wrong. The goal was not to build another reporting layer, but to make one specific diagnostic task repeatable.

The approach

The workbook acts as a thin front-end. The user provides one or more stable identifiers; the tool retrieves the related snapshots, joins the relevant information and presents the sequence in chronological order. The database remains the source of truth, while Excel provides the familiar inspection surface.

The design deliberately separates configuration, retrieval and presentation. That makes it easier to change visible fields, add optional joins or adjust the query without redesigning the whole interface.

How it works

• The input contains the identifiers to investigate.
• VBA prepares the query and controls the interaction.
• Oracle returns the historical snapshots and related records.
• The output workbook standardises column names and ordering.
• Alternating formatting and an information sheet make the result easier to inspect and share.

Result

The useful part is not the query itself. It is the reduction in cognitive load: instead of remembering joins and reconstructing the chronology each time, the analyst starts from a consistent evidence set and can focus on what actually changed.

What I learned

Small diagnostic tools benefit from a narrow scope. Once the retrieval logic, the identifiers and the output conventions are stable, the interface can remain simple. The most important design decision is often not adding another feature, but deciding which evidence must always be visible.

Stack: Excel · VBA · Oracle · SQL