Installation — TCOMP

1 Step FUNCTIONAL

Pick the tables, the join, the field-level check types

Decide what "in sync" means for this domain.

The product team that owns the data — articles, BPs, contracts, pricing, customising — decides the comparison shape. Which tables, joined how, which fields are display only, which trigger a warning, and which are an outright error if they drift.

TABLES

Most fundamental table at the lowest level; secondary tables joined upward via shared keys.

JOIN CONDITIONS

Per joined table — pairs of (this field) ↔ (that field), or a constant filter to narrow the upper-level rows.

FIELDS & CHECK TYPES

Display / Warning / Error / Exclude / Always Display. Key fields are always Display; extra keys can be Set Key on the fly.

LONG-TEXT & SYS. DEP.

Optional: long-text comparison (e.g. article description), system-dependent fields whose meaning differs per region.

Rule of thumb

If the View has ≤ 20 fields, batch size 400 000 is comfortable.
If it has more than 20, drop the batch size to 200 000 or less.
Keep the View on "In DB" compare mode (default). Local-memory mode is legacy.

2 Step DEVELOPER

Once per target system

Wire up the RFC connections to every system you'll compare against.

TCOMP fans out its dynamic SELECTs over standard SAP RFC. Each target system needs an RFC destination on the source system, plus a logical name in the RFC mapping table — that's what shows up as the column header on the result screen ("System B" instead of RFC_SYS_B).

RFC → System Name RFC mapping

RFC destination	System name	Description
`RFC_SYS_B`	`System B`	Connected system · 1
`RFC_SYS_C`	`System C`	Connected system · 2
`RFC_SYS_D`	`System D`	Connected system · 3
(local)	`System A`	Source system — comparisons run from here

Maintained once at deployment time. Functional teams never touch this — they just see "System B / System C / System D" on the result screen.

3 Step FUNCTIONAL

Save a SAP variant on the TCOMP main transaction

Pin the View to a target system, lock in the filters.

Run the TCOMP main transaction, pick the View, set the RFC target, choose the output mode (display, background, email, save), tick Merge (All systems in 1 line), set the status icons you care about, layer in basic selection criteria, and add Pro Conditions if you need free-form SQL sub-selects (e.g. dynamic date filters, "only articles extended to one sales org"). Save it as a regular SAP variant.

Master Data Management: Table Comparison Selection screen

Execution Parameters

View Name * BP

Compare with Current System

RFC Destination * RFC_SYS_B

Output Parameters

Mode Send to Email Display Save

Only Mismatches

Merge (All systems in 1 line)

Execute in Background

Status Criteria ✕

Selection Criteria

Tab. Lvl	Table	Field	Desc.	Value
1	`BUT000`	`TYPE`	Partn. Cat.	2
1	`BUT000`	`BU_GROUP`	Grouping	S100
1	`BUT000`	`XBLCK`	Central	(any)
… every field of every table in the View is selectable here.

The selection screen for view BP: pick the View, the RFC target, output options, status filters, and any field-level filters from the right pane. Hit Save as Variant… at the top to make this re-runnable.

That's the variant. Re-run it manually any time, or hand it off to the WLA job in step 4 to run on schedule.

4 Step DEVELOPER / OPS

Schedule via WLA · SM36 / SM37

Run the variant every day (or every week) — unattended.

The WLA team adds a step to an existing scheduled job, or creates a new one via SM36. Program the TCOMP main report, the Variant from step 3, the technical step-user.

The job hits each target system over RFC, batches the result via the temp tables, writes the run to the result table, and (if the View is wired up for SNOW — step 5) emits the ServiceNow payload at the end.

SM36 — Define Background Job SM36

Job name TCOMP_PMD_DAILY

Step program TCOMP main report

Variant PMD_05_DAILY

User WLA_TCOMP_USR

Schedule Daily 06:00

Want a one-off check after a transport? Run the variant manually from the TCOMP main transaction; or click "Re-execute" from the result screen on a previous run.

5 Step FUNCTIONAL + RSDF

One-time per Group · in the TCOMP RSDF area

Tell ServiceNow how the incident should look.

All the SNOW payload templates live in the Rules & Static Data Framework in the TCOMP RSDF area. Per Group (PMD, BP, CONTRACT, PRICING, CUST, …) you configure: Assignment Group, Impacted Service, Severity, Configuration Item, Knowledge Article, Short Description template, Description template, Comment template.

ZRSDF — Maintain Parameter ZRSDF

Area TCOMP

Object SNOW_TEMPLATES

Parameter PMD

Payload mapping

SNOW field	Value
Assignment Group	`MASTER_DATA_ARTICLE`
Impacted Service	`SVC_S4_MASTER_DATA`
Severity	`3`
Configuration Item	`SYS_A_S4HANA`
Short Description	"TCOMP · {VIEW} · {ERROR_COUNT} deviations"
Description	"Deviations between System A and {RFC_TARGET}. See Execution ID {EXEC_ID}…"

{VIEW}, {ERROR_COUNT}, {EXEC_ID}, {RFC_TARGET} get substituted at run-time. Same placeholders work for the comment that fires on each subsequent run.

One-time setup

Done by IT.

Per landscape, not per domain

Deploy the TCOMP objects on the source system
Wire up the RFC destinations (step 2)
Set technical job user in the TCOMP RSDF area (OBJECT GLOBAL · PARAM JOB_USER)
Set RFC mapping in ZRSDF AREA SYSTEM · OBJECT RFC_SYSTEMS

Per domain

Repeat for every comparison.

Hours, not days

Define the View — tables, joins, fields, check types
Save a Variant for each target / cadence
Schedule via WLA
Configure the SNOW Group templates in RSDF
Iterate as the data model evolves

First-time deployment per landscape: ~half a day of IT work (steps 2 + 5's RSDF skeleton). Each new domain afterwards: an afternoon of functional work, no developer involvement.

Five steps. Bring a new domain online in an afternoon.