WC Inventory Overview 1.43.2

WC Inventory Overview 1.43.2 — release notes

Changed

• Automatic updates now come from a private update server via the bundled
  Plugin Update Checker v5
  library (lib/plugin-update-checker/). The bespoke GitHub-release updater
  (includes/class-github-updater.php) has been removed.
• The update check runs only when the PRIVATE_UPDATE_SERVER constant is defined
  in wp-config.php (admin/cron only).
• Added a CI workflow that uploads the release ZIP to the update server on each
  v* tag.

Install

Deploy wc-inventory-overview 1.43.2 / tag v1.43.2.

Rollback: 1.43.1 / v1.43.1.

WC Inventory Overview 1.43.1

WC Inventory Overview 1.43.1 — Plugins screen links

Release Date: August 2026
Plugin Version: 1.43.1
Database Version: 11 (unchanged from v1.43.0)

Overview

Adds Overview and Settings links on the WordPress Plugins screen for quick access to Inventory & Profit admin.

What's new

• Overview — opens the Inventory Overview tab (edit_products or higher).
• Settings — opens plugin settings (manage_woocommerce).

Upgrade

From	Action
1.43.0	Use Plugins → Update or upload this ZIP
Older	Upgrade normally; no schema changes since v1.42.0

Install

1. Download wc-inventory-overview-1.43.1.zip from this release.
2. Upload via Plugins → Add New → Upload or extract to wp-content/plugins/wc-inventory-overview/.

Full changelog: CHANGELOG.md

WC Inventory Overview 1.43.0

WC Inventory Overview 1.43.0 — Apply Replenishment Defaults to Variations

Release Date: August 2026
Plugin Version: 1.43.0
Database Version: 11 (unchanged from v1.42.0)

Overview

This release adds bulk Set/Clear for replenishment defaults on a variable product’s variations, using WooCommerce’s existing variation bulk-edit workflow.

You can apply a preferred supplier and/or a default replenishment quantity to all child variations in one action — or clear those fields in bulk. Each variation still keeps its own values afterward and remains independently editable.

This is copy/apply now, not inheritance. There is no ongoing parent-to-variation link, and the variable parent itself does not receive these replenishment defaults from this workflow.

What's new

Variation bulk apply (M26)

• Set preferred supplier across all variations of the product being edited (choose from active eligible suppliers).
• Clear preferred supplier on all variations.
• Set default replenishment quantity across all variations.
• Clear default replenishment quantity on all variations.
• Actions appear in the classic WooCommerce variation bulk-edit menu on the product edit screen.
• After apply, each variation keeps its own meta and can still be edited individually (same as before).

Product limit

• Bulk apply supports products with at most 100 variations. Products with more than 100 variations must have defaults edited per variation.

What this does not do

• Does not create Purchase Orders.
• Does not change stock quantities or product costs.
• Does not invent parent-level replenishment defaults or inheritance rules.
• Does not change Planning or Bulk Draft PO behavior from v1.42.0 — those features continue to use each variation’s own stored defaults.

What to expect after upgrading

• No database change — DB_VERSION stays at 11. No migration runs.
• Existing preferred-supplier and default-quantity settings on products/variations are unchanged until you run a bulk action.
• Inventory Overview, Planning, and Draft PO workflows from earlier releases remain available.

Compatibility

• Requires PHP 7.4+
• Requires WordPress 6.0+
• Compatible with WooCommerce 6.0–8.5+
• HPOS-compatible (High-Performance Order Storage)

Upgrade notes

Back up as you normally would, then upgrade. Because there is no schema change, this is a plain code update.

Roadmap note

v1.43.0 completes the currently scheduled replenishment roadmap. Further ideas (for example advisory concurrency UI, hiding unused parent-level fields, or forecasting) remain optional backlog only and are not scheduled as a next numbered milestone.

WC Inventory Overview 1.42.0

WC Inventory Overview 1.42.0 — Replenishment Planning & Bulk Draft PO Creation

Release Date: August 2026
Plugin Version: 1.42.0
Database Version: 11 (unchanged from v1.40.0)

