Demand Planning & Forecasting Integration Playbook

TL;DR

• Bottom line: Extract 2-3 years of historical sales from ERP via batch API, push to demand planning tool (Anaplan/SAP IBP/Oracle Planning Cloud), run statistical + ML forecasts, then write consensus forecast back to ERP as planned independent requirements (PIRs) or demand forecasts that feed MRP.
• Key limit: Historical data extraction is the bottleneck — 50M+ transaction rows require bulk APIs (Anaplan Integration API v2.0, SAP CPI-DS, Oracle EPM Automate), not real-time endpoints.
• Watch out for: Granularity mismatch between planning tool (product-location-week) and ERP MRP (material-plant-day) — missing disaggregation logic causes either over-procurement or stockouts.
• Best for: Companies with $50M+ revenue, 500+ SKUs, multi-location distribution, and seasonal or promotional demand patterns that outgrow basic ERP forecasting.
• Feedback loop: Actual sales vs. forecast comparison (MAPE, bias) must flow back into the planning tool monthly — without this, forecast accuracy degrades 5-15% annually.

System Profile

This playbook covers the end-to-end integration pattern for connecting ERP systems with dedicated demand planning tools. The ERP serves as the system of record for historical transactions (sales orders, shipments, invoices) and as the execution system that consumes the approved forecast (MRP, procurement). The demand planning tool is the analytical engine that generates, adjusts, and publishes the demand signal.

Integration Flow Architecture

The demand planning integration follows a six-phase closed-loop pattern. Every phase has distinct data objects, frequencies, and failure modes.

Phase 1: EXTRACT — Historical Data from ERP
         (Sales orders, shipments, invoices, returns, promotions)
         Frequency: Nightly batch or weekly full refresh
              |
Phase 2: TRANSFORM — Cleansing & Harmonization
         (UoM conversion, calendar mapping, hierarchy alignment,
          outlier detection, promo flag tagging)
              |
Phase 3: LOAD — Into Demand Planning Tool
         (Master data sync first, then time-series actuals)
              |
Phase 4: FORECAST — Generate & Review
         (Statistical baseline → ML enrichment → consensus adjustment)
         Human-in-the-loop: S&OP review meeting
              |
Phase 5: PUBLISH — Approved Forecast to ERP
         (Planned Independent Requirements / Demand Forecasts)
         Write to ERP MRP input tables
              |
Phase 6: FEEDBACK — Accuracy Measurement
         (Actual vs. Forecast: MAPE, WMAPE, Bias, FVA)
         Flows back to Phase 3 for model retraining

API Surfaces & Capabilities

Rate Limits & Quotas

Per-Request Limits

Rolling / Daily Limits

Authentication

Authentication Gotchas

• Anaplan OAuth tokens expire after 35 minutes — long-running bulk imports must refresh mid-job [src1]
• SAP IBP CPI-DS requires a Communication Arrangement in S/4HANA with specific communication scenarios — missing scenarios cause silent connection failures [src2]
• Oracle EPM Automate basic auth counts against the user's concurrent session limit — automated jobs can lock out interactive users [src3]

Constraints

• Forecast granularity mismatch between planning tool (product-location-week) and ERP MRP (material-plant-day) requires disaggregation logic — ERP will reject forecasts at the wrong granularity level
• Historical data must include returns, credits, and cancellations with proper sign convention — excluding these inflates the baseline forecast by 3-8%
• Consensus review (S&OP) is a human-in-the-loop step that cannot be automated via API — integration must preserve manual adjustments
• Frozen forecast horizon in ERP (typically 1-4 weeks) means forecast writes inside this window are rejected or ignored
• Multi-currency environments require exchange rate alignment — planning tool and ERP must use the same rate type
• Product lifecycle events (NPI, phase-out) require special handling — no historical data exists for new products

Integration Pattern Decision Tree

START — Integrate ERP with Demand Planning Tool
├── What type of data is flowing?
│   ├── Historical actuals (ERP → Planning tool)
│   │   ├── Volume < 100K records → REST API
│   │   ├── Volume 100K-10M → Bulk API (Anaplan v2.0, CPI-DS, EPM Automate)
│   │   └── Volume > 10M → File-based (CSV/SFTP) + staged loading
│   ├── Master data (bidirectional sync)
│   │   ├── Product/location hierarchy → push from ERP (source of truth)
│   │   └── Planning attributes → push from planning tool
│   ├── Approved forecast (Planning tool → ERP)
│   │   ├── SAP: Planned Independent Requirements (PIRs) via BAPI
│   │   ├── Oracle: Demand Forecast via FBDI
│   │   ├── D365: Demand Forecast Entity (OData)
│   │   └── Always: respect frozen horizon, apply disaggregation
│   └── Accuracy feedback (actuals vs. forecast)
│       └── Scheduled weekly/monthly comparison
├── What middleware to use?
│   ├── SAP ecosystem → SAP Integration Suite / CPI-DS
│   ├── Oracle ecosystem → Oracle Integration Cloud
│   ├── Multi-vendor → MuleSoft, Boomi, Workato
│   └── Budget-constrained → Custom scripts + SFTP + cron
└── Error handling?
    ├── Master data failures → queue and retry; block dependent jobs
    ├── Historical load failures → partial OK; log gaps
    ├── Forecast write failures → CRITICAL alert; MRP on stale data
    └── Accuracy feedback failures → non-blocking; degrade gracefully

