AWRA OpsHub Search

Two Days From When You Knew

Helpdesk & Support AWRA OpsHub Team 13 min read

Canada gives a business that sells a consumer product two days to tell the Minister about an incident, and the two days do not run from the incident. They run from the day the business became aware of it. That is a date about your organization rather than about the product, and almost no operational system has a field for it — including this one. What every system has instead is the moment somebody typed something in, which is a different date, sometimes by a week.

An incident is four things, and one of them is a missing label

Section 14(1) of the Canada Consumer Product Safety Act defines the trigger, and the definition is wider than the word suggests. Nobody has to be hurt. Nothing has to have happened in Canada. And one of the four limbs is not an event at all — it is the state of your own documentation.

The four limbs of an incident

The limb What it covers, and what it does not require

An occurrence Something happened

In Canada or elsewhere, that resulted or may reasonably have been expected to result in death or serious adverse health effects, including a serious injury. A near-miss abroad counts.

A defect or characteristic Something is wrong with it

That may reasonably be expected to result in the same. No occurrence needed — the property of the product is itself the incident.

A labelling failure Something is missing from it

Incorrect or insufficient information on a label or in instructions, or the lack of a label or instructions, where that may reasonably be expected to result in the same. An absence of paperwork is a reportable incident.

A recall elsewhere Somebody else acted

A recall or measure initiated for health or safety reasons by a foreign entity, a provincial government, a provincial public body, an aboriginal government, or an institution of one of those. Their decision starts your clock.

The third limb is the one worth sitting with. If you sell a product whose instructions are inadequate, and inadequate instructions could reasonably be expected to cause a serious injury, that is an incident under this Act on the day you realise it — with no complaint, no injury and no event of any kind.

2 days
to inform the Minister and your own supplier
10 days
for the manufacturer or importer's written report
6 years
after the end of the year, to keep the records

The clock starts on awareness

Section 14(2) reaches anybody who manufactures, imports <em>or sells</em> the product commercially — so a retailer is squarely inside it — and it requires all the information in your control to go to two places: the Minister, and the person you got the product from. Both. Within two days after the day you become aware. Section 14(3) then adds a ten-day written report, and that one falls on the manufacturer, or on the importer where the manufacturer is outside Canada.

Awareness is a peculiar thing for a database to hold, because it is a fact about people rather than about records. A customer mentions something at a counter on Tuesday. The branch manager repeats it on Thursday. A ticket gets raised the following Monday. Under this Act the interesting date is somewhere in that sequence and it is not the last one — and the last one is the only one an operations system records without being asked.

Three dates a single complaint produces

The customer says something at the counter Tuesday
A manager repeats it to head office Thursday
A support ticket is created Monday
The statutory deadline, on the first date Thursday
The deadline a ticket-anchored clock would show Wednesday
Distance between the two answers Six days

Our support clock anchors on the ticket's creation time, which is exactly right for a service promise you made and wrong for a duty that attaches to knowledge. The fix is not a better clock; it is one more date, entered by a person, with a note saying how they knew.

What a retailer has to be able to produce

Section 13 is the record-keeping half, and it splits by who you are. A retailer must hold the name and address of whoever they obtained the product from, <em>and the location where and the period during which they sold it</em>. Everybody else holds the name and address of the person they got it from or sold it to, or both. Read the retailer limb again: it does not ask who bought it. It asks where you sold it and for how long — which is a question about your own footprint rather than about your customers.

Section 13 record duties against what this product holds

What must be producible Held today Queryable across products Survives six years
The location where the product was sold Yes Yes Yes
The period during which it was sold Yes Yes Yes
Which counter, and in which currency and country Yes Yes Yes
The supplier a batch or a serialised unit came from Yes Partly — configurable by you Yes
The supplier an ordinary, unbatched item came from Partly — configurable by you No Partly — configurable by you
The day the organization became aware of an incident No No No
The trail showing how a movement was captured Yes Yes No

Built and maintained Configurable by you, not maintained by us Not built

The first three rows are quietly good and were built for other reasons: every till sale carries a counter, a warehouse and a location, plus a snapshot of the country and currency it was taken in. So "where and for how long" is a join and a pair of dates. The fifth row is the gap that matters for a retailer, and it is a schema fact — an item carries a name, a free-text category, prices and a photo, and no supplier at all. The supplier lives on the batch or the serialised unit that arrived, which means the answer exists exactly when you were disciplined enough to receive against one.

The documents outlive the trail that shows how they were captured

Nothing in this product prunes a sale, a batch or a movement — the retention policies cover logs and job tables, not business documents, so the six-year duty is met by the simple fact that we do not delete. But look at what the policies do cover. The audit log is kept 730 days. Document-vault access logs, the same. Scan events, scan sessions and scanner tokens are kept 30 days. So in year four, the record that a unit moved is there and the evidence of the scan that recorded it is long gone. That is a defensible default for an operational log and an odd one beside a statutory duty that runs to six years past the end of the year, and it is worth a deliberate decision rather than a default.