Overview

This release completes the replenishment workflow started in v1.40.0. You can now review every item that currently needs reordering in one Planning screen, then create supplier-grouped Draft Purchase Orders from the lines you select — with quantities you control.

You stay in control. Nothing is ordered automatically. Drafts are created only when you explicitly confirm. Existing Purchase Order screens and the full place/receive workflow are unchanged.

Note: Development version 1.41.0 (Planning screen alone) was never published. This train ships once as v1.42.0.

What's new

Replenishment Planning (M24)

• Planning tab under Purchasing — a catalog-wide (or selection-scoped) read-only plan of current needs-reorder items.
• Grouped by supplier with each supplier’s currency shown separately (never blended).
• Suggested quantities from your configured default replenishment quantity when set; otherwise shown as zero for you to decide.
• Unresolved section when no single eligible supplier can be determined (no history, or multiple possible suppliers).
• Scoped planning from Inventory Overview via a bulk action that opens Planning for the selected items only.

Bulk Draft PO Creation (M25)

• On the same Planning tab, users who can edit Purchase Orders see checkboxes (default unchecked) and editable quantities.
• Create Draft Purchase Orders builds one Draft PO per resolved supplier group from your selection.
• The server always re-checks needs-reorder status, supplier, and product identity at confirm time — the browser only submits which lines you selected and the quantities you entered.
• Duplicate / concurrent protection for this workflow: same-form replay is blocked; overlapping commits on the same item are serialized; items that already have a draft/placed/partially-received PO line are skipped rather than duplicated.
• Partial success: if one supplier group cannot be created, other groups in the same confirm can still succeed. You see a clear created / failed / skipped summary.
• Drafts keep unit cost 0 and no invented expected date; currency comes from the supplier; each PO notes it was created from Replenishment Planning.

Why this matters to you

• See the full replenishment picture before creating any PO.
• Turn a reviewed plan into real Draft POs without re-typing lines per supplier.
• Keep the existing PO review / place / receive process as the path to stock.

Visibility

• Viewing Planning requires Purchase Order view access.
• Creating Draft POs from Planning requires Purchase Order edit access. View-only users still see the read-only plan.

What to expect after upgrading

• No database change — DB_VERSION stays at 11. No migration runs.
• No automatic ordering and no background jobs for purchasing.
• Existing Purchase Orders, suppliers, and Inventory Overview behavior remain as in v1.40.0; Planning and bulk draft creation are additive.

Compatibility

• Requires PHP 7.4+
• Requires WordPress 6.0+
• Compatible with WooCommerce 6.0–8.5+
• HPOS-compatible (High-Performance Order Storage)

Upgrade notes

Back up as you normally would, then upgrade. Because there is no schema change, this is a plain code update. Intermediate development version 1.41.0 was never tagged or published.

Known limitations

• Advisory locks used during bulk commit serialize other bulk commits on the same catalog items; they do not lock out unrelated stock or PO edits made outside this workflow.
• A deliberate later reorder after a prior draft has been received/cancelled/closed_short remains allowed when the item again needs reordering — that is intentional.

WC Inventory Overview 1.40.0

WC Inventory Overview 1.40.0 — Reorder-to-Draft Purchasing Workflow

Release Date: August 2026
Plugin Version: 1.40.0
Database Version: 11 (unchanged from v1.38.0)

Overview

This release closes the loop on the plugin's existing "Needs reorder" signal (v1.38.0): a low-stock item that genuinely needs reordering can now go straight to a draft Purchase Order, prefilled from the supplier information the plugin already knows about it — with an optional layer of merchant-set defaults to make repeat purchasing even faster.

You stay in control at every step. Nothing is ever ordered automatically. The new "Create Draft PO" action only opens the existing New Purchase Order screen with some fields pre-filled; you review, edit anything you like, and submit it yourself exactly as you always have.

What's new

