Supplier Direct Delivery: What Should Your Order App Track When Goods Never Enter Your Warehouse?

When a supplier sends goods straight to your customer, your order app should represent that route explicitly. Connect the customer's order line to the supplier-side work and its delivery evidence. Do not require staff to record an arrival at your warehouse simply to make the order screen turn green.

This is a requirements guide for an order-management application, not advice on starting a dropshipping business. It does not establish tax treatment, contractual delivery obligations or consumer rights.

Draw the physical route before choosing statuses

Odoo's dropshipping documentation describes goods moving directly from supplier to customer. In its example, a dropship sales order generates a linked supplier request for quotation. Confirming that request creates a purchase order and linked dropship receipt. That receipt uses the supplier as source and the customer as destination.

The terminology matters: a record called a receipt is not necessarily evidence that goods entered your building. Ask the developer to show source, destination and business meaning rather than letting the label decide the process.

For each eligible order line, specify whether it will be supplied from your stock or directly by the supplier. If the route changes after work starts, require an explicit reconciliation of the old supplier or warehouse instruction before creating replacement work. Otherwise both paths can remain active.

A prepared supplier order is not a confirmed delivery

Write down the evidence behind each customer-facing promise. A draft supplier request, an order you sent, a supplier's acknowledgement and confirmed dispatch are different facts. Do not display “on the way” because the app generated a purchase record.

Recommended fields include the customer order line, supplier order line, agreed destination, requested quantity, supplier-confirmed quantity, expected date and relevant delivery references. Choose only what your team actually uses. Label unconfirmed dates as estimates rather than commitments.

Also identify who updates the evidence. An integration may return a tracking reference without confirming receipt by the customer. A staff member may obtain confirmation outside the app. Both cases need a clear source and an honest status, not a single checkbox that implies everything happened.

Keep unknown outcomes visible

Suppose, hypothetically, a supplier order transmission times out. Before staff resend it, they need to know whether the supplier already received it. Require a pending-reconciliation state with an accountable next action. Creating another supplier order is not a safe substitute for finding out what happened.

Similarly, if a supplier reports delivery but the customer disputes it, preserve both pieces of information for investigation. Do not erase the supplier evidence or quietly mark the customer as satisfied. The dispute process and commercial remedy need their own agreed policy.

If the supplier cannot fulfil, decide who may change the route, choose another supplier or contact the customer. This article does not specify the full split-shipment lifecycle; it addresses which external party is doing the fulfilment and how that work stays linked to the customer promise.

What should happen to your warehouse quantity?

The expected result should follow the actual route. For this direct-delivery workflow, ask that no fictitious own-warehouse receipt or dispatch be created. Check the relevant stock views as well as the order screen.

Odoo's source illustrates a supplier-to-customer movement and confirmation of delivered quantities. It does not establish how your custom app, accounting package or supplier integration should book every event. Have the relevant specialists confirm financial treatment separately.

A compact acceptance scenario

For the acceptance criteria, prepare fictitious supplier and customer records:

1. Create a direct-delivery line and trace it to the intended supplier request.
2. Show a prepared request without implying supplier acceptance or dispatch.
3. Confirm the agreed destination and inspect what the supplier receives.
4. Record dispatch evidence separately from customer-receipt evidence where your process needs both.
5. Inspect your warehouse balance and confirm that no invented physical movement occurred there.
6. Simulate an uncertain transmission and reconcile it before any replacement order.
7. Change the fulfilment route through the agreed review path, ensuring obsolete work is not left active.

For an order-application project discussion, describe one real route using invented names and addresses. A diagram of who holds and sends the goods is more useful than a request for a generic “delivered” status.

Common questions

Can one order contain warehouse and direct-delivery lines?

That is a feature to specify and demonstrate, not assume. Staff must be able to identify the route of each line and the evidence behind it.

Does a tracking number prove the order arrived?

Do not define it that way by default. Agree which evidence your operation accepts and how missing or disputed confirmation is handled.

Should the app automatically order from a supplier?

Only within the authority you deliberately grant it. The Odoo example describes automatic request generation in its configured workflow; that is not proof that a supplier accepted the request or that unattended purchasing suits your business.