Sequential Printing – Steps to keep printouts in sequence
There are a number of reasons why output requests may not print sequentially and there is no way to absolutely guarentee sequence (except using a server with only one spool work process for such spools where it is critical that the sequence is preserved).
First, check the following SAP notes:
# 412065 – Incorrect output sequence of output requests
# 1054561 – Output sequence is lost when you use SAPSprint
# 776933 – “Sequential order processing” does not seem to work.
If sequential processing is NOT working, known reasons are:
1. The flag is not checked for the printer in SPAD.
2. You send too many requests at the same time which can cause an overflow of internal queues (see note 692486 for general information).
2.1. Internal spool queue (note 412065)
2.2. Dispatcher queue overflow (maximum: instance profile parameter rdisp/elem_per_queue)
2.3. too many commit messages (note 48924)
3. Auto restart of Sp_Wp (note 776933)
Check all of the above and, if there is no cause there, then proceed as described in note 855342:
# 855342 – Sequential processing: Help for the analysis
There is no way to absolutely guarentee sequence (except using a server with only one spool work process for such spools where it is critical that the sequence is preserved).
Requests can also be printed out of sequence when you get a dispatcher queue overflow due to a large number of requests being printed at the same time (more than 50). Then some of the output requests are delayed which can change the sequence. See the following notes in relation to minimising this risk:
# 48914 – Output requests are partially delayed
# 412065 – Incorrect output sequence of output request
Also consider with the Application team if the documents can be included in ONE singe spool request (one big spool request is always better than several small ones). Or assign a dedicated formatting server to that printer with only ONE spool workprocess.