Flowlity Co-planner

List planner comments on products and orders for a site. Comments are the free-text "qualitative why" a planner left next to a product or order — e.g. "FC revu suite info client" or "pic créé par la rétention des commandes en rupture". They are best read alongside the other MCP tools rather than alone: - pair with `get_forecast_accuracy` to classify a bad MAPE as explained (promo, one-off order, data issue) vs unexplained; - pair with `get_order_alerts` / `get_stock_coverage` for stockout post-mortems; - cross-reference manual-override comments (rationale + author + date) with forecast value added; - reconcile commented promos against `list_promotions`. Filter with `product_site_id` and/or `order_id` to focus on one product or order, and `date_from` / `date_to` (inclusive, YYYY-MM-DD) to pull comments from a given period. Set `unread_only=True` for unread comments only. Results are ordered most-recent-first so recency weights relevance. Notes: - Text is inconsistent, multilingual (FR/EN/SV) and jargon-heavy (`GC` = grand compte, `S11` = week 11, `1037363 --> 1041355` = substitution). Cite the source comment; never silently auto-action. - Coverage is uneven — absence of a comment is not absence of a problem. Comments are scoped to the site through their product, so legacy order-only comments without a product link are not returned.

Run every master-data check over every item on a site, and return only the defects. The whole data-quality audit in one call: missing supplier link, placeholder lead time, stale lead time, wrong ABC category, item not deactivated, missing valuation price, no primary supplier. Each one is evaluated against **100% of the item base** in the database, and only the flagged items come back — ranked by the value they expose, each with the field to correct and a link to the item. Use this instead of paging `list_products`, `get_product_supplier_constraints` and `get_product_constraints` and comparing them: a 4,000-item site is over 1 MB of tables that way, and an audit assembled from a few pages of it covers a few percent of the base while reading as complete. `get_demand_summary` and `get_monthly_demand_forecast` are not needed either — the demand figures behind every impact here are the ones they read. `tag_ids` narrows the audited population to a family, class or buyer, with every check still running fully inside it. `abc_tag_ids` names the site's ABC class tags (from `list_tags`) for the ABC check; without it they are guessed from tag names, which misses a site whose classes are named in another language. `checks` runs a subset; valid keys are missing_price, missing_supplier, placeholder_lead_time, stale_lead_time, no_primary_supplier, wrong_abc, not_deactivated.

Return demand history and forecast summary for a product. The period tables are product totals, summed across customers. `by_customer=True` adds the past demand of each customer over the last 30 days, 3 months and 12 months, its share of the 12 months and its firm orders for the next 3 months, read from the demand rows themselves. `customer_id` (resolve it with `list_customers`) keeps one customer in that table and in the recent daily demand. For a split by month, use `get_monthly_demand_forecast(by_customer=True)`. Set `chart=True` to also get the recent daily demand as a chart image, drawn from the same rows. Leave it off unless a picture is wanted: an image costs input tokens on this turn and on every later one.

Return forecast accuracy, model setup, and review status for one product. Includes MAPE/MAE/FVA accuracy windows, the forecast model demand type, whether the planner configured expert models (for new products an expert/launch model is an alternative to a similar-product link), and the last demand/planning review dates by a planner. Accuracy is measured on the product total, across customers. To review one retailer, compare its actual demand with its final forecast month by month with `get_monthly_demand_forecast(by_customer=True)`.

Run every forecast check over every product on a site, and return the ranked review list. The whole forecast audit in one call: shortage-distorted history, outliers, forecast-degrading overrides (planner or imported), demand level shifts, new products with nothing to anchor on, persistent bias, and unexplained low accuracy, each evaluated on **100% of the products** in the database, in the procedure's attribution order, so a miss explained by a shortage, a promotion or an end-of-life is never flagged as a forecast defect. Returns the forecast error value and how concentrated it is, the share that is not a forecasting problem, override value added (each override scored against the Flowlity run from before its edit, fair months only), error value by root cause, per-check coverage, and the flagged products ranked by impact, each with the forecast input to fix and its Demand and Planning links. Products whose demand a planner reviewed inside `review_window_weeks` are left off the list unless one of their anomalies started inside that window. Use this instead of looping `get_monthly_demand_forecast`, `get_forecast_accuracy`, `get_forecast_history` and `get_my_forecast_history` per product: that covers a few percent of a site while reading as complete. For the site's accuracy KPI and its trend, add `get_site_kpis` and `get_kpi_trends`. `tag_ids` narrows the population (a family, a class), every check still running fully inside it. `checks` lists a subset; valid keys are shortage_history, outlier, override, level_shift, new_product, bias, unexplained.

