Rules for Imported Purchase Orders

The Purchase Order Import hook fires when a purchase order arrives in DropStream — typically from a replenishment system, EDI partner, or supplier portal. The available record is the purchase_order itself with its purchase_order_items collection.

This hook is less busy than Order Import but the shape of the rules is similar — categorize, route, tag, filter.

Route POs by destination warehouse

Build this in the visual editor. Warehouses are picked from a named dropdown there. The code below shows the shape the editor produces.

rule "Route POs by destination"
  when
    purchase_order.custom.destination_warehouse_code is "EAST"
  then
    route purchase_order to warehouse 4   # your East receiving warehouse
  end

  when
    purchase_order.custom.destination_warehouse_code is "WEST"
  then
    route purchase_order to warehouse 5   # your West receiving warehouse
  end
end

If the source system already specifies the destination, this rule just copies it into DropStream’s routing. When destination isn’t on the PO, route based on supplier or item type.

Tag high-value POs

rule "Tag high-value POs"
  accumulate purchase_order_items in purchase_order
    total: sum purchase_order_item.unit_cost * purchase_order_item.quantity
  end

  when total > 10000.0 then
    set purchase_order.custom.tag to "high-value"
    set purchase_order.notes to "High-value PO: $" & total as text
  end
end

A high-value tag can drive notifications and approval workflows downstream. The total is computed across line items with accumulate.

Categorize by supplier

rule "Categorize by supplier"
  set $category to "standard"

  when purchase_order.custom.supplier_id is "SUPPLIER-A" then
    set $category to "expedited"
  end

  when purchase_order.custom.supplier_id is "SUPPLIER-B" then
    set $category to "international"
  end

  set purchase_order.custom.category to $category
end

A simple default-then-override pattern that classifies POs by their source.

Filter test or duplicate POs

rule "Filter test purchase orders"
  when
    purchase_order.notes contains "TEST"
    or purchase_order.external_id starts_with "TEST-"
  then
    archive purchase_order
  end
end

Archive (rather than reject) keeps test POs out of the receiving queue while preserving them for reference.

Fail POs missing critical data

rule "Fail POs without supplier"
  when
    purchase_order.custom.supplier_id is blank
  then
    fail purchase_order with "PO " & purchase_order.id & " has no custom.supplier_id"
  end

  when
    purchase_order.custom.expected_arrival is blank
  then
    fail purchase_order with "PO " & purchase_order.id & " has no custom.expected_arrival date"
  end
end

Failing puts the PO in DropStream’s error queue with a clear message. A human investigates, fixes the upstream data, and re-imports.

Tag urgent POs by ETA

rule "Tag urgent inbound"
  timezone "Eastern Time (US & Canada)"

  when
    purchase_order.custom.expected_arrival < 7D after @now
  then
    set purchase_order.custom.tag to "urgent-inbound"
  end
end

POs arriving within a week get an urgent-inbound tag — useful for warehouse staffing and dock scheduling.

Route line items to different facilities

Build this in the visual editor. The warehouse comes from a named dropdown. The facility name (the part after /) is platform-specific — check your warehouse connection’s settings for the values that platform accepts.

rule "Split PO across facilities"
  for purchase_order_items in purchase_order
    when
      purchase_order_item.sku starts_with "FROZEN-"
    then
      route purchase_order_item to warehouse 1 / "Cold Storage"
    end

    when
      purchase_order_item.sku starts_with "HAZMAT-"
    then
      route purchase_order_item to warehouse 1 / "Hazmat"
    end
  end
end

Different SKU prefixes go to different facilities within the same warehouse. Items not matching either pattern stay on the default route.

Tips

• POs are usually fewer and bigger than orders. A single PO can have hundreds of line items. Aggregations (accumulate, quantifiers) over that collection are useful for summary fields.
• Watch out for duplicate IDs. When suppliers re-send POs (with revisions), the second arrival can reach DropStream as a fresh import. Use purchase_order.external_id or a similar field to detect duplicates and either fail or archive them.
• The PO model is leaner than orders. Some fields you’d take for granted on orders (customer_email, shipping_amount) don’t exist on POs. Stick to fields you can confirm in the Test tab.