Food traceabilityBatch traceability
Batch timelines: distinguish event time from the time of data entry
A batch timeline is clearer when it distinguishes when an event happened from when someone entered or corrected the record. That distinction helps reviewers interpret late entries and imports without assuming that screen order equals the physical sequence.
At a glance
A batch timeline is clearer when it distinguishes when an event happened from when someone entered or corrected the record. That distinction helps reviewers interpret late entries and imports without assuming that screen order equals the physical sequence.
Define the decision behind the record
Record relevant time zones where events span locations. Do not sort every record solely by upload time if offline work or later document entry is possible. Preserve the basis of any reconstructed event rather than presenting it as a contemporaneous observation.
Separate when the event happened from when it was entered
Define the timestamps used by receiving, production, dispatch and later data entry. Record the relevant timezone when sites or systems differ. A single ‘date’ field can become ambiguous if some users enter event time and others enter the time they completed the form.
Preserve actual event timestamps and distinguish later entry, synchronisation and correction times. If information arrives late, place it in the event history using the supported facts without hiding the delay. Keep an uncertain event time identified as uncertain rather than using entry time as a convenient substitute.
Test a receipt entered after production, a delayed offline upload and a corrected timestamp. A reviewer should reconstruct the supported chronology and also see when the business learned or changed the information. Sorting solely by data-entry time should not make late records appear to describe a different physical sequence.
Worked example
A receiving event is entered after a subsequent stock movement. The timeline shows both the event time supplied and the actual entry time. A reviewer can understand the sequence and identify the late entry instead of seeing an apparent movement before receipt.
Build a usable record
Use the fields below to capture the facts needed for this particular decision. Keep the actual observation separate from any later correction or approval.
- Event type and batch
- Actual or reported event time
- Entry time and author
- Time zone where relevant
- Correction or import reference
Example record and review decision
Fictional record example: EVENT-01: production at 08:10; ENTRY-01: recorded at 08:25; CORRECTION-01: reviewed at 09:00 with reason.
Keep event time, entry time and correction time distinguishable, including timezone where teams or sites differ.
Sorting solely by entry time can imply that a late-entered receipt happened after production when the event chronology was different.
Test the review, not just the form
Create a practice late entry and correction. Verify the timeline and export preserve both times and indicate their meaning. If the original event time is unknown, leave that uncertainty visible rather than inventing a precise timestamp.
A few useful answers
Is upload time always the event time?
No. Preserve and label the distinction whenever data can be entered or synchronized later.
Should offline upload time replace the original event time?
Keep them distinguishable. Upload time describes data transfer; the event timestamp describes the physical activity. Where either is unknown or corrected, preserve that fact and the evidence behind the amendment.
Sources and further reading
MarkdownExplore starter templates
Start with a useful checklist
English
