Goods Receipts

Goods Receipts (GRs) document what your organization actually received from a vendor against an approved Purchase Order (PO). They close the loop between what was ordered and what arrived at the dock or office, and they feed receipt status on the PO so finance and procurement always share the same picture.

Overview

In a typical procurement cycle, a PO is created, approved, and sent to the vendor. When goods or services are delivered, someone records a Goods Receipt in Waqti: who received it, when, and—per line—how much was accepted, how much was rejected, and how quality looked. The system assigns a GR number automatically and derives the receipt status from the line-level quantities you enter.

Goods receipts are essential for:

• Operational control — Know what has physically arrived versus what is still outstanding on the PO.
• Partial deliveries — Support multiple shipments against the same PO without losing history.
• Quality traceability — Capture ratings and notes so vendor performance and disputes are auditable.
• Three-way matching — The GR is the “receipt” leg matched with the PO and the supplier invoice before payment.

Creating a Goods Receipt

Eligible purchase orders

Only POs with workflow status approved appear when you create a new goods receipt. Draft or pending-approval POs cannot be linked until they are approved.

Opening the create form

1. Open Goods Receipts from your tenant navigation.
2. Choose Create (or equivalent action) to start a new GR.
3. If you already have a PO in context, the app may pre-select it when you arrive with a PO query parameter (deep link from the PO flow).

Header fields

Field	Required	Description
Purchase order	Yes	Link the GR to one approved PO. Vendor and line context come from this PO.
Receiver (received_by)	Yes	The user who is accountable for recording the receipt (from your tenant user list).
Received date	Yes	Date goods were received (or service acceptance date, per your process).
Expected date	No	Optional; used for on-time delivery indicators when set.
Delivery note number	No	Reference from the carrier or vendor’s delivery documentation.
Notes	No	General remarks for the whole receipt.

Line items

For each PO line you include on the receipt:

Field	Description
Quantity ordered	Carried from the PO line for reference.
Quantity received	Units accepted into your process or stock for this delivery.
Quantity rejected	Units refused or sent back; drives line status when it fully supersedes receipt.
Quality rating	Optional integer 1–5 (1 = poor, 5 = excellent). If omitted, the system may default to 4 when saving.
Quality notes	Free text for inspection details, batch numbers, or conditions.
Rejection reason	Explain why rejected quantities were not accepted (damage, wrong spec, etc.).

You must provide at least one line item on create.

GR number (auto-generated)

You do not assign the GR number manually. On create, Waqti generates a unique number in the form GR-YYYY-NNNNN (year plus a zero-padded sequence for your tenant). A preview may be shown on the create screen (generateGrNumber), but the authoritative value is set when the record is stored.

Statuses and how they are calculated

Each goods receipt has one of these header statuses: pending, partial, complete, or rejected.

After items are saved, the application runs updateStatus() on the goods receipt. The logic (in order) is:

1. No line items → status is pending.
2. Every line item’s internal status is rejected → header status is rejected.
   (Line items become rejected when quantity rejected is at least the quantity ordered for that line—i.e. the full ordered quantity is treated as rejected for that line.)
3. Every line has quantity_received ≥ quantity_ordered → complete (full receipt on every included line).
4. Otherwise, if any line has quantity_received > 0 → partial (something was accepted, but not all lines are fully received to the ordered quantity).
5. Else → pending (nothing positively received yet on the lines that define the outcome).

When status is recalculated, the related PO receipt status is also refreshed (updateReceiptStatus on the purchase order), so aggregates stay aligned across receipts.

Partial vs complete on the PO

A single GR can be partial while another GR completes the PO. The PO’s receipt status considers all goods receipts and the sum of quantities received across them versus total ordered lines.

Editing goods receipts

Edit is allowed only when the GR status is pending or partial. If the receipt is complete or rejected, the application redirects you back to the detail view with an error—you cannot change quantities, receiver, or notes through the edit flow in that state.

Updates support adjusting header fields and line quantities/quality fields; line rows can be added, updated, or removed subject to validation. After save, updateStatus() runs again.

Marking complete

You can mark a goods receipt complete explicitly from the receipt’s actions. That path:

• If the GR is already complete, you get an informational message and nothing changes.
• Otherwise the status is set to complete, and the system calls purchaseOrder->updateReceiptStatus() so the PO reflects the latest receipt picture.

Use this when your process requires a formal “closed” receipt even if automated rules already moved the header status, or to align with operational sign-off.

Deleting goods receipts

Delete is permitted only for receipts whose status is pending. Processed receipts (partial, complete, or rejected) cannot be removed this way; attempting deletion returns an error so historical receipt data stays intact.

Deletion removes the GR’s line items first, then the header.

Partial receipts and multiple deliveries

Large or staggered deliveries are normal. You can:

• Create one GR per shipment, each linked to the same PO, entering only the quantities received in that shipment.
• Use partial header status as an indicator that more goods may still be due on those lines.
• Rely on the PO’s receipt status and totals to see whether the full ordered quantity has been received across all GRs.

Always align received and rejected quantities with what actually happened in that delivery so audits and vendor conversations stay accurate.

Quality inspection

Quality is captured per line:

• Rating 1–5 gives a quick, comparable signal for reporting and vendor scorecards.
• Quality notes hold narrative detail (visual inspection, testing results, temperature, packaging).
• Rejection reason documents why units were not accepted—critical for returns, claims, and three-way match exceptions.

The detail view can show average quality rating across lines for a quick sense of the whole receipt.

Three-way matching

Three-way matching compares three documents before payment:

1. Purchase Order — what you agreed to buy and at what price.
2. Goods Receipt — what you acknowledged as received (and in what condition).
3. Invoice — what the vendor billed.

When three-way matching is enabled for your tenant, the GR is the proof-of-receipt leg. Discrepancies between ordered, received, and invoiced quantities or prices are flagged for review instead of paying automatically.

Listing, search, and filters

The index view supports:

• Search by GR number, PO number, or vendor name.
• Status filter (or “all”).
• Date range on received date.

Pending receipts contribute to a pending count used for badges or reminders in the UI.

Tips

Link from the PO

When you start a GR from an approved PO, use any in-app shortcut that passes the PO id so the correct order is pre-selected and lines load with the right context.

Be explicit on rejections

If goods are refused, record rejected quantity and a clear rejection reason. That keeps the GR header status honest and preserves evidence for vendors and auditors.

Use expected dates for SLA tracking

If you maintain expected date on the GR, you can reason about on-time delivery using the comparison built into the model (received date vs expected date).

Do not delete once you have progressed past pending

If you need to correct a mistake after the receipt is no longer pending, use edit while status is still pending or partial. If the receipt is already finalized, follow your company’s adjustment process (e.g. returns, credit notes, or a supplementary GR) rather than expecting a delete.

Receiver accountability

Pick the receiver user carefully—the field represents who is signing off on the physical or logical receipt for your organization.

Related topics

• Purchase Orders — Creating and approving POs before receipt.
• Invoice Processing — How invoicing ties to PO and receipt data when matching is enabled.