Special functions · Credit Master Loader

Mass-maintain SAP credit master data — planned, warned, and approved before a single write.

Bulk create and change SAP Credit Management master data — risk class, check rule, calculation rule, credit group, credit limit and validity, block reason, special-attention flag — through the released OData service, not screen scraping or Z-programs. Every file is planned read-before-write so unchanged rows are skipped and re-runs are safe; a partner with a calculation rule warns before an explicit limit overwrites it; and a credit-limit increase routes through an amount-banded approval before it applies. The same engine ships as a hosted demo and a clean-core Node loader.

Open the Credit Master Loader demo →

01 · The landscape

What the market has

SAP standard mass maintenance (UKM_BP / mass jobs)

In-GUI credit master maintenance + mass update jobs

The gap: No read-before-write preview, no per-row plan, no approval band on limit increases — and GUI-bound

Precisely Automate (Winshuttle)

Excel-to-SAP scripting that records screens

The gap: Per-user licensing, brittle to UI changes, no domain awareness (limit-rule overwrite) or approval semantics

Custom LSMW / BAPI Z-programs

In-core mass load programs

The gap: Clean-core violation, no preview, no governance — retested every upgrade

SAP MDG for credit

Full master-data governance suite

The gap: Standing up all of MDG to govern one object — heavyweight and expensive

02 · Differentiators

Where we differ

A read-before-write plan you see before anything is written — create-master / update-profile / create-segment / update-segment / skip per row, so re-running a file is idempotent and safe
Domain-aware: it warns when an explicit limit is written against a partner that has a score/limit calculation rule — a recalc would silently overwrite it, and generic mass tools don't know that
An approval band on credit-limit increases (2 / 4 / 6 eyes by size) — governance exactly where the risk is, without implementing full MDG
Runs on the released OData service (API_CRDTMBUSINESSPARTNER), clean-core — no Z-programs, no screen scraping, survives upgrades; the field mapping is reconciled against the live service $metadata

03 · Functionality

What we built

CSV / Excel change files with a fixed, documented column set → a per-row plan (create master, update profile, create/update segment, skip)
Read-before-write against current credit master: only genuine differences are written; unchanged rows are skipped and reported
$metadata-verified field mapping: risk class, check rule, calculation rule, credit group (BP node); credit limit + validity, block reason, special-attention flag (segment node)
Per-row limit-rule overwrite warning surfaced before commit
BCM-style approval band on credit-limit increases with a step-by-step audit trail
Deep-insert for brand-new partners (auto-adds the UKM000 credit role); direct-entity update for existing ones — the service's two documented patterns

See it working — today

The demo runs the complete loop on live data: capture, decide, govern, post, audit. No process change required on day one.

Open the Credit Master Loader demo

All special functions