Most Quantity Discounts plugins use product postmeta with a serialised array of tier objects (min quantity, discount type, discount amount). SleekView reads the array and flattens it into one row per tier so the data behaves like a normal table while the plugin's resolution logic stays untouched.

Yes if the plugin records applied-tier data on order line items. SleekView joins wc_order_items by product id and aggregates Hit Count and Last Hit columns. Filter Hit Count equals zero or Last Hit older than ninety days to find zombie thresholds.

Yes. Variations are product_variation posts with their own postmeta. SleekView can show thresholds per variation (one row per variation per tier) or aggregate to the parent product depending on the workflow.

Yes. Filter to products with zero thresholds set, then run a bulk action that writes a default tier set (e.g. 3 = 5%, 6 = 10%, 12 = 15%) to each via the product CRUD. Each row triggers update hooks normally so price caches invalidate as expected.

Yes. HPOS changes order storage (wc_orders instead of shop_order posts) but product storage stays in wp_posts with postmeta. Quantity discount data is unaffected. SleekView reads both schemas correctly.

Yes via a union view. Product-level quantity thresholds and cart-level conditional rules each get their own view from their respective storage, and a discount dashboard unions both with a Source column. The resolution order remains whatever the plugins decide at runtime.

Some Quantity Discounts plugins allow per-role tiers. The role field on the tier object surfaces as a column so wholesale-only tiers are distinguishable. Filter the view to one role at a time for a clean per-segment audit.

Reading postmeta rows is indexed by post_id and meta_key. Flattening tier arrays happens after rows return, so the cost is bounded by the number of products with thresholds, not the total SKU count. Catalogues into the thousands load sub-second on the typical pricing-manager view.