Reference · built on requestOperator by FibricInventory & supply

PO Chase

Finds purchase orders with no vendor acknowledgement or ship date past a set age, then proposes a chase message for a buyer to send.

Request accessPricing ↗

About

An order the vendor has not acknowledged is an order that may not exist on their side. PO Chase reads each open purchase order, the field your system keeps for the vendor's acknowledgement or confirmed ship date, and the age of the order against the threshold you set. It also reads the buyer's mailbox for vendor replies, so an order already answered is not chased twice.

For each order past the threshold it drafts a chase: recipient, subject, and a body naming the order, lines, and the date the goods are needed. The buyer approves and the message goes from their own mailbox or the team's channel. A second chase with an escalation contact is proposed when the first is not answered.

This is a reference listing. It documents what Fibric would read from PO Chase and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Coupa purchase orders with status, transmission-status, and acknowledged-flag, and order confirmations at /order_header_confirmations
  • Business Central purchase orders with status Draft, In Review, or Open, their orderDate, and lines with no expectedReceiptDate
  • Katana purchase orders with last_document_status NOT_SENT, SENDING, FAILED, or SENT and no expected_arrival_date
  • NetSuite purchase orders and any inbound shipment record linked to them
  • Vendor contact details on the vendor record
  • Vendor replies in the buyer's mailbox, so an order that has been answered drops off the chase list

Proposed actions

  • Target capability: propose a chase email from the buyer's mailbox naming the order, lines, and the date needed, for the buyer to send
  • Target capability: propose a message to the buying channel in Slack or Microsoft Teams listing orders past the age you set
  • Target capability: propose a second chase to an escalation contact when the first goes unanswered past a set number of days
  • Target capability: propose a cancellation review on an order the vendor has confirmed it cannot ship

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Chase unacknowledged Coupa orders

    Orders whose acknowledged-flag is still false past the threshold get a drafted email through the buyer's Outlook mailbox. The buyer edits, sends, or declines each one.

    With Coupa, Microsoft Outlook

  • Post the late list to the buying channel

    Business Central orders in Open status with no expected receipt date past the age you set are listed in one Slack message to the buying channel, once the buyer approves it.

    With Microsoft Dynamics 365 Business Central, Slack

  • Follow up Katana orders that never left

    Katana orders whose last_document_status is FAILED or NOT_SENT past the threshold are flagged, and a Gmail draft to the supplier is proposed for the buyer.

    With Katana Cloud Inventory, Gmail API

Requirements

  • Purchase orders with an order date and a place the vendor's acknowledgement or ship date is recorded: Coupa, Business Central, NetSuite, or Katana
  • An age threshold in days after which an unacknowledged order is chased, and a second threshold for escalation
  • A mailbox or channel the buyer sends from: Microsoft Outlook, Gmail, Slack, or Microsoft Teams
  • A buyer named to approve every message before it goes
Authentication
Purchasing read access in your ERP or procurement system, plus Mail.Send on the buyer's mailbox through Microsoft Graph, the Gmail API send scope, or chat:write for a Slack app.

Limits

  • Acknowledgement is read where your system records it. Business Central's API v2.0 purchase order has no such field, so a receipt stands in.
  • A vendor reply in a mailbox it cannot read is invisible. The buyer marks the order answered by hand.
  • It sends nothing on its own. Every message is a draft until the buyer approves it.
  • One chase per order per interval. It does not send daily reminders.

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request PO Chase ↗

Questions and answers

What does the buyer approve before a chase goes out?
A message: recipient, subject, and a body listing the order number, lines, and the date the goods are needed. The buyer edits the wording or recipient, sends it, or declines. Sent messages go from the buyer's own mailbox or the team's channel.
How does it know an order was acknowledged?
From the field your system keeps: acknowledged-flag or an order confirmation in Coupa, expected_arrival_date in Katana, an inbound shipment in NetSuite. Where no such field exists, a posted receipt closes the chase.
What record is left?
A receipt per chase: the order, the age at which it was flagged, the message text, who approved it, when it was sent, and any reply matched afterwards. Declined chases are kept with the reason given.
Ask about PO Chase

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy