Lesson 3 of 5
Reading system messages
8 min
SAP talks to you through messages. Most appear in the status bar at the bottom of the window; some appear in a dialog box. Reading them properly is one of the most underrated skills in SAP, and capturing them properly is one of the most underrated skills in testing.
Message types
Every message has a type, shown by a letter internally and usually by an icon and color on screen.
| Type | Name | What it means for you |
|---|---|---|
| S | Success | The action worked, for example a document was saved. Processing continues. |
| W | Warning | Something looks unusual. You can usually press Enter to continue, or correct the entry. |
| E | Error | Processing cannot continue until you correct the input on this screen. |
| I | Information | Shown in a dialog box you must acknowledge; informs without blocking. |
| A | Abort (termination) | The transaction stops and you return to an earlier screen. Unsaved data is lost. |
SAP message types
There is also type X, which triggers a runtime error (a short dump). You will rarely see it as a business user, but if a transaction ends with a runtime error screen, that is always worth reporting.
The message number
Every message has an identity: a message class and a number. Two messages can look alike in English and still be different messages, and the same message can read differently in German. The class and number are what support teams, developers and SAP Notes use to find exactly what happened.
- Read the status barNote the type icon and the short text.
- Double-click the messageThe performance assistant opens with the long text.
- Read Diagnosis and ProcedureMany messages explain the cause and what to do.
- Open Technical InformationSee the message class and number.
- Record all of itType, text, class, number, transaction and data entered.
The long text often contains the answer. For example, an error when Contoso’s buyer Luis posts a goods receipt might explain that the posting period is not open, and name the transaction to check. A key user who reads the long text can often fix the problem without opening a ticket at all.
Warnings are not noise
It is tempting to press Enter through every yellow warning. Resist it during testing. A warning may be the only sign that a price came from an unexpected source, a delivery date cannot be met, or a quantity is unusually high. If a warning appears that the test case did not predict, stop and read it. Either the test case needs updating, or you have found something the business needs to know before go-live. Equally, if a warning the test case expects does not appear, that is a finding too: a control may have been switched off.
Messages that disappear
Success messages vanish as soon as you move on. If you need the document number from "Standard Order 12345 has been saved," copy it before pressing anything else. Some transactions keep a message log (for example after a billing run or a mass change); open it to see every message, not just the last one. In Fiori apps, messages appear in a message popover or a dialog instead of a status bar, but the same rule applies: capture them.
What would you do?
During testing, Dana sees a red message when saving a sales order for a new fleet customer: the customer is not defined for the sales area. What is the best response?
- Message types: S success, W warning, E error, I information, A abort; X means a runtime error.
- Double-click a status bar message for the long text and its class and number.
- Success messages disappear; copy document numbers immediately.
- Good evidence records type, text, class and number, transaction and data entered.
Check your understanding · not graded
Lesson check
1. Which message type stops processing until the input is corrected?
2. How do you see the long text of a status bar message?
3. Why record the message class and number?