S/4HANA Simplification Items and Readiness Check Explained

Every S/4HANA conversion project starts with the same nervous question: "What breaks?" SAP redesigned — simplified — hundreds of tables, transactions, and data models on the road from ECC to S/4HANA. The MATDOC table replaced a family of inventory tables; the universal journal (ACDOCA) swallowed FI and CO line items whole; custom code that read the old tables needs attention. Simplification items are SAP's catalog of every such change, and the Readiness Check is the tool that maps that catalog onto your system.

---

What a simplification item is

A simplification item is a documented change between ECC and S/4HANA: what changed, why, what you must do about it, and how critical it is. Each item carries a category — mandatory (you must act, e.g. adopt the new asset accounting), conditional (act only if you use the affected functionality), or informational — plus a detailed description with links to SAP Notes.

There are hundreds of them, which is exactly why nobody reads the catalog cover to cover. You need the subset that applies to your system: the transactions your users actually run, the tables your custom code actually reads, the modules you've actually licensed. That's the Readiness Check's job.

Key takeaway: Simplification items = SAP's catalog of every functional and technical change in S/4HANA. The Readiness Check filters that catalog down to what matters for your specific system.

---

Running the Readiness Check

The Readiness Check runs against your ECC system (via the SAP Readiness Check service / Simplification Item Check) and produces a dashboard: which simplification items are relevant to you, their categories, and the required follow-up activities. The typical flow:

1. Run the data collection in the source system — it inventories transactions used, tables accessed, custom code, add-ons, and business functions active.
2. Upload/analyze — the service cross-references your inventory against the simplification item database for your target S/4HANA release.
3. Review the dashboard — relevant items grouped by area (finance, logistics, technical), each with effort indicators.
4. Plan from it — mandatory items become project work packages; conditional items get owners to confirm relevance.

Run it early — during the discovery/prepare phase, not two weeks before conversion. The check shapes scoping, timeline, and budget; running it late turns findings into surprises.

---

Reading the results like a project manager

The dashboard's real value is prioritization. Mandatory items are non-negotiable scope — schedule them first. High-effort conditional items in modules you use heavily deserve proof-of-concepts early (custom code remediation for a heavily customized module is where timelines go to die). Informational items become training content, not project tasks.

Watch for the custom code findings specifically. The check flags custom programs touching simplified tables or removed function modules — that's your ABAP remediation backlog, quantified. "We have 340 findings in FI custom code" is a plannable statement; "we have some custom code issues" is not.

And re-run the check as the project progresses. Remediated items should drop off; newly discovered usage (that department that "doesn't use WM" but does) adds items. The dashboard is a living backlog, not a one-time report.

---

The usual suspects: items that bite hardest

Certain simplification items show up in nearly every conversion, so they're worth knowing by name. The universal journal (ACDOCA) merged FI and CO line items into one table — the old tables still exist as compatibility views, but custom code reading them directly needs review. MATDOC replaced the MSEG/MKPF inventory document tables the same way. Business partner (CVI) integration is mandatory: customers and vendors become business partners, and any code or interface still speaking "customer number" needs mapping. The material number field length extension (18 to 40 characters) breaks fixed-length assumptions in custom code and interfaces. And credit management migrated to a new architecture — old credit-check customizations don't carry over.

If your Readiness Check flags these, you're in normal territory. Budget remediation time for each, and tackle the mandatory ones before the nice-to-haves.

---

Common gotchas

Stale results. The simplification database is release-specific. A check run against the 2023 item catalog doesn't cover a 2026 target release — re-run when the target release changes.

"Not relevant" without evidence. Marking conditional items irrelevant because nobody remembers using that functionality is how conversion weekend surprises are born. Confirm with usage data (the check itself provides it), not memory.

Ignoring the technical items. Functional teams review their modules; the technical items (archiving, interfaces, authorizations) need owners too. Unowned categories become nobody's problem until they're everybody's problem.

Treat the Readiness Check as the project's early-warning radar: run it early, staff the findings, re-run often. The conversions that go smoothly aren't the ones with no simplification items — they're the ones that knew about all of theirs in advance.

