Skip to Content
Pro-A-Motors / Purchasing & Pricing

Purchase receiving control

See which purchases are still with the supplier, which are on a container, and which have reached the warehouse.

See the real screens ↓
Classify the receiving policyRead the supply mixInvestigate unfinished workClose only eligible leftovers
The working interface

See it in use.

Explore 1 real view of this workflow. Select a task, show every screen, or enlarge an image to read the original controls.

Read the receiving picture / Actual Odoo screenEnlarge screenshot ↗
Actual purchase-order workspace with receiving policy, receipt status and the three-way progress snapshot visible. Supplier names alone are covered; quantities, values and order references remain readable.
01 / Purchasing and receiving

Read the receiving picture

  • Compare receiving policies across purchase orders.
  • Read the on-order, on-container and received percentages together.
  • Open the order that needs investigation before changing its receiving state.

Actual Pro-A-Motors interface captures. Private identities and contact details are covered or outside the crop; screen data has not been replaced.

What improved

Separate ordered, shipped and received quantities.

The business problem

A confirmed purchase order does not say whether the goods are still with the supplier, already on a container, or in the warehouse. Old zero-quantity lines also made the outstanding workload harder to interpret.

What we changed

Receiving classifications, a quantity-weighted supply split and guarded stale-line cleanup make outstanding purchase work clearer.

What the team can do now

Buyers can separate supply follow-up from receiving work and explain why an order is still open.

Read the actual screen / Existing purchase order

One order can be fully on a container and still not received.

The real list includes order 1841 with On Container status and a mix of 0% on order, 100% on container and 0% received.

On order
0%
On container
100%
Received
0%
Meaning
Inbound, not received

What the screen shows

The receiving list keeps container coverage beside receiving policy and billing status. These are separate decisions.

What the team does next

Follow the inbound shipment rather than treating the confirmed PO as warehouse stock.

What the next team receives

Receiving retains the next physical step while purchasing can see that the outstanding quantity is already on a container.

How the work moves

Follow the work from one decision to the next.

01

Classify the receiving policy

Distinguish standard stock receipts, manual confirmation and purchases that require no warehouse receipt.

02

Read the supply mix

Compare the scheduled percentages still on order, on active containers and already received.

03

Investigate unfinished work

Filter outstanding orders by container coverage and inspect the lines behind a receiving status.

04

Close only eligible leftovers

The cleanup considers zero-quantity age and active operational commitments before closing stale lines.

Built, used, refined

How the workflow improved over time.

  1. Receiving policies and stale-line cleanup

    Added explicit receiving classifications and guarded cleanup of old zero-quantity purchase lines.

  2. The receiving mix became visible

    Added a scheduled quantity-weighted split between on-order, on-container and received stock.

About these dates

Dates identify recorded implementation changes, not claimed rollout dates or measured results. Reviewed revisions: 678087c, 4f42431.

Build notes and background
Workflow automationInventory logicOperational reporting

The boundaries we made explicit.

A snapshot has a refresh time

The receiving mix is scheduled data. It is not a promise of a real-time warehouse refresh.

Not every purchase is a stock receipt

Manual and no-receipt policies stay distinct from fully received stock.

Zero quantity does not erase commitments

Active moves, invoice lines, container allocations and reserve-call commitments can keep a stale line out of automatic cleanup.

Existing records are shown as captured. Private identities are covered or outside the crop. No business records were changed for this collection. Implementation history supports behavior beyond the visible screen; a still image is not an end-to-end test or a measured productivity result.

Built on Captivea CAP modules and Odoo. This case describes the subsequent Pro-A-Motors extensions and refinements recorded in the reviewed repository; it does not attribute the original CAP implementation to Toro.

Which handoff is slowing your team down?

Talk through your workflow →