You can track partial goods receipts in Airtable by recording each delivery against a purchase-order line, then keeping shortages, damage and accepted quantities separate. A miniExtensions receiving form gives staff a focused way to report what arrived. The resulting queue helps purchasing decide what still needs attention without turning a delivery note into an accounting entry.

Imagine fictional Pine Workshop ordering 20 desk lamps and 10 stands for a new office. The first delivery contains 12 lamps, including one damaged unit, and all 10 stands. A single “Order received” checkbox cannot explain that outcome. The team needs to preserve the first delivery, anticipate the remaining units and distinguish physically received from accepted for use.

Use one receipt line for each observed delivery

Build this suggested structure in an Airtable base connected to miniExtensions:

  • Suppliers: Supplier name as text and Supplier reference as text.
  • Purchase orders: PO reference as text, Supplier as a linked record, Ordered date as a date, and Buyer as text.
  • PO lines: Line reference and Item description as text, Purchase order as a linked record, and Ordered quantity as a number.
  • Staff: Name as text and Work email as an email field.
  • Receipt lines: Receipt reference as text, PO line and Receiver as linked records, Delivery reference as text, Received on as a date, Received quantity and Accepted quantity as numbers, Observation as long text, and Photos as an attachment.
  • Discrepancies: Discrepancy reference as text, Receipt line and PO line as linked records, Type as a single select, Description as long text, Owner as text, Follow-up date as a date, and Resolution status as a single select.

For PO-318, record receipt R-101 for 12 lamps and R-102 for 10 stands, both carrying delivery reference DEL-51. R-101 has Accepted quantity 11 and a discrepancy for one damaged lamp. A later delivery gets a new receipt line rather than replacing the 12 with a cumulative number that erases the first arrival.

Keep Ordered quantity staff-managed. If purchasing changes the order, record the reason and reconcile the affected lines deliberately. Receipt entry should not quietly revise what was ordered to make a shortage disappear.

Give receiving staff only the fields they need

Start with a miniExtensions Form for Receipt lines. Ask for the PO line, delivery reference, date, observed quantity and notes. If several receivers need a recurring queue, use a Portal with Receiver as its direct User Field. The Users table documentation explains why each portal data table needs its own link to the staff user records.

For a controlled first version, the coordinator prepares receipt records against expected PO lines and assigns a Receiver. Staff opens those records to enter observations. The existing-record form guide describes generating record-specific edit URLs; choose an appropriate login-controlled arrangement when the information is private rather than treating knowledge of a URL as identity verification.

If you offer a line selector, use clear labels such as “PO-318 / Lamps / 20 ordered.” Where useful, configure dynamic linked-record filters so selecting a purchase order narrows its lines. Verify the empty-filter behavior and ensure users cannot select a line from another order. This picker improves selection; the receiver still checks the physical label and delivery paperwork.

Separate reported quantity from accepted quantity

The receiver first records what is physically present. Keep Accepted quantity out of the receiver’s editable form; only the designated reviewer updates that field in Airtable. A coordinator or qualified reviewer then records what can be accepted under the team’s procedure. For the lamp example, received is 12, accepted is 11, and the remaining unit has a damage case. The eight lamps not yet delivered are a different issue from the damaged unit already on site.

Use numeric Field Validation for appropriate simple checks, such as a quantity greater than zero. Do not claim that a required number field prevents an over-receipt. The documentation notes that direct comparisons between fields need a formula-based approach and Save & Continue; this example uses staff reconciliation instead of configuring that more complex behavior.

You can add rollups to PO lines for received and accepted quantities if you know how those fields should aggregate in your base. Label the results clearly. “Ordered minus received” and “ordered minus accepted” answer different questions. Returns, replacements and canceled balance quantities require explicit conventions before these totals can be treated as operationally reliable.

Keep discrepancy evidence connected to the right line

Create a discrepancy only where there is something to resolve. For the damaged lamp, record the visible issue, attach relevant photos to the linked Receipt line and assign the buyer to decide the supplier follow-up. Do not make every delivery photo a separate problem, and do not put all order photos into one unlabeled attachment field.

Set a sensible Maximum allowed files using the attachment-count guidance. Ask receivers to photograph the item and relevant packaging without including unrelated personal or payment information. A photo can support a discussion but does not establish who caused the damage or what the supplier owes.

If a second delivery contains only seven of the eight outstanding lamps, record seven on a new Receipt line. Keep the one-unit shortage visible on the PO line review. If the supplier proposes canceling the last unit, purchasing records that decision separately; the receiver should not enter an imaginary unit to make the receipt total match the order.

Make purchasing own the exception queue

Suggested Discrepancies states are New, Investigating, Waiting for supplier, Action agreed and Closed. These are custom workflow choices. An owner should review open entries, write a specific next action and update the follow-up date after an actual conversation. A date field alone does not send a reminder.

The supplier delivery update workflow covers promised dates before arrival. This receiving process covers observed quantities afterward. Keep those records linked where helpful, but do not let a supplier’s “delivered” update automatically stand in for the receiver’s inspection.

Before launch, test one full receipt, a split delivery, a damaged unit and an unexpected item. Confirm that a new delivery does not overwrite earlier evidence and that accepting one line leaves another discrepancy open. Test a second staff user’s access if you use a portal. These are recommended checks, not observed results.

This design suits a team that needs an understandable receiving and follow-up record. It does not replace inventory valuation, stock accounting, barcode hardware workflows or a warehouse management system. Start by making physical receipt, acceptance and purchasing resolution individually visible.