Announce a purchase order to the warehouse
When stock is on its way to your 3PL, the warehouse needs to know it is coming. An expected arrival is that heads-up: an Advance Ship Notice built from a SKU.io purchase order and sent to VeraCore.
The page is explicit about what it is and is not:
Advance Ship Notices announcing inbound purchase orders to VeraCore. An arrival is an announcement, not a receipt — VeraCore locks it once the warehouse starts receiving.
Announcing a purchase order does not receive it, does not create stock, and does not change your purchase order. It tells the warehouse what to expect so that when the truck arrives, the receiving team has something to check the pallets against.
Before you announce
The items must exist at VeraCore. An announcement references VeraCore item codes. If a product on the purchase order has never been pushed to VeraCore, there is nothing for the announcement to point at — and VeraCore will say so.
The offers must be mapped. A pushed item still needs a mapping so SKU.io knows which VeraCore item each purchase order line corresponds to.
The facility must be mapped. The announcement is addressed to a specific VeraCore facility, resolved through your warehouse mappings.
If any of those are missing, the announcement is refused with a list of exactly what is wrong — see When VeraCore refuses below. Nothing is silently half-sent.
Announce it
- Open the connection's Expected Arrivals tab.
- Click Announce Purchase Order.
- The dialog explains itself: Sends an Advance Ship Notice so VeraCore knows what is inbound. It announces the purchase order — receiving still happens in the warehouse.
- Pick the purchase order. The search field is focused for you and already lists the newest orders, so a recent PO is usually one click away. Otherwise type — it searches by PO number or supplier.
- Check the summary that appears.
- Click Send Announcement.
Send Announcement stays disabled until you choose an order, with the reason on hover: Pick a purchase order to announce.
The search is live as you type. Before you type anything it prompts Type to search purchase orders; if nothing matches it says No matching purchase orders. Each result shows the supplier and receipt status beneath the PO number, which is usually enough to tell two similar orders apart.
Check the summary before you send
Once you select an order, a summary card appears with three rows:
| Row | Why it matters |
|---|---|
| Purchase Order | Links straight to the order — open it in a new tab if you want to check the lines |
| Supplier | The quickest way to catch the wrong order |
| Receipt Status | Tells you whether receiving has already started in SKU.io |
That last one is worth a second's thought. Announcing an order that is already partly received is not an error, but it usually means the announcement is late and the quantities VeraCore is told to expect will not match what actually turns up.
What gets sent
The announcement carries the purchase order's lines translated into VeraCore's terms: the VeraCore item code for each mapped product, the quantity expected, and identifiers linking the arrival back to the SKU.io purchase order and its lines. It is addressed to the facility behind the destination warehouse and dated with the anticipated arrival date.
Once accepted, the arrival gets a reference — VeraCore's key for the announcement — which is what the warehouse will use when the stock shows up.
The confirmation is Expected arrival queued (or VeraCore's own wording), and the job runs in the tray under Push VeraCore Expected Arrival:. The table refreshes itself when it finishes.
When VeraCore refuses
This is the part worth understanding, because the design deliberately front-loads the failure.
The arrival is built completely before anything is queued. If it cannot be built — a missing mapping, an unmapped facility, an item VeraCore has never heard of — you are told immediately, in the dialog, with the specific reasons listed:
VeraCore will not accept this purchase order yet
followed by one line per problem.
Nothing was sent. Nothing is half-created. You fix the listed problems and try again.
That is better than the alternative, where the announcement queues successfully, fails somewhere inside a background job, and you discover it as an error row hours later. The blocking list tells you what to fix while you are still looking at the dialog.
Common entries and their fixes:
| Reason | Fix |
|---|---|
| A product has no VeraCore item | Push it, sync, then map it |
| An offer is not mapped | Map the offer |
| The destination warehouse has no facility | Map the facility |
| The order has nothing announceable | Check the purchase order has lines with mapped products |
After it is announced
The arrival appears in the table as Pending and moves to Sent once VeraCore has accepted it. From there the warehouse takes over: when receiving begins, VeraCore locks the arrival and its status becomes Received.
What to do next depends on what you see — Track and cancel expected arrivals covers the statuses, the receiving lock, and how to withdraw an announcement while you still can.
Nothing stops you announcing the same purchase order again — you might genuinely want to, if the first announcement was cancelled or went to the wrong facility. But two live announcements for one delivery means the warehouse expects the stock twice. Cancel the first one before you send a replacement.
Next steps
- Track and cancel expected arrivals — what happens after the announcement lands.
- Push products to VeraCore — the usual prerequisite when an announcement is refused.
- Map VeraCore facilities to warehouses — how the announcement knows which building to address.