Quick Reference — Integration Process Flow

Step-by-Step Integration Guide

1. Extract Historical Sales Data from ERP

Extract 2-3 years of daily sales transactions including orders, shipments, returns, and credit memos. Include promotional flags, pricing, and customer segment. [src2, src8]

-- SAP CDS View for sales history extraction
SELECT
  material, plant, billing_date,
  SUM(quantity) AS shipped_qty,
  SUM(net_amount) AS revenue,
  currency_code, sales_org, distribution_channel
FROM i_billingdocumentitem
WHERE billing_date >= ADD_DAYS(CURRENT_DATE, -1095)
  AND billing_type IN ('F1', 'F2')
  AND cancelled_billing_doc = ''
GROUP BY material, plant, billing_date, currency_code,
         sales_org, distribution_channel

Verify: Record count in extract matches ERP transaction count (tolerance: <0.1% variance).

2. Transform and Cleanse Historical Data

Transform raw ERP data to match the planning tool's data model: UoM conversion, calendar period mapping, outlier detection, hierarchy alignment. [src4, src7]

# Transform daily ERP sales to weekly planning granularity
def transform_sales(raw_df, uom_factors):
    # UoM: ERP eaches → planning cases
    raw_df['planning_qty'] = raw_df['shipped_qty'] / raw_df['case_qty'].fillna(1)
    # Calendar: fiscal → ISO weeks
    raw_df['iso_week'] = pd.to_datetime(raw_df['date']).dt.isocalendar().week
    # Outlier: flag values > 3 std dev from rolling 8-week mean
    # Aggregate to product x location x week
    return weekly_aggregated_df

Verify: SUM(planning_qty * case_qty) in output equals SUM(shipped_qty) in source (must be exact).

3. Load Actuals into Demand Planning Tool

Master data must load before time-series data. Always sync product and location hierarchies first. [src1, src5]

# Anaplan Integration API v2.0 bulk import
# 1. Upload file (chunked if > 50MB)
# 2. Mark upload complete
# 3. Run import action
# 4. Poll for completion (refresh token at 30-min mark)

Verify: Record count in planning tool matches extract. Spot-check 5 random product-location-week combinations.

4. Generate and Review Forecast

Statistical baseline + ML enrichment + promotional uplift + consensus adjustment. The S&OP review is human-in-the-loop. [src8]

Verify: Forecast Value Added (FVA) at each step — if ML or consensus worsens accuracy vs. baseline, the step adds cost without value.

5. Export Approved Forecast to ERP

Disaggregate from planning granularity (product-location-week) to ERP granularity (material-plant-day) and write to ERP forecast consumption mechanism. [src2, src3]

# SAP: Write PIRs via BAPI_REQUIREMENTS_CREATE
# Oracle: Import via FBDI CSV
# D365: Write via Demand Forecast Entity (OData)
# Always: skip frozen horizon dates, validate disaggregation totals

Verify: MRP run picks up new forecast quantities. Check planned orders vs. expected.

6. Implement Forecast Accuracy Feedback Loop

Compare actual sales to published forecast at same granularity. Feed back for model recalibration. [src4, src7]

# Key metrics:
# MAPE = mean(|actual - forecast| / actual) * 100
# WMAPE = sum(|actual - forecast|) / sum(actual) * 100
# Bias = sum(forecast - actual) / sum(actual) * 100
# FVA = naive_mape - forecast_mape (positive = value added)

Verify: Bias within +/-5%. Persistent bias >10% requires model recalibration.

Data Mapping

Field Mapping Reference — ERP to Planning Tool

Data Type Gotchas

• SAP quantities use 3 decimal places (QUAN type); most planning tools use 2 — rounding causes cumulative drift [src2]
• Oracle ERP Cloud uses NULL for zero demand periods; planning tools interpret missing periods differently — always insert explicit zero records [src3]
• Date timezone: SAP stores dates without timezone (plant-local); planning tools use UTC — late-day shipments can shift to next ISO week [src2]
• Negative quantities (returns) are silently dropped by some planning tool import processes, inflating the demand baseline [src1]

Error Handling & Failure Points

Common Error Codes

Failure Points in Production