Return Flowlity forecast versions for one product, by target month. Shows how the monthly forecast for a given target month evolved across forecast runs (e.g. May-26 run forecasted Aug-26 = 30; Jun-26 run forecasted Aug-26 = 45). Rows are sorted by target month then by forecast run date (`updated_date`) ascending, so the latest run is at the bottom of each target-month block. Forecasts are sourced from the Flowlity ML output at the site's configured granularity — `ml.demand_forecast_flowlity_day_aggregated`, `_week_aggregated`, or `_month_aggregated` depending on `public.site.forecast_granularity` (daily / weekly / monthly, default weekly). Day and week buckets are aggregated into calendar months via `date_trunc('month', target_date)`; a bucket whose start date straddles a month boundary is attributed to the month containing its start. Forecast runs that happen within the same calendar month as the target are excluded so partial-month sums don't appear as a sudden revision (matches the dbt accuracy convention). Dates must be in YYYY-MM-DD format. `target_month_start` and `target_month_end` are inclusive and bound the target months covered. Forecast runs are kept per product, not per customer, so these versions have no customer split; the current final and Flowlity forecast by customer is `get_monthly_demand_forecast(by_customer=True)`.

Return the future demand a site has received, bucketed by period. Reads `public.demand_future`: one row per product, customer and day, split by `status`: `firm` is a confirmed sales order, `planned` is expected demand not yet confirmed. Covers the whole site by default; pass `product_site_id` for one product, or `customer_id` (resolve it with `list_customers`) for one customer. `by_customer=True` splits each bucket by customer, so the order book of every retailer comes back in one call rather than one call per customer. `granularity` is `month` (default), `week` or `day`. The `Origin` line splits the total between the site's own customers, a child site (intercompany) and MRP explosion of a BOM. Only the first is a customer order: read the split before quoting `Total` as demand from customers, since a site whose demand is mostly intercompany transfers or exploded components would otherwise read as one with a full order book. `start_date` and `end_date` are inclusive, in YYYY-MM-DD format; past dates are allowed. A range that starts or ends inside a bucket makes that bucket partial, so ask from the 1st of a month to the last day of one before comparing monthly totals. `limit` caps how many buckets come back (default 50, max 1000), taking the earliest ones: a range that needs more is cut off at its far end, and the header says so when that happens. With `by_customer` it caps bucket-and-customer rows instead. Set `chart=True` to also get firm and planned demand as a chart image, drawn from the same rows; the split by customer has no chart. Leave it off unless a picture is wanted: an image costs input tokens on this turn and on every later one.

Return latest import status rows by site, dataset, or specific import id.

Return monthly KPI trend points, with optional tag-level filtering. Valid `kpi` values: demand_plan, inventory_level, supply_plan, stock_coverage, zero_stock_days. Units: demand_plan / inventory_level / supply_plan trends carry a quantity (default unit) and a value (EUR). stock_coverage is expressed in days of coverage (site average) — it has no value/currency dimension. zero_stock_days is a 0-1 rate shown as a percentage; for stock-out days per item, and the units they cost, use `get_stockout_kpis`. Set `chart=True` to also get the trend as a chart image, drawn from the same rows. Leave it off unless a picture is wanted: an image costs input tokens on this turn and on every later one.

