Identify the system of record for each field and the person who understands its operating meaning.
Data and integrations
Connect the records that explain the decision, not every table in the system.
Openfluid can begin with structured exports before production APIs are added. The integration scope depends on the forecast: revenue may need daily POS totals, while ingredient recommendations require recipes, inventory and purchasing commitments.
CSV-first discoveryPOS and inventory mappingSource-by-source validation
POSOrders · items · taxes · channels
RecipesIngredients · quantities · yield
InventoryOn hand · usage · transfers
PurchasingPOs · receipts · vendors
OpenfluidForecast and decision layer
Integration matrix
The required sources change with the decision.
| Capability | Minimum data | Additional data for a stronger decision |
|---|---|---|
| Revenue forecasting | Business date, outlet, net revenue, completed orders | Channel, daypart, promotion, closure and event calendar |
| Menu demand | Business date, outlet, item, quantity sold | Stockout periods, substitutions, modifiers, availability and cancellations |
| Preparation planning | Menu forecast and current preparation baseline | Batch size, holding life, service buffer and actual prep |
| Ingredient requirement | Menu forecast, recipe master, current stock | Yield, open POs, lead time, pack size, shelf life and transfers |
| Waste prevention | Forecast, planned preparation, actual sales | Actual preparation, leftovers and waste by reason |
Implementation path
Start with files. Earn the need for an API.
Use stable CSV or Excel extracts to profile coverage, identifiers, timestamps, units and revisions.
Map source-specific fields to Openfluid entities without discarding raw identifiers or provenance.
Confirm that the available history can support the intended grain and horizon before building continuous ingestion.
Add API, SFTP or scheduled object-storage ingestion only after the decision and data contract are stable.
Readiness checks
What “integration-ready” actually means.
Data checks
- Business date follows the restaurant’s trading-day definition
- Cancelled, refunded and complimentary orders are identifiable
- Outlet and item identifiers remain stable across exports
- Units of measure and conversion rules are explicit
- Late adjustments and backdated transactions can be detected
Operational checks
- A named owner can explain each source
- Expected delivery time and failure handling are agreed
- Historical corrections have a reprocessing policy
- User permissions map to outlet and role scope
- The team knows what happens when a feed is stale
Honest scope
Current connector status.
The website does not claim a production-certified integration with Petpooja, POSist, Restroworks, Swiggy, Zomato or another named provider. The present prototype demonstrates the canonical data and product workflow. Connector availability, API permissions and commercial access must be confirmed for each implementation.
POS exports
Usually the fastest route to revenue, order and item-demand backtesting. Channel and tax fields vary substantially by provider.
Aggregator data
Useful for channel demand and settlement economics, but order feeds and financial settlements may arrive through different interfaces.
Recipe and inventory systems
Often less standardised than sales data. Effective recipes, units, yield and physical-count practices require operational validation.
Manual operating inputs
Events, closures, preparation overrides and waste reasons may initially come from a simple governed form rather than an external system.
FAQ
Integration questions.
Do we need two years of history?
Two years is useful for annual seasonality, but a pilot may begin with less when weekly patterns are stable. Coverage should be evaluated by series, not only by the oldest transaction date.
Can Openfluid read directly from a database?
A production architecture can support database, API, SFTP or object-storage patterns. Read-only access, network controls and source load need to be agreed.
What happens when item names change?
Forecasts should use stable item identifiers and effective mappings. Name matching alone can split one item into multiple histories or merge unrelated products.
Are Swiggy and Zomato orders already inside the POS?
Many restaurants receive aggregator orders in the POS, but completeness and fields vary. The source must be reconciled before channel-level conclusions are trusted.
Find the smallest useful integration.
Share sample exports and the decision you want to improve. The first assessment should identify what is usable, missing and unnecessary.