sap-dtw-expert
SAP DTW Expert
Quick start
- Search
assets/TEMPLATE_INDEX.yamlbytable_codeorobject_nameto find the right template(s). - Read the target
.tsvfile — row 1 is the DI API field name (used by DTW), row 2 is a label (ignored by DTW). - Fill data from row 3 onward; every column in row 1 is available, only a subset is mandatory.
Template lookup
import yaml, pathlib
index = yaml.safe_load(pathlib.Path("assets/TEMPLATE_INDEX.yaml").read_text())
matches = [e for e in index if e["table_code"] == "OCRD"]
matches = [e for e in index if "BusinessPartner" in e["object_name"]]
matches = [e for e in index if e["module"] == "Business Partners"]
template_path = pathlib.Path("assets/templates") / matches[0]["path"]
rows = template_path.read_text(encoding="utf-8").splitlines()
di_fieldnames = rows[0].split("\t") # row 1 — DI API field names used by DTW
labels = rows[1].split("\t") # row 2 — labels (ignored by DTW)
Each index entry has: table_code, object_name, module, category, path.
Key rules
- Row 1 = DI API field names (what DTW maps to DB). Never change row 1 structure.
- Row 2 = display labels — free to rename, ignored by DTW.
- Multi-table objects: produce one TSV per table, load header first; child tables link via
ParentKey. - Custom fields: append
U_FieldNameto the end of row 1; DTW rejects unrecognised names. - Encoding: UTF-8 without BOM; no tab characters inside data values.
- DTW vs Service Layer: DTW for bulk migrations; Service Layer for real-time/programmatic writes.
- DTW vs DI API field names: DTW uses DI API COM property names (e.g.
FederalTaxID), not raw HANA column names (e.g.LicTradNum). Usesap-schema-expertto map them. - Service Layer field names: Service Layer is independent of the DI API — it shares most property names by convention but has exceptions. Always verify against the Service Layer OpenAPI spec, not DI API docs.
Reference
See REFERENCE.md for:
make_tsv()generation helper- Multi-table objects table with ParentKey rules
- Mandatory column minimums per object type (OCRD, OITM, document lines)
- DTW vs Service Layer decision matrix
- Common pitfalls and fixes
- COM property ↔ DB column mapping examples
More from kehwar/skills
to-prd
Turn the current conversation context into a PRD and publish it to Beads. Use when user wants to create a PRD from the current context.
9setup-workflow-skills
Sets up an `## Agent skills` block in AGENTS.md/CLAUDE.md and `docs/agents/` so the engineering skills know this repo uses Beads for issue tracking and where to find domain docs. Run before first use of `to-issues`, `to-prd`, `tdd`, `improve-codebase-architecture`, or `zoom-out` — or if those skills appear to be missing context about the issue tracker or domain docs.
9tdd
Test-driven development with red-green-refactor loop. Use when user wants to build features or fix bugs using TDD, mentions "red-green-refactor", wants integration tests, or asks for test-first development. Tracks progress in Beads Issue Tracker.
8grill-me
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
7to-tasks
Break a plan, spec, or PRD into independently-grabbable tasks/issues on Beads Issue Tracker using tracer-bullet vertical slices. Use when user wants to convert a plan into tasks, create implementation tickets, or break down work into tasks.
7improve-codebase-architecture
Find deepening opportunities in a codebase, informed by the domain language in CONTEXT.md and the decisions in docs/adr/. Use when the user wants to improve architecture, find refactoring opportunities, consolidate tightly-coupled modules, or make a codebase more testable and AI-navigable.
6