• Master data sync lag: New products added Monday not in planning tool until Tuesday — Monday actuals silently dropped. Fix: Run master data sync before actuals load. [src2]
• Partial load treated as complete: 950K of 1M records loaded, job reports success. Fix: Validate post-load count; alert on >0.1% variance. [src1]
• Forecast overwrites consensus: Automated export runs after S&OP and overwrites adjustments. Fix: Use version-controlled forecasts; export to "system" version, not "consensus". [src5]
• Stale forecast after planning tool outage: ERP runs MRP on 2+ week old forecast. Fix: Add forecast age check; alert if >7 days old. [src8]
• Calendar boundary errors: ISO week 1 maps to late December, causing Q4 demand distortion. Fix: Use explicit date ranges instead of week numbers at year boundaries.

Anti-Patterns

Wrong: Full refresh of 3 years every night

# BAD — wastes API calls, risks rate limits, takes 4+ hours
all_data = extract_all_sales_last_3_years()  # 50M rows
delete_all_actuals()
load_all_actuals(all_data)

Correct: Incremental delta + weekly reconciliation

# GOOD — nightly delta (10K-100K rows), weekly full reconciliation
delta = extract_sales_since(last_load_timestamp)
upsert_actuals(delta)  # upsert, not insert

Wrong: Writing weekly forecast directly to daily ERP

# BAD — all demand lands on Monday; MRP over-orders
create_pir(date=week_start, quantity=weekly_qty)

Correct: Disaggregate using historical daily profiles

# GOOD — spread weekly forecast across days using demand pattern
for day, weight in daily_profile:
    upsert_pir(date=day, quantity=weekly_qty * weight)

Wrong: Fire and forget — never measure accuracy

# BAD — forecast degrades 5-15% per year without feedback
generate_forecast(); publish_to_erp()  # Done! Never look back.

Correct: Closed-loop accuracy with automated alerts

# GOOD — monthly accuracy review with threshold alerts
metrics = calculate_accuracy(actuals, forecast)
if metrics['wmape'] > 40: alert("Review forecast model")
if abs(metrics['bias']) > 10: alert("Systematic bias detected")

Common Pitfalls

• Not separating base from promotional demand: Promo spikes inflate the statistical baseline permanently. Fix: Tag promo orders in ERP; model promo lift as overlay on base demand. [src8]
• Using shipment data instead of demand data: Stockouts show as zero demand, teaching the model demand dropped. Fix: Use order data (gross demand); impute unconstrained demand for stockout periods. [src4]
• Aggregating too early: Monthly extraction loses daily signal for demand sensing. Fix: Extract at finest granularity; aggregate in planning tool. [src7]
• No master data governance: Product hierarchy changes break planning tool mapping mid-cycle. Fix: Maintain MDM mapping layer; freeze hierarchy during forecast cycle. [src2]
• Treating accuracy as a single number: Company MAPE of 25% hides A-items at 15% and C-items at 60%. Fix: Segment by ABC class, product family, demand pattern, and horizon. [src4]
• Over-engineering real-time integration: Demand planning doesn't benefit from real-time — forecasts are reviewed weekly. Fix: Use batch (nightly max); reserve real-time for demand sensing only. [src8]

Diagnostic Commands

# Verify Anaplan API connectivity
curl -X POST "https://us1a.app.anaplan.com/token/authenticate" \
  -H "Content-Type: application/json" \
  -d '{"grant_type":"client_credentials","client_id":"ID","client_secret":"SECRET"}'

# Check Anaplan import actions
curl -X GET "https://api.anaplan.com/2/0/workspaces/{id}/models/{id}/imports" \
  -H "Authorization: AnaplanAuthToken {token}"

# SAP IBP — monitor CPI-DS jobs via BTP cockpit
# Oracle — check EPM Automate job status
epmautomate.sh liststatus

# Validate record counts post-load
echo "ERP: $(wc -l < exports/sales.csv) | Planning: $(curl -s $API/count)"

When to Use / When Not to Use

Cross-System Comparison — Demand Planning Tools

Important Caveats

• Full demand planning integration typically takes 3-6 months for single ERP + planning tool; 6-12 months for multi-ERP, multi-region
• Data quality is the binding constraint — sophisticated ML cannot compensate for incomplete historical data
• Vendor lock-in: SAP IBP + S/4HANA and Oracle Planning + Oracle ERP are tightly coupled — switching requires rebuilding integration
• Total integration cost (iPaaS + BTP entitlements + planning tool license) often exceeds the planning tool license alone
• API versioning: Anaplan v1 deprecated (sunset 2024); SAP CPI-DS being replaced by Integration Suite; Oracle EPM basic auth being phased out
• Forecast accuracy benchmarks vary by industry, product lifecycle, and horizon — do not compare without controlling for these variables