Return demand and forecast bucketed by calendar month for a product. Use this tool for cross-year same-month comparisons (e.g. compare the forecast for Jul-26 against the actual demand for Jul-25 and Jul-24). Each row aggregates one calendar month between `start_date` and `end_date` (inclusive, YYYY-MM-DD). `Actual Demand` is summed from `public.demand` (typically populated for past months); `Final Forecast` and `Flowlity Forecast` are summed from `public.final_forecast` (typically populated for current/future months). Use a date range that spans the years you want to compare. Every figure is summed across customers unless asked otherwise: `customer_id` (resolve it with `list_customers`) keeps one customer, and `by_customer=True` splits each month by customer in one call — the answer to "who buys this product", "how much goes to each retailer" or "was this spike one customer". The split adds a per-customer total over the period with its share of the actual demand, and its rows add up to the unsplit product totals. Demand with no customer is on customer 0, shown as "No customer"; on a site without a customer axis it is all of it. `limit` and `offset` page the month-by-customer rows only. Set `chart=True` to also get actuals and both forecasts as a chart image, drawn from the same rows; the split by customer has no chart. Leave it off unless a picture is wanted: an image costs input tokens on this turn and on every later one.

Return My Forecast (planner override) values for a product, past dates included. Reads `public.my_forecast`, which keeps planner-entered forecast values for past buckets as well as future ones. Each row is one forecast bucket date (site forecast granularity, typically the week start) with the quantity summed across customers, the date of the last edit, and the source (`user` = edited in the app, `data` = imported). Buckets whose override was cleared (no value) are omitted. Combine past values with actual demand (`get_monthly_demand_forecast`) and Flowlity forecast versions (`get_forecast_history`) to judge whether planner overrides improved or degraded forecast accuracy. `customer_id` (resolve it with `list_customers`) keeps one customer's overrides, and `by_customer=True` gives one row per bucket and customer, for an override made on one retailer only. `limit` then caps those rows. Dates must be in YYYY-MM-DD format; past dates are allowed.

Get order alert summaries and recent alert rows.

One-call order review for a site: what to validate, what is late, and qty vs stock. Composite tool for the order-analysis use case. Returns a summary of open orders and validation deadlines (overdue / next 7d / 14d / 30d), the list of planned orders to validate (soonest deadline first, with order qty next to current stock), and the top suppliers with late firm deliveries. Use this instead of paging `list_orders` and cross-checking statuses and dates by hand. A planned order (`status_id = 1`) must be validated by its `latest_order_date`; a firm order (`status_id = 3`) whose delivery date has passed counts as a late delivery.

Return product-level planning constraints (coverage, min/max stock, shelf life). This is the product level (public.product_site): the inventory policy that constrains a product on its own, independent of supplier — minimum stock policy, target coverage days, maximum stock, shelf life and stock valuation price. Filter with ``product_ids`` and/or ``tag_ids``. Each row's Tags column lists the product's tags as ``Category: tag``; ``tag_categories`` (category names from ``list_tags``, any case) keeps only those categories in it. For supplier-specific MOQ/lead time/price/lot size use ``get_product_supplier_constraints``.

Return full product details including tags, suppliers, alerts, and BOM. The "Forecast Model & Review" section reports the planner's expert/launch model (an alternative to a similar-product link for new products) and the last demand/planning review dates, so the forecast-audit skill can avoid flagging products that have an expert model or were recently reviewed.

Return the planning time series (stock, supply, demand, forecast, min, max) for ONE product over a date range. Use this to inspect a single product's projected stock curve. For "which products are in stock-out or at risk", use `list_product_alerts` instead. `granularity` is `day` (default), `week` or `month`. **Ask for `week` or `month` on any range longer than a month or so**: the default window is 90 days against a `limit` of 30, so a daily call over it returns a third of the range. Aggregating in SQL is the cheaper answer than a bigger `limit` — a year is 12 monthly buckets. Aggregation is per column, because the columns are not the same kind of number. Supply, demand and forecast are flows and are summed. Stock is a level, so it is the bucket's **closing** value, and a second column gives the bucket's **lowest** stock — which is what answers "does this week break the minimum", and what a daily table makes a reader scan for by eye. `Min` and `Max` are the Flowlity min and max. When the product has a "My stock max" (the planner's own overstock threshold), a `My stock max` column gives it in units for each bucket: the quantity as set, or the coverage in days times the bucket's closing average daily final forecast. Measure overstock against it rather than `Max` when present. Set `chart=True` to also get this series as a chart image, drawn from the same rows. Leave it off unless a picture is wanted: an image costs input tokens on this turn and on every later one.

