Pre-sell and incoming stock from a purchase order

A purchase order in Landara does two things in your Shopify store, and it is worth knowing exactly which, because both change numbers your customers can see.

• Stock you have ordered shows as incoming. Shopify's inventory has a column called Incoming, separate from what is on the shelf. When you place an order in Landara, the ordered units appear there at the destination location. Nothing becomes sellable.
• Lines you mark as pre-sell become sellable straight away. The ordered quantity is added to the variant's Available stock, and the variant is flagged as pre-selling so your theme can say so. Your store sells exactly that many and then shows sold out.

Each line on the order is one or the other, never both. Landara will not let a line be released for pre-sell once it is on the incoming transfer, or put on the transfer once it has been released. That rule is what stops the same units being counted twice.

What happens at each step

Showing "pre-order" in your theme

Landara sets the figures; your theme decides what to show. Landara does not edit your theme and has no access to it: a theme is yours in the same way a product title is. What it gives your theme is two fields it can read. They live in your store's own custom namespace on the variant, because a pre-sell is per SKU, and they are created for you the first time a line is released. If you created a custom.pre_sell definition yourself, it must be a whole number (integer): a definition's type cannot be changed, so a boolean one has to be deleted first.

| Metafield | Type | Meaning | |---|---|---| | custom.pre_sell | whole number | How many of the available units are pre-sell: released on an open order and not yet arrived. 0 means not pre-selling | | custom.pre_sell_expected | date | The purchase order's expected arrival date, when you entered one |

The rule the theme applies: the variant is pre-selling when pre_sell is above 0 and the available quantity is at or below pre_sell. Above that, units on the shelf are still being sold and the variant reads as in stock. Both definitions appear under Settings → Custom data → Variants in your Shopify admin once a pre-sell line has been released, and the same fields can be read from the Storefront API or a Shopify Flow trigger, since they are ordinary variant metafields.

Three ways to show it

• Ask your theme developer. Send them this page. Everything they need is above, and the reference snippet below is complete. This is the route we recommend if anyone other than you edits the theme.
• The theme editor, without code. Many themes let you connect a text block to a metafield from the theme editor (the small database icon beside a text setting is the "dynamic source" picker). That can show the expected date on the product page. Whether it can show the text only while the pre-sell count is above zero depends on the theme, and that condition is what the snippet does.
• A pre-order app. If you already use one, check whether it can key its badge or button label off a variant metafield. Landara keeps the count and the date correct; the app does the display.

If you edit the theme yourself

The snippet below only reads the two fields. It changes nothing in Shopify, it does not touch the buy button, and when the variant is not pre-selling it renders nothing at all. The risk in any theme edit is a typo in the wrong file on the live theme, and Shopify's own workflow removes it:

{%- assign v = product.selected_or_first_available_variant -%}
{%- assign presell_qty = v.metafields.custom.pre_sell | default: 0 -%}
{%- if presell_qty > 0 and v.inventory_quantity <= presell_qty -%}
  <p class="preorder-note">
    Pre-order.
    {%- if v.metafields.custom.pre_sell_expected != blank -%}
      Expected to ship from {{ v.metafields.custom.pre_sell_expected | date: "%-d %B" }}.
    {%- else -%}
      Ships when stock arrives.
    {%- endif -%}
  </p>
{%- endif -%}

Two things to keep in mind:

• Variant switching. If your theme swaps variants without reloading the page, it needs to re-read the metafield when the variant changes. Themes built on Shopify's Online Store 2.0 usually re-render the section; older themes may need the snippet inside the section that re-renders.
• Sold out is still sold out. The snippet says "pre-order" while the count is above zero and the shelf units are gone. When the released quantity has all been sold, the theme's own out-of-stock state applies. If you want to say "pre-order sold out", check v.available as well.

Landara support covers what Landara writes: the transfer, the released quantity and the two fields. For the theme itself, your theme's developer or Shopify support is the right door, and they will need nothing more than the table above.

Things that look wrong and are not

• "The page says in stock, but this location only has pre-sell units." A theme sees the variant's available quantity across all locations, and Liquid has no per-location count to compare against. If another location holds real units of the same variant, the store treats those as sellable first and shows pre-order only once the store-wide figure is at or below the pre-sell count. A single-location store never sees this.
• "Available went up before the stock arrived." That is what pre-sell means. If a line should not be selling yet, leave pre-sell off and its units show as incoming instead.
• The transfer shows in Shopify with no origin location. Correct: it is a supplier transfer, so there is no store location it came from.
• A line cannot be switched off pre-sell. Once released, the units are already for sale in your store. Adjust the quantity in Shopify if it should not be selling, and the order's history records what was released.
• The order shows a Shopify sync failure. The order itself went through; only the Shopify half did not. The message says why (a SKU not in your catalogue is the usual one). Fix the cause and use Retry sync on the order. Retrying never repeats what already succeeded.

What pre-sold units cost, and why the number looks the way it does

This is the question your accountant will ask, so here is the full answer.

FIFO is a cost flow, not a physical flow. Under first-in first-out, a sale is costed from the oldest stock on the ledger, whichever physical unit ends up in the box. That is the definition of the method, it is what the accounting standards require once you have chosen it (IAS 2, AASB 102, ASC 330), and Landara applies it without exception. Costing a pre-order at the price on the purchase order it will ship from would be a different method, specific identification, which is reserved for goods that are not interchangeable, such as a numbered artwork or a car by VIN.

A worked example with round numbers:

| | | |---|---| | On the shelf | 17 boards, layered at $506 each from earlier purchases | | Released for pre-sell | 10 boards on a purchase order at $222 each, not yet arrived | | Sold today | 19 boards |

Landara costs today's 19 sales at $506 from the 17 on the shelf plus 2 from the next oldest layer. It does not cost any of them at $222. When the 10 boards are received, they become a new layer at $222 (provisional until the supplier invoice is costed), and the next sales consume it. Over the life of the stock the total cost of sales is identical either way. What moves is the timing: FIFO recognises the higher cost first because that stock was bought first.

Which cost basis to use. Landara can cost a sale on the day it was ordered (sale basis) or the day it shipped (fulfilment basis). For a store that pre-sells, use the fulfilment basis, for two reasons:

• A pre-order ships after the stock arrives. On the fulfilment basis the purchase order's layer exists by the time the unit ships, so it is costed correctly. On the sale basis the order date comes before the layer exists, Landara never costs a sale from stock received after it, and that sale stays uncosted for good. This is deliberate: costing a January sale from March stock would move cost between periods.
• Location. A Shopify order has no location at the moment it is placed, so the sale basis draws the oldest units across the whole store. A fulfilment is from one location, so the fulfilment basis draws only that location's layers. If you hold the same SKU at more than one location, only the fulfilment basis keeps each location's cost to itself.

If a sale needs more units than the ledger holds when it is costed, the units beyond that are costed at the last-known unit cost and flagged uncosted, and a delivery received later does not re-cost them. That is honest rather than wrong: the report says so instead of pretending the number is complete. The practical rule for a store that pre-sells: use the fulfilment basis, and record the receipt in Landara before the pre-orders ship.

What this does and does not cost

Placing an order creates no cost. Receiving does: each received line gets a provisional cost layer at the order price, dated the receipt, so sales are costed from the day the goods land instead of waiting for the invoice. Finalise on the order, or costing the supplier invoice on the linked shipment, corrects that layer in place. The whole path is in Purchase orders end to end, and Deposits, balances and exchange rates covers instalments in a foreign currency.