• "Create Draft PO" quick action — on any Inventory Overview row already showing "Needs reorder," a new button takes you straight to a New Purchase Order form for that item, with the product and (where clear) a supplier already selected.
• Automatic supplier suggestion from purchase history — if an item has been ordered from exactly one supplier before, that supplier is pre-selected. If it's been ordered from more than one, or never, you'll see a short note and pick one yourself — nothing is guessed.
• Preferred supplier — you can now set a specific "go-to" supplier for any product or product variation, on the product's own edit screen. When set, it's used directly instead of the purchase-history guess. If that supplier is later archived or merged into another, the form safely falls back to the purchase-history behavior and lets you know why — your saved preference is never silently lost.
• Default replenishment quantity — you can also set a standard reorder quantity for any product or variation, so the New PO form starts with the amount you usually order instead of a plain default of 1. You can always change it before submitting.
• Product and variation defaults are independent. Each variation keeps its own preferred supplier and quantity — setting one on a variation never affects its parent product or sibling variations.

Why this matters to you

• Fewer clicks for repeat purchasing. Once you've set a preferred supplier and usual quantity for your regular items, reordering them is close to a two-click action: click "Create Draft PO," review, submit.
• Nothing happens without your review. The quick action never creates a Purchase Order by itself — it only opens the existing form, pre-filled. Every draft is still created only when you submit the form, through the exact same validated purchasing pipeline as before.
• Safe by default. An out-of-date preferred supplier (archived or merged) is never silently used — you'll see a clear notice and a sensible fallback instead.
• Nothing is removed. Every existing Purchase Order, Supplier, and Inventory Overview screen behaves exactly as it did in v1.38.0, with this new action added alongside.

Visibility

The "Create Draft PO" quick action is visible to users who can manage Purchase Orders (the same access level already required to create one manually). The new preferred-supplier and default-quantity fields on the product edit screen are visible to anyone who can edit that product — the same access level WooCommerce already uses for all other product fields.

What to expect after upgrading

• No database change — DB_VERSION stays at 11. The upgrade is a plain code swap with nothing to migrate. The two new settings (preferred supplier, default quantity) are stored as ordinary product data, the same way WooCommerce stores any other product field.
• No new settings to configure and no migration step to run. Every existing screen, filter, bulk action, and workflow behaves exactly as it did in v1.38.0 until you choose to set a preferred supplier or default quantity somewhere.
• Existing Purchase Orders, Suppliers, and their history are completely unaffected.

Compatibility

• Requires PHP 7.4+
• Requires WordPress 6.0+
• Compatible with WooCommerce 6.0–8.5+
• HPOS-compatible (High-Performance Order Storage)

Upgrade notes

Because this release changes no schema and no existing stored data, it carries the same low-risk profile as a typical plugin update: back up as you normally would before any update, then upgrade normally. No feature-specific migration or setup is required — the new fields simply appear, unset, on your existing products.

Known limitations

Purchase quantity suggestions are always a fixed number you set yourself — the plugin does not forecast demand, sales velocity, or lead time, and does not calculate a target stock level. Supplier suggestions come only from your own explicit choice or from this item's own purchase history; the plugin never learns or infers a preference on its own. Setting a preferred supplier or quantity for many product variations at once is not included in this release.

Additional information

For questions or issues, see the plugin's Settings tab and the built-in admin help sections.

---

This release bundles two milestones (M22, M23) as one feature train, following the same release pattern used for the M9–M12 (v1.29.0), M13–M15 (v1.32.0), and M18–M19 (v1.36.0) trains. Intermediate development version 1.39.0 (M22 alone) was never tagged or published. It builds directly on v1.38.0. Previous releases (M0–M8 GA, M9–M12 feature train, M13–M15 feature train, M16, M17, M18–M19 feature train, M20, M21) remain in their respective version tags.

WC Inventory Overview 1.38.0

WC Inventory Overview 1.38.0 — Position-Aware Reorder Signal

Release Date: August 2026
Plugin Version: 1.38.0
Database Version: 11 (unchanged from v1.37.0)

Overview

This release adds a new Reorder Signal to the plugin's existing Low Stock indicator. Until now, "Low stock" only looked at current on-hand quantity — a product could show as low stock even though a purchase order already on its way would cover it. This release tells you, for every low-stock line, whether it's already covered by incoming supply or still genuinely needs a reorder.

