Skip to content

Logistified

Logistified is procurement. It owns suppliers, what you buy and the paperwork of buying it. It does not touch a physical box — the moment goods exist in your building, they are Floormode’s.

The connection exists so that neither app has to be told twice: a purchase orderPurchase orderAn order placed on a supplier — the document in Logistified that names the supplier, the lines and the expected date, and which appears in Floormode receiving as the delivery to book in. Read more → raised there becomes work here, and what the floor actually receives goes back there.

  • Purchase orders become expected deliveries
  • Receiving them
  • What goes back to Logistified
  • Revisions and cancellations
  • Transfer orders
  • Counts exported as stock takes
  • Moving between the apps
  • See also

Purchase orders become expected deliveries

Section titled “Purchase orders become expected deliveries”

When a purchase order in Logistified reaches a confirmed state for a location Floormode receives at, it announces itself here as an expected receiptExpected receiptA delivery you are waiting on. It moves from expected, through being received, to received as the floor books it in line by line. Read more → — no rekeying, no CSV.

What arrives with it:

DocumentThe purchase order’s number and name, so the dock and the office use the same reference
SupplierWho it is coming from, visible on the receipt without opening Logistified
Expected dateWhen it is due, so you can see what is landing this week
LinesProduct, SKU and ordered quantity
DestinationWhich of your warehouses it is for

The receipt’s Source column reads “Logistified purchase order” rather than “Entered by hand”, so at a glance you can tell announced work from work someone typed in.

Go live in every receiving warehouse before you connect: the switch refuses otherwise, because Logistified stops updating received quantities the moment it is on.

Identically to any other delivery. There is no separate integration workflow to learn: the Floor receive job scans the item, confirms the quantity and scans the putaway bin, exactly as it does for a receipt you created yourself.

Everything Floormode does with a delivery still applies — putaway to real bins, lot and expiry capture where you use them, over-receipt tolerance, discrepancies, and partial receipts. A purchase order that arrives across three pallets on three days is three receipts against one document, and each is booked when it lands.

Two different things, at two different times, and the distinction is the useful part:

  • Progress, while receiving is underway. As the floor books lines in against an open receipt, Logistified’s copy of the purchase order updates — how many units are in, how many lines disagree with the plan, and a link straight to the receipt. Somebody in the office watching the purchase order sees it filling up without ringing the warehouse.
  • Totals, when the receipt completes. Closing a receipt sends the confirmed figures, which is what Logistified’s records are actually built from.

Those totals are always running totals for the whole document, never “and another twelve”. A second delivery reports the full quantity received so far. It is the detail that makes a re-sent message harmless: a total that arrives twice is the same total, while an increment that arrives twice is a wrong number nobody can trace back.

Purchasing changes its mind; the connection expects it.

  • A revision rewrites the part you have not yet received. Quantities already booked in are never touched, never reduced, and never un-received. If a line is cut below what already landed, the outstanding remainder simply becomes zero and the excess is recorded as an over-receipt rather than becoming a negative expectation.
  • A cancellation closes whatever is still outstanding. Units already booked in stay booked in — they are in your bins, and no message from another app can change that.
  • A later, larger revision can arrive as an additional delivery against the same document, netted against what earlier receipts already booked, so nothing is announced twice.

Out-of-order messages are refused rather than applied. If an older revision turns up after a newer one, Floormode declines it and says so — nothing changes, which is the correct outcome.

Transfers between your own locations work the same way as purchase orders, from both ends:

  • Arriving — a transfer bound for one of your warehouses announces itself as an expected delivery, with the source location on it, and is received exactly like a purchase order. Its Source reads “Logistified transfer”.
  • Leaving — confirming that the outbound leg has left the source warehouse tells Logistified the stock is genuinely in transit. That is a status signal rather than a quantity: the units were counted when they were picked.

Approving a cycle count in Floormode exports it to Logistified as a stock take, so its records reflect the count.

This is reporting only, by design. Floormode has already corrected the bins and already written the new availability to Shopify. Logistified records what you counted; it must not — and does not — re-apply those quantities on top.

A receipt created from a Logistified document carries the document’s identity, so the two views of the same delivery are one click apart: Logistified’s purchase order links to the exact Floormode receipt that booked the goods in.