Return per-supplier sourcing constraints for products (MOQ, lead time, price, lot size). This is the product x supplier level (public.product_supplier_link): the MOQ, lead time, unit price, lot size and order frequency negotiated with each supplier for each product. Defaults to the primary supplier per product (highest active quota share, resolved from public.quota); set ``primary_supplier_only=False`` to list every supplier grouped by product x supplier. Filter with ``product_ids`` and/or ``tag_ids``. Products with no supplier linked are not in this list: use ``list_products(without_supplier=True)`` for them, never a comparison of the two lists. For supplier-wide constraints (basket MOQ, full truck) use ``get_supplier_constraints``; for product planning policy (coverage, min/max stock, shelf life) use ``get_product_constraints``; for tag-based supply agreements use ``get_tag_constraints``. When a row has a non-null Tag Family / Family MOQ, the line MOQ is enforced at the **tag-family scope** (sum over every product in the family >= Family MOQ) at sites where config.site_or.tag_family_moq is on. Audits like "MOQ vs forecast" should aggregate demand at the family level in that case, not per product. Use ``list_products(tag_ids=[<family_id>])`` to enumerate the family.

Get one promotion: its economics, its budget line, and its products. Returns the whole read-time cost derivation — mechanic preset, generosity rate, committed volume, redemption rate, redeemable units, forecast NIP cost, gross and net cost, max liability, flat fee, net coefficient — plus the invoiced/outstanding split for a NIP, the realised sell-out against the forecast for the days already past, and the per-product impact rows at `site_id`. Every euro figure is derived from the stored inputs at read time (the schema stores no cost), by the same math the Flowlity app uses, so a number here should equal the number on the promotion's page. Those figures are company-wide; the per-product table is the only site-scoped part of the answer, and `limit` bounds it.

Aggregate promotion volume, revenue and cost over one dimension. This is the reporting tool: it answers "net cost per retailer this quarter", "which mechanic costs most", "how much of each budget is consumed" in one query. Do **not** page `list_promotions` and add the rows up — 300 promotions is 300 rows of client-side arithmetic and the totals will not match the app's. `group_by` is one of: `customer`, `type`, `mechanic`, `status`, `month` (the promotion's start month), `budget`, `owner` (the envelope's key account manager). Set `chart=True` to also get net cost and revenue by month as a chart image, drawn from the same rows as the table. Only `group_by=month` records a series — the other dimensions are rankings, not a time axis. Filters: `period_start` / `period_end` (YYYY-MM-DD, inclusive) select promotions *overlapping* the window; `status` (`planned`, `in_progress`, `confirmed`; comma-separated), `customer_id` and `promotion_type` narrow further. `Allocated` is the total of the distinct budget envelopes the group's promotions charge, and `% Consumed` is the group's net cost against it — so with `group_by=budget` it is the envelope's own consumption, and with any other dimension it is that slice's share of the envelopes it touches. `Realised / Forecast` compares realised sell-out against the forecast for the days already past, never the whole period.

Fetch detailed site configuration and feature flags.

Return aggregated dashboard KPIs for a site (inventory, demand, supply, forecast). Call this first for a site-wide overview before drilling into per-product tools. For one KPI over a date range, use `get_kpi_trends`.

Fetch one of Flowlity's written procedures for a recurring planning job. Call this *before* starting the work it describes, not after: it gives the order to do things in, which tools to use, and the mistakes that make an answer wrong. If the user names a skill below — with or without a leading slash — fetch that one, even when a different skill looks like a better match for what they are asking about. A name they typed is an instruction, not a hint, and overriding it silently leaves them with no way to get the procedure they asked for. The identifier, the title, or a unique part of either all resolve, so pass whatever they wrote. When you have followed one, end with a single short line naming it — "Followed Flowlity's <title> procedure; ask for it by name next time." Most users never learn these exist, and the moment they have just been useful is the only moment worth spending a sentence on it. **The set is not listed here.** It is authored outside this deployment and changes without one, so call this with **no name** first to get the current list, then fetch the one you need by name. Do that for "what procedures do you have" asked in general, and equally when the user names or describes **one** job — "is there a guide for a replenishment review?" — because the list is where the exact name comes from. **`vars` overrides a procedure's own parameters, and is for when the user asked for one in so many words.** A skill can declare its windows and thresholds — a demand window, a horizon, a threshold — and the text you get back ends with the ones in force. Those names are what `vars` takes: after "but look at the last six months", fetch it again with `vars={"period": "last 6 months"}`. The defaults are what make two runs of a procedure agree, so do not invent one — a name the skill did not declare is ignored, and the footer, not your memory, is what to report the values from. The names are not listed here either: they belong to the skill, which is authored without a deploy, so read them off that footer. **Call it again every time you are asked, even when you already have a list.** The set changes while a conversation is open — someone adding, pausing or removing one between two questions is ordinary — so an earlier reply of yours is not evidence of what exists now. Answer from a fresh call, never from the transcript.

Return stock-coverage metrics and optional low-coverage filter.

Build the whole stock coverage review of a site in one call: every SKU, on a like-for-like cohort. Covers **100% of the products** of the site (or of `tag_ids`) and returns: - the usable history and the two windows: the last `window_months` complete months against the same months `base_offset_months` earlier, or the first months of history when it is shorter. The current partial month is always excluded. - the continuing cohort (demand in both windows), its share of current stock value, and what sits outside it: new since base, lapsed, no demand, phased out past end-of-life, and proposed version switchover pairs (an EOL item and its successor by external-id stem, to confirm with the user). - coverage today as median and value-weighted days, never the site mean, with products holding stock and no forecast held out. - stock € and SKUs per coverage bucket (< 30, 30–90, 90–180, 180–365, > 365 days): today, the last complete month and the base month. - the supplier-minimum test: max(MOQ, lot size), family-level where a tag family minimum is enforced, in years of trailing 12-month actual demand (forward forecast for end-of-life or never-sold items), split locked / constrained / addressable by stock €, plus the renegotiation and delisting shortlist. - stock with no forward forecast, classed MTO / promotional (linked, or by a PAV/PCB/promo/display name or tag) / obsolete (past end-of-life included) / forecast gap / launch build / failed launch, by stock €. - the monthly trend on the cohort from the base window to the last complete month: stock €, median and mean coverage, zero-stock days, demand, with the app's own series beside it. - every SKU, stock € first: coverage, trailing and forward demand and which one is used, effective minimum, its years, sourcing class, no-forecast class, forecast model, and flags (divergence, suspect unit of measure, end-of-life, successor of). Use it instead of paging `get_stock_coverage` and `get_product_supplier_constraints` and calling `get_monthly_demand_forecast` and `get_demand_summary` per product, which reaches a fraction of a site while reading as complete. For a trend per tag segment, add `get_kpi_trends(tag_ids=...)`; for the forward view, `list_product_alerts` and `list_stockouts_without_firm_orders`. Set `chart=True` to also get the cohort trend as a chart image.

Return past stock on hand for ONE product over a date range, by period. This is inventory *history* — what the product actually held on a past date. `get_stock_levels` gives stock as of today, and `get_product_planning` only starts at yesterday and runs forward, so this is the tool for "how much stock did we hold in March", for stock seasonality, and for any month-over-month inventory comparison. Reads `dbt_flowlity.past_stock`, the daily series the app's own inventory KPIs are built from, so the figures agree with the UI. It is `public.stocks` made continuous: that table holds a row only where an import wrote one, and a gap between two rows is the stock staying put rather than the stock being unknown — so each reading is carried forward until the next one, storage sites are summed, and shortend storage counts as zero. Querying `public.stocks` by date directly returns nothing on most dates for that reason. `granularity` is `day` (default), `week` or `month`. **Ask for `week` or `month` on a range longer than a month or so**: a year of daily buckets is past the ceiling this tool will return, and aggregating in SQL is the cheaper answer than a bigger `limit`. Stock is a level, not a flow, so it is never summed — an aggregated bucket reports its **closing** stock plus the average, lowest and highest stock inside it. The average is the inventory figure an S&OP or IBP review quotes for a period; the low is what says whether the period ran dry. `start_date` and `end_date` are inclusive, in YYYY-MM-DD format. A range starting or ending mid-bucket makes that bucket partial and its average an average of fewer days, so ask from the 1st of a month to the last day of one before comparing monthly figures. The series ends at the last completed day; for stock as of today call `get_stock_levels`, which also breaks it down by storage site. For a whole site or a tag rather than one product, use `get_kpi_trends` with `kpi='inventory_level'`: it is monthly, and it carries the value in EUR as well as the quantity. For days out of stock across items, use `get_stockout_kpis`. Set `chart=True` to also get the series as a chart image, drawn from the same rows. Leave it off unless a picture is wanted: an image costs input tokens on this turn and on every later one.

Return stock levels either by product or storage-site breakdown.

Per-item stock-out KPIs for a whole site: past and projected days out of stock, and the units each costs. One call covers every item on the site (or in `tag_ids`), so use it for any portfolio question about stock-outs ("which items ran out last quarter and how many sales did we lose", "which will run out and how much forecast is not covered") instead of looping `get_stock_history` or `get_product_planning` per product. For each item: - **Past days out**: days in the last `lookback_days` (ending yesterday) the actual stock closed at zero. - **Est. lost units**: past days out × average daily sales on the days the item was in stock. - **Projected days out**: days in the next `horizon_days` (from today) the projected stock is at zero, weekends included. - **Units short**: forecast the projected stock cannot serve over the horizon, with the first projected stock-out date. Only items with demand count: sold in the last 12 months for the past figures, forecast left uncovered for the projected ones. The summary lines total the whole list, not just the page. For what to act on now (criticality, last date to act) use `list_product_alerts`; for shortages detected from demand drops use `list_shortage_periods`. `lookback_days` and `horizon_days` are 1 to 365. `sort_by` is `units` (lost + short, default), `past_days` or `projected_days`.

Return supplier-wide constraints (basket MOQ, full truck, order frequency). This is the supplier level (public.partner_site): constraints that apply to a whole order to a supplier rather than to one product line — the basket minimum order quantity, full-truck quantity, order frequency, max supplies per order and transportation lead time. Lists the suppliers used at the site. Filter with ``supplier_ids`` (partner_site IDs). For per-product MOQ/lead time/price/lot size use ``get_product_supplier_constraints``.

Return tag-based supply-agreement constraints applied to products. This is the tag level (public.tag via public.product_tag_link): lot size and supply-agreement / supply-price rules defined once on a tag and shared by every product carrying it. Returns one row per product x constraint-tag. Filter with ``product_ids`` and/or ``tag_ids``. Per-supplier MOQ/lead time/price lives in ``get_product_supplier_constraints``; supplier-wide rules in ``get_supplier_constraints``.

Return the full config of a view (columns, filters, sorting, compiled where). Use it to verify a view you just created, or to mirror an existing working view before cloning its column/filter set. Works for any view on a site you can access (not just ones you created).

One-call weekly supply-chain review for a site: KPIs, risks, and order actions. Capstone digest for the recurring weekly supply-chain presentation. Combines the site headline KPIs, the stock-out and overstock risk counts (including how many stock-outs have no firm order on the way), the order validation backlog (overdue / 7d / 14d / 30d) and late deliveries, plus short top-`top_n` lists of the orders to validate this week and the stock-outs that need an order. Use this for a weekly summary instead of calling the KPI, alert and order tools separately.

Compare two files the user uploaded, matched on a shared reference. The question this exists for is "last month's export against this month's": two files whose rows correspond through a SKU, a supplier code or an article reference, where the answer is a number over the pair rather than over either one. **The reply says how many rows found a partner**, always. A pairing that matched nothing looks exactly like a file with nothing above the threshold, and the usual cause is one of the two exports having lost an identifier's leading zeros in Excel — `describe_uploaded_file` warns about that, and this is where it bites. Rows that matched nothing are counted, not listed. Both files must belong to the caller's company; either one that does not resolves to nothing. Call `describe_uploaded_file` on each file first, for its column names. Pass `chart=True` on `/mcp` to get a grouped answer as an image as well; the agent bridge strips both the flag and this paragraph, since that channel has the cheaper `chart` event.

List site capacity units with supplier and product counts.

List the site company's customers with their internal ids. Use this to resolve a customer name or external id (e.g. "Aldi") into the internal id that `create_promotion(customer_ids=...)` and the demand tools' `customer_id` expect. `search` matches name and external id; `Products` counts the products linked to the customer on this site. `12-Month Demand` is the customer's past demand on this site over the last 12 months, and `12-Month Share` its part of the site's. Both are summed quantities across products, so they rank customers on a site whose products share a unit and are no volume to quote otherwise. `sort="demand"` lists the largest customers first ("top customers"); the default `name` sorts alphabetically.

List all tables in demo schemas (schemas starting with `demo`).

List products with an end-of-life (EOL) date and their remaining stock. Surfaces products carrying a `sale_end_at` date so planners can monitor and run down stock. Each row also carries **past demand and the forecast model**, which is what separates an item that is genuinely finished from one whose EOL date is simply wrong: zero 12-month demand with a `no_data` model is dead, while a named model and recent demand means the date needs correcting, not the status. Both come off a table this query already joins, so the whole set is one call rather than one `get_demand_summary` per row. Set `past_due_only=True` for products already past EOL, and `only_with_stock=True` to keep only those still holding stock: together they answer "which discontinued items still have warehouse stock to push to stores". The summary line also reports how many products have an EOL date defined at the site. Set `chart=True` to also get the stock value per item as a chart image, drawn from the same column the table prints. Leave it off unless a picture is wanted: an image costs input tokens on this turn and on every later one.

List order lines for a site, with optional product/supplier/status/date filters. Use this for orders placed, to validate, due soon, or late. For late or at-risk order lines specifically, see `get_order_alerts`. Each row's Tags column lists the product's tags as ``Category: tag``, so the class or sub-family of the ordered products needs no per-product call. ``tag_categories`` (category names from ``list_tags``, any case) keeps only those categories in it.

List product alerts (stock-out, overstock, and other risks) with summary counts by criticality. This is the entry point for "what is in stock-out, at risk, or needs action". Each alert carries its criticality code and type, the exceeding quantity/value, and the last date to act. Filter on one type with `criticality`, by the code the web app names: 0 = Expiring stock, 1 = Out of stock, 2 = Below Flowlity min, 3 = Above Flowlity max, 4 = Possible end of life, 8 = Above My stock max, 9 = Decreasing MRP, 11 = Possible outlier, 12 = Possible shortage. For one product's detailed stock curve, use `get_product_planning`. For how many days items were or will be out of stock, and the units it costs, use `get_stockout_kpis`. For overstock, pass `overstock=True` rather than a criticality: it keeps 8 (above the planner's own My stock max) and 3 (above the Flowlity max) only on products without a My stock max, so each product is measured against the planner's threshold when one is set. Each row's Tags column lists the product's tags as ``Category: tag``; ``tag_categories`` (category names from ``list_tags``, any case) keeps only those categories in it.

Search and list products with inventory and demand KPIs, including end-of-life (sale end) date, default unit and tags. Omit ``site_id`` to search every site you can access, in one call: do that for "which site is this product on", and before answering that a product does not exist when a search on one site found nothing. Rows then carry a Site column with the id to pass to per-product tools. ``without_supplier=True`` keeps only products with no supplier linked — the app's "Without supplier" filter. Use it for "which products have no supplier" rather than comparing this list with ``get_product_supplier_constraints``. Each row's Tags column lists the product's tags as ``Category: tag``, so a product's class or sub-family, or products carrying several tags at once, need no per-product call. ``tag_categories`` (category names from ``list_tags``, any case) keeps only those categories in it.

List the promotion budget envelopes with what the promotions charge them. One envelope is a (retailer × cost type × period) pocket of money. Only `Allocated` is stored: `Consumed`, `Confirmed only`, `Ceiling` and `Remaining` are summed at read time from the promotions pointing at the envelope, the same way the app's budget checkbook does it. - `Consumed (net)` — every linked promotion's net forecast cost. - `Confirmed only` — the subset in status `confirmed`; the finance-grade number, since that is what reaches the ERP. - `Ceiling` — the worst case: for a NIP, the whole committed volume selling through with every unit redeemed. - `Remaining` — allocated − consumed. Negative means overcommitted. Filters: `customer_id` (resolve with `list_customers`), `budget_type` (`nip` consumer discounts, `rsf` invoice discounts, `tmp` trade-marketing fees — comma-separated for several), `period_start` / `period_end` for envelopes *overlapping* that window, and `owner_email` for one key account manager's envelopes (substring match).