Each scenario follows the same flow: a TCOMP variant runs on schedule, hits every target system over RFC, and produces a colour-coded row plus a ServiceNow incident — open while the deviation lasts, auto-closed when the next clean run lands.
Article master data team · daily variant
Article 100020 was extended to sales org
ER01 in System A ten days ago. The replication should have
propagated MARC + MVKE rows to System D within hours, but
something stalled. From the source system everything looks fine;
from System D the article doesn't yet exist for the new
sales org.
TCOMP's daily variant joins MARA + MARC + MVKE across all four
systems on the (Article, Sales Org, Distribution Channel) key.
System D returns no row for that key — TCOMP renders it
as Missing data.
PMD_05_MARC_05
VariantPMD_05_DAILY
"Article 100020 — key combination missing in System D for sales org ER01. Replication may have failed."
Business Partner team · daily variant
Vendor 1004563 updated its shipping address. The
change was made directly on System B — bypassing the
usual System A-driven flow — and the local update never made it back
to the source system or out to your other connected systems.
TCOMP's BP-address variant compares BUT020 +
ADRC across all systems on the (BP) key. The street
and postal code match for three systems and disagree on a
fourth.
BP_ADDR_05
VariantBP_DAILY
"Vendor 1004563 — street and postcode differ on System B vs. System A/System C/System D. Local update on System B not yet replicated back."
Contract management team · weekly variant
Contract 4500876123 got a one-month extension in System A
(KDATB pushed from 2026-08-30 → 2026-09-30). The transport carrying
the change reached System B and System C but
failed quietly on System D. From the buyer's view in System A
everything looks fine; the planner on System D
is still working with the old expiry.
CONTRACT_05_EKKO_05
VariantCONTRACT_WEEKLY
"Contract 4500876123 — KDATB out of sync between System D and the rest of the landscape. Likely failed transport TR-System A-244183."
Pricing & conditions team · daily variant
Condition record 0000812044 for article
200034 has a validity end date of
2026-08-30 in System A / System B / System C, but
2026-08-15 in System D — a difference
of 15 days at the end of a promotion campaign.
The field is configured as Warning rather than Error: the team wants visibility, but the difference isn't necessarily wrong (legal calendars vary). The result row is amber, and a low-severity SNOW incident is opened for review.
PRICE_KONP_05
VariantPRICE_DAILY
"Condition 0000812044 (article 200034) — validity end differs by 15 days in System D. Confirm calendar before closing."
Customising lead · weekly variant (TCOMP_CUST)
A new plant 9012 was created directly in System B last
sprint to support a temporary cross-dock site. The
customisation never landed in System A or in the sister regions —
the table T001W now diverges by one row.
TCOMP's customising-tables variant picks this up on its weekly run. Because the comparison is on the customising cluster, not master data, the result auto-resolves once the plant is either rolled out everywhere or removed from System B.
CUST_T001W_05
VariantCUST_WEEKLY
Once plant 9012 was rolled out via standard customising transport (or removed from System B), the next weekly run found the four systems aligned — TCOMP closed the incident with the standard auto-close note.
Whatever the data — articles, partners, contracts, pricing, customising — the shape is the same. Define a View, save a Variant, schedule the run. The colour grid and the SNOW lifecycle do the rest.
How to install → Back to overview