For SAP architects
We strengthen SAP’s integrity model. Never around it.
The questions you will ask on the first call, answered the same way every time. If something is not precise enough for your landscape, ask — we would rather come back to you than improvise.
How a record reaches SAP Write is done by SAP
Your sources
SAP ECCJD EdwardsDynamics / NAVLegacy & files
vise DMW
ValidateProfileMapLoad SimApprove
Business rules on top of SAP checks; dry run against your customizing; named approver. Your SAP
BAPIIDocOData / RAPMigration Cockpit
CVI, customizing, BAdIs, number ranges, change documents — all on. Direct writes to KNA1, LFA1, BUT000 or any SAP table — never.
01
Six things that are always true.
01 Standard interfaces only Every load goes through BAPI, IDoc or OData/RAP — or through SAP Migration Cockpit if you prefer to keep it. DMW never writes to KNA1, LFA1, BUT000 or any other table directly.
02 SAP integrity stays on CVI synchronisation, customizing checks, BAdI/exit validation, number ranges, authorisations, change documents (CDHDR/CDPOS) — all of it runs exactly as it would for any SAP-approved tool, because the write is done by SAP.
03 A second layer of validation, not a replacement SAP checks whether it will accept the record. vise DMW checks whether your business can work with it: cross-object consistency, regulatory formats, financial governance, business policy, workflow prerequisites, master-data coherence.
04 Simulation before every load The load is dry-run against your target system with your customizing. The target validates every record as it would on the real load, so you see the same errors — per record, before anything is committed.
05 AI drafts, people approve Field mappings, transformation rules and validation rules can be drafted by AI. Every proposal is versioned, tested in a sandbox and switched on by a named person. Nothing the AI writes touches your target unapproved.
06 Audit-ready from day one Every transformation, value change and merge decision is recorded with the user, the time and the rule applied. Cross-reference tables (legacy KUNNR / LIFNR → target PARTNER) are produced natively.
02
The load engine is your decision.
DMW is agnostic about the load mechanism. The built-in loader is the default; every other path gets the same pre-validated data.
| Path | When | What DMW delivers |
|---|---|---|
| Built-in DMW loaderDefault | Default. One click from DMW; BAPI, IDoc or OData chosen per object and configuration. | End-to-end in one tool, load audit joined to validation and transformation audit, real-time monitoring and error handling in the DMW UI. |
| SAP Migration Cockpit (LTMC / LTMOM) | You already run it, your integrator standardises on it, or a predefined migration object fits the scope exactly. | Files in the Cockpit template format, pre-validated so the upload has no surprises, mapping to the migration-object structure. |
| BAPI | Default for many objects including Business Partner in CVI scenarios; custom objects without a Cockpit template. | Payloads per BAPI structure (BAPI_BUPA_CREATE_FROM_DATA, BAPI_BUPA_ROLE_ADD, CVI_FS_BP_BAPI_*…), mandatory fields per BP category and role, batched commits, retry logic. |
| IDoc | Master-data distribution across a landscape; ALE infrastructure in place; DEBMAS / CREMAS with CVI generating the BP. | Segment-correct IDoc payloads, pre-validated so WE02 / SM58 stay clean, status monitoring and recovery. |
| OData / RAP | S/4HANA Cloud and Public Cloud, continuous data flows after go-live, API Business Hub integrations. | API_BUSINESS_PARTNER and RAP services, token handling, batching and error handling. |
| Your own loader or BODS | You have a custom loader, an ETL pipeline or BODS and want to keep it. | Clean, pre-validated datasets in your format (CSV, XML, JSON, staging tables), transformation history and the documented mapping rules. |
What DMW never does: direct database writes to SAP tables, bypassing module-level validation, or pseudo-RFC tricks into internal tables.
03
SAP asks whether it will accept the record. We ask whether your business will work with it.
Field formats, mandatory fields, customizing and BAdI checks are SAP’s layer — Migration Cockpit, LSMW and BODS validate against them. A record can pass all of it and still be unusable: a vendor assigned to a purchasing organisation outside the plant’s hierarchy, a VAT number with the right length and a wrong checksum, payment terms outside purchasing policy, a strategic customer without a key account manager. Those are silent errors; they surface months after go-live, in accounting or in a blocked approval. DMW’s rule library is where your business defines them once, and every record is checked before the load.
Cross-object consistencyVendor ↔ purchasing org ↔ plant; cost centre ↔ profit centre ↔ company code; sales area ↔ plant.
Regulatory formatsNIP, USt-IdNr, GB VAT, EIN — with checksums; industry identifiers; GDPR retention flags.
Financial governanceBank country vs. seat, beneficial-owner data, credit limits vs. approval, sanctions exposure.
Business policyPayment terms per supplier category, discount caps per segment, pricing vs. brand rules.
Workflow prerequisitesKey account manager per strategic customer, cost-centre owner, planner per material.
Master-data coherencePrice conditions per sales area, info records per purchasing org, equipment ↔ functional location.
04 · Customer Vendor Integration
CVI is routine work here, not a risk item.
DMW prepares; SAP executes. The record that reaches CVI is already consistent.
- 01Customer + vendor merge
- Deterministic and fuzzy matching on name, VAT ID, address and bank account; one BP candidate with FLCU01 + FLVN01; discrepancies flagged for a business decision; cross-reference table for audit and reconciliation.
- 02BP grouping and number ranges
- Legacy account groups mapped to your BP groupings from customizing; required fields validated per grouping before the load.
- 03BP category
- Person / Organisation / Group derived from legacy data and checked against the roles each record carries.
- 04Addresses, tax numbers, bank data
- Primary and additional addresses to BUT020/BUT021; STCD1–3 / STCEG mapped to S/4 tax number types and validated per country; IBAN and bank key checked against BNKA.
05
Where it runs.
- Hosting
- AWS (ECS)
- Connectivity
- VPN to customer systems; no inbound access to your network
- Access
- Role-based (CAS), per programme / project / site
- Encryption
- In transit and at rest
- Certifications
- ISO/IEC 27001, ISO 9001
- AI
- No personal data in AI prompts; proposals only, approved by people
Technical Q&A.
- 01Does DMW need Migration Cockpit to work?
- No. vise DMW has its own load engine using standard SAP interfaces. Cockpit is an option, not a requirement: if you keep it, DMW delivers the pre-validated dataset for the upload.
- 02S/4HANA Public Cloud, where there is no direct DB or classic BAPI access?
- OData / RAP APIs (API_BUSINESS_PARTNER and friends) — the native SAP path for Public Cloud. Direct database access is neither possible nor needed.
- 03What about performance at 5M+ records?
- Load throughput depends on the target, the interface and your BAdIs. DMW batches per interface (parallel BAPI processing, IDoc packaging). We do not quote numbers without a benchmark on your data — that is what the PoC is for.
- 04Custom BP roles or groupings?
- Validation rules are configuration, not code we have to ship. Custom roles with their mandatory fields and custom groupings are added per customer.
- 05What happens when one record fails CVI sync during a load?
- Record-level retry, batch isolation and an error queue. The failed record goes to correction, the rest of the load continues, the record is re-processed after the fix.
- 06BP relationships (BUT050)?
- A separate object class in the mapping. Primary BPs first, then relationships (contact person → organisation), in the sequence CVI expects.
- 07Greenfield S/4 with a non-SAP source?
- Yes. Any source: legacy ERP, Excel, staging tables, files. Carve-outs and M&A integrations are typical.
- 08Corrections after go-live?
- That is vise Data Run: the same validation library, optimised for recurring mass changes instead of one-off migration.
- 09SAP partnership or certification?
- Visehub is not an SAP partner, by choice. vise DMW works through SAP’s released interfaces (BAPI, IDoc, OData/RAP, Migration Cockpit) under your own SAP licence, so nothing in it depends on a partner programme — and there is no partner margin in our price.
Bring your landscape diagram. We bring the answers.
A 60-minute technical session with the people who built the load engine — not a sales call.