Flieber

The plan's active targets, by start: units over a period across their listings and the factor the plan is scaled by after the protected window. Add or remove them with forecast_plan_change (target, remove_target). Needs a Flieber sign-in.

Undo the plan's latest change still in force, as the portal's change log does: the preview shows which change it would undo; the commit undoes exactly that one, and Flieber refuses if another change came since. Preview and commit again to walk back one more change; committing the same preview twice is refused. An undo can't be undone. Needs a Flieber sign-in and plan mode.

The plan's approved versions, latest first: each a frozen copy of the plan. Needs a Flieber sign-in.

Dismiss Demand Forecast review flags for good, or snooze them until a moment (until), as the portal's Review tab does. A commit hides each flag from forecast_review_flags, across rebuilds, for the whole organisation; it changes no forecast number. A dismissal stays and a snooze ends when until passes, unless forecast_review_flag_restore brings the flag back; dismissing the same flag again replaces its reason and until. Name each flag by its check, product_id and store_id exactly as forecast_review_flags gave them. Preview first (commit=false), then commit with the preview_id. Needs a Flieber sign-in.

Bring back dismissed or snoozed Demand Forecast review flags, as the portal's Review tab does: a commit deletes each flag's dismissal or snooze, so forecast_review_flags lists it as open again (for the whole organisation). The dismissal's reason and who made it are not kept. A key with no dismissal or snooze (an open flag, or no such flag) is no error: its row says not_dismissed and nothing changes. Name each flag by its check, product_id and store_id exactly as forecast_review_flags (state dismissed or snoozed) gave them. Preview first (commit=false), then commit with the preview_id. Needs a Flieber sign-in.

The Demand Forecast review flags: places where the forecast is likely wrong, or needs something only you know, ranked by the units at stake, as the portal's Review tab lists them. By default the open flags; state dismissed or snoozed lists those instead, each with its dismissal. meta.summary covers every page of the open flags matching the filters, whatever the state: flag_count, units_at_stake, how many of the top flags cover cover_share (80%) of those units (items_covering_share), and when they were computed (computed_at). Needs a Flieber sign-in.

The Forecast review label vocabulary, which the app loads before the ledger: one row per metric of forecast_review_ratings with its title, the input that filters it, the label names in index order (index 0..3 is what a label filter takes) and the N/A label. Needs a Flieber sign-in, and Forecast review enabled for the organisation.

The Forecast review ledger, as the app shows it: one row per listing (product × store) with ten metrics of how hard its forecast is (outliers, level shifts, stockouts and dips, peaks, auto- and manual adjustments, seasonality), each labelled by percentile against comparable listings across Flieber, grouped by channel and tier (by default VERY SMALL, SMALL, HIGH, VERY HIGH, or N/A). Ratings are computed daily. Filter by search, stores, tiers, new listings and each metric's labels (indexes from forecast_review_rating_labels); sort with ordering; page by page number. Needs a Flieber sign-in, and Forecast review enabled for the organisation (Flieber refuses otherwise).

The forecast ledger summed by product, store, tier or a catalog attribute, as the app's Sales forecast page shows it with Group by: per group, its listings, units over the previous 30, 90 and 365 days (adjusted sales), forecast units over the next 30, 90 and 365 days, revenue over the previous and next 30 days and the 30-day relative change, as Flieber last computed them. Discontinued listings are left out, as Flieber does by default. For one row per product × store use `trends`. Needs a Flieber sign-in.

Set or clear weekly forecast adjustments, in units, for one product in one store, as the app's Sales forecast editor does by week: `units` sets the week's total (Absolute), `units_per_day` each day's units (Daily), `units_percent` changes the week's forecast by a percentage, and `clear` removes the week's adjustment. Weeks run Monday to Sunday; the current week from today. For whole months use `adjust_forecast`, for single days `forecast_daily_adjustment_set`. Like the app's Apply, each item replaces every adjustment of its days, revenue adjustments included. A commit recalculates this product-store's demand forecast before it answers; the inventory forecast built on it is recomputed in the background (meta.warnings says so). There is no undo: to go back, set the old values again or clear the periods (read the forecast first with `forecast`). Preview first (commit=false): Flieber's own preview gives each period's forecast units before and after, and changes nothing. Then commit with the preview_id. Needs a Flieber sign-in.

The inventory balance per product, as the app's Inventory balance page shows it: units on hand and on order across the product's supply-chain locations, their value at purchase cost, and the units at each location. Active products unless asked otherwise. Needs a Flieber sign-in.

The inventory balance per SKU (the app's 'View by SKU'): the units of each SKU on hand and on order at each inventory location, with the product it maps to. Needs a Flieber sign-in.

Set or clear SKUs' units on hand at one inventory location, as the app's Edit inventory balance page does on Save: one location per call, only SKUs mapped to it, and only at a location no integration feeds (a store connection's or a Google Sheet's location is read-only in the app too). A commit replaces each SKU's units on hand there; clear removes its balance at the location. It can be undone by setting the previous units again (the preview shows them as units_before). Flieber then recomputes the inventory forecast asynchronously. Preview first (commit=false), then commit with the preview_id. Needs a Flieber sign-in (OAuth).

Totals of the inventory balance over every product the filters match, and per inventory location: units on hand and on order, and their value at purchase cost (the app's totals row). Needs a Flieber sign-in.

One product at one location, day by day: the demand Flieber's inventory forecast plans for there, the units fulfilled, lost and backordered (the portal's demand chart in the product drawer). No rows when Flieber has no calculation details for the pair. Needs a Flieber sign-in.

The inventory forecast per product × location, as the portal's Inventory forecast list shows it: status (replenish now, soon, healthy, overstock), what to order and by when, stock on hand and in transit, days of stock, the last day of stock, lead times and the supplier. Best sellers first unless `ordering` says otherwise; meta.total counts every matching row (the portal's status cards are this count with `inventory_statuses`). Needs a Flieber sign-in.

Inventory history by month (the app's Inventory history chart): units on hand and on order at the start and end of each month, monthly averages, days of stock and stockout days, summed over the products and locations the filters match. Default: from a year ago to today, so 13 calendar months (the current one and the 12 before it), as the app's default period. Needs a Flieber sign-in.

Inventory history per product × location over the current month and the 12 before it (the app's Inventory history table), one measure per call: units on hand or on order at the end or start of each month, the monthly average, or days of stock. Needs a Flieber sign-in.

Set the shipment lead time of origin → destination routes (from a supplier, or a transfer from another inventory location), as the Flieber app's Edit shipment lead times page saves them. Only the routes named change. As in the app, a route not in use or from a location to itself can't be set. Clearing a route in use follows the organisation's page: refused where it is the newer Edit shipment lead times page or the page can't be confirmed, allowed elsewhere (the app then shows the route as pending configuration). A commit replaces each route's lead time: to undo, send the preview's lead_time_days_before again (clear when it was null, where the page allows it). After a commit, Flieber recalculates the inventory forecast in the background; inventory_lead_times shows the saved routes (it needs the portal's Inventory Forecast section). Preview first (commit=false), then commit with the preview_id. Needs a Flieber sign-in.

Shipment lead times, one row per origin (supplier or location) and destination location. A page holds up to `page_size` origins. Needs a Flieber sign-in.

One inventory location's balance by SKU, as the app's Edit inventory balance page for that location shows it: units on hand and on order for each SKU mapped to the location (discontinued products included), and whether its balance can be edited by hand (no integration feeds the location). 100 SKUs per page. Needs a Flieber sign-in (OAuth).

The organisation's inventory locations (warehouses, Amazon FBA and other fulfilment centres), as the portal's location filter lists them. Needs a Flieber sign-in.

Run the app's manual inventory update (its Update button): Flieber promotes the inventory its integrations sent, reprocesses inbound shipments, and queues an asynchronous recompute of the forecast and the inventory forecast. The preview reads the status and rejects it, as the app's button does, within 10 minutes of the last one finishing or when no integration data arrived since; stricter than the app, it also waits while Flieber has an update marked as running (one that never finished blocks it until Flieber clears it). A commit re-reads the status and sends nothing then. A commit can't be undone, but it only applies data the integrations already sent, and repeating it is safe: Flieber refuses another update for 10 minutes after one finishes. Preview first (commit=false), then commit with the preview_id. Needs a Flieber sign-in (OAuth).

The status of the app's manual inventory update (the Update button on the inventory balance, inventory forecast and inbound shipments pages): when integration inventory and inbound shipments last arrived, when the last manual update finished, whether one is running, when its 10-minute cooldown ends, and whether the app would allow an update now. Flieber answers it only for an organisation with manual inventory updates turned on. Needs a Flieber sign-in (OAuth).

Set a product's supplier and supply facts (MOQ, production lead time, purchase cost in USD, carton and pallet), as the Flieber app's Edit suppliers page saves them. Each item names the fields to set or clear; the others keep their value. The supplier is named: an existing supplier with exactly that name, else Flieber creates one, and a supplier no product uses any more is deleted with its shipment lead times; changing a product's supplier can also remove the old supplier's lead times on routes no longer in use. The preview shows each change, whether the supplier exists, and those deletions. A commit replaces the products' rows: to undo, set the previous values again (the preview's `changes` lists them); a deleted supplier's lead times must be set again. The carton fields and cartons_per_pallet need the app's carton editing for the organisation. After a commit, Flieber recalculates the inventory forecast in the background; inventory_product_suppliers shows the saved rows (it needs the portal's Inventory Forecast section). Preview first (commit=false), then commit with the preview_id. Needs a Flieber sign-in.

Each product's supplier and supply facts: MOQ, production lead time, purchase cost, carton and pallet. Needs a Flieber sign-in.

One product at one location, day by day: the projected units on hand and in transit, and the days inbound shipments arrive (the portal's inventory projection chart). Needs a Flieber sign-in.

How much to order or move for each product × location so stock lasts until `cover_until`, computed by Flieber for that window (the portal's 'cover until'). It computes only: nothing is saved or ordered. Needs a Flieber sign-in.

The inbound shipment attributes in use: each name and value, with how many shipments have it. Needs a Flieber sign-in (an API key gets auth_missing).

Set attributes on inbound shipments, as the app's attributes dialog does: replace each shipment's attributes, or append to them. The preview shows each shipment's attributes before and after (to restore by hand); a Google Sheets shipment's are changed in its sheet. Attributes don't change Flieber's calculations. Preview first (commit=false), then commit with the preview_id. Needs a Flieber sign-in (an API key gets auth_missing).

Inbound shipment lines, one per SKU on a shipment, with the product it maps to and its shipment (e.g. a product's open lines: `product_ids`). Needs a Flieber sign-in.

One inbound shipment's lines, or every shipment with a code, with what the shipment writes act on: each line's item_id and index, and the shipment's code, internal code, provider, destination, delivery date, whether Flieber counts it, and its attributes. Needs a Flieber sign-in (an API key gets auth_missing).

Change one inbound shipment's code (manual shipments only), destination, delivery date or whether Flieber counts it, as the app's Inbound shipments list does. If the new code or destination is another shipment's (same code, destination and provider), Flieber moves that shipment's lines into this one and deletes it, which cannot be undone: the preview lists those shipments (action merge_and_delete), and a commit refuses to merge unless allow_merge is true. A plain change can be reversed with another update. Flieber then recomputes the inventory forecast in the background. Preview first (commit=false), then commit with the preview_id. Needs a Flieber sign-in (an API key gets auth_missing).

Inbound shipments with their lines: destination, delivery date, status, units shipped, received and pending. Closed shipments and those left out of Flieber's calculations are hidden unless asked for. Needs a Flieber sign-in.

Add manual inbound shipments, line by line, as the app's 'Add new' grid saves them: a SKU, units, the destination, and optionally the delivery date, a code and attributes. Lines with the same code and destination are one shipment; a line without a code is its own. The preview says which lines join an existing manual shipment with that internal code at that destination (whose delivery date and attributes they then set) or replace one of its lines, and which code an Amazon shipment has (with Amazon shipment code matching turned on for the organisation, such a line adjusts the Amazon shipment instead). A commit saves the lines; there is no undo (edit them with inventory_shipments_edit). Committing the same lines again is safe for lines with a code (they upsert onto the same shipment) but adds each line without a code again, as another shipment. Flieber then recomputes the inventory forecast in the background. Preview first (commit=false), then commit with the preview_id. Needs a Flieber sign-in (an API key gets auth_missing).

Turn on or off whether Flieber fills in the delivery date of each new integration shipment (its creation date plus the longest lead time of its SKUs), as the app's 'Turn auto-delivery date on/off' does. It applies to shipments that arrive afterwards; a date someone set is kept. Reversible: set it back. Preview first (commit=false), then commit with the preview_id. Needs a Flieber sign-in (an API key gets auth_missing).

Change inbound shipment lines, as the app's 'Edit shipments' grid saves them: the SKU, units shipped or received, and the line's shipment's destination, delivery date, code, attributes and whether Flieber counts it (those apply to the whole shipment). A new destination moves the line to the shipment with the same code there; its other lines stay. On an integration line the app lets only some fields change (Amazon: destination, delivery date, counted; others: counted), and so does this. A commit replaces the lines; the preview's `changes` hold the values to restore by hand. Flieber then recomputes the inventory forecast in the background. Preview first (commit=false), then commit with the preview_id. Needs a Flieber sign-in (an API key gets auth_missing).

Choose where manual inbound shipments are kept, as the app's 'Configure inbound shipments input' does: in the app (manual) or in a Google Sheet Flieber creates and shares with an email. Switching back to manual moves the sheet to Google Drive's trash and keeps its shipments as manual ones; connecting again creates a new sheet, so the old one is not restored. In the app this needs a plan with Google Sheets. Preview first (commit=false), then commit with the preview_id. Needs a Flieber sign-in (an API key gets auth_missing).

How the organisation's inbound shipments come in: whether Flieber fills in new integration shipments' delivery dates, and whether manual shipments are kept in the app or in a Google Sheet (its email and link). Needs a Flieber sign-in (an API key gets auth_missing).

Counts of the organisation's inbound shipments that need attention: past their delivery date, missing a date or a destination, or with SKUs not mapped to products. No row when there is no shipment yet. Needs a Flieber sign-in.

Which inventory location fulfils each store's orders and which stores for it. Needs a Flieber sign-in.

Totals over every product × location the filters match: units and value on hand and in transit, stockouts, replenishment needs and gross profit, in USD. Needs a Flieber sign-in.

Flieber's active terms, in full. A person accepts them when they create their Flieber sign-in; create_organization returns them itself when Flieber still needs an explicit acceptance.

The organisation's listings: one row per product × store, with the product and store ids the signal capabilities filter by, SKUs, tier and lifecycle. Store names are not unique; use store_id.

The SKUs each store's channel reports, and the catalog product each is mapped to. The only capability that shows unmapped SKUs (mapped = false). store_ids is required.

New Product Forecast: the products judged as proxies for a new product, best match first, with the six criteria scores, lane, whether each is picked, pinned or excluded, and its launch. Same inputs as new_product_forecast; Flieber returns the top 300 and every picked, pinned or excluded one. Computed on request; nothing is stored. Its figures are New Product Forecast's own estimate from the proxies' launches, not Flieber's actual sales, adjusted sales or forecast signals. Needs a Flieber sign-in; only for organisations set up for the Flieber portal (Flieber refuses others).