Every screen you already use looks the same, with new information added alongside. No existing button, filter, badge, column, or workflow was removed or changed — the new signal appears next to the information you already had.

What's new

• "Needs reorder" and "Covered by incoming" badges on the Inventory Overview screen, shown next to the existing Low Stock badge for any line that's already low — never in place of it. For variable products, each variation is judged on its own; the parent row shows how many of its variations need reordering.
• New "Needs Reorder" summary card on the Inventory Overview screen.
• New "Needs Reorder" KPI on the Dashboard, alongside the existing Low Stock Items KPI.
• Two new columns — Incoming and Reorder status — on the Dashboard's "Recent Low Stock Items" table.

Why this matters to you

• Fewer false alarms. If a purchase order is already inbound and large enough to cover a low-stock line, you'll see "Covered by incoming" instead of an unqualified low-stock warning — so you don't reorder something you've already reordered.
• A clearer to-do list. The new "Needs Reorder" counts (on both the Dashboard and Inventory Overview) show only the lines that genuinely need attention, separate from the broader Low Stock count.
• Nothing is removed. The existing Low Stock badge, count, and behavior are exactly as before, on every screen.
• No purchasing action happens automatically. This release only shows information — it never creates, modifies, or suggests a purchase order on your behalf.

Visibility

The new Reorder Signal information (badges, cards, KPI, and columns) is visible to users who can manage WooCommerce (Shop Manager / Administrator). If your account only has product-editing access, you'll continue to see the Inventory Overview and Dashboard screens exactly as they looked before this release.

What to expect after upgrading

• No database change — DB_VERSION stays at 11. The upgrade is a plain code swap with nothing to migrate.
• No new settings to configure and no migration step to run.
• Every existing screen, filter, bulk action, inline stock edit, CSV export, restock form, and cost adjustment behaves exactly as it did in v1.37.0.

Compatibility

• Requires PHP 7.4+
• Requires WordPress 6.0+
• Compatible with WooCommerce 6.0–8.5+
• HPOS-compatible (High-Performance Order Storage)

Upgrade notes

Because this release changes no schema and no stored data, it carries the same low-risk profile as a typical plugin update: back up as you normally would before any update, then upgrade normally.

Known limitations

The Reorder Signal is based on your configured low-stock threshold and currently open purchase orders — it does not forecast future demand or sales velocity. Creating a purchase order directly from a "Needs reorder" line is not included in this release and may be considered for a future update.

Additional information

For questions or issues, see the plugin's Settings tab and the built-in admin help sections.

---

This release is a standalone milestone (M21), following the same release pattern used for M16 (v1.33.0), M17 (v1.34.0), and M20 (v1.37.0). It builds directly on v1.37.0. Previous releases (M0–M8 GA, M9–M12 feature train, M13–M15 feature train, M16, M17, M18–M19 feature train, M20) remain in their respective version tags.

WC Inventory Overview 1.37.0

WC Inventory Overview 1.37.0 — Admin Controller Decomposition, Phase 3

Release Date: August 2026
Plugin Version: 1.37.0
Database Version: 11 (unchanged from v1.36.0)

Overview

This release is an internal admin-architecture improvement. It contains no new merchant-facing features, no workflow changes, and no schema migration. It completes the Admin Controller Decomposition project that began with M18/M19 (v1.36.0) by extracting the two remaining, mutation-bearing admin tabs — Inventory Overview and Restock / Cost Adjustment — into their own dedicated controller classes.

If you use this plugin day-to-day, you should not notice any difference after upgrading. Every screen, button, filter, bulk action, inline stock edit, CSV export, restock form, and cost adjustment behaves exactly as it did in v1.36.0.

What changed (internally)

• Inventory Overview tab — summary cards, table, filters/search, bulk actions (set draft, hide from catalog, mark in/out of stock), inline stock AJAX editing, and CSV export — extracted into WC_Inventory_Overview_Overview_Controller.
• Restock / Cost Adjustment tab — Quick Restock and Cost Adjustment sub-views, including their admin-post mutation handlers and the cost-adjustment preview AJAX endpoint — extracted into WC_Inventory_Overview_Restock_Controller.

