> ## Documentation Index > Fetch the complete documentation index at: https://docs.aimventory.com/llms.txt > Use this file to discover all available pages before exploring further. # Choose an in-store purchase or purchase order > Choose the supported purchase door, capture the purchase details, and verify intake without conflating the two workflows. 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 | Step | Role | AIM surface | Action | Expected state | | ---- | ---------------------------------------- | ------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | Purchasing operator | Purchase choice | Choose exactly one door: In-Store Purchase for goods being captured at the point of purchase, or Purchase Order for a standard order that will be sent and received as its own steps. | The correct form opens; no third purchase option is added to this decision. | | 2 | Purchasing operator | In-Store Purchase | Enter the vendor and receiving location, scan or select each product/variant, enter quantity, unit cost, box/condition details, and choose the Pre-owned mode when each item is unique. | AIM has enough line detail to create or update the in-store PO. A manual UPC path is available; camera scanning is not promised here. | | 3 | Purchasing operator | In-Store Purchase review | Use the displayed stock, recent-sales, and market context to review the purchase decision. Correct identity or configuration before submitting. | The context helps the operator decide; it does not silently set cost, listing price, or marketplace publication. | | 4 | Purchasing operator | Purchase Order | Create a draft or standard PO with vendor, expected date, location, lines, quantities, and unit costs. Save the draft when details are incomplete; verify configuration before sending. | The standard PO remains editable as a draft, or is sent for a later receive action. | | 5 | Purchasing operator / receiving operator | Submit and receive | Submit the in-store purchase, or send the standard PO and then open its receive workflow. For either path, verify the queued/processing/terminal receive status and line quantities. | In-store submission creates a PO-backed automatic receive request; standard PO submission leaves receiving as a separate action. Neither queue submission nor a closed dialog proves completed inventory. | | 6 | Receiving operator | Purchase Order and inventory records | Compare the durable PO quantities with the physical delivery, inspect units/cost/condition, and follow any separate sync, listing, pricing, or label workflow. | The selected door and receipt evidence remain distinguishable; received inventory is not assumed to be listed or repriced. | ## The two supported doors | Door | Choose it when | What AIM does | What you must verify | | --------------------- | ------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- | | **In-Store Purchase** | Goods were bought in-store and should be captured through the in-store intake form. | The form creates or updates an `in_store` purchase order and submits an automatic receive request after any required pricing-review step. | Vendor, location, line identity, quantity, cost, condition, and the durable receive status/units. | | **Purchase Order** | Goods were ordered through the standard purchasing process and will be sent/received as an order. | The form creates a draft or standard order; after validation and sending, the operator starts receipt from the Purchase Order surface. | Draft/sent state, remaining quantity, receive status, units/cost, and any separate sync or publication state. | **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 | What you see | What it means | What to do | Where it is explained | | -------------------------------------------------------------------------------------------- | --------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- | | Vendor or receiving location is missing on the in-store form | The in-store path cannot submit its required purchase context. | Correct the form before submitting. For a standard PO draft, a location may be assigned later, but it must be present before receive. | See **Before you start**. | | A barcode is unknown, ambiguous, or not on the active PO | AIM cannot safely identify the intended product/line. | Stop and resolve the product/variant or PO line; do not substitute a visually similar item. | See **Variants**. | | Configuration, pricing review, or a Shopify prerequisite blocks receipt | A downstream prerequisite differs for this business or item. | Resolve the surfaced prerequisite, then recheck the same purchase order. Do not bypass it by choosing the other door. | See [Send and receive a purchase order](/operations/send-and-receive-a-purchase-order). | | The in-store dialog says it is finished but status is queued, processing, failed, or partial | The UI phase is not the durable receipt result. | Open the resulting PO, check status and quantities, and preserve any request/operation identifier. | See [Send and receive a purchase order](/operations/send-and-receive-a-purchase-order). | | The item was entered under the wrong identity, condition, or ownership | The intake evidence would describe the wrong business object. | Stop. Do not “fix” it by changing the purchase door; route the correction to the responsible product/inventory owner. | See **Variants**. | | A committed receipt needs reversal or correction | This guide does not establish a universal reverse-receive path. | Stop, preserve audit details, and escalate to the responsible owner or manager for a supported correction decision. Do not clear, retry, or reverse from this workflow by assumption; this guide does not promise that a reversal endpoint is available. | See [Send and receive a purchase order](/operations/send-and-receive-a-purchase-order). | 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. ## Related * [Send and receive a purchase order](/operations/send-and-receive-a-purchase-order) — complete the standard PO workflow and verify receipt. * [Existing versus custom products](/setup/existing-vs-custom-products) — resolve item identity before either purchase door. * [Product, inventory, and listing](/understand/product-inventory-listing) — keep inventory intake separate from publication. * [Review pricing and print barcodes](/operations/review-pricing-and-print-barcodes) — review inbound pricing and use the separate label workflow. * [Print labels](/inventory/print-labels) — submit and verify a label job after inventory is ready.