Lesson 5 of 5
Testing call generation
10 min
Listen to this lesson
Preventive maintenance fails quietly. A broken corrective process is noticed the same day; a broken maintenance plan is noticed months later, when a compressor that should have been serviced in April fails in June. That is why call generation needs deliberate tests, with dates worked out in advance and compared with what the system actually creates.
Design the expected dates first
For each test plan, write down the cycle start, cycle, offset, call horizon, shift factors and tolerance, and calculate by hand the expected planned dates and call dates for the next three calls. Then schedule the plan and compare. SAP's scheduling overview and simulation (IP19) let you check future dates without creating orders, which is useful before go-live. Because testers cannot change the system date, Priya's team uses cycle start dates in the past and short test cycles in CMQ to bring calls into the window.
| Test | Setup | Expected result and evidence |
|---|---|---|
| Single-cycle start | Hoist plan, 12-month cycle, start date 11 months ago, horizon 90% | One call now; order PM02 with the inspection operations; planned date one month out |
| Strategy hierarchy | Compressor plan with 1M, 3M and 12M packages; date when all are due | One order with the operations of the highest-hierarchy package due, not three orders |
| Late completion shift | Complete a call 15 days late; late shift factor 100% | Next planned date 15 days later than the original rhythm |
| Tolerance | Complete 2 days early; tolerance 10% of 30 days | No change to the next date |
| Completion requirement | Leave the hoist call open; run deadline monitoring | No new call until the open one is completed |
| Performance-based call | Enter readings that pass the 2,000 h threshold minus horizon | Overhaul order created on the next deadline monitoring run |
| Bad reading | Enter a reading lower than the previous one | System rejects it unless counter replacement is used |
| Deadline monitoring job | Run the scheduled job for plant 1710 | Only due plans called; job log shows calls created |
Contoso's call generation tests.
- ExpectedPlanned and call dates worked out by hand, with operations per call
- ScheduleStart the plan or run deadline monitoring
- Scheduling listCompare planned and call dates in the plan's scheduling overview
- OrderCheck type, object, operations, components and dates on the created order
- CompleteTECO the order and check the next date against the expected shift
Conversion: converted plans and cutover
Contoso's plans come across from ECC with their scheduling history. Two risks follow. First, during the 60-hour cutover window nothing runs, so on Monday morning deadline monitoring may create several days of calls at once; that is expected, but the volume must be understood. Second, if the deadline monitoring job runs in both EP1 and the new production system around cutover, duplicate calls appear. Luis's cutover plan stops the job in EP1 before the conversion starts and releases it in CMP only after the business validation step. Priya's test compares the scheduling overview of a sample of plans in EP1 and SAP S/4HANA after each mock conversion.
What would you do?
After mock conversion 2, a tester finds that the compressor plan in CMQ shows its next planned date one month earlier than in EP1. All other sampled plans match. What should Priya's team do first?
| Plan | Expected call date | Expected planned date | Expected operations | Actual |
|---|---|---|---|---|
| Hoist 10000480, single cycle 12M | Today | Today + 1 month | Annual safety inspection | Match |
| Compressor 10000460, 3M package | Mar 17 | Apr 1 | 0010, 0020 | Match |
| Winding machine 10000451, 2,000 h | Next run after reading crosses 1,800 h | About when 2,000 h is reached | Spindle overhaul | Order one run late: defect logged |
Do not forget the orders the calls create. A call on the right date with the wrong operations, a missing component or the wrong order type is still a failure. Check each created order against the task list and the maintenance item, then run it through release, confirmation and technical completion so the next date can be checked too. The full loop is what proves the plan works year after year.
In SAP S/4HANA Cloud Public Edition, deadline monitoring runs as a scheduled application job set up in the Fiori job apps rather than an IP30 background job; the logic and the tests are the same.
- Calculate expected planned and call dates before testing, then compare.
- Test the parameters you rely on: hierarchy, shift factors, tolerance, completion requirement, readings.
- Evidence is orders created on the expected dates with the expected operations.
- In a conversion, control deadline monitoring around cutover and compare converted plans with ECC.
Check your understanding · not graded
Lesson check
1. What is the core evidence for a call generation test?
2. How can testers check future plan dates without creating orders?
3. Why does Luis stop deadline monitoring in EP1 before the conversion?
4. Why does Rosa prepare an expected list of calls before the cutover weekend?