Automate a weekly report with an explicit reporting cutoff

A weekly report should select a defined business period, not whatever records happen to exist when a script starts. Separate the event-time window from the extraction time, and decide how late arrivals affect the report version.

Use fixed parameters for reruns. If a failed Monday report is retried on Tuesday, it should not silently become a different reporting period because the code recalculates its dates from the current clock.

Define three times with different roles

The original synthetic report automation lab reports paid events from January 5, 2026 at 00:00 UTC inclusive through January 12 at 00:00 UTC exclusive.

The event timestamp determines which week contains an event. The received timestamp records when the source learned about it. The extraction timestamp identifies the source snapshot used for the report.

The fixture allows extraction up to one hour after the period ends. E2 occurs at January 11, 23:59 but arrives at January 12, 00:30, so it belongs to the reporting week and is available in the declared 01:00 extract.

Use inclusive start and exclusive end boundaries

E1 occurs exactly at the period start and is included. E3 occurs exactly at the period end and is excluded. Adjacent reports using the same half-open convention can meet without counting the boundary event twice.

The configuration file stores both boundaries explicitly. The pipeline validates UTC timestamps and compares event time with those parameters.

import json
from pathlib import Path
from pipeline import load_source

config = json.loads(Path('report-config.json').read_text())
selected,metrics,evidence = load_source('events.csv','source-manifest.json',config)
assert config['period_start']=='2026-01-05T00:00:00Z'
assert config['period_end']=='2026-01-12T00:00:00Z'
assert [row['event_id'] for row in selected]==['E1','E2','E5']
assert metrics['selected_events']==3 and metrics['amount_paise']==3500
assert metrics['identical_replays']==1
assert metrics['by_region']['South']['amount_paise']==2000
print({'period_start':metrics['period_start'],'period_end':metrics['period_end'],
       'selected_events':metrics['selected_events'],'amount_paise':metrics['amount_paise']})

Run the example from the lab directory. It produces three selected events totaling 3,500 paise, or ₹35. One identical replay is collapsed before aggregation. A canceled event and records outside the period do not contribute.

Make source readiness a separate gate

The source manifest declares an event watermark through the report's exclusive end. If that watermark is earlier, the pipeline refuses to prepare the report. It also checks the extraction time against the configured allowance.

Those are consistency checks against the supplied manifest. A locally generated watermark is not independent proof that the upstream system has delivered every event. A production watermark needs a documented operational meaning and evidence that the source honors it.

Similarly, a one-hour allowance does not guarantee that no event will arrive after an hour. Select that policy from source behavior and business needs, then define what happens when a later correction appears.

Version corrections instead of rewriting history invisibly

If another eligible event arrives later, preserve the original report and create a corrected input version with its own evidence. State whether the business publishes preliminary and final versions or restates prior periods under an explicit rule.

A weekly total that changes can be legitimate, but the reason should be traceable to changed source records, configuration or code. A stable reporting period makes that explanation possible.

The lab hashes those inputs into its run identity and retains local bundles. It prepares output for review only; no external distribution occurs.

Be explicit about timezone and calendar

This exercise uses UTC and fixed seven-day boundaries. A business week defined in a local timezone may have a different UTC boundary, particularly around daylight-saving changes. Define the local calendar first, then convert to unambiguous instants.

Do not mix timezone-naive source timestamps with UTC cutoffs or assume every local day always has twenty-four elapsed hours. The earlier timezone examples in this programme show why that assumption can fail.

Exercise: add an event one second before the upper boundary and one exactly at it. Predict the selected IDs before running the code. Then describe how a late arrival after the extraction allowance would become a separately reviewed correction.

NeuraPath's Data Analytics with Generative AI course connects Python reporting with metric contracts. A reliable weekly automation makes its period, source snapshot and correction policy reproducible.

Continue learning

This article is part of the Reliable reporting automation sequence. Use the neighbouring tasks when you need the prerequisite or the next application.

• Continue with Make a reporting script safe to rerun.
• Then apply it in Detect incomplete source files before generating a report.