This completes the reorganization started in v1.36.0 (M18: Dashboard/Settings; M19: Movements/Order Profit/Product Profitability). The plugin's former god-class admin controller is now primarily a composition root / routing shell that wires requests to dedicated controllers — it no longer contains tab-specific rendering or mutation logic itself.

Why this matters to you

• Behavior-preserving by design. Like M18/M19, this milestone was built characterization-tests-first: automated tests captured the exact existing behavior of Overview and Restock before any code moved, then verified identical behavior after the move. 94 milestone-specific automated tests were added to prove this.
• Mutation ownership unchanged. The actual business logic that mutates stock and cost data was not touched or moved: Restock_Service and Cost_Adjustment_Service remain the sole owners of restock and cost-adjustment mutations, exactly as before. Overview's bulk/inline mutations remain the same product-level operations, relocated verbatim into the new controller.
• No database change. DB_VERSION stays at 11 — there is nothing to migrate, and the upgrade is a plain code swap.
• No new integration surface. No new WordPress hooks, filters, REST endpoints, or capabilities were introduced.
• No new settings, fields, or options. Every screen's controls, defaults, and validation are unchanged.

What to expect after upgrading

• Inventory Overview and Restock / Cost Adjustment load and behave exactly as before, including bulk actions, inline stock editing, CSV export, Quick Restock, and Cost Adjustment.
• Dashboard, Settings, Inventory Movements, Order Profit, and Product Profitability are unaffected (already decomposed in v1.36.0).
• No manual action is required after upgrading. There is no new option to configure and no migration step to run.

Compatibility

• Requires PHP 7.4+
• Requires WordPress 6.0+
• Compatible with WooCommerce 6.0–8.5+
• HPOS-compatible (High-Performance Order Storage)

Upgrade notes

Because this release changes no schema and no stored data, it carries the same low-risk profile as a typical plugin update: back up as you normally would before any update, then upgrade normally. No feature-specific testing checklist is needed — this is not a new-capability release.

Known limitations

None new in this release. This milestone completes the Admin Controller Decomposition project tracked in the plugin's docs/architecture-audit.md; no further phases are planned under that project.

Additional information

For questions or issues, see the plugin's Settings tab and the built-in admin help sections.

---

This release is a standalone milestone (M20), following the same release pattern used for M16 (v1.33.0) and M17 (v1.34.0). It builds directly on the M18–M19 train (v1.36.0). Previous releases (M0–M8 GA, M9–M12 feature train, M13–M15 feature train, M16, M17, M18–M19 feature train) remain in their respective version tags.

WC Inventory Overview 1.36.0

WC Inventory Overview 1.36.0 — Admin Controller Decomposition, Phases 1–2

Release Date: August 2026
Plugin Version: 1.36.0
Database Version: 11 (unchanged from v1.34.0)

Overview

This release is an internal admin-architecture improvement. It contains no new merchant-facing features, no workflow changes, and no schema migration. It bundles two milestones (M18 and M19) that together reorganize how the plugin's admin screens are implemented internally, without changing what you see or how you use them.

If you use this plugin day-to-day, you should not notice any difference after upgrading. Every screen, button, filter, CSV export, and notice behaves exactly as it did in v1.34.0.

What changed (internally)

The plugin's main admin controller class had grown large over several years of feature additions, making it harder to test and safely extend. This release splits five of its seven admin tabs out into dedicated, independently-tested controller classes:

• M18 — Dashboard and Settings tabs extracted into WC_Inventory_Overview_Dashboard_Controller and WC_Inventory_Overview_Settings_Controller.
• M19 — Movements, Order Profit, and Product Profitability tabs extracted into a new WC_Inventory_Overview_Reporting_Controller.

Two tabs — Inventory Overview and Restock / Cost Adjustment — remain on the main controller for now and are unaffected by this release. They may be addressed in a future release; there is no committed timeline.

