Online Store Sync
An app that connects to your online store on a schedule — refreshing products and availability, and importing new orders into ERP.net.
Selling in two places — an online store and ERP.net — means the same data lives twice: products, prices, stock levels, and orders. Someone has to keep them in step, or prices go stale and orders arrive as a list to retype. Operator builds a small app that does this by itself: on a schedule it calls the store's own interface, refreshes what changed, and brings new orders in as real ERP.net sales orders.
What you get
- A store connector — the app talks to your online store's API using credentials stored securely in the app, never visible in the screens or the code.
- Scheduled runs — every few minutes, every hour, or at set times; you choose how fresh the data needs to be.
- Products and availability refreshed — new products appear, prices and quantities update in your ERP.net instance.
- Orders imported — each new store order becomes a sales order in ERP.net, ready for your normal fulfilment flow, without retyping.
- A visible history — every run shows in the app's Triggers tab: when it ran, what it synced, and anything that went wrong.
Example
You say: "Every 15 minutes, pull new orders from our WooCommerce store into ERP.net as sales orders, and every hour update product availability from our stock." Operator asks which store and which fields matter (product codes, quantities, prices), builds the app with a schedule, and connects the store with the key you provide. From then on, orders arrive in ERP.net minutes after a customer checks out.
How to ask for one
Describe what should be kept in step, and how often:
every 15 minutes, import new orders from our online store into ERP.net sales orders
keep product availability in ERP.net in sync with our store — update stock every hour
every morning at 7:00, update prices in the store from our ERP.net price lists
Useful things to mention:
- Which store — WooCommerce, Shopify, a custom shop — and what its API needs (an address and a key are usually enough; Operator asks if more).
- What flows which way — products and availability into the store, orders into ERP.net, prices out from ERP.net — or all of it.
- How often — minutes matter for order import; hourly is often enough for stock.
- The rules — which warehouse's stock to publish, how to match products between the two systems, what happens with an order from an unknown customer.
What to check before approving
- The product match. The app pairs store products with ERP.net products by a code (SKU, barcode, or your own numbering). Check the rule on a few real products — a wrong match updates the wrong product.
- The first run on real data. Ask Operator to run the sync once immediately, then compare: a few products, a few orders. The first import of existing orders should be skipped — usually only orders newer than a chosen date are pulled.
- No order arrives twice. Each store order is imported once, even if the app runs repeatedly; ask Operator to show how it tells already-imported orders apart.
- Who the customer is. A webshop order needs a customer in ERP.net — the app can create one from the order, or collect orders under one "online store" customer. Pick what suits your accounting.
- The schedule and timezone. Check the times shown in the Triggers tab are the times you mean.
Changing it later
- Change the frequency — "run the order import every 5 minutes instead" — and only the schedule moves; the sync rules stay.
- Add a flow — "also send tracking numbers back to the store when orders ship" — and the app gains the new step.
- Fix a rule — "match products by barcode instead of SKU" — and the next run uses it.
- Pause it — "pause the store sync while we renumber our products" — and it resumes when you say so.
Good to know
- The store's access key is stored in the app as a secure secret; screens and code never show it, and replacing an expired key is one step.
- Calls to the store go through Operator's secured path — no credentials sit in the app itself.
- Large first imports are done carefully: Operator will suggest importing products first, orders second, and will show counts before committing anything unusual.
- Orders are created in ERP.net with the store's items and quantities; payments, invoices and shipment documents follow your usual ERP.net process.
- A run that fails — store unreachable, key expired — is recorded with the reason in the Triggers tab; it does not silently disappear.
- If your store has no API at all, tell Operator — it will say what is possible instead of improvising.