Skip to main content
Choose the purchase workflow that matches what happened in the business, then capture enough identity, quantity, condition, cost, and location detail to verify the resulting intake. AIM has exactly two purchase doors here: In-Store Purchase and Purchase Order. Single Product Intake is outside this choice; it is not a third door in this guide. Who does this: Purchasing operator. Who else is involved: A receiving operator may verify the delivery; a product or catalog administrator may resolve an unknown identity or configuration; an owner or manager handles a committed correction or ownership decision. These labels describe workflow responsibilities, not distinct receiving-specific permissions. Current AIM access determines which surfaces and actions are available; a named responsibility does not by itself grant a receiving-specific permission.

Before you start

  • You can access the Purchase Orders/intake workspace and know whether the goods were bought for immediate in-store intake or ordered for a planned delivery.
  • Have the vendor, receiving location, product or variant identity, quantity, unit cost, condition, and ownership information ready.
  • Decide the path from the two-door table below before entering lines. The two paths share purchase order and receiving records, but their screens and submission sequence differ.
  • If identity, condition, or ownership is uncertain, stop before submitting and resolve it through the appropriate product path.
What this touches: The selected purchase order and lines, inventory units and costs after a receipt, receiving request and event evidence, and any separate sync or label-job state. Market and sales figures shown during an in-store purchase are decision context, not an automatic price or listing instruction.

Steps

The two supported doors

Single Product Intake is excluded. Do not turn this decision into a third door or use a single-item shortcut to avoid resolving the product, condition, ownership, or receiving evidence required by the selected path.

Variants

Existing versus new/custom product. Use an existing product/variant when its identity is known. When AIM does not know the item or configuration, stop and resolve the product path before the purchase is submitted. A custom-product choice is an identity decision, not evidence that the purchase was received or listed. Pre-owned purchase. Choose the Pre-owned mode when each scan represents a unique item, supply the condition grade/details, and verify each resulting unit. Do not treat Pre-owned items as ordinary quantity lines or infer that their listing state is complete. Consigned or uncertain ownership. Stop when ownership is not settled. This page chooses the purchase door; it does not assign consignment ownership or transfer ownership after intake. Partial delivery or failed intake. A standard PO can remain partially received. An in-store request can be queued, fail, or commit a partial subset. Use the durable receive state and quantity evidence for either path, rather than treating the in-store form’s finish state as proof.

When it does not go to plan

An in-store or standard purchase can create receipt evidence without making an item Ready to list, published, or repriced. Verify those downstream decisions separately.

Check it worked

  1. Confirm that the chosen purchase order exists and that its type and vendor match the business transaction: in-store for the in-store door, or the standard purchase-order path for an order.
  2. Compare ordered, received, and remaining quantities. For an in-store purchase, wait for the durable receive status; for a standard PO, check the explicit receive action and status.
  3. Inspect resulting units, unit cost, and condition/ownership evidence. Resolve any mismatch before moving to listing, publication, repricing, or labels.
  4. Treat Shopify sync and label generation as separate statuses. A successful door choice is not proof that either downstream job completed.

What was recorded

Both doors converge on purchase-order, line-item, receive-request, receiving-event, inventory-unit, and audit evidence, but the trigger differs: In-Store Purchase submits an automatic receive request, while the standard Purchase Order path leaves receive as an explicit next action. The operator’s line details, condition, unit cost, location/method, and durable request status provide the evidence needed to distinguish the two paths later.
Last modified on August 9, 2026