Lesson 4 of 6
Explaining an IDoc error and summarizing a transport list
9 min
Listen to this lesson
Two more everyday tasks show where prompting pays off in SAP operations: explaining an interface error to someone who has to act on it, and turning a long transport list into a summary a release manager can decide on. Both involve pasting system output into a prompt, so both need data-protection care. We'll do them the Contoso way.
Task 1: explaining an IDoc in status 51
During integration test cycle 2 in CMQ, an inbound order IDoc from Great Lakes Fleet Services ends in status 51, "application document not posted". Theo, the integration lead, has the status record from WE02: "Material CMC-ALT-100 is not defined for sales area 1710/10/00". Maria needs a plain-language explanation and a clear owner. Theo builds the prompt like this:
- Role: You are an SAP integration analyst explaining IDoc errors to business users.
- Context: SAP S/4HANA Cloud Private Edition 2025; inbound message type ORDERS, basic type ORDERS05; the status records and the relevant segments in <idoc>, with partner names and addresses replaced by placeholders such as [CUSTOMER-1].
- Task: Explain in plain English what the error means, classify the cause as master data, configuration, mapping or partner data, and say who usually fixes that class of cause.
- Constraints: Quote the exact status message you are explaining. Base the explanation only on <idoc>; if the cause can't be determined from it, say so and list what to check next. Don't propose changing the IDoc status.
- Format: three short sections: What happened, Likely cause and owner, What to check next.
A good answer explains that the material exists but has no sales data for sales organization 1710 and distribution channel 10, classifies it as master data, and suggests checking the material's sales views for 1710/10. Theo still verifies that in the system before telling Maria. The model's explanation saves time; the system confirms the fact. After the material master is extended, the original IDoc is reprocessed in BD87, exactly as course sap-int-201 teaches.
Task 2: summarizing a transport list
Luis, Contoso's release manager, gets a list of 40 transport requests for the next production import into CMP. He exports the request headers and object lists (the transport tables E070 for request headers and E071 for object entries are the usual source) and wants a one-page summary for the change advisory board. The prompt asks the model to group and flag, not to judge:
| Ask the model to... | Because |
|---|---|
| Group requests by type: workbench (repository objects) versus customizing | Customizing and code changes need different testers |
| Count objects by object type (for example R3TR CLAS, R3TR PROG, R3TR TABU) | Gives the board a sense of size and kind |
| Flag deletions, table content entries and authorization-related objects | These are higher-risk and need explicit approval |
| List requests whose description doesn't match their objects | A classic sign of a mixed or mislabeled transport |
| Quote the request number for every flag | So Luis can verify each one in SE09/SE10 or STMS |
What a transport-list summary prompt should request.
- ExportRequest numbers, descriptions, types and object entries from the transport tables
- StripRemove owner user IDs and any names; keep request numbers and object names
- PromptGroup, count and flag; quote request numbers; no approvals or recommendations to import
- VerifyLuis checks every flagged request in SE09/SE10 and the import queue in STMS
- DecideThe change advisory board approves; the summary is an input, not a decision
The same pattern for defect write-ups
A third task follows directly: once Theo knows the cause, he needs a defect or incident a colleague can act on. Give the model the facts (system CMQ client 100, IDoc 0000000004711, status 51, the exact message, the steps to reproduce, the expected and actual result) and a fixed format: title, environment, steps, expected, actual, evidence, suspected cause class. Ask it to keep the title under 80 characters and to leave the severity blank. Severity is a team decision based on business impact, not something a model should guess.
What these two tasks have in common
- You supply the facts (status records, object lists); the model supplies structure and language.
- The prompt asks the model to quote what it is explaining, so you can check it against the source.
- Personal and partner data is replaced with placeholders before anything leaves the system.
- A person verifies in SAP before acting: WE02/BD87 for IDocs, SE09/SE10 and STMS for transports.
What would you do?
Theo pasted a full IDoc, including the customer contact's name, phone number and delivery address, into a public chatbot to get an explanation. The explanation was correct. What should happen next?
- For IDoc errors, ask for a plain explanation, a cause class (master data, configuration, mapping, partner data) and next checks.
- For transport lists, ask the model to group, count and flag with request numbers, not to recommend imports.
- Replace partner and personal data with placeholders before prompting.
- Verify every claim in SAP (WE02, BD87, SE09/SE10, STMS) before acting.
Check your understanding · not graded
Lesson check
1. What should Theo remove from an IDoc extract before asking an approved LLM to explain it?
2. Which cause class fits "Material CMC-ALT-100 is not defined for sales area 1710/10/00"?
3. What should a transport-list summary prompt ask the model not to do?
4. Where does Luis verify a flagged transport request before the change board meets?