A segregation of duties conflict says somebody could do two incompatible things. Did-Do answers the next question, which is whether they did. That distinction is what turns a list of thousands of theoretical conflicts into a short list worth investigating, and it is usually the difference between a finding an auditor accepts and one they escalate.
What it needs
Did-Do draws on two sources, and they answer different questions.
| Source | Tables | Tells you |
|---|---|---|
| Usage data | usage | How often an action was executed, and when it was last executed |
| Change documents | CDHDR, CDPOS | What was actually changed: object type, object ID, change type, date, and field-level before and after values |
Usage data alone gives you execution counts. Change documents give you evidence of the change itself, which is what a fraud investigation or an audit finding needs. Load both where you can.
See SAP File Import for exporting them.
Enabling it
Turn on Did do in the analysis criteria before running. See Running User Analysis. Results then carry a Did-do tab, and the summary report gains a Did-do column.
Reading the result
Users mode
One row per function and action, for each user who both holds the conflicting access and shows activity against it:
| Field | Meaning |
|---|---|
| Function, Action | The ruleset function and action involved |
| System | Where the activity occurred |
| User, Local User ID | Canonical identity, and the account in this system |
| User Group, Full Name, Department, HR Function, Location | Attribution, when HR data is loaded |
| Execution count | Total executions from usage data |
| Last executed on | Most recent execution |
| Changes | Distinct change log entries |
| Change types | Count of changes per object type |
Roles mode
One row per function and action per role, with the population underneath:
| Field | Meaning |
|---|---|
| Role, Is composite | The role, and whether it is a composite |
| Execution count, Last executed on | Aggregated across holders |
| Users having executed action | Which holders actually used it, with their individual counts |
| User details | Per-user change summary |
The per-user breakdown is the useful part. A role granting conflicting access to sixty people where two have ever exercised it is a different problem from one where fifty have.
Change document indexing
CDPOS is frequently the largest table in an SAP landscape and can exceed 50 GB. Rather than scan it, MTC Skopos builds a binary index beside it:
/path/to/CDPOS.csv the export
/path/to/CDPOS.csv.idx the index
Indexing starts automatically in the background once the data source finishes loading. Until it completes, header-level changelog data is available but field-level detail is not, and the interface says so: "Transaction changelog file is being indexed, details cannot be shown yet." Wait and reopen the row.
The index is validated against the CDPOS file's path and modification time, so replacing the export with a fresh one triggers an automatic rebuild. An interrupted build is detected and rebuilt rather than used, so a crash mid-index costs time but never correctness.
How it changes remediation
Did-Do evidence is what the remediation engine uses to decide whether access can be withdrawn safely. Without usage data the engine cannot tell unused access from unmeasured access, and its recommendations become markedly more conservative. This is the single largest quality difference between a remediation run with usage data and one without. See Generating Recommendations.
Interpreting absence of evidence
No recorded activity is not proof that nothing happened. Usage statistics may have been reset or may not be collected, change document logging is configurable per object, and a Fiori app may leave no usage trace at all. Treat an empty Did-Do result as an absence of evidence rather than evidence of absence, and confirm that the source data actually covers the period you are reviewing before concluding that a conflict is dormant.