Direct answer: A procurement demand forecasting and forecast-error management page is not "run a formula on sales". The page should state: how forecasting relates to S&OP/demand review, material planning/MRP, budget, supplier capacity and safety stock; forecast level/granularity/period (SKU/category/customer/region, weekly/monthly, horizon, frozen window); how methods are selected (naive/moving average/exponential smoothing/Holt-Winters/regression/machine learning, intermittent demand, new products, promotions, spare parts); inputs/assumptions/data quality (history, orders, pipeline, customer schedules, seasonality, price/promotion, lead time, outliers, hierarchy reconciliation); error metrics/review (MAPE/sMAPE/MASE/bias/WMAPE, FVA, by category/customer, targets, review cadence); override/consensus/authority (who changes, reason codes, limits, audit trail, S&OP confirmation); systems/tools; public boundary. On the rules: MOF Internal Control Application Guideline No. 7 (Procurement) requires procurement plans, requisitions, supplier selection, contracts, acceptance, payment and records; No. 15 (Comprehensive Budgeting) requires budget preparation, execution, adjustment and assessment; No. 8 (Asset Management) requires reasonable purchase dates and quantities plus inventory/count/disposal. This article is current to 2026-11-10 and is a summary of public rules and page method, not supply-chain/finance/audit advice; the company's forecasting policy, data basis and systems control.
This article is for planning, procurement, sales, supply-chain, production, finance and website teams at equipment, electronics, automotive-parts, medical-device, hardware, chemical, packaging and export manufacturers in Changzhou and nearby. It covers how to write and accept a procurement demand forecasting and forecast-error management page. The usual gap is "one number without assumptions, hierarchy conflicts, one method for everything, no error measurement, overrides without reasons, forecast disconnected from procurement/inventory", ending with a page that only says "accurate forecasting, smart replenishment", while shortages/inventory/budget still disagree.
A forecast is not a commitment: state the level, period, assumptions and error. A method is not "the more complex the better": choose by demand pattern, and separate intermittent/new-product/spare-part demand. An override is not a gut call: require reason codes, limits, approval and review, and link the result to procurement/inventory/budget.
How does this page relate to S&OP/demand review, material planning/MRP, budget, supplier capacity and safety-stock pages?
The forecasting page answers "at what granularity/method/assumptions demand is calculated, how large the error is, and how it is changed"; the S&OP/demand review page answers "how monthly demand—supply—finance consensus is reached and gaps closed"; the material planning/shortage alert page answers "MRP parameters, safety stock, kitting and shortage escalation"; the budget page answers "limits/commitment/execution/adjustment"; the supplier capacity reservation page answers "reserved volume/ramp-up/allocation". Forecasting is the main page for "where the demand number comes from" and cannot be replaced by an S&OP or MRP page.
Common breaks: one number only; no assumptions/version; hierarchy conflicts (SKU sum ≠ category); one method for everything; intermittent/new/spare parts not separated; no error measurement; overrides without reasons; forecast disconnected from procurement/inventory/budget. The page separates "positioning—level—method—inputs—error—override—governance—boundary" so planning/procurement/sales/supply-chain/production/finance share one vocabulary.
| Page | Question it answers | Key content | Cannot replace |
|---|---|---|---|
| Demand forecasting/error | Where the number comes from/error/how changed | Level, method, assumptions, metrics, override | S&OP consensus |
| S&OP/demand review | Monthly demand-supply-finance consensus | Consensus, gaps, decisions, KPIs | Forecast method |
| Material planning/MRP | MRP/safety stock/kitting/shortage | Parameters, kitting, escalation | Demand forecast |
| Budget | Limits/commitment/execution/adjustment | Budget, commitment, variance | Demand number |
| Supplier capacity | Reservation/ramp-up/allocation | Reserved volume, ramp-up, fees | Demand forecast |
| Safety stock | Service level/variability/replenishment | Safety stock, reorder point | Forecast accuracy |
Page relationships are editorial; the company's forecasting policy, data basis and systems control.
How should forecast level, granularity and period be set?
At minimum state: level (SKU/material/category/product family/customer/region/plant), granularity (pieces/cases/tons/value), period (week/month/quarter), horizon (e.g. 3/6/12/18 months), frozen window (e.g. 4 weeks), update frequency and version. Levels must reconcile bottom-up and top-down (hierarchy reconciliation); different levels may use different methods but must reconcile. Procurement uses material/supplier lead-time view, sales uses customer/product view, finance uses value/period view; the page should state the mapping. Period/frozen window should align with S&OP, MRP and budget cadence.
Acceptance checks: level; granularity; period; horizon; frozen window; update frequency; version; aggregation/disaggregation; basis mapping; alignment with S&OP/MRP/budget. Common gaps: one total only; hierarchy conflict; mixed periods; no freeze; unclear version; wrong basis.
| Item | What to write | Evidence | Common gap |
|---|---|---|---|
| Level | SKU/material/category/customer/region/plant | Hierarchy | One total |
| Granularity | Pieces/cases/tons/value | Basis | Mixed units |
| Period | Week/month/quarter, start/end | Calendar | Mixed period |
| Horizon | 3/6/12/18 months | Policy | No horizon |
| Frozen window | 4 weeks/monthly freeze | Rule | Changed anytime |
| Update/version | Frequency, version, release | Record | Unclear version |
| Aggregation | Bottom-up/top-down, reconciliation | Reconciliation | Hierarchy conflict |
| Basis mapping | Sales/procurement/finance basis | Mapping | Different languages |
Level/period are editorial; the company's planning system, S&OP policy and systems control.
How should forecasting methods be selected and accepted?
Methods should at least cover: naive/moving average/exponential smoothing/Holt-Winters (trend/seasonality), regression (price/promotion/customer/macro), machine learning (multivariate/non-linear), intermittent demand (Croston/Poisson etc.), new products (analogy/pilot/customer commitment), spare parts (installed base × failure rate/life), promotion/project (event-driven). Selection depends on demand pattern (stable/trend/seasonal/intermittent/new), data volume/quality, horizon, interpretability and maintenance cost; not "the more complex the better". State applicability/non-applicability, parameters, backtest window and comparison with a naive benchmark; avoid a black box.
Acceptance checks: method list; applicability; parameters; backtest; benchmark; intermittent/new/spare parts; interpretability; maintenance; tools. Common gaps: one method for all; no backtest; no benchmark; black box; new product guesswork; spare parts treated as finished goods.
| Method | Applicability | Validation | Common gap |
|---|---|---|---|
| Naive/moving average | Stable/short-term; not trend/season | Backtest | Used long-term |
| Exponential smoothing | Stable/trend; parameter sensitive | Backtest | Arbitrary parameter |
| Holt-Winters | Trend + season; needs history | Backtest | Insufficient history |
| Regression | Price/promotion/customer/macro; causality | Backtest/significance | Spurious correlation |
| Machine learning | Multivariate/non-linear; large data | Backtest/explanation | Black box |
| Intermittent demand | Low frequency/spares; not high frequency | Backtest | Treated as finished goods |
| New product | Analogy/pilot/customer commitment | Tracking | Guesswork |
| Promotion/project | Event-driven; needs assumptions | Review | Treated as baseline |
Methods are editorial; the demand pattern, data quality and system capability control.
How should inputs, assumptions and data quality be accepted?
Inputs should at least include: historical shipments/orders, backlog, sales pipeline, customer schedules/rolling forecasts, new products/NPI, promotions/projects, seasonality/holidays, price/discount, lead time/supply constraints, installed base/spare parts, macro/policy. Assumptions should at least include: market/customer/share, price/promotion, capacity/lead time, substitution/loss, exceptional events. Data quality should at least cover: basis, missing values, outliers, duplicates, units, returns/cancellations, channel inventory and versions. Outliers should be flagged/handled (not simply deleted); customer forecast deviations should be recorded; hierarchy differences should be explained. Guideline No. 7 requires procurement plans/requisitions to have a basis, No. 15 requires a budget basis, and No. 8 requires reasonable purchase dates/quantities.
Acceptance checks: input list; assumptions; data source; missing/outliers; returns/cancellations; channel inventory; version; hierarchy difference; review. Common gaps: history only; no assumptions; outliers deleted; channel inventory ignored; mixed versions; unexplained differences.
| Item | What to write | Evidence | Common gap |
|---|---|---|---|
| History/orders | Shipments, orders, returns, cancellations | System | Shipments only |
| Backlog/pipeline | Open orders, sales pipeline | CRM/ERP | Backlog missing |
| Customer schedule | Rolling forecast, commitment, window | Customer file | Treated as commitment |
| New product/promotion | NPI, promotion, project, event | Plan | Guesswork |
| Price/lead time | Price, discount, lead time, supply constraint | Contract/plan | Constraint ignored |
| Outliers | Flag, handling, reason | Record | Deleted |
| Channel inventory | Channel/customer inventory, sell-out | Report | Ignored |
| Assumptions/version | Market/customer/price, version | Assumption sheet | No assumptions |
Inputs/assumptions are editorial; the company's data, customer agreements and forecasting policy control.
How should error metrics and review be accepted?
Metrics should at least include: MAPE/sMAPE (watch zero values), MASE, bias (systematic over/under), WMAPE, value/volume weighting, by category/customer/period, forecast accuracy targets, FVA (forecast value added versus naive). Review should at least include: monthly/quarterly, by category/customer, deviation causes (demand/price/promotion/new product/supply/customer), improvement actions, owner, deadline. Error is not "the lower the better"; it should be read with cost/service level; different levels/periods need different metrics to avoid "averages hiding large misses". Distinguish forecast accuracy from plan accuracy and budget attainment.
Acceptance checks: metrics; zero handling; bias; weighting; segmentation; targets; FVA; review; causes; actions; owner. Common gaps: MAPE only; averages hide misses; no bias; no review; no action; targets disconnected from assessment.
| Item | What to write | Evidence | Common gap |
|---|---|---|---|
| MAPE/sMAPE | Definition, zero handling, segmentation | Report | Zero explosion |
| MASE/WMAPE | Benchmark, weighting, value/volume | Report | MAPE only |
| Bias | Systematic over/under, direction | Report | Not measured |
| Segmentation | Category/customer/period | Report | Averages hide |
| Targets | Accuracy target, service level | Policy | No target |
| FVA | Improvement over naive | Backtest | No value added |
| Review | Monthly/quarterly, causes, actions | Minutes | No review |
| Owner/deadline | Who changes, when, validation | Register | No action |
Error/review are editorial; the company's metric basis, cost and service level control.
How should override, consensus and governance be accepted?
Override should at least state: who may change (sales/planning/procurement/management), reason codes (customer/promotion/new product/supply/price/exception), limits/thresholds, approval, audit trail, validity, review (right/wrong). Consensus should at least include: S&OP/demand review confirming the version, cross-functional sign-off, linkage with budget/procurement/capacity, frozen window. Governance should at least include: owner (demand planning/sales/supply chain), forecast lead, KPIs, training, tools, data quality, exception escalation. An override is not "the boss picks a number"; it must trace who changed how much when, why, and with what result; forecast version and execution version must be distinguished.
Acceptance checks: override authority; reason codes; limits; approval; audit trail; review; consensus; freeze; owner; KPIs; tools. Common gaps: anyone can change; no reason; no approval; no trail; no review; no sign-off; mixed versions.
| Item | What to write | Evidence | Common gap |
|---|---|---|---|
| Override authority | Who/level/value or percentage | Authority table | Anyone can change |
| Reason codes | Customer/promotion/new product/supply/price/exception | System | No reason |
| Limits/approval | Threshold, approval, escalation | Approval | Gut call |
| Trail/validity | Who/when/how much/validity | Log | No trail |
| Review | Right/wrong, reason | Review | No review |
| Consensus/freeze | S&OP confirmation, frozen window | Minutes | Changed anytime |
| Owner/KPIs | Owner, accuracy/bias | Policy | No owner |
| Tools/data | System, version, data quality | System | Manual sheets |
Override/governance are editorial; the company's forecasting policy, authority and systems control.
How should the website page be written, and what must not be published?
Suggested sections: (1) positioning/relationship with S&OP, MRP, budget and capacity; (2) level/granularity/period; (3) methods/applicability/backtest; (4) inputs/assumptions/data quality; (5) error metrics/review; (6) override/consensus/governance; (7) contact window/update date. The public page explains "method, level, basis, error, governance, boundary" and does not publish specific customers/orders/forecast numbers, accuracy, price/promotion, capacity/inventory or system screenshots. The English page should use consistent terms (demand forecasting, forecast granularity, horizon, frozen window, intermittent demand, forecast error, MAPE/sMAPE/MASE, bias, forecast value added, override, consensus) and state the cut-off date.
Do not turn the forecasting page into an "AI precise forecast/zero shortage" slogan, and do not claim "100% accuracy/zero error" if it cannot be proven. The page should let planning/procurement/sales/supply-chain/production/finance judge "where the number comes from, how large the error is, who changes it, how it is reviewed and how it links", without exposing customer and forecast information.
Go-live acceptance checklist
Ten checks: positioning/relationship; level/period; methods/backtest; inputs/assumptions; data quality; error metrics; review/actions; override/consensus; governance/systems; public boundary. Each needs evidence and a review date. The pass standard is not "there is a forecast table", but that planning/procurement/sales/supply-chain/production/finance can judge the forecast basis, error, overrides and linkage, with traceable versions.
Before go-live, run a tabletop exercise on a real (redacted) category: history → assumptions → method → backtest → error → override → S&OP consensus → procurement/inventory linkage, simulating "new product without history", "major customer cuts orders", "promotion" and "supply disruption", to see whether the page and process work.
| Check | Pass standard | Evidence | If failed |
|---|---|---|---|
| Positioning/relationship | Boundary with S&OP/MRP/budget/capacity | Page | Add positioning |
| Level/period | Level, granularity, horizon, freeze, version | Policy | Add basis |
| Methods/backtest | Applicability, parameters, backtest, benchmark | Backtest | Add backtest |
| Inputs/assumptions | History/orders/pipeline/new product/promotion/assumptions | Assumption sheet | Add assumptions |
| Data quality | Missing/outliers/returns/channel inventory/version | Record | Add cleansing |
| Error metrics | MAPE/sMAPE/MASE/bias/FVA/segmentation | Report | Add metrics |
| Review/actions | Monthly/quarterly, causes, owner, deadline | Minutes | Add review |
| Override/consensus | Authority, reasons, approval, trail, S&OP | System | Add governance |
| Governance/systems | Owner, KPIs, tools, version | Policy | Add governance |
| Public boundary | No customers/forecasts/accuracy/prices | Page/permissions | Take down |
The acceptance list is editorial; the company's forecasting policy, data basis and systems control.
Who should read it, who should not, and what decisions does it support?
For planning, procurement, sales, supply-chain, production, finance and website teams at equipment, electronics, automotive-parts, medical-device, hardware, chemical, packaging and export manufacturers in Changzhou and nearby; also for companies handling "one number, no assumptions, hierarchy conflicts, one method for everything, no error measurement, overrides without reasons, forecast disconnected from procurement". Not for teams without demand forecasting management, or that want one page to replace supply-chain/finance/audit advice.
Read it if: building a forecasting/error page; only "accurate forecasting"; no assumptions; hierarchy conflict; one method for everything; no error measurement; override gut calls; forecast not linked. Not suitable if: treating "forecast" as "commitment"; "method" as "the more complex the better"; "override" as "the boss picks a number"; "page" as "forecast conclusion/budget". Supports: level/period, methods/backtest, inputs/assumptions, error/review, override/governance and public-boundary self-checks.
FAQ
What is the difference between the forecasting page and the S&OP/demand-review page?
The forecasting page answers "at what level/method/assumptions the demand number is calculated, how large the error is, and how overrides are managed"; the S&OP/demand-review page answers "how monthly demand—supply—finance consensus is reached, how gaps are closed, who decides". A forecast is an input; S&OP is consensus and decision. The forecasting page cannot replace S&OP, and S&OP cannot replace forecasting methods.
How should forecast level and period be set?
By use: procurement uses material/supplier lead time, sales uses customer/product, finance uses value/period; levels should cover at least SKU/category/customer/region/plant, periods week/month/quarter, horizon 3/6/12/18 months, frozen window e.g. 4 weeks. Levels must reconcile bottom-up/top-down and align with S&OP/MRP/budget; not every level needs the same method.
How to choose moving average/exponential smoothing/regression/machine learning?
By demand pattern/data volume/horizon/interpretability: stable short-term can use moving average/exponential smoothing; trend+season uses Holt-Winters; price/promotion/customer drivers use regression; multivariate/large data can try machine learning; intermittent/spare parts use Croston etc.; new products use analogy/pilot/customer commitment. All should be backtested against a naive benchmark, avoiding black boxes and one method for everything.
How to forecast intermittent demand/spare parts/new products?
Do not treat intermittent/spare parts as high-frequency finished goods: use installed base × failure rate/life, historical replacement, customer inventory/service level and intermittent-demand methods; new products have no history, so use analogy, pilot, customer commitment, pre-sale/project pipeline, and track actuals to correct. Promotion/projects are event-driven and should not be mixed into the baseline. State assumptions and error rather than chasing one "accurate number".
Which error metrics should be used (MAPE/bias/MASE/FVA)?
MAPE is intuitive but explodes on zero/low values, so pair with sMAPE; MASE compares with a naive benchmark; bias shows systematic over/under; WMAPE weights by value/volume; FVA shows improvement over naive. Segment by category/customer/period to avoid averages hiding large misses; read metrics together with service level/cost, not "accuracy" alone.
How should overrides be managed?
Limit who can change, require reason codes (customer/promotion/new product/supply/price/exception), limits/thresholds, approval, audit trail, validity, and review whether the override was right. An override is not the boss picking a number; distinguish forecast version from execution version, freeze after S&OP/demand-review confirmation, and record changes.
Should the website publish forecasts/customers/errors?
Usually not specific customers/orders/forecast numbers, accuracy, price/promotion, capacity/inventory or system screenshots; it can publish forecasting methods, level/basis, error metrics, override/governance process, review mechanism and update date. The goal is to let customers/suppliers understand the planning method, not to disclose customer and forecast positions.
One-sentence takeaway
The procurement demand forecasting and forecast-error management page on a Changzhou manufacturer's website is not about "accurate forecasting"; it is about turning the relationship with S&OP/MRP/budget/capacity, level/granularity/period, methods/backtest, inputs/assumptions/data quality, error metrics/review, override/consensus/governance, systems/tools and public boundaries into a checkable list, so planning/procurement/sales/supply-chain/production/finance can judge where the number comes from, how large the error is, who changes it, how it is reviewed and how it links.
Research method and limitations
This article is a summary of public rules and page method, not supply-chain/finance/audit advice. It uses no unpublished company customers/orders/forecast numbers, accuracy, price/promotion, capacity/inventory, system screenshots or undisclosed disputes; the tables and acceptance items are editorial and not supply-chain/finance/audit conclusions. MOF Internal Control Application Guideline No. 7 (Procurement), No. 15 (Comprehensive Budgeting) and No. 8 (Asset Management) are public sources; the company's forecasting policy, data basis and systems control. This article does not decide whether any specific forecast/error is reasonable, and does not promise "100% accuracy/zero shortage"; companies should set them item by item based on category, customer, data and service level.
Sources and basis
Current to 2026-11-10; the official pages below control.
- MOF Internal Control Application Guideline No. 7 — Procurement (Cai Kuai [2010] No. 11): Linyi Finance Bureau. Procurement plans, requisitions, supplier selection, contracts, acceptance, payment and records; used for the basis from forecast to procurement plan.
- MOF Internal Control Application Guideline No. 15 — Comprehensive Budgeting (Cai Kuai [2010] No. 11): Linyi Finance Bureau. Budget preparation, approval, execution, adjustment and assessment; used for the forecast/budget basis and linkage.
- MOF Internal Control Application Guideline No. 8 — Asset Management (Cai Kuai [2010] No. 11): Linyi Finance Bureau. Reasonable determination of inventory purchase dates and quantities, inventory/count/disposal; used for the forecast-to-procurement/inventory link.