AI for SAP ECC customers before they migrate

#The 60-second version

Many SAP customers still run SAP ECC, the ERP system that came before S/4HANA. Most of them plan to move. The question this topic answers: should they spend money on AI now, on a system they are about to leave?

Often the answer is yes, for a narrow set of work. AI that sits beside ECC, reads it through proper interfaces and keeps its own logic separate can move with the company. AI built into ECC, or wired to its internal tables, is usually thrown away at the migration.

SAP's own AI is mostly built for its cloud products. As of October 2026, SAP offers some Joule assistants and agents to ECC customers, but only to those who have committed to moving to SAP's cloud ERP. So the decision has three outcomes for each idea: invest now, wait, or tie it to the migration and its business case.

#Why it matters to the business

The clock is real. SAP states that mainstream maintenance for SAP Business Suite 7, which includes ECC, runs through 31 December 2027. Optional extended maintenance runs through 31 December 2030 (SAP News, October 2026). A paid transition option can keep ECC-based systems running from 2031. SAP's 13 October 2026 update says these subscriptions may run until 31 December 2035, with further prerequisites (SAP News).

Within that window, a company has two risks:

• Waiting too long. A migration takes years. Two years of manual invoice keying, missed price errors and slow exception handling are a real cost while the team waits.
• Building throwaway work. An AI tool wired into ECC's internal tables, or into its screens, stops working when ECC goes. The money is spent twice.

#How SAP does it

As of October 2026, SAP's AI for ECC customers comes in three forms. Check each against your own contract.

1. Joule assistants and agents, for customers committed to the cloud. At Sapphire in May 2026, SAP said ECC and on-premise S/4HANA customers "are not excluded". Customers who commit to moving the majority of their landscape to SAP Cloud ERP get select AI scenarios (SAP News, 12 May 2026). An SAP blog of 7 October 2026 adds detail. Customers on the RISE with SAP journey who meet minimum cloud commitments can enable Joule assistants and agents on ECC or on-premise S/4HANA. SAP's activation service is free for up to three assistants, and the Max Success Plan offers broader activation (sap.com blog). SAP did not publish the size of the commitment on the pages opened for this topic.

2. SAP BTP services that work beside any SAP system. Services on SAP Business Technology Platform, such as SAP Document AI and the generative AI hub, are called over the network. A small agent called the Cloud Connector links them to systems in the company's own data center (SAP BTP documentation). These services don't depend on the ERP release, but SAP's own reference designs mostly show S/4HANA as the target. Plan and test the ECC connection yourself.

3. Help with the move itself. SAP announced migration and modernization assistants inside RISE with SAP, for tasks such as data quality, custom code and testing. General availability was planned from Q3 2026 (SAP Sapphire guide). AI for migration projects has its own topic: AI in S/4HANA migration projects.

What ECC does not get is the embedded AI that SAP builds into S/4HANA and its cloud applications (Embedded AI across SAP applications). That arrives with the migration.

#A decision guide: invest now, wait, or tie to the migration

The deep layer turns this table into a small program with Calder's numbers.

#Questions to ask

1. What is our migration date, and which processes move first? How many months of value would an AI tool have on ECC?
2. Does our contract qualify us for SAP's Joule assistants on ECC, which ones, and what does it commit us to?
3. Does the design read ECC through interfaces (OData services, BAPIs, IDocs, replication), or through internal tables or screens?
4. Which parts survive the move: the model, the prompts, the test set, the user interface? Which part is rewritten, and how many days does that take?
5. Who owns the tool after go-live, and when is each ECC-only part retired?
6. Would the migration project itself pay for this, because it reduces migration risk?
7. Does SAP's standard in S/4HANA cover this after the move, making our build unnecessary?

#Common misconceptions

• "ECC customers get no SAP AI." Since May 2026, SAP offers select Joule assistants to ECC customers committed to its cloud ERP, and BTP services work beside ECC.
• "Everything built on ECC is thrown away." Logic that sits beside ECC and reads it through interfaces can move. Only the connection layer changes.
• "Wait for S/4HANA and get AI for free." Embedded AI arrives with the move, but many AI features in SAP's products are licensed separately (Embedded AI across SAP applications). Waiting also has a cost: the months of manual work.
• "ECC support ends in 2027, so it's too late." Mainstream maintenance ends in 2027, with extended maintenance to 2030 and paid options beyond. Many companies still have years on ECC.
• "The fastest path is reading ECC's tables." It is fast to build, and it breaks at the move. S/4HANA's released interfaces don't expose those tables to new cloud-ready code.

#Key terms

All course terms, A to Z, in the glossary

• SAP ECC (ERP Central Component): SAP's ERP system before S/4HANA, part of SAP Business Suite 7.
• Mainstream and extended maintenance: SAP's standard support period, and a paid extension after it.
• Transition option: a time-limited SAP subscription that keeps ECC-based systems running after 2030, under conditions.
• RISE with SAP: SAP's subscription offering for moving to its cloud ERP.
• Side-by-side: an application that runs next to the ERP, usually on SAP BTP, and talks to it through interfaces.
• Cloud Connector: SAP's agent that links BTP to systems inside a company's network.
• Adapter: the small part of a tool that talks to one specific system, so the rest of the tool doesn't care which system it is.
• Throwaway work: money spent on something that must be rebuilt at the migration.

#Check yourself

#Mental model

Build the AI for the system you're moving to, and plug it into the system you have. Everything that makes the tool useful (the model or prompt, the business rules, the test set, the user interface, the approval step) should not know or care whether ECC or S/4HANA is underneath. One thin adapter talks to ECC today. At the migration you write a second adapter for S/4HANA and retire the first.

The adapter's cost is the only throwaway part. The decision about whether to build now then becomes arithmetic: value until go-live, plus value after it, minus the build and the adapter rewrite.

#How it works

#Three places AI can sit next to ECC

SAP Gateway is the OData entry point for ABAP systems, including Business Suite. SAP's training says it supports OData V2 from AS ABAP 7.00 and V4 from 7.50. For Business Suite it recommends a hub deployment with development in the back end (SAP Learning). ECC has no released-API contract like S/4HANA's. Its OData services are usually custom, built on BAPIs or function modules, so each one you build is part of the adapter. IDocs, BAPIs and RFC are covered in How SAP systems talk.

The Cloud Connector links BTP to the ECC system. It opens the tunnel from the on-premise side and carries RFC and HTTP(S) (SAP BTP documentation). For analytics, Datasphere can replicate ECC tables through SAP Landscape Transformation Replication Server; the reporting topic shows that route for Calder.

#The adapter pattern

flowchart LR
  subgraph Core[AI core: survives]
    M[Model or prompt] --> R[Business rule]
    R --> A[Approval step]
    T[Test set] -.-> R
  end
  E[(ECC CP20)] -->|OData on Gateway, BAPI| AE[ECC adapter<br/>until July 2027]
  S[(S/4HANA CP10)] -->|released API| AS[S/4HANA adapter<br/>from July 2027]
  AE --> Core
  AS --> Core
  K[Key map from<br/>the migration] --> AS

The core works on the tool's own canonical model: a small, stable shape for each business object it needs ("PO item: number, supplier, ordered, received, price, currency"). Each adapter turns one system's records into that shape. The migration's key map, the table that links each old number to its new one, belongs in the S/4HANA adapter. Calder's data migration merges and extends some suppliers (Data migration strategy), and suppliers will keep quoting their old numbers.

#Knowing the successor before you build

SAP's Cloudification Repository on GitHub lists S/4HANA objects and their state. For a classic table that new cloud-ready code shouldn't use, it names the released successor. As of the file read on 31 October 2026, the private cloud file lists purchase order header table EKKO as not to be released, with successor I_PurchaseOrderAPI01. Item table EKPO maps to I_PurchaseOrderItemAPI01, and supplier master LFA1 to I_Supplier (SAP Cloudification Repository).

That gives a simple rule. For every ECC object the AI reads, write down its S/4HANA successor before you build. If a design reads something that has no successor, the after-migration adapter has no target, and the cost of the move is unknown. The fit-to-standard topic uses the same files to rate extensions.

#The payback test

For each candidate, with a go-live date G:

• Value before = months live before G x monthly value.
• Value after = 12 months x monthly value, if the tool survives the move; otherwise 0.
• Rework = adapter rewrite (built to move) or most of the build again (built straight onto ECC).
• Invest now if value before covers the build, or if the tool survives and value before plus value after exceeds build plus rework.

The 12-month horizon is a course choice. Use your own investment rule, as in The AI business case.

#Build it yourself

Before you start: finish Set up your computer for this course and Set up for Unit 12.

You will build Calder's pre-migration AI register. One script scores six AI ideas for CP20's ECC system and writes the decision record. It also lists what each idea reads in ECC with its S/4HANA successor. Last, it runs one invoice check through an ECC adapter and an S/4HANA adapter to prove the core doesn't change.