Read more →

Custom Fields and Logic in S/4HANA: Key-User Extensibility Explained

Not every business requirement needs a developer. A sales manager wants one extra field on the customer record. Finance wants a small validation before invoices post. In the old world, that meant a development request, a transport, and a wait. In S/4HANA, the Custom Fields and Logic Fiori app lets key users do it themselves — no ABAP, no Eclipse, no transport queue.

---

What key-user extensibility is

SAP's clean-core strategy draws a hard line: the core stays standard, and extensions happen at defined points. Key-user extensibility (sometimes called in-app extensibility) is the lowest rung of that ladder — changes a trained business user can make directly in the running system, through Fiori apps, without writing code in the traditional sense.

Custom Fields and Logic is the flagship app for this. It has two halves: Custom Fields for adding fields to SAP business contexts (customers, materials, sales orders, journal entries — hundreds of enabled contexts), and Custom Logic for adding small pieces of behavior at predefined enhancement points using a guided, form-based editor.

Key takeaway: Key-user extensibility = business users extending S/4HANA through Fiori apps, no developer needed. Custom Fields adds data; Custom Logic adds behavior — both within SAP-defined boundaries that keep the core clean.

---

Custom fields and the YY1_ namespace

Here's how it works in practice. Open the app, go to Custom Fields, and pick a business context — say, "Customer." Create a new field: give it a label, pick a type (text, number, date, checkbox, dropdown), and decide where it should appear. The system generates the field with a technical name in the YY1_ namespace, like YY1_LoyaltyTier_Customer.

That prefix matters. YY1_ is SAP's reserved namespace for key-user custom fields, and it's how the system (and every future upgrade) knows this field is yours, not SAP's. You'll never collide with a field SAP adds in a later release, because SAP will never create anything starting with YY1_. It's a small detail that prevents an entire class of upgrade headaches.

Once created, the field can be published to the places it needs to surface: the Fiori UI (it appears on the relevant object pages automatically), OData services, reports, and even forms. You control this per field — a field used only for internal segmentation doesn't need to clutter the customer-facing UI.

---

Custom logic without ABAP

The Custom Logic half is where it gets more interesting. SAP exposes enhancement options — predefined BAdI-like spots where custom code can run, such as "validate before saving a sales order" or "derive a value when a field changes." The key user picks an enhancement, and the app provides a guided scripting environment to implement it.

Let's be honest about the limits: this isn't a replacement for real development. The logic editor handles straightforward cases — validations, derivations, default values — and deliberately can't do the things that would threaten system stability (no direct database writes to standard tables, no wild COMMIT statements). When a requirement outgrows these guardrails, that's the signal to escalate to on-stack developer extensibility (ABAP Cloud) or side-by-side (BTP). Choosing the lowest tier that fits is the whole philosophy.

---

Transport and lifecycle

A common worry: "If a key user creates this in production, how does it get to the other systems?" In S/4HANA Cloud, custom fields and logic are captured in the tenant's extensibility inventory and move through the standard cloud transport mechanism — they're part of the software collection, versioned and transportable like any other configuration. In on-premise S/4HANA, they travel in regular transports.

Either way, the governance point stands: key-user extensibility still deserves oversight. Decide who may create custom fields (usually a small group of trained key users, not everyone with Fiori access), agree on naming conventions beyond the YY1_ prefix, and review the inventory periodically. A thousand orphaned custom fields is its own kind of technical debt.

It's also worth knowing which business contexts are enabled before you promise anything. SAP ships a few hundred of them, but not every object you'd like is covered — if the exact context you need isn't enabled, that's the point where key-user extensibility stops and developer extensibility begins. Check the "Business Context" view in the app first; it takes thirty seconds and saves awkward conversations later.

Used with a little discipline, Custom Fields and Logic is one of the highest-value apps in S/4HANA: real business requirements, delivered in hours instead of sprints, without touching the core. That's the clean-core promise working as intended.

Read more →