The Act asks a retailer where it sold the thing and for how long. It does not ask who bought it. Most systems are built to answer the question it did not ask.

The sibling query

The ten-day report has a requirement inside it that is easy to skim past. It must cover not only the product involved, but any products you manufacture or import that, to your knowledge, <em>could be involved in a similar incident</em>. That is not a lookup. It is a similarity search over your own catalogue — same component, same supplier, same instructions, same tooling — and the answer decides how wide the report is.

What this product gives you to answer it is a free-text category on the item and, where you receive against batches or serials, the supplier and purchase order the units arrived on. That last one is genuinely the useful axis: "everything we took from that supplier on that order" is a real query and it is often the right shape for a similar-incident answer. What is not there is a brand, a model, a manufacturer or a component — an item is a name, a category, a description, prices and a photograph.

Where and when a product was sold

Every till sale carries a counter, a warehouse, a location and a timestamp, with the country and currency snapshotted onto the record.

Built in

Where a batch or a serialised unit came from

A batch and a serial each carry a supplier, a purchase order and a received date, so a receipt is attributable.

Built in

Where a batch went afterwards

A recall trace returns the batch, its movements in order of occurrence, the locations still holding it, and quantities in, out and remaining.

Built in

A recall marker on a batch

A batch carries a recall status that is set and read across the traceability screens and the inventory reports.

Built in

A supplier on an ordinary item

An item carries a name, a free-text category, a description, prices and a photograph, so the sourcing answer travels with a receipt rather than with the product.

We can add

A date the organization became aware

A ticket records when it was created and when each clock is due; a duty that attaches to knowledge wants a separate, human-entered date with a note on how it was learned.

We can add

A similarity axis over the catalogue

Beyond the supplier and order a unit arrived on, an item carries no brand, model, manufacturer or component to group siblings by.

We can add

A recall as an action rather than a status

The status is a value somebody sets; the notification, the hold on further sale and the record of who was told would sit around it.

We can add

Four questions for a system that will hold a reporting deadline

What date does the deadline count from?

What you will probably hear

When the case was created.

How to read it

Right for a service promise, wrong for a duty that attaches to knowledge. Ask whether an awareness date can be entered separately, back-dated, and audited — because it will be back-dated, and a back-dated statutory date without a trail is worse than none.

Can you tell me where a product was sold and for how long?

What you will probably hear

We can show you the sales.

How to read it

Ask for it as a place and a window rather than as a list of transactions. Canada asks a retailer for the location and the period, which is an aggregate, and a system that can only produce ten thousand rows has not answered the question the regulator asked.

Where does the supplier of a product live in your data?

What you will probably hear

On the purchase order.

How to read it

Then it is a property of a receipt, and the answer is only as good as your receiving discipline. Ask what happens for an item that has never been received against a batch or a serial, because that is the common case and it is the one the record duty falls on.

How would we find other products that could fail the same way?

What you will probably hear

Search by category.

How to read it

Ask what the category is — in most systems, including ours, it is free text somebody typed. A supplier and a purchase order are usually the better axis, and worth asking for by name, because "everything from that shipment" is a defensible answer and "everything we filed under kitchenware" is not.

The straight answer

What AWRA OpsHub does today

  • Every till sale placed in space and time, with a counter, a warehouse, a location and a timestamp, and the country and currency snapshotted onto the record at the moment of sale.
  • A supplier and a purchase order on every batch and every serialised unit, alongside the date it was received.
  • A recall trace for a batch, returning its movements in order of occurrence, the locations still holding stock, and the quantities in, out and remaining.
  • A recall status on a batch, surfaced on the traceability dashboard and in the inventory reports.
  • Business documents that nothing prunes, so a six-year record duty is met by a retention policy that covers logs and job tables and leaves sales, batches and movements alone.
  • A dated, attributable support record, with a first-response and a resolution clock and a full comment trail, for the conversation an incident usually arrives through.
  • Custom fields on tickets, items and till sales, so any date or reference this Act needs can be recorded, reported and exported today.

More we can add to your workspace

  • A date the organization became aware, held separately from the day a record was created, with a note on how it was learned and an audit trail on any change.
  • A supplier on an ordinary item, so sourcing is a property of the product and not only of the receipt it happened to arrive on.
  • A brand, model or manufacturer on an item, which is the axis a similar-incident question is usually answered along.
  • A sales footprint as an aggregate, answering where and for what period a product was sold rather than listing every transaction.
  • A recall as an action, carrying the notification, a hold on further sale, and a record of who was told and when.
  • A retention decision for the audit and scan trail that can be set to match a statutory document period rather than an operational one.
  • An outbound notification with its own deadline, so a duty to tell somebody within a fixed number of days is a tracked obligation rather than a diary note.

Where we point you to a specialist

  • We will not tell you whether something is an incident under this Act. Three of the four limbs turn on whether harm "may reasonably be expected", which is a judgement about a product and a hazard, and the fourth turns on the acts of a foreign or provincial body you have to be watching for. That is a product-safety adviser's call and a regulatory one, and it decides whether a two-day clock is running at all.
  • We will not compute an awareness date for you. Awareness is a fact about people — who knew, when, and whether what they knew amounted to knowledge of an incident — and a system that inferred it from the earliest timestamp it happened to hold would be manufacturing evidence. What software should do is make the date easy to enter, hard to change quietly, and impossible to confuse with the day a record was created.
  • We hold a position on where a statutory date belongs, and it is beside the record rather than in a calendar. A reminder in somebody's diary is not an operational control, and the two-day duty here runs to two recipients, one of whom is your own supplier. A quotation from us for this work puts both recipients and both deadlines on the record itself, and we would push back on a specification that made it a notification and nothing else.

The first item is the one that matters and it is one nullable date, one note field and an audit entry — small, and it is what the whole two-day duty hangs on. The second and third are columns on the item and each is useful well beyond this Act; the third is the one that turns the similar-incident question from a guess into a query. The fourth is a report over data we already hold. The sixth is a setting rather than a build. The fifth and seventh are the larger conversation, because a recall that holds further sale touches the till, and that is worth scoping properly rather than bolting on.

More we can add for you

What we can build for Canada on top of the standard product

Everything listed above as something we can add describes what ships in the standard product today — it is a starting point for Canada, not a limit on what AWRA OpsHub can do there. Kenya's eTIMS integration and its maintained payroll engine are in the product because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If storing the split, not just the total, a bank or mobile money feed, a statutory return format, a rule specific to how your operation runs, or a link to a system you already have is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.

The cheapest first build in this corpus, and then three larger ones

Persist the per-levy breakdown onto the document at the moment of saving. The figures are already computed — our engine works out each levy against its own base and returns them — and today they are discarded, leaving a blended rate and one tax type on the record. In a province levying two taxes that means the total is right and the split, which is the only thing either return needs, has to be re-derived from settings that may since have moved. Storing what is already in hand would make every such invoice decomposable for the rest of its life, and it is a fraction of the size of the capability it unlocks. After that: a tax type on the line, a province on the customer and the sale, and a return assembled from the three.

Banks and payments

EFT files and bank statement feeds wired into the Payments Register, so money in and out reconciles against the documents rather than being typed twice.

Certifications and inspections, which is where a Canadian commission usually starts

A trade ticket, a medical or an equipment examination with a date that has to be watched, and a consequence when it passes: an asset that cannot be issued, a crew member who cannot be assigned, a list somebody actually receives. Custom field sets and expiry reporting exist today; making an expiry refuse rather than notify is the small build, and it is the same shape of work as the certificate stop we would do in Guyana. Seasonal resupply planning per location — lead times driven by a window rather than a reorder point — is the other one we would expect to be asked for here.

Payroll and statutory returns

A Canadian payroll engine with CPP and EI contributions, T4 and record-of-employment production and provincial levies computed on live employee records. None of it exists today; labour cost attribution to projects and cost centres does.

Systems you already run

The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.

How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.

Tell us what you need integrated

Our take

If you sell consumer products in Canada, the surprising half of this Act is not the two days. It is that the two days run from knowledge, and that a labelling gap with no injury behind it is a reportable incident. Our sales records already answer the retailer's record duty well — where, for how long, at which counter, in which currency — because a till sale carries its whole context. What we do not hold is the date you knew, and that is the field the deadline is computed from. Record it as a custom field on the ticket today, with a note on how you learned; ask us for it as a first-class dated field with an audit trail, and it is a small build. And check your supplier answer for ordinary items before you need it, because in this product it lives on the receipt rather than on the product.

Tell us which of your obligations start on knowledge

Deadlines that run from awareness rather than from an event are the ones operational systems handle worst, because every timestamp they hold is about a record. If you want the wider traceability picture, <a href="/blog/twenty-four-hours-and-a-glossary">the FDA's traceability records</a> covers the lot-level side and <a href="/blog/the-recall-notice-arrives-on-a-friday">a recall arriving from a manufacturer</a> covers the case where somebody else started the clock.

Talk to us about your workspace

Help Center

Need a quick answer while you read?

Run inventory, procurement, assets, sales, and field work with approved AWRA guidance for setup, migration, integrations, security, pricing, and support.

Search all approved AWRA public help articles.

Open Help Center