Deploy AIOS web (React glide grid + FastAPI slice)

RELEASES.json

@@ -1,5 +1,5 @@
 {
- "current": "9a6a561",
+ "current": "c2d4c3a",
  "releases": [
   {
    "version": "v29",

VERSION

@@ -1 +1 @@
-9a6a561
+c2d4c3a

api/routes_script_views.py

@@ -212,7 +212,7 @@ def create_script_view(body: dict = Body(default=None),
     if not database:
         raise err(400, "no_database", "a script view is bound to one database")
     _database_ok(session, database)
-    # ⭐  is CREATE's alone - see . The picker mints a view the
+    # ⭐ `allow_empty` is CREATE's alone - see `_clean_source`. The picker mints a view the
     # moment a person chooses the mode, so the empty source is the normal first state, not a slip.
     source = _clean_source(body.get("source"), allow_empty=True)
     refusal = sandbox.check_source(source)

platform/aios_grid_fields.json

@@ -469,14 +469,14 @@
         "label": "Inbound units",
         "type": "int",
         "source": "odoo",
-        "description": "Units already on order and not yet received, from Odoo's own incoming quantity on the product. In the product's STOCK unit of measure, the same unit as On hand, so the two can be added. Both cover gap columns count this as stock."
+        "description": "Units already on order and not yet received, from Odoo's own incoming quantity on the product. In the product's STOCK unit of measure, the same unit as On hand, so the two can be added. Days of supply and both cover gap columns all count this as stock (owner, 2026-08-19)."
       },
       {
         "key": "dos",
         "label": "Days of supply",
         "type": "int",
         "source": "odoo",
-        "description": "Days of supply at the LTM rate, from ON-HAND stock only; null means it never sells through. It deliberately IGNORES inbound units, because dead stock and overstock are questions about what is on the shelf. The cover gap columns are the ones that count inbound. Consolidated; absent for a BU-scoped caller."
+        "description": "Days of supply at the trailing twelve month rate, counting ON HAND PLUS INBOUND units as stock; null means it never sells through. Same stock figure as the cover gap columns, so the two cannot disagree about how much you have. They still divide by different rates: this one is the trailing average, the cover gap uses the forward 8 month forecast, so a seasonal SKU reads differently in each. Consolidated; absent for a BU-scoped caller."
       },
       {
         "key": "cover_gap_d",
@@ -484,7 +484,7 @@
         "type": "int",
         "source": "odoo",
         "default": false,
-        "description": "Days of cover minus supplier lead time. Negative means it runs out before a reorder lands. Counts INBOUND units as stock (owner, 2026-08-19), so this reads longer than Days of supply on any SKU with an open purchase order."
+        "description": "Days of cover minus supplier lead time. Negative means it runs out before a reorder lands. It counts INBOUND units as stock, exactly as Days of supply now does. The one thing it does differently: the burn rate is the FORWARD 8 month forecast rather than the trailing twelve month average, so a seasonal SKU reads differently here."
       },
       {
         "key": "cover_gap_units",
@@ -492,14 +492,21 @@
         "type": "int",
         "source": "odoo",
         "default": false,
-        "description": "The recommended reorder quantity: units of demand over the lead time that on-hand plus inbound does not cover. POSITIVE means buy this many; negative is surplus units; blank means we cannot say, because the SKU has no lead time on file or never sells through. Rounded AWAY from zero, so a real shortfall never rounds down to nothing."
+        "description": "The recommended reorder quantity: units of forecast demand over the lead time that on-hand plus inbound does not cover. POSITIVE means buy this many; negative is surplus units; blank means we cannot say, because the SKU has no lead time on file or no forecast demand. Rounded AWAY from zero, so a real shortfall never rounds down to nothing."
+      },
+      {
+        "key": "demand_fwd",
+        "label": "Forecast units (8 mo)",
+        "type": "int",
+        "source": "odoo",
+        "description": "Units this SKU is expected to sell over the next 8 months, read as the units it actually sold in the same 8 calendar months one year ago. Seasonal on purpose: a flat annual average spreads Valentine's, Mother's Day and Christmas evenly across the year and understates the months buyers actually order for. A SKU too new to appear in that window falls back to its trailing twelve month rate scaled to 8 months. This is the burn rate both cover gap columns divide by, shown so the reorder quantity can be checked."
       },
       {
         "key": "stock_bucket",
         "label": "Stock status",
         "type": "select",
         "source": "odoo",
-        "description": "Dead / excess / healthy bucket from the inventory module. Consolidated; absent for a BU-scoped caller."
+        "description": "Dead / excess / healthy bucket, from the same days of supply figure beside it, so it counts inbound units too. One exception on purpose: 'Out of stock' still keys on the REAL shelf, because that is a present tense fact somebody can walk into the warehouse and check. A row can honestly read 'Out of stock' with a days of supply beside it when the replenishment is on the water; Inbound units is why. Consolidated; absent for a BU-scoped caller."
       },
       {
         "key": "discontinued",

platform/core/odoo.py

@@ -264,12 +264,34 @@ def excluded_partner_ids():
     return res
 
 
-def sale_line_domain(date_from=None, date_to=None, team_id=None, extra=None, partner_ids=None):
+def sale_line_domain(date_from=None, date_to=None, team_id=None, extra=None, partner_ids=None,
+                     all_channels=False):
     """Build a sale.order.line domain in the RI+FFS confirmed-order scope, excluding
     the configured house accounts, with optional date window / single team / extra clauses.
     partner_ids (a collection, possibly empty) restricts to those customers — the carrier for
-    the Customer module's Agent filter; None = no partner restriction (an empty set matches none)."""
-    tids = active_team_ids()
+    the Customer module's Agent filter; None = no partner restriction (an empty set matches none).
+
+    ⭐⭐ `all_channels=True` DROPS THE WHOLESALE FENCE, and exists for exactly one class of
+    question: how much stock to BUY. Owner, 2026-08-19: *"for the Cover gap we need to include
+    Amazon SKUs as well ... Amazon units sold through Giftware deals client"*. Those units leave
+    the same warehouse, so a buy quantity computed without them under-orders every SKU Amazon
+    moves. The default fence is right for revenue, margin and customer analysis and is unchanged.
+    ⚠ This is not a new policy: the standing scope rule already reads *"inventory/SKU/dead-stock
+    analysis uses ALL channels"*. It is the first caller that needed a way to say so in code.
+
+    ⛔⛔ IT TAKES **TWO** FENCES DOWN, AND MISSING THE SECOND MAKES THIS FLAG A SILENT NO-OP.
+    MEASURED 2026-08-19: dropping only the excluded-partner clause changed the answer by ZERO
+    units, because GIFTWARE DEALS is not gated by the partner list at all in practice — its orders
+    sit on **`crm.team` 7 ('Giftware Deals')** while `active_team_ids()` is `[5 Fisch, 6 Royal]`,
+    so the TEAM clause was already excluding them and the partner clause never bit. In the
+    forecast window that is **3,794 lines on team 7 against 0 on the active teams**. So this drops
+    the team restriction as well.
+    ⚠ AN EXPLICIT `team_id` STILL WINS. A BU-scoped caller asked about ONE unit and must keep
+    getting that unit; only a consolidated read widens.
+    ⛔ OPT-IN, never the default: flipping the default would silently widen revenue everywhere."""
+    # ⛔ `all_channels` suppresses the ACTIVE-TEAM fence, which is the one that actually excludes
+    # the Amazon channel (crm.team 7). An explicit `team_id` below still overrides either way.
+    tids = () if all_channels else active_team_ids()
     dom = [('state', 'in', ['sale', 'done']), ('product_id', '!=', False)]
     if tids:
         dom.insert(1, ('order_id.team_id', 'in', tids))
@@ -280,7 +302,7 @@ def sale_line_domain(date_from=None, date_to=None, team_id=None, extra=None, par
         dom.append(('order_id.date_order', '>=', f'{date_from} 00:00:00'))
     if date_to:
         dom.append(('order_id.date_order', '<=', f'{date_to} 23:59:59'))
-    ex = excluded_partner_ids()
+    ex = () if all_channels else excluded_partner_ids()
     if ex:
         dom.append(('order_partner_id', 'not in', list(ex)))
     if partner_ids is not None:

platform/modules/product_data.py

@@ -311,7 +311,47 @@ def _bu_ltm_share(t, team_id):
 _DEFAULT_SHARE = 0.0
 
 
-def _rescope_inventory(e, share):
+def _dos_with_inbound(on_hand, incoming, qty_ltm):
+    """`(dos, bucket)` where DAYS OF SUPPLY COUNTS UNITS ALREADY ON ORDER as stock.
+
+    ⭐⭐ OWNER, 2026-08-19: *"Days of supply field should INCLUDE inbound quantities."* This
+    REVERSES the split shipped hours earlier the same day, in which `dos` stayed on-hand-only while
+    only the cover gap counted inbound. That split was defensible and the owner has ruled against
+    it: one number, one meaning, and the two columns can no longer disagree about how much stock
+    this SKU has.
+
+    ⛔ ONE DEFINITION, USED BY BOTH THE CONSOLIDATED AND THE BU-SCOPED PATH. They used to compute
+    days-of-supply in two places — `inventory.sku_inventory` for everybody and `_rescope_inventory`
+    for a scoped caller — and a change like this one is exactly how those two drift into answering
+    the same question differently ([[one-question-two-normalizers]]). Both roads now end here.
+
+    ⚠ `_bucket` STILL RECEIVES THE REAL SHELF, NOT THE EFFECTIVE FIGURE, and that is deliberate.
+    Its only use of the quantity is an `on_hand <= 0` test that yields **'Out of stock'** — a
+    present-tense fact somebody can walk into the warehouse and check. A SKU with nothing on the
+    shelf and 500 units on the water IS out of stock today; the `dos` beside it says how long the
+    cover lasts once they land, and `Inbound units` shows why the two differ.
+
+    ⚠ `on_hand is None` means no inventory row for this SKU: blank, never zero. Inbound alone
+    cannot manufacture a days-of-supply for a SKU the warehouse has never heard of.
+    """
+    if on_hand is None:
+        return None, None
+    effective = float(on_hand) + float(incoming or 0.0)
+    qty = float(qty_ltm or 0.0)
+    daily = qty / 365.0
+    if daily > 0:
+        dos_raw = effective / daily
+    else:
+        dos_raw = float('inf') if effective > 0 else 0.0
+    try:
+        import modules.inventory as inventory
+        bucket = inventory._bucket(dos_raw, float(on_hand), qty)
+    except Exception:                                                  # noqa: BLE001
+        bucket = None
+    return (None if dos_raw == float('inf') else round(float(dos_raw), 0)), bucket
+
+
+def _rescope_inventory(e, share, incoming=None):
     """`(qty_ltm, dos, bucket)` recomputed for ONE business unit's sales rate.
 
     The formulas are `inventory.sku_inventory`'s, applied to a BU-shaped numerator — NOT a second
@@ -328,17 +368,11 @@ def _rescope_inventory(e, share):
     if on_hand is None:
         return None, None, None          # no inventory row for this SKU: blank, never zero
     qty = float(e.get("qty_ltm") or 0.0) * float(share or 0.0)
-    daily = qty / 365.0
-    if daily > 0:
-        dos_raw = on_hand / daily
-    else:
-        dos_raw = float('inf') if on_hand > 0 else 0.0
-    try:
-        import modules.inventory as inventory
-        bucket = inventory._bucket(dos_raw, on_hand, qty)
-    except Exception:
-        bucket = None
-    return qty, (None if dos_raw == float('inf') else round(float(dos_raw), 0)), bucket
+    # ⭐ THE FORMULA MOVED TO `_dos_with_inbound` (owner 2026-08-19) so the scoped and consolidated
+    # paths cannot answer days-of-supply differently. Only the NUMERATOR is BU-shaped: `qty` is
+    # this unit's share of LTM units, while the shelf and the inbound are one warehouse's.
+    dos, bucket = _dos_with_inbound(on_hand, incoming, qty)
+    return qty, dos, bucket
 
 
 def _catalogue_by_code():
@@ -405,6 +439,14 @@ def pool(team_id=None, t=None):
     tiers, _tier_report = products.tier_prices_by_code(_prods)
     packs, _pack_report = products.packagings_by_code(_prods)
     cat = _catalogue_by_code()
+    # ⭐ THE BUY LIST'S DEMAND HORIZON (owner ruling 2026-08-19). BU-shaped through `team_id`, the
+    # same way the revenue columns are: a Fisch reader's reorder quantity must answer what FISCH
+    # will sell. Degrades to `{}` on a read failure, matching every other column source here — a
+    # blank cover gap is honest, a product grid that will not render is not.
+    try:
+        fwd_demand, _fwd_report = products.forward_demand_by_code(t=t, team_id=team_id)
+    except Exception:                                                  # noqa: BLE001
+        fwd_demand, _fwd_report = {}, {"error": "forward demand unavailable"}
     # The LEFT side of the join, indexed by the same code key. ⛔ A code here that the catalogue
     # does not carry belongs to a product no ACTIVE record claims — archived, and R12 keeps those
     # out. `validate()` asserts that of Odoo rather than assuming it, and reports the revenue
@@ -478,10 +520,18 @@ def pool(team_id=None, t=None):
             "first_cost": s.get("first_cost"),
         })
         e = inv.get(code) or {}
+        # ⭐⭐ OWNER 2026-08-19: *"Days of supply field should INCLUDE inbound quantities."* Read
+        # here rather than in the cover-gap block below, because `dos` now needs it too.
+        incoming = meta.get("incoming")
         if consolidated:
-            qty_ltm, dos, bucket = e.get("qty_ltm"), e.get("dos"), e.get("bucket")
+            # ⛔ RECOMPUTED, NOT `e['dos']`. `inventory.sku_inventory` returns a shelf-only
+            # days-of-supply and knows nothing about purchase orders; taking its figure here would
+            # ship the pre-ruling number under the new column description.
+            qty_ltm = e.get("qty_ltm")
+            dos, bucket = _dos_with_inbound(e.get("on_hand"), incoming, qty_ltm)
         else:
-            qty_ltm, dos, bucket = _rescope_inventory(e, bu_share.get(code, _DEFAULT_SHARE))
+            qty_ltm, dos, bucket = _rescope_inventory(
+                e, bu_share.get(code, _DEFAULT_SHARE), incoming)
         row.update({
             # UNSCOPED on purpose (owner 2026-08-11): one warehouse, no per-brand shelf.
             "on_hand": e.get("on_hand"),
@@ -512,32 +562,43 @@ def pool(team_id=None, t=None):
         # this repo has the scar already (wave 17: archiving `ar` "would have DELETED the
         # proof"). Two comparisons per SKU is what that costs.
         #
-        # ⭐ READS THE SCOPED `dos`, NOT `e['dos']`. On a Fisch pull the cover gap must answer
-        # "does the shelf outlast a reorder AT FISCH'S RATE" — reading the consolidated figure
-        # here would print a buy signal computed from both units' velocity beside a days-of-supply
-        # computed from one, and the two columns would disagree on the same row.
+        # ⭐ BU-SHAPED THROUGH THE DEMAND READ, not through `dos`. This block no longer divides by
+        # days-of-supply at all — `forward_demand_by_code` took `team_id`, so on a Fisch pull the
+        # cover gap already answers "does the stock outlast a reorder AT FISCH'S RATE". The rule
+        # the old comment protected still holds: never mix one unit's velocity with another's.
         # ⭐⭐ OWNER 2026-08-19 — INBOUND COUNTS AS STOCK FOR THE COVER GAP. Verbatim: *"Cover gap
         # day also should INCLUDE the incoming SKUs so it assumes those as stock even though its
         # inbound"*, and *"we need the 'Cover gap (units)' basically tell us how much to buy"*.
         #
-        # ⛔ `dos` AND `stock_bucket` DELIBERATELY DO NOT MOVE. They answer "what is on the shelf",
-        # which is the question dead-stock, excess and overstock are built on; folding inbound into
-        # them would change the Inventory module's meaning from a buy-list request. So a row can
-        # honestly read `dos 5, lead 30, cover gap +12` when 900 units are on the water, and the
-        # two columns' own descriptions say which is which.
+        # ⭐⭐ `dos` NOW COUNTS INBOUND TOO (owner, 2026-08-19), so the shelf figure behind this
+        # gap and the one behind Days of supply are THE SAME NUMBER. The earlier split, where only
+        # the cover gap counted inbound, is reversed. ⚠ What still differs between the two columns
+        # is the RATE, not the stock: `dos` divides by the trailing LTM rate, the cover gap by the
+        # forward 8-month forecast, so they still disagree on a seasonal SKU. Both say so in their
+        # own descriptions.
+        # ⚠ The INVENTORY module is untouched: `sku_inventory` is consumed only by this grid, and
+        # the overstock/dead-stock dashboards read `_enrich`'s own row-level `dos`, a separate path.
         #
-        # ⚠ THE VELOCITY BASIS IS UNCHANGED AND IS **TRAILING** TWELVE MONTHS, not a forward
-        # projection. `daily` here is the same `qty_ltm / 365` that produced `dos` upstream, so the
-        # new columns cannot disagree with the old one about how fast the SKU moves. The owner
-        # described the existing column as "based on the next 8 months Unit sales"; it is not, and
-        # that is REPORTED rather than quietly repaired — changing the basis in the same edit that
-        # adds inbound would make it impossible to tell which change moved which number.
+        # ⭐⭐ THE VELOCITY BASIS IS FORWARD 8 MONTHS (owner ruling, 2026-08-19). The owner
+        # described the cover gap as *"based on the next 8 months Unit sales"*; it was a TRAILING
+        # twelve-month rate, and asked to choose, they ruled forward. `products.forward_demand_by_
+        # code` is a SEASONAL read (the same 8 calendar months a year ago), which matters for a
+        # floral wholesaler whose year is Valentine's, Mother's Day and Christmas: a flat LTM rate
+        # spreads those peaks evenly and understates exactly the months a buyer is ordering for.
+        #
+        # ⛔ `dos` STILL USES THE LTM RATE, and the difference is deliberate rather than an
+        # oversight. `dos` and `stock_bucket` feed dead-stock and overstock, which ask "how long
+        # will what is on the shelf last at the rate it has been moving" — a backward-looking
+        # question. The cover gap asks "will it last until the reorder lands", which is forward.
+        # Both columns say which basis they use in their own descriptions.
         lead = s.get("lead_days")
-        # ⚠ FROM THE CATALOGUE ROW (`meta`), NOT THE INVENTORY ROW (`e`). Both live on this SKU
-        # and only one of them was read from Odoo's product record.
-        incoming = meta.get("incoming")
+        # ⚠ `incoming` came from the CATALOGUE row (`meta`) above, not the inventory row (`e`):
+        # both live on this SKU and only one was read from Odoo's product record.
         row["incoming"] = incoming
-        daily = (qty_ltm / 365.0) if isinstance(qty_ltm, (int, float)) and qty_ltm > 0 else None
+        fwd = fwd_demand.get(code)
+        row["demand_fwd"] = round(fwd) if isinstance(fwd, (int, float)) and fwd > 0 else None
+        daily = (fwd / float(products.FORWARD_DAYS)) if isinstance(fwd, (int, float)) \
+            and fwd > 0 else None
         on_shelf = row["on_hand"]
         effective = ((on_shelf or 0.0) + (incoming or 0.0)
                      if isinstance(on_shelf, (int, float)) else None)
@@ -956,6 +1017,66 @@ def validate(team_id=None, t=None):
                        "po_lines": po_report, "uom_note": "purchase uom vs stock uom; the shipped "
                        "column is in the STOCK uom so it can be added to On hand."},
         })
+
+        # ⭐⭐ OWNER 2026-08-19 — `dos` COUNTS INBOUND, and this is the leg that proves it rather
+        # than trusting the expression. Two halves, because either alone is passable by accident:
+        #   (a) EVERY row's dos re-derives from (on_hand + incoming) / (qty_ltm / 365), and
+        #   (b) at least one row's dos is STRICTLY GREATER than the shelf-only figure would be.
+        # Without (b) the check stays green if `incoming` silently becomes 0 everywhere — the
+        # column would read exactly as it did before the ruling, and nothing would say so.
+        moved, wrong = 0, []
+        for r in rows:
+            oh, inc, q = r.get("on_hand"), r.get("incoming") or 0.0, r.get("qty_ltm")
+            if oh is None or not isinstance(q, (int, float)) or q <= 0:
+                continue
+            want = round((float(oh) + float(inc)) / (float(q) / 365.0), 0)
+            if r.get("dos") != want:
+                wrong.append(r["code"])
+            if inc > 0 and want > round(float(oh) / (float(q) / 365.0), 0):
+                moved += 1
+        checks.append({
+            "check": "Days of supply counts INBOUND units: every row re-derives from "
+                     "(on_hand + incoming) / daily, and inbound demonstrably moves it",
+            "ours": moved, "theirs": len([r for r in rows if (r.get("incoming") or 0) > 0]),
+            "ok": not wrong and moved > 0,
+            "detail": {"rows_not_re_deriving": wrong[:10], "n_wrong": len(wrong),
+                       "rows_where_inbound_raised_dos": moved,
+                       "note": "a 0 in 'rows_where_inbound_raised_dos' means the column reads as "
+                               "it did BEFORE the ruling, which is the silent-regression case."},
+        })
+
+        # ⭐ RULE 8 — the FORWARD demand basis against a DIRECT Odoo read_group over the same
+        # reference window. ⛔ The oracle re-reads Odoo itself rather than re-calling
+        # `forward_demand_by_code`, which would reconcile the number with itself — the self-sealing
+        # shape this function already carries a scar for.
+        fwd_map, fwd_report = products.forward_demand_by_code(t=t, team_id=team_id)
+        _rf, _rt = fwd_report["reference_window"]
+        # ⚠ `include_excluded_partners=True` HERE TOO, or the oracle would measure a narrower
+        # universe than the column and go red on the Amazon units the owner asked to include.
+        direct = O.read_group('sale.order.line',
+                              O.sale_line_domain(_rf, _rt, team_id, extra=products._NO_SVC,
+                                                 all_channels=True),
+                              ['product_uom_qty:sum'], [], lazy=False)
+        theirs_u = float((direct[0] or {}).get('product_uom_qty') or 0.0) if direct else 0.0
+        # ⚠ A BRACKET, NOT AN EQUALITY, and the reason is in the number itself: the shipped total
+        # is the seasonal rows PLUS the LTM-fallback rows scaled onto the horizon, and the fallback
+        # rows are by definition SKUs that window never saw. Asserting equality would go red
+        # forever on a difference the design creates on purpose.
+        shipped = sum(float(r["demand_fwd"]) for r in rows
+                      if isinstance(r.get("demand_fwd"), (int, float)))
+        checks.append({
+            "check": f"Forward {products.FORWARD_MONTHS}-month demand basis: the shipped forecast "
+                     f"ties to Odoo units over its own reference window {_rf} to {_rt}",
+            "ours": round(shipped, 0), "theirs": round(theirs_u, 0),
+            # The shipped total is seasonal rows PLUS scaled fallback rows, so it cannot equal the
+            # window total exactly; what must hold is that it is a real, bounded fraction of it and
+            # that the window itself returned units at all.
+            "ok": theirs_u > 0 and 0.5 * theirs_u <= shipped <= 1.5 * theirs_u,
+            "detail": {**fwd_report,
+                       "skus_with_a_forecast": len([r for r in rows if r.get("demand_fwd")]),
+                       "note": "shipped = seasonal rows + LTM-fallback rows scaled to the "
+                               "horizon, so it brackets rather than equals the window total."},
+        })
     checks.extend(validate_measures(t=t, team_id=team_id,
                                     pool_codes={r["code"] for r in rows}))
     checks.extend(validate_price_and_unit_cells(rows))