flowchart LR
  U[USE_CASES<br/>six ideas] --> S[ecc_ai_plan.py]
  C[SUCCESSORS<br/>SAP's repository] --> S
  S --> R[ecc_ai_register.md]
  S --> X[--explain]
  S --> Y[--reuse]
  S --> Z[--adapter<br/>ECC vs S/4HANA]
  S -.->|--online| G[SAP's file<br/>on GitHub]

#What you need

• The course folder orchestrate-course with its .venv, from the setup topics.
• No account and no key. The script uses only Python's built-in modules, so requirements.txt doesn't change.
• Network access only for the optional --online step, which downloads about 12 MB from GitHub.
• Cost: free. Time: about 30 minutes.

All data in the script is made up for Calder, a fictional company. No step connects to an ECC system.

#Step 1: Open your course folder and turn on the virtual environment

1. Open VS Code, then File > Open Folder and choose orchestrate-course.

2. Open a terminal with Terminal > New Terminal.

3. Turn on the virtual environment:

   • Windows (PowerShell):

     Copy

     .venv\Scripts\Activate.ps1

   • macOS / Linux:

     Copy

     source .venv/bin/activate

4. You should see (.venv) at the start of the prompt. The unit12 folder exists from the setup topic. If it doesn't, create it with mkdir unit12 (the same command works in both terminals).

Run every command from the course folder, not from inside unit12.

#Step 2: Create the script

1. In VS Code's file list, right-click unit12, choose New File, and name it ecc_ai_plan.py.
2. Paste the script below and save the file.

"""Calder Pumpworks (fictional): which AI to build on CP20's ECC before July 2027.

Modes:
  python ecc_ai_plan.py               decision register for E01-E06, writes ecc_ai_register.md
  python ecc_ai_plan.py --explain E01 the numbers and rule behind one decision
  python ecc_ai_plan.py --reuse       ECC objects each use case reads, and their S/4HANA successors
  python ecc_ai_plan.py --adapter     one invoice check, run on ECC data and on S/4HANA data
  python ecc_ai_plan.py --online      compare the successor snapshot with SAP's current file

All amounts, dates and rules are course values for a fictional company.
Only built-in Python modules are used.
"""

import argparse
import json
import sys
import urllib.request
from datetime import date
from pathlib import Path

GO_LIVE = date(2027, 7, 5)        # CP20 runs in CP10's S/4HANA from this day (course plan)
DAY_RATE = 900                    # USD per person-day (course input)
MONTHS_AFTER = 12                 # how far past go-live the payback test looks

# ---------------------------------------------------------------------------
# 1. The candidate use cases (course values)
# ---------------------------------------------------------------------------
USE_CASES = [
    {"id": "E01", "name": "Extract Augsburg supplier invoices with document AI",
     "pattern": "extract", "driver": "operations", "demand": "1,000 invoices a month keyed by hand",
     "build_days": 24, "live": date(2027, 1, 11), "monthly_usd": 3600, "survives": True,
     "adapter_days": 3, "rebuild_share": 0.6,
     "reads": ["EKKO", "EKPO", "EKBE", "LFA1"], "writes": "invoice by IDoc through the integration layer"},
    {"id": "E02", "name": "Chat over CP20's open purchase order aging report",
     "pattern": "retrieve", "driver": "operations", "demand": None,
     "build_days": 12, "live": date(2027, 1, 4), "monthly_usd": 0, "survives": False,
     "adapter_days": 0, "rebuild_share": 1.0,
     "reads": ["EKKO", "EKPO", "EKET"], "writes": None},
    {"id": "E03", "name": "Flag intercompany price mismatches between CP20 and CP10",
     "pattern": "plain automation", "driver": "operations", "demand": "price mismatches found at month end",
     "build_days": 5, "live": date(2026, 12, 7), "monthly_usd": 1500, "survives": True,
     "adapter_days": 1, "rebuild_share": 0.8,
     "reads": ["VBAK", "VBAP", "I_PURCHASEORDERITEMAPI01"], "writes": None},
    {"id": "E04", "name": "Activate SAP Joule assistants on CP20's ECC",
     "pattern": "act", "driver": "commercial", "demand": "finance asked for Joule",
     "build_days": 0, "live": None, "monthly_usd": 0, "survives": True,
     "adapter_days": 0, "rebuild_share": 0.0,
     "reads": [], "writes": None},
    {"id": "E05", "name": "Find duplicate suppliers and customers before the mock loads",
     "pattern": "predict", "driver": "migration", "demand": "duplicates broke the first mock plan",
     "build_days": 8, "live": date(2026, 12, 14), "monthly_usd": 0, "survives": False,
     "adapter_days": 0, "rebuild_share": 1.0,
     "reads": ["LFA1", "KNA1"], "writes": None},
    {"id": "E06", "name": "Screen agent that types PO date changes into ECC",
     "pattern": "act", "driver": "operations", "demand": "buyers change 300 dates a month",
     "build_days": 15, "live": date(2027, 2, 1), "monthly_usd": 1100, "survives": False,
     "adapter_days": 0, "rebuild_share": 1.0,
     "reads": ["EKPO", "EKET"], "writes": "PO item dates through SAP GUI screens"},
]

# ---------------------------------------------------------------------------
# 2. Successors, from SAP's Cloudification Repository
#    (file objectReleaseInfo_PCELatest.json, read 31 October 2026)
# ---------------------------------------------------------------------------
SUCCESSORS = {
    "EKKO": "I_PURCHASEORDERAPI01",
    "EKPO": "I_PURCHASEORDERITEMAPI01",
    "EKET": "I_PURORDSCHEDULELINEAPI01",
    "EKBE": "I_PURCHASEORDERHISTORYAPI01",
    "LFA1": "I_SUPPLIER",
    "KNA1": "I_CUSTOMER",
    "VBAK": "I_SALESDOCUMENT",
    "VBAP": "I_SALESDOCUMENTITEM",
}
CR_URL = ("https://raw.githubusercontent.com/SAP/abap-atc-cr-cv-s4hc/main/src/"
          "objectReleaseInfo_PCELatest.json")


def months_between(start: date, end: date) -> float:
    return round(max((end - start).days, 0) / 30.44, 1)


def evaluate(uc: dict) -> dict:
    """Return the decision, the rule that made it, and the numbers."""
    build = uc["build_days"] * DAY_RATE
    months = months_between(uc["live"], GO_LIVE) if uc["live"] else 0.0
    before = round(months * uc["monthly_usd"])
    after = MONTHS_AFTER * uc["monthly_usd"] if uc["survives"] else 0
    rework_adapter = uc["adapter_days"] * DAY_RATE if uc["survives"] else 0
    rework_direct = round(uc["build_days"] * uc["rebuild_share"] * DAY_RATE) if uc["survives"] else 0
    nums = {"build": build, "months": months, "before": before, "after": after,
            "rework_adapter": rework_adapter, "rework_direct": rework_direct,
            "net_adapter": before + after - build - rework_adapter,
            "net_direct": before + after - build - rework_direct}

    if not uc["demand"]:
        return {"decision": "Wait", "rule": "no evidence that anyone needs it", **nums}
    if uc["driver"] == "migration":
        return {"decision": "Tie to migration", "rule": "the value is in the migration itself", **nums}
    if uc["driver"] == "commercial":
        return {"decision": "Tie to migration", "rule": "depends on SAP's terms for the move", **nums}
    if before >= build:
        return {"decision": "Invest now", "rule": "pays back before go-live", **nums}
    if uc["survives"] and nums["net_adapter"] > 0:
        return {"decision": "Invest now", "rule": "pays back after go-live if built to move", **nums}
    return {"decision": "Wait", "rule": "does not pay back and does not survive the move", **nums}


def register(out_dir: Path) -> None:
    print(f"CP20 AI register, key date 2026-10-31, go-live in S/4HANA {GO_LIVE.isoformat()}\n")
    print(f"{'ID':<4} {'Decision':<17} {'Build USD':>9} {'Before':>8} {'Net 12m':>8}  Rule")
    lines = ["# CP20 AI register (course values, fictional company)", "",
             f"Go-live of CP20 in CP10's S/4HANA: {GO_LIVE.isoformat()}. Net 12m = value before go-live",
             f"+ {MONTHS_AFTER} months after - build - rework, for a design with an adapter layer.", "",
             "| ID | Use case | Pattern | Decision | Why |", "| --- | --- | --- | --- | --- |"]
    for uc in USE_CASES:
        r = evaluate(uc)
        net = f"{r['net_adapter']:>8,}" if uc["driver"] == "operations" and uc["demand"] else f"{'-':>8}"
        print(f"{uc['id']:<4} {r['decision']:<17} {r['build']:>9,} {r['before']:>8,} {net}  {r['rule']}")
        lines.append(f"| {uc['id']} | {uc['name']} | {uc['pattern']} | {r['decision']} | {r['rule']} |")
    path = out_dir / "ecc_ai_register.md"
    path.write_text("\n".join(lines) + "\n", encoding="utf-8")
    print(f"\nWrote {path.name}. Amounts are course values, not SAP or customer figures.")


def explain(uc_id: str) -> None:
    uc = next((u for u in USE_CASES if u["id"] == uc_id.upper()), None)
    if uc is None:
        sys.exit(f"No use case '{uc_id}'. Use one of: " + ", ".join(u["id"] for u in USE_CASES))
    r = evaluate(uc)
    print(f"{uc['id']}  {uc['name']}")
    print(f"  pattern            {uc['pattern']}")
    print(f"  demand evidence    {uc['demand'] or 'none'}")
    print(f"  driver             {uc['driver']}")
    if uc["driver"] != "operations" or not uc["demand"]:
        print(f"  decision           {r['decision']}: {r['rule']}")
        return
    print(f"  build              {uc['build_days']} days x {DAY_RATE} = {r['build']:,} USD")
    print(f"  before go-live     {r['months']} months x {uc['monthly_usd']:,} = {r['before']:,} USD")
    print(f"  survives the move  {'yes' if uc['survives'] else 'no'}"
          + (f", {MONTHS_AFTER} months after = {r['after']:,} USD" if uc["survives"] else ""))
    if uc["survives"]:
        print(f"  rework, adapter    {r['rework_adapter']:,} USD   net {r['net_adapter']:,} USD")
        print(f"  rework, direct     {r['rework_direct']:,} USD   net {r['net_direct']:,} USD")
    print(f"  decision           {r['decision']}: {r['rule']}")


def reuse() -> None:
    print("What each use case reads in ECC, and what replaces it in S/4HANA\n")
    for uc in USE_CASES:
        if not uc["reads"]:
            print(f"{uc['id']}  reads nothing itself (SAP delivers it)")
            continue
        for obj in uc["reads"]:
            if obj in SUCCESSORS:
                print(f"{uc['id']}  {obj:<26} -> {SUCCESSORS[obj]}")
            else:
                print(f"{uc['id']}  {obj:<26}    already a released S/4HANA object (CP10)")
        if uc["writes"]:
            print(f"{uc['id']}  writes: {uc['writes']}")
    print("\nRead ECC through an interface (OData on Gateway, BAPI, IDoc, replication), never by")
    print("reading tables directly. The successor tells you what the adapter will call after the move.")


# ---------------------------------------------------------------------------
# 3. One invoice check, two adapters (E01)
# ---------------------------------------------------------------------------
# Course tolerance, as for CP10: review above +5% or +250 per item (here in EUR).
PCT_LIMIT, ABS_LIMIT = 0.05, 250.00

# Supplier key map from the data migration plan: 20000007 (Ridgeline in CP20)
# extends 20000003, and 20000004 (a Tamsfield duplicate) merges into 20000002.
SUPPLIER_MAP = {"20000007": "20000003", "20000004": "20000002"}

# Invoice lines as an extraction step would return them (course sample).
INVOICES = [
    {"invoice": "PSH-27-0211", "supplier": "20000011", "po": "4500001204",
     "material": "CP-BAR42", "qty": 1500, "price": 2.85},
    {"invoice": "TF-88214", "supplier": "20000002", "po": "4500001201",
     "material": "CP-CAST200", "qty": 120, "price": 44.20},
    {"invoice": "RBS-E-4471", "supplier": "20000007", "po": "4500001203",
     "material": "CP-BRG6310", "qty": 40, "price": 18.40},
]

# ECC side: rows of Augsburg's PO extract interface (course column names).
ECC_PO_ROWS = [
    {"po": "4500001201", "item": "10", "supplier": "20000002", "material": "CP-CAST200",
     "ordered": 200, "received": 120, "net_price": 41.50, "currency": "EUR"},
    {"po": "4500001203", "item": "10", "supplier": "20000007", "material": "CP-BRG6310",
     "ordered": 40, "received": 0, "net_price": 18.40, "currency": "EUR"},
    {"po": "4500001204", "item": "10", "supplier": "20000011", "material": "CP-BAR42",
     "ordered": 1500, "received": 1500, "net_price": 2.85, "currency": "EUR"},
]

# S/4HANA side: the same POs after the move, shaped like the purchase order API
# (API_PURCHASEORDER_PROCESS_SRV entities A_PurchaseOrder and A_PurchaseOrderItem).
# Received quantities come from PO history; here a course summary stands in for it.
S4_PO_HEADERS = [
    {"PurchaseOrder": "4500001201", "Supplier": "20000002", "CompanyCode": "CP20"},
    {"PurchaseOrder": "4500001203", "Supplier": "20000003", "CompanyCode": "CP20"},
    {"PurchaseOrder": "4500001204", "Supplier": "20000011", "CompanyCode": "CP20"},
]
S4_PO_ITEMS = [
    {"PurchaseOrder": "4500001201", "PurchaseOrderItem": "10", "Material": "CP-CAST200",
     "OrderQuantity": "200", "NetPriceAmount": "41.50", "NetPriceQuantity": "1",
     "DocumentCurrency": "EUR"},
    {"PurchaseOrder": "4500001203", "PurchaseOrderItem": "10", "Material": "CP-BRG6310",
     "OrderQuantity": "40", "NetPriceAmount": "18.40", "NetPriceQuantity": "1",
     "DocumentCurrency": "EUR"},
    {"PurchaseOrder": "4500001204", "PurchaseOrderItem": "10", "Material": "CP-BAR42",
     "OrderQuantity": "1500", "NetPriceAmount": "2.85", "NetPriceQuantity": "1",
     "DocumentCurrency": "EUR"},
]
S4_RECEIVED = {("4500001201", "10"): 120, ("4500001203", "10"): 0, ("4500001204", "10"): 1500}


def ecc_adapter(po: str, material: str):
    """ECC today: read the PO extract interface, return the course's own PO item shape."""
    for row in ECC_PO_ROWS:
        if row["po"] == po and row["material"] == material:
            return {"po": row["po"], "item": row["item"], "supplier": row["supplier"],
                    "ordered": float(row["ordered"]), "received": float(row["received"]),
                    "price": float(row["net_price"]), "currency": row["currency"]}
    return None


def s4_adapter(po: str, material: str):
    """S/4HANA after the move: same shape, from API records (strings in OData V2 JSON)."""
    head = next((h for h in S4_PO_HEADERS if h["PurchaseOrder"] == po), None)
    for it in S4_PO_ITEMS:
        if head and it["PurchaseOrder"] == po and it["Material"] == material:
            per = float(it["NetPriceQuantity"]) or 1.0
            return {"po": po, "item": it["PurchaseOrderItem"], "supplier": head["Supplier"],
                    "ordered": float(it["OrderQuantity"]),
                    "received": float(S4_RECEIVED.get((po, it["PurchaseOrderItem"]), 0)),
                    "price": float(it["NetPriceAmount"]) / per, "currency": it["DocumentCurrency"]}
    return None


def check_line(inv: dict, item, supplier_map: dict) -> str:
    """The core rule. It never changes when the system underneath does."""
    if item is None:
        return "review: no matching PO item"
    supplier = supplier_map.get(inv["supplier"], inv["supplier"])
    if supplier != item["supplier"]:
        return f"review: supplier {inv['supplier']} is not the PO's supplier {item['supplier']}"
    open_qty = item["received"]
    if inv["qty"] > open_qty:
        return f"review: invoiced {inv['qty']:g}, received {open_qty:g}"
    diff = (inv["price"] - item["price"]) * inv["qty"]
    if inv["price"] > item["price"] * (1 + PCT_LIMIT) or diff > ABS_LIMIT:
        pct = (inv["price"] / item["price"] - 1) * 100
        return f"review: price {inv['price']:.2f} vs {item['price']:.2f} (+{pct:.1f}%)"
    return "propose posting"


def adapter_demo() -> int:
    print("Same check, two systems underneath\n")
    print(f"{'Invoice':<12} {'PO':<11} {'On ECC (before July 2027)':<36} On S/4HANA (after)")
    differ = 0
    for inv in INVOICES:
        before = check_line(inv, ecc_adapter(inv["po"], inv["material"]), {})
        after = check_line(inv, s4_adapter(inv["po"], inv["material"]), SUPPLIER_MAP)
        differ += before != after
        print(f"{inv['invoice']:<12} {inv['po']:<11} {before:<36} {after}")
    print(f"\n{differ} difference(s). Only the adapters and the supplier key map changed.")
    print("Every line is a proposal; a person posts or rejects it.")
    return 1 if differ else 0


def online() -> int:
    try:
        with urllib.request.urlopen(CR_URL, timeout=90) as resp:
            data = json.load(resp)
    except OSError as err:
        sys.exit(f"Could not download SAP's file: {err}. The offline modes still work.")
    found = {}
    for item in data.get("objectReleaseInfo", []):
        key = item.get("objectKey", "").upper()
        if key in SUCCESSORS:
            found[key] = [s.get("objectKey", "").upper() for s in item.get("successors", [])]
    changed = 0
    for table, succ in SUCCESSORS.items():
        now = found.get(table)
        ok = now is not None and succ in now
        changed += not ok
        print(f"{'OK     ' if ok else 'CHANGED'}  {table:<5} course: {succ:<28} SAP now: {', '.join(now) if now else 'not listed'}")
    print(f"\n{changed} change(s) since 2026-10-31.")
    return 1 if changed else 0


def main() -> None:
    ap = argparse.ArgumentParser(description="Plan AI on CP20's ECC before the move (course example).")
    ap.add_argument("--explain", metavar="ID", help="show the numbers behind one decision")
    ap.add_argument("--reuse", action="store_true", help="list ECC objects and S/4HANA successors")
    ap.add_argument("--adapter", action="store_true", help="run one invoice check on ECC and S/4HANA data")
    ap.add_argument("--online", action="store_true", help="re-check successors against SAP's file")
    args = ap.parse_args()
    if args.explain:
        explain(args.explain)
    elif args.reuse:
        reuse()
    elif args.adapter:
        sys.exit(adapter_demo())
    elif args.online:
        sys.exit(online())
    else:
        register(Path(__file__).resolve().parent)


if __name__ == "__main__":
    main()

#Step 3: Build the register

1. Run:

   • Windows (PowerShell):

     Copy

     python unit12\ecc_ai_plan.py

   • macOS / Linux:

     Copy

     python unit12/ecc_ai_plan.py

2. You should see exactly this:

CP20 AI register, key date 2026-10-31, go-live in S/4HANA 2027-07-05

ID   Decision          Build USD   Before  Net 12m  Rule
E01  Invest now           21,600   20,520   39,420  pays back after go-live if built to move
E02  Wait                 10,800        0        -  no evidence that anyone needs it
E03  Invest now            4,500   10,350   22,950  pays back before go-live
E04  Tie to migration          0        0        -  depends on SAP's terms for the move
E05  Tie to migration      7,200        0        -  the value is in the migration itself
E06  Wait                 13,500    5,610   -7,890  does not pay back and does not survive the move

Wrote ecc_ai_register.md. Amounts are course values, not SAP or customer figures.

The script also wrote unit12/ecc_ai_register.md, a table you can paste into a design document. "Net 12m" shows only for operational ideas with demand; the others are decided by a rule before any arithmetic.

#Step 4: Explain one decision

1. Run:

   • Windows (PowerShell):

     Copy

     python unit12\ecc_ai_plan.py --explain E01

   • macOS / Linux:

     Copy

     python unit12/ecc_ai_plan.py --explain E01

2. You should see:

E01  Extract Augsburg supplier invoices with document AI
  pattern            extract
  demand evidence    1,000 invoices a month keyed by hand
  driver             operations
  build              24 days x 900 = 21,600 USD
  before go-live     5.7 months x 3,600 = 20,520 USD
  survives the move  yes, 12 months after = 43,200 USD
  rework, adapter    2,700 USD   net 39,420 USD
  rework, direct     12,960 USD   net 29,160 USD
  decision           Invest now: pays back after go-live if built to move

Read the last three lines. Invoice extraction doesn't pay back before July 2027 (20,520 against 21,600 USD), but it survives the move. Built with an adapter, the rewrite costs 2,700 USD. Built straight onto ECC, the course assumes 60% of the build is redone, which costs 10,260 USD more. That difference is the price of throwaway work. Try --explain E06 to see a tool that fails both tests.

#Step 5: List what each idea reads, and its successor

1. Run:

   • Windows (PowerShell):

     Copy

     python unit12\ecc_ai_plan.py --reuse

   • macOS / Linux:

     Copy

     python unit12/ecc_ai_plan.py --reuse

2. You should see:

What each use case reads in ECC, and what replaces it in S/4HANA

E01  EKKO                       -> I_PURCHASEORDERAPI01
E01  EKPO                       -> I_PURCHASEORDERITEMAPI01
E01  EKBE                       -> I_PURCHASEORDERHISTORYAPI01
E01  LFA1                       -> I_SUPPLIER
E01  writes: invoice by IDoc through the integration layer
E02  EKKO                       -> I_PURCHASEORDERAPI01
E02  EKPO                       -> I_PURCHASEORDERITEMAPI01
E02  EKET                       -> I_PURORDSCHEDULELINEAPI01
E03  VBAK                       -> I_SALESDOCUMENT
E03  VBAP                       -> I_SALESDOCUMENTITEM
E03  I_PURCHASEORDERITEMAPI01      already a released S/4HANA object (CP10)
E04  reads nothing itself (SAP delivers it)
E05  LFA1                       -> I_SUPPLIER
E05  KNA1                       -> I_CUSTOMER
E06  EKPO                       -> I_PURCHASEORDERITEMAPI01
E06  EKET                       -> I_PURORDSCHEDULELINEAPI01
E06  writes: PO item dates through SAP GUI screens

Read ECC through an interface (OData on Gateway, BAPI, IDoc, replication), never by
reading tables directly. The successor tells you what the adapter will call after the move.

Every table on the left has a released successor on the right, so each idea has a known target after the move. E03 already reads one S/4HANA object, because the other side of the intercompany price is CP10's purchase order. E06 writes through screens, which have no successor at all: one more reason it waits.

#Step 6: Run one check on ECC and on S/4HANA

1. Run:

   • Windows (PowerShell):

     Copy

     python unit12\ecc_ai_plan.py --adapter

   • macOS / Linux:

     Copy

     python unit12/ecc_ai_plan.py --adapter

2. You should see:

Same check, two systems underneath

Invoice      PO          On ECC (before July 2027)            On S/4HANA (after)
PSH-27-0211  4500001204  propose posting                      propose posting
TF-88214     4500001201  review: price 44.20 vs 41.50 (+6.5%) review: price 44.20 vs 41.50 (+6.5%)
RBS-E-4471   4500001203  review: invoiced 40, received 0      review: invoiced 40, received 0

0 difference(s). Only the adapters and the supplier key map changed.
Every line is a proposal; a person posts or rejects it.

The same three invoice lines get the same answers on both systems. Two things changed underneath. The S/4HANA records use the purchase order API's field names (NetPriceAmount, OrderQuantity) and strings, as OData V2 JSON does. Ridgeline's supplier number changed from 20000007 to 20000003 in the migration, so the S/4HANA adapter applies the key map. Without it, the third line would fail on a supplier mismatch. The script exits with code 0 when both sides agree and 1 when they don't, so a test pipeline can run it.

#Step 7: Re-check the successors online (optional)

SAP updates the Cloudification Repository regularly. This step checks the script's SUCCESSORS against SAP's current private cloud file.

1. Run:

   • Windows (PowerShell):

     Copy

     python unit12\ecc_ai_plan.py --online

   • macOS / Linux:

     Copy

     python unit12/ecc_ai_plan.py --online

2. After a few seconds you should see (on 31 October 2026):

OK       EKKO  course: I_PURCHASEORDERAPI01         SAP now: I_PURCHASEORDERAPI01
OK       EKPO  course: I_PURCHASEORDERITEMAPI01     SAP now: I_PURCHASEORDERITEMAPI01
OK       EKET  course: I_PURORDSCHEDULELINEAPI01    SAP now: I_PURORDSCHEDULELINEAPI01
OK       EKBE  course: I_PURCHASEORDERHISTORYAPI01  SAP now: I_PURCHASEORDERHISTORYAPI01
OK       LFA1  course: I_SUPPLIER                   SAP now: I_SUPPLIER
OK       KNA1  course: I_CUSTOMER                   SAP now: I_CUSTOMER
OK       VBAK  course: I_SALESDOCUMENT              SAP now: I_SALESDOCUMENT
OK       VBAP  course: I_SALESDOCUMENTITEM          SAP now: I_SALESDOCUMENTITEM

0 change(s) since 2026-10-31.

A CHANGED line means SAP's entry differs from the script's copy. Look the table up in the repository and update SUCCESSORS.

#Step 8: Save your work in Git

git add unit12/ecc_ai_plan.py unit12/ecc_ai_register.md
git commit -m "Add Calder pre-migration AI register"

#What each part of the code does

#If something goes wrong

This script needs no API key, so key problems don't apply here.

#The SAP way

As of October 2026, these are the SAP pieces an ECC customer can use for AI before migrating. Each needs its own license and setup.

• Joule assistants and agents on ECC. Offered to customers who commit to moving most of their landscape to SAP Cloud ERP (SAP News, May 2026). SAP's 7 October 2026 blog says customers on the RISE journey who meet minimum cloud commitments can enable them on ECC. Activation is free for up to three assistants, in finance, supply chain and spend; the Max Success Plan widens it (sap.com blog). SAP's Sapphire guide says the Max Success Plan covers "eligible on-premises systems" with general availability planned for May 2026 (SAP Sapphire guide). The pages don't list which assistants run against ECC data. Ask SAP for the list for your release, and which back-end calls each one makes. For Joule itself, see Joule and Joule Studio.
• SAP Document AI. A BTP service that extracts data from documents (Document AI, built and bought). SAP's Architecture Center lists three posting patterns: a direct API call, an Integration Suite flow that converts to IDoc, SOAP or REST for cloud or on-premise targets, and a CAP service that posts through the Cloud Connector with OData or RFC (SAP Architecture Center). Its examples name S/4HANA, not ECC. The IDoc and RFC routes are the ones that reach ECC, but test them with your own ECC message types.
• Generative AI hub in SAP AI Core. Model access with orchestration, masking and filtering, called from a BTP application (SAP's generative AI hub). It doesn't touch ECC; your application does.
• Integration Suite and Cloud Connector. The route from BTP into ECC, and the place to put IDoc and SOAP conversions (Integration platform and clean core).
• Datasphere in Business Data Cloud. Replicates ECC data for analytics, and keeps ECC history after the system is switched off. SAP-managed data products come from SAP's cloud applications; plan ECC data as a custom load (Reporting and analytics architecture).

Licensing notes. BTP services are paid by consumption or subscription. Joule on ECC is tied to cloud commitments. Ask for the commitment terms in writing before you plan around them. An October 2026 SAP article says that after 2030, SAP's support for third-party databases under Business Suite 7 ends, and so does Suite 7-to-S/4HANA conversion tooling from them (SAP News). A pre-migration AI plan that assumes ECC runs past 2030 needs that checked.

#Build vs. SAP

Buy vs. build for SAP AI gives the general method; the pre-migration twist is the extra question "does it survive the move?".

#Architecture view

Where it sits. Calder's pre-migration AI runs on BTP, beside both systems:

flowchart LR
  subgraph DC[Augsburg data center]
    ECC[(ECC CP20)]
    CC[Cloud Connector]
  end
  subgraph BTP[SAP BTP]
    IS[Integration Suite]
    APP[Invoice app<br/>core + adapters]
    DOX[Document AI]
  end
  S4[(S/4HANA CP10<br/>RISE)]
  ECC --- CC
  CC -->|RFC, OData| APP
  APP --> DOX
  APP -->|IDoc| IS --> CC
  APP -->|released APIs| S4

Non-functional requirements that decide the design

Integration and identity. Data flows through the Cloud Connector: RFC or OData reads on ECC, IDoc posting through Integration Suite, released APIs on S/4HANA. The tool proposes; a person in accounts payable approves, and the approval is recorded with that person's identity (Human approval in AI workflows). ECC roles and S/4HANA roles differ, so plan the tool's S/4HANA technical user and the approvers' roles as part of the rollout's role design (Roles and authorization design).

The decision to record (in the ADR form from Writing a solution design doc):

• Context: Augsburg keys about 1,000 supplier invoices a month in ECC. CP20 moves into CP10's S/4HANA on 5 July 2027. The invoice tool would run on ECC for about six months.
• Options: (1) wait for S/4HANA; (2) build an ABAP add-on in ECC that calls a model; (3) build on BTP with an ECC adapter now and an S/4HANA adapter before go-live.
• Decision: (3). It doesn't pay back before go-live, but it survives the move with a three-day adapter rewrite.
• Consequences: Calder runs two adapters during the rollout's test cycles. The S/4HANA adapter must apply the supplier key map from the migration. The ECC adapter is retired the day after go-live, with its technical user locked.

What a design review will ask

1. What exactly is rewritten at the migration, and how many days does it take?
2. Which ECC objects does the tool read, and what are their S/4HANA successors?
3. Does the tool write to ECC, and who approves each write?
4. How is the tool tested on S/4HANA before go-live, with migrated data and key maps?
5. Has SAP confirmed in writing which Joule assistants we get on ECC, and would one replace this tool?

#Production concerns

• Security and SAP authorizations. ECC technical users tend to be broad. Give the tool's user only the read services and posting messages it needs. Lock it after go-live. Never let the AI post without a person's approval (Agent permissions and SAP authorizations).
• Evaluation. Keep the test set (invoices with known right answers) outside both systems. Run it on ECC now and on S/4HANA during the migration's test cycles; the results must match, as in Step 6.
• Cost. Track build, adapter, run and rewrite costs per use case. Re-run the payback test when the go-live date moves; a slip lengthens the ECC value window.
• Operations. Name an owner and a retirement date for every ECC-only part: adapter, technical user, Cloud Connector route, IDoc partner setup.
• Clean core. Don't add ABAP enhancements to ECC for AI. They become custom code to analyze, adapt or retire in the migration (Fit-to-standard and extension choices).

#Pitfalls

• Reading tables because it's quick. A generic table read through RFC works on ECC and has no clean path forward. Use or build a service, and write down its successor.
• Letting the ECC shape leak into the core. If ECC field names appear in prompts, rules or the user interface, the "adapter" is the whole tool.
• Forgetting the key map. Suppliers and customers keep quoting old numbers after go-live; the tool must translate them.
• Assuming SAP's offer applies. Joule on ECC depends on contract terms. Get the list of assistants and the conditions before you cancel your own build.
• Ignoring the date. A go-live that moves forward kills the payback of tools that rely on value before go-live. A slip extends it.
• Building what S/4HANA's standard will do. Check the target release's standard features first. A tool can still be worth it for the months before go-live, if it pays back in that window.

#Exercise

Add a seventh idea to Calder's register and test whether it survives the move. The result feeds AI in S/4HANA migration projects, where AI supports the migration project itself.

1. Open unit12/ecc_ai_plan.py and add this entry at the end of USE_CASES (before the closing ]):

   Copy

   {"id": "E07", "name": "Predict late deliveries from Augsburg's suppliers",
    "pattern": "predict", "driver": "operations", "demand": "planners expedite every week",
    "build_days": 10, "live": date(2027, 2, 15), "monthly_usd": 1800, "survives": True,
    "adapter_days": 2, "rebuild_share": 0.7,
    "reads": ["EKKO", "EKPO", "EKET", "EKBE"], "writes": None},

2. Run python unit12/ecc_ai_plan.py (on Windows, python unit12\ecc_ai_plan.py) and find the E07 line.

3. Run --explain E07 and note the value before go-live, the rework with and without an adapter, and the net.

4. Change "survives": True to "survives": False for E07 and run the register again. Write one sentence on why the decision changed.

5. Run --reuse and check that every object E07 reads has a successor.

6. Change E07 back to "survives": True and commit the script and the new ecc_ai_register.md.

Done when the register shows E07 Invest now with a Net 12m of 19,080, it changes to Wait when E07 doesn't survive the move, and --reuse lists four successors for E07.

#Check yourself