Why this matters to you

• Behavior-preserving by design. Both milestones were built characterization-tests-first: automated tests captured the exact existing behavior of each screen before any code moved, then verified byte-for-byte identical behavior after the move. 66 new automated tests were added specifically to prove this (36 characterization + 25 architecture-guard style checks across the two milestones, plus 30 targeted regression checks against everything else).
• No database change. DB_VERSION stays at 11 — there is nothing to migrate, and the upgrade is a plain code swap.
• No new integration surface. No new WordPress hooks, filters, REST endpoints, or capabilities were introduced. If you have custom code integrating with this plugin, nothing about that integration changes.
• No new settings, fields, or options. Every screen's controls, defaults, and validation are unchanged.

What to expect after upgrading

• Dashboard, Settings, Inventory Movements, Order Profit, and Product Profitability all load and behave exactly as before, including their CSV exports, screen options ("items per page"), filters, and notices.
• Inventory Overview and Restock / Cost Adjustment are entirely unaffected.
• No manual action is required after upgrading. There is no new option to configure and no migration step to run.

Compatibility

• Requires PHP 7.4+
• Requires WordPress 6.0+
• Compatible with WooCommerce 6.0–8.5+
• HPOS-compatible (High-Performance Order Storage)

Upgrade notes

Because this release changes no schema and no stored data, it carries the same low-risk profile as a typical plugin update: back up as you normally would before any update, then upgrade normally. No feature-specific testing checklist is needed — this is not a new-capability release.

Known limitations

• Two admin tabs (Overview, Restock / Cost Adjustment) are not yet part of this internal reorganization and remain on the original controller class. This is intentional scoping, not an oversight — see the plugin's docs/architecture-audit.md for the tracked follow-up.

Additional information

For questions or issues, see the plugin's Settings tab and the built-in admin help sections.

---

This release bundles two milestones (M18, M19) as one feature train, following the same release pattern used for the M9–M12 (v1.29.0) and M13–M15 (v1.32.0) trains. Intermediate development version 1.35.0 (M18 alone) was never tagged or published. Previous releases (M0–M8 GA, M9–M12 feature train, M13–M15 feature train, M16, M17) remain in their respective version tags.

WC Inventory Overview 1.34.0

WC Inventory Overview 1.34.0 — Supplier Merge

Release Date: August 2026
Plugin Version: 1.34.0
Database Version: 11 (migrated from v10)

Overview

This release introduces Supplier Merge — a controlled operation to consolidate redundant or duplicate supplier records while preserving all associated purchasing history, costs, and audit trails.

New Feature: Supplier Merge

What is Supplier Merge?

Suppliers can now be merged into another active supplier. This consolidation operation:

• Reassigns all Purchase Orders from the source supplier to the target supplier
• Reassigns all Goods Receipts from the source supplier to the target supplier
• Preserves historical snapshots — supplier name at the time of order/receipt remains unchanged
• Preserves inventory movements — all cost records, landed-cost allocations, and stock movements remain intact
• Does not overwrite target metadata — the target supplier's name, lead time, and other settings are never modified by the merge
• Permanently dissolves the source supplier — it becomes archived and cannot be reactivated
• Records audit history — every merge operation is logged with source/target, reassigned counts, timestamp, and who performed it

Using Supplier Merge

1. Navigate to Purchasing → Suppliers
2. Click the supplier name you wish to merge (source supplier)
3. If eligible, a "Merge Supplier" button appears on the supplier detail screen
4. Select a target supplier from the dropdown
5. Review the warning (the operation is irreversible)
6. Type the confirmation text to enable the submit button
7. Click "Merge"

The system verifies your confirmation server-side and processes the merge atomically.

What Moves, What Stays

Item	Behavior
Purchase Orders	Reassigned to target supplier; supplier snapshots remain unchanged
Goods Receipts	Reassigned to target supplier; supplier snapshots remain unchanged
Inventory Movements	Remain tied to their original costs/receipts; stock figures and valuations are unaffected
Expected Delivery Dates	Follow reassigned POs; end-customer messaging is unchanged
Supplier Spend/Stats	Reflect reassigned PO ownership; historical totals transfer
Source Supplier	Archived; cannot be reactivated; cannot be selected for new operations

Eligibility Rules

• Source supplier must be active (not already merged or archived)
• Target supplier must be active (not merged, archived, or the source itself)
• A supplier cannot be selected if it has already been merged into another supplier

Irreversible Operation — Important

⚠️ CODE ROLLBACK DOES NOT UNDO COMPLETED SUPPLIER MERGES.

A completed supplier merge is irreversible at the product level by design. If you rollback plugin code from v1.34.0 to v1.33.0:

• The schema additions (new columns, tables) remain in your database
• Previously completed merges remain — reassigned POs/GRs stay reassigned
• The dissolved source supplier remains archived
• There is no automatic "undo merge" feature in the plugin

Recommendation: Take a database backup before your first supplier merge in production. In the unlikely event you need to undo a completed merge, restore the database backup; do not attempt manual SQL corrections on uncertain state.

Server-Side Security

The merge operation:

• Requires explicit server-side confirmation of the selected target
• Uses nonces/tokens to prevent CSRF
• Enforces atomic transactions — if any part fails, all changes roll back
• Protects against concurrent new Purchase Order/Goods Receipt creation against a dissolving supplier
• Is logged in the audit trail

Database Schema Changes

Version Migration (v10 → v11)

The wc_io_db_version option is automatically upgraded to 11 on plugin activation or update.

New Column:

• wc_io_suppliers.merged_into_supplier_id (nullable INT) — tracks which supplier this one was merged into

New Table:

• wc_io_supplier_merges — audit log of all merge operations
  • Columns: id, source_supplier_id, target_supplier_id, purchase_orders_reassigned, goods_receipts_reassigned, performed_by_user_id, performed_at

All historical data is preserved; no data is deleted during the schema upgrade.

Compatibility

• Requires PHP 7.4+
• Requires WordPress 6.0+
• Compatible with WooCommerce 6.0–8.5+
• HPOS-compatible (High-Performance Order Storage)

Known Limitations

• A supplier can only be merged once (into one target); subsequent merges of that target are not supported within the same merge operation
• The merge operation requires a network roundtrip; very large operations (1,000s of POs/GRs) may take several seconds
• Concurrent new PO/GR creation against a dissolving supplier is protected, but timing is tight — avoid manual splits during an ongoing merge in production

Upgrade Notes

Before upgrading to v1.34.0 in production:

1. Take a full database backup (recommended for all updates, mandatory if you plan to use the merge feature)
2. Test the merge feature in a staging environment first
3. Document your supplier hierarchy before performing any merges

After upgrade:

1. Verify the schema upgrade completed: check Settings for the new "Supplier Merge" confirmation option
2. Test the Supplier Merge workflow on a disposable test supplier pair before using it on production data
3. The merge feature is available immediately after activation; no additional configuration is needed

Additional Information

For questions or issues, see the plugin's Settings tab and the built-in admin help sections.

---

This is a standalone release. Previous releases (M0–M8 GA, M9–M12 feature train, M13–M15 feature train, M16 PO Expected-Date & Delay Transparency) remain in their respective version tags.

WC Inventory Overview 1.33.0

WC Inventory Overview v1.33.0

Release: PO Expected-Date & Delay Transparency (M16)
Release Date: 2026-08-11
Schema Version: 10 (unchanged)
Database Migration: None

Overview

Milestone M16 introduces three focused read-mostly surfaces for improving transparency around expected delivery dates and purchase order delays. No schema changes, no domain-level mutations, and zero impact on purchase order, goods receipt, or inventory position business logic.

Features

A. PO Expected-Date Suggestion Provenance

When creating a new Purchase Order, the pre-filled Expected Date suggestion now displays its source:

• Observed delivery history: "Suggested from this supplier's delivery history (N orders, avg D days)." — drawn from the supplier's historical on-time performance tracked across closed purchase orders, including the sample size and average historical days.
• Configured supplier default: "Suggested from configured supplier default (D days)." — falls back to the supplier's configured lead-time setting when no historical data exists.
• No source available: No suggestion message appears when neither observed nor configured defaults are available.

The suggestion remains fully advisory — merchants may freely override the expected date when creating the PO, and once manually edited, the hint disappears and is not restored on future edits.

Implementation details:

• Expected_Date_Suggestion_Service returns sample_count and average_days (both null when source is not observed)
• Both values derive from existing supplier statistics; no additional queries are performed
• The suggestion algorithm itself is unchanged; only the transparency layer is new

B. PO Delay Grace-Days Setting

A new Settings field under the Purchasing section allows configuration of the purchase order delay grace period:

Field: "PO delay grace period (days)"
Valid range: 0–365 (both inclusive; 0 is a valid grace period)
Behavior:

• Invalid or missing input always preserves the existing stored value — no silent coercion to a default
• Non-numeric values, decimal numbers, scientific notation, and out-of-range values (<0 or >365) leave the setting untouched
• A clean integer within 0–365 is saved exactly as submitted

Implementation details:

• Exposes the existing WC_Inventory_Overview_PO_Delay::OPTION_GRACE_DAYS option through the UI
• Uses Settings::maybe_save_po_delay_grace_days() with strict validation (no absint()-style coercion)
• Delay calculation itself is unchanged; this is a UI exposure of an existing, already-functional setting

C. Inventory Position Drilldown Columns

When drilling down into the expected-delivery details for a line item in the Inventory Position grid, the detailed supply list now includes two additional columns:

New columns:

1. Supplier — the supplier name at the time the purchase order was placed (immutable snapshot, survives supplier archive/rename)
2. Status — the purchase order status (draft, placed, partially received, received, cancelled, closed short)

Column order (fixed):

1. PO number
2. Supplier
3. Status
4. Outstanding
5. Expected date
6. Confidence
7. Delayed

Implementation details:

• Both columns source from the existing Purchase_Orders query; no additional queries are performed
• Supplier uses the historical supplier_name_snapshot column to ensure deleted/archived suppliers do not break the display
• Status uses the canonical PO_Statuses::label() formatter (the same label map governing the Purchasing screens)

What Did NOT Change

• No schema change — DB_VERSION remains at 10; all new data is presentation-time derived
• No database migration — no new columns, no table changes, no schema upgrade step
• No PO/receipt/stock/cost mutations — one existing settings-option write only (po_delay_grace_days)
• No new public API — all new services are Internal (D16); no public hooks or filters
• No new capability — existing manage_woocommerce gate governs all access
• No storefront impact — expected-delivery rendering remains unchanged; customers see no difference
• Backward compatible — the suggestion provenance fields are optional in the return shape; merchants relying on just days and source see no change

Rollback

Because DB_VERSION remains 10 and no schema migration occurs, rollback is code-only:

1. Deactivate v1.33.0
2. Activate v1.32.0
3. No database cleanup, restoration, or reversal required
4. The grace-days option value may remain stored while v1.32.0 is active; it is safe and expected

Testing

• ✅ All unit tests pass (362 tests / 1916 assertions)
• ✅ M1–M16 focused suite passes (667 tests / 3126 assertions)
• ✅ Integration suite passes (316 tests / 1252 assertions)
• ✅ Architecture guards pass (sole-mutator, query-count, schema-shape assertions)
• ✅ Performance baseline maintained (expected-date suggestion: 1 query regardless of supplier count; position drilldown: ≤2 queries)
• ✅ PHP lint, parallel lint, and build verification pass

Related Documentation

• Implementation Plan: docs/milestones/m16-implementation-plan.md
• Release Readiness: docs/checklists/m16-release-readiness.md
• Rollback Plan: docs/rollback-plan.md
• Admin Guide — Suppliers: docs/admin-guide-suppliers.md (Suggestion Provenance section)
• Admin Guide — Purchase Orders: docs/admin-guide-purchasing-purchase-orders.md
• Validation Checklist: docs/checklists/validation-checklist.md