> For the complete documentation index, see [llms.txt](https://docs.didge.io/home/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.didge.io/home/checkpoints/incoming-goods/ig-1-incoming-goods-simple.md).
# IG-1 Incoming Goods - Simple
### 1. Purpose and When to Use This
The Incoming Goods – Simple checkpoint is used to verify that food products are received in a safe condition and meet food safety requirements at the point of delivery, using manual data entry.
This checkpoint is performed each time food goods are delivered, before acceptance into storage or production.
It is intended for environments where invoice image capture or AI extraction is not required or practical, while still ensuring full regulatory compliance and auditability.
***
### 2. Who Uses This
This checkpoint is typically used by:
* Receiving staff
* Kitchen or stores staff
* Supervisors responsible for accepting deliveries
The person receiving the delivery is responsible for:
* Entering supplier and product information
* Recording temperature and condition checks
* Making the acceptance or rejection decision
* Completing corrective actions if required
* Signing and submitting the record
***
### 3. What You’ll Need Before You Start
Before starting, ensure you have:
* Access to the Incoming Goods – Simple form (mobile or web)
* The delivered goods available for inspection
* A calibrated thermometer or probe, where temperature checks are required
Optional:
* A device camera, if attaching an image as supporting evidence
***
### 4. What You’ll See
When completing the Incoming Goods – Simple checkpoint, users are presented with a structured form that includes:
* Supplier selection or manual supplier entry
* Temperature type selection (Chilled, Frozen, Ambient)
* Product identification fields
* Temperature or frozen-state inputs (depending on product type)
* Visual inspection result
* Acceptance or rejection selection
* Corrective action fields (displayed when required)
* Optional image upload
* Signature field
All critical food safety information is entered directly by the user.
***
### 5. Standard Workflow
At a high level, the workflow follows this sequence:
* Receive the delivery
* Identify and select the supplier
* Identify the product being checked
* Record temperature or condition data
* Perform a visual inspection
* Evaluate compliance and accept or reject the delivery
* Record corrective actions if required
* Sign and submit the record
This workflow is intentionally simple and linear to support rapid execution in operational environments.
***
### 6. Decision Points and Exceptions
The system automatically evaluates entered data against configured rules, including:
* Missing required information
* Temperature exceeding defined limits for chilled goods
* Frozen goods not frozen solid
* Manual rejection of a delivery
When non-compliance is detected:
* The delivery is flagged as non-compliant
* Corrective action fields are required before submission
***
### 7. Corrective Actions
Corrective actions are triggered when:
* Temperature limits are exceeded
* Frozen goods are not frozen solid
* A delivery is rejected
* Other non-compliance conditions are recorded
When triggered:
* Users must select and record corrective actions within the form
* The non-conformance and actions taken are permanently linked to the Incoming Goods record
* Follow-up and escalation occur according to site-specific procedures
***
### 8. Validation and Records
* Compliance or non-compliance is determined automatically based on entered data
* A user signature is required to submit the checkpoint
* Completed records are stored with a full audit trail
* Records contribute to:
* Compliance reporting
* Audit evidence
* Exception tracking and trend analysis
### 9. Data Captured & Data Requirements
The Incoming Goods – Simple checkpoint captures structured food safety and compliance data through manual user entry, producing a complete, auditable record for regulatory, operational, and reporting purposes.
#### Core Data Capture Table
| Category | Data Element | Description | Mandatory | Critical to Compliance |
| -------------- | ---------------------------- | -------------------------------------------------------------------------------- | ------------ | ---------------------- |
| Supplier | Supplier source | Indicates whether supplier is selected from an approved list or entered manually | Yes | Yes |
| Supplier | Supplier name | Name of the delivering supplier | Yes | Yes |
| Supplier | Approved supplier checkpoint | Verification against approved supplier list (where configured) | Yes | Yes |
| Delivery | Temperature type | Chilled, Frozen, or Ambient | Yes | Yes |
| Delivery | Product tested (chilled) | Name/description of chilled product tested | Conditional | Yes |
| Delivery | Product tested (frozen) | Name/description of frozen product tested | Conditional | Yes |
| Delivery | Product tested (ambient) | Name/description of ambient product tested | Conditional | Yes |
| Temperature | Recorded temperature | Measured temperature value (°C) for chilled goods | Conditional | Yes |
| Temperature | Chilled temperature limit | Configured critical limit used for compliance evaluation | Yes (system) | Yes |
| Condition | Frozen state | Frozen solid / Not frozen solid | Conditional | Yes |
| Condition | Visual check result | Visual inspection outcome (OK / Not OK) | Yes | Yes |
| Decision | Acceptance decision | Accept or Reject delivery | Yes | Yes |
| Compliance | Non-compliance flag | Indicates whether the delivery failed compliance checks | System | Yes |
| Compliance | Corrective actions required | Indicates corrective action workflow triggered | System | Yes |
| Compliance | Corrective actions applied | Actions taken to address non-compliance | Conditional | Yes |
| Evidence | Image (optional) | Optional supporting photo (delivery, packaging, invoice) | No | No |
| Accountability | User signature | Confirms responsibility and submission | Yes | Yes |
| Metadata | Submission timestamp | Date and time of record submission | System | Yes |
| Metadata | Site / location | Site context associated with the record | System | Yes |
#### Notes on Data Behaviour
* Conditional fields appear dynamically based on temperature type and compliance outcome.
* Critical limits are evaluated automatically by the system using configured thresholds.
* Corrective actions become mandatory when non-compliance is detected.
* All captured data is stored in a structured format, enabling:
* Compliance reporting
* Audit evidence generation
* Trend and exception analysis
* Dashboard visualisation
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.didge.io/home/checkpoints/incoming-goods/ig-1-incoming-goods-simple.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
