How to Reconcile Revel POS Sales Against MarketMan Theoretical Usage

Build a Spojit workflow that runs every morning, compares yesterday's Revel POS orders against MarketMan actual-vs-theoretical usage, and alerts your kitchen manager in Slack when shrinkage crosses a threshold.

What This Integration Does

Theoretical usage is what your recipes say you should have consumed for the food you sold; actual usage is what MarketMan counts you really consumed. The gap between them is shrinkage: over-portioning, waste, spoilage, or theft. Catching that gap early, while yesterday's service is still fresh, is the difference between a one-day blip and a slow bleed on your food cost. This workflow pulls both numbers automatically each morning, does the variance math for you, and only pings a human when the number actually matters.

The workflow is driven by a Schedule trigger that fires once a day on a cron expression in your restaurant's timezone. On each run it lists the prior day's orders from Revel, fetches the matching MarketMan actual-vs-theoretical data for the same window, computes a variance percentage with the math connector, and branches on a threshold. If shrinkage is within tolerance the run ends quietly; if it exceeds the threshold a Slack message goes to the kitchen manager. Each run is independent and stateless: it reads a fixed date window, writes nothing back to Revel or MarketMan, and is safe to re-run by hand for any past day.

Prerequisites

A Revel connection (API key) added under Connections → Add connection, with access to the establishment whose sales you want to reconcile.
A MarketMan connection (API key) for the same site, with permission to read actual-vs-theoretical inventory data.
A Slack connection authorized to post to the channel your kitchen manager watches, plus the manager's work email if you want to resolve them by lookup.
Your restaurant's IANA timezone (for example Australia/Sydney) and the daily run time you want.
The MarketMan buyer the site belongs to. If your account has one buyer you can leave the buyer field blank and the default is used.
An agreed shrinkage threshold, expressed as a percentage (for example alert when variance exceeds 3%).

Step 1: Start the workflow on a daily Schedule trigger

Open the Workflow Designer and add a Trigger node, then set its type to Schedule. A Schedule trigger uses a 5-field Unix cron expression plus a timezone. To run at 8:00 every morning, set the cron to 0 8 * * * and the timezone to your site, for example Australia/Sydney. The trigger output is {{ trigger.scheduledAt }}, the moment the run started. You will use the day before that timestamp as your reporting window.

Run at a time after MarketMan has reconciled the prior day's counts so the actual figures are settled.

Step 2: Compute yesterday's date window

Add a Connector node using the date connector in Direct mode. Revel filters orders by ISO 8601 timestamps, and MarketMan expects yyyy/mm/dd hh:mm:ss, so build both bounds here once and reuse them.

Use the subtract tool to step back one day from {{ trigger.scheduledAt }}, then the start-of and end-of tools (unit day) to get the start and end of yesterday. Capture them in clear variables such as {{ window.startIso }} and {{ window.endIso }}. Keep this node's timezone aligned with the trigger so "yesterday" means the restaurant's business day, not UTC.

Step 3: List the prior day's Revel orders

Add a Connector node for the revel connector in Direct mode and pick the list-orders tool. Map the date filters to the window from Step 2 and scope to the right site:

created_date__gte: {{ window.startIso }}
created_date__lte: {{ window.endIso }}
establishment: 1
ordering: -created_date
limit: 200

The result is your day's sales. To turn the orders into a single sales total for variance context, add a Connector node using the math connector with the sum tool, summing the order totals from {{ revel_orders }}. Store the figure as {{ sales.total }}. If a busy day exceeds your limit, raise it or page with offset in a Loop node.

Step 4: Fetch MarketMan actual-vs-theoretical usage

Add a Connector node for the marketman connector in Direct mode and select the get-actual-theo-data tool. This returns the actual and theoretical usage figures MarketMan derives from your counts and recipes. Supply the same window, formatted as MarketMan expects:

fromDateUTC: 2026/06/19 00:00:00
toDateUTC:   2026/06/19 23:59:59

Drive those fields from your Step 2 variables (reformat them with the date connector's format tool if your window variables are ISO 8601). Leave buyerGuid blank to use the account default, or paste the buyer GUID for the specific site. Store the response as {{ theo }}.

Step 5: Calculate the shrinkage variance

Add a Connector node using the math connector in Direct mode. Variance percentage is the gap between actual and theoretical usage relative to theoretical, so use the percentage tool on the actual and theoretical totals from {{ theo }}, or the calculate tool with an explicit expression:

(actualUsage - theoreticalUsage) / theoreticalUsage * 100

Round the result with the round tool and store it as {{ variance.pct }}. If your team reasons in dollars rather than percent, also use currency to format the raw dollar gap. Keep this node deterministic in Direct mode so the same inputs always produce the same number and there is no AI cost on a job that runs daily.

Step 6: Branch on the threshold and alert Slack

Add a Condition node that tests whether {{ variance.pct }} is greater than your agreed threshold (for example 3). Leave the false branch empty so in-tolerance days end silently with nothing in the channel.

On the true branch, add a Connector node for the slack connector in Direct mode. If you store the manager's email rather than a channel ID, first call lookup-user-by-email to resolve them, then call send-message with a clear, templated summary:

channel: #kitchen-ops
text: Shrinkage alert for {{ window.startIso }}
  Variance: {{ variance.pct }}% (threshold 3%)
  Revel sales: {{ sales.total }}
  Review portioning, waste, and counts in MarketMan.

If you would rather email the manager and skip the Slack connection, swap this for a Send Email node, which sends from Spojit's built-in mail service; recipients must be on your organization's allowlist under Settings → General → Email recipients.

Tips

Hold multiple schedules on the one trigger if you run several sites: each can fire on its own cron in its own timezone while sharing the same downstream logic.
Want a plain-English read instead of a raw number? Add a Connector node in Agent mode after Step 5 that explains the likely drivers of the variance, and attach a Response Schema so it returns clean JSON fields you can drop into the Slack text.
Ask Miraxa, the intelligent layer across your automation, to scaffold this for you: "Build a workflow on a daily Schedule trigger that lists yesterday's Revel orders, fetches MarketMan actual-vs-theoretical data, computes the variance with the math connector, and sends a Slack message when it exceeds 3 percent." Then fine-tune each node in the properties panel.
If you reconcile per category rather than site-wide, use a Loop node over the MarketMan results and run Step 5 inside it so each category gets its own variance line.

Common Pitfalls

Timezone drift: if the Schedule timezone, the date node, and the connector filters disagree, "yesterday" can shift by hours and pull a partial business day. Set one timezone everywhere.
Date format mismatch: Revel expects ISO 8601 while MarketMan expects yyyy/mm/dd hh:mm:ss. Format each window bound for its own connector rather than passing one string to both.
Running too early: if the job fires before MarketMan has finished reconciling the prior day, actual usage is incomplete and the variance looks worse than reality. Schedule after counts close.
Division by zero: on a day with no theoretical usage the percentage formula errors. Add a Condition node before Step 5 to skip the math when theoretical usage is zero.
Alert fatigue: too low a threshold floods the channel and the manager tunes it out. Start conservative and tighten once you see a few days of real numbers.

Testing

Before scheduling it, validate on one known day. Temporarily swap the trigger for a Manual trigger and hard-code a single past date into the Revel and MarketMan window fields, then click Run and read the execution log step by step: confirm the Revel order count and sales total look right, the MarketMan call returns actual and theoretical figures, and {{ variance.pct }} matches a hand calculation. Set the threshold to 0 so the Slack branch always fires and you can confirm the message lands in the channel. Once the numbers and the alert both check out, restore the Schedule trigger, reset the threshold, and enable the workflow.