7/17/2019 SAP_Note_1843002

http://slidepdf.com/reader/full/sapnote1843002 1/2

SAP Knowledge Base Article 

Symptom 

Numbers allocated from internal number ranges show gaps. We must distinguish between the following situations:  

l Number ranges are buffered in main memory.

You can see this with displaying the attributes of the number range object via transaction SNRO. There, the buffering type is set to "Mainmemory buffering" and the size is a number bigger 0. A buffer size of 0 means "no buffering" although formally the buffering type is set.Sometimes, not only there are gaps, but the numbering jumps ahead and back and the value of the difference is significantly high.  

l   Number ranges were buffered in main memory but the buffering was disabled by the customer precisely in order to avoid gaps.l Number ranges are not buffered, neither in the SAP delivered customizing, nor in the customer's system.

Cause 

1. With buffering in main memory for a number range object active, a buffer will be set on demand in the main memory of the instance where theprogram asking for a number runs. After the program finishes, there may be still unused numbers in the buffer, which can be used at a latertime by a program running in the same instance and needing numbers from the same interval. Let us give an example: buffer size is 100, theinterval limits being between 1 and 10000. The first program running on instance A loads a buffer, with numbers 1 to 100. It allocates 10documents, and the numbers for these documents will be 1 to 10. Another user, working in instance B, needs numbers from the same

interval, then a new buffer of size 100 will be set on instance B, with value 101 to 200. The program uses 5 numbers, which will be 101 to 105.Later, still another user draws 1 number being logged on instance A, it will receive number 11. Then, in time, the numbers allocated will be 1to 10, 101 to 105, then 11. Apparently skipping and jumping, but with a coherent explanation.

Several observations:

¡ Even skipping and jumping, the same number is never allocated twice¡ If the instance is restarted, all numbers of all intervals which are loaded there are lost¡ Even if a number drawn is not used by the program due to a rollback or application design, it is not returned to the buffer and therefore

it is lost.

2. In the customer's system, buffering is disabled for an object which is buffered in the SAP standard, but still gaps occur.

SAP delivers number range objects buffered only in proven cases that there is no law for those particular objects to skip or jump. Somecustomers simply do not like this situation and try to avoid it by un- buffering. This may be very unwise from the sight of performance (see SAP

note 678501) but may be not so harmful if the numbers are seldom used and there is not much concurrent activity on the intervals of thatobject.The problem here is that the applications are not designed for gap-less ascending numbering, as there was no such request in the firstplace. In some cases, numbers are drawn early at the start of the transaction, and if the user does not save, the number is, as we have seen,lost. There will be more specific information in the causes to the next point.

3. When number ranges are not buffered, it means that, at least in some countries, there are legal demands of gap-less ascending numberingof documents; gaps then should be regarded as a serious bug.

¡  According to the R/3 concept, a document number is assigned early during the posting process . In the case of a "serious error" (forexample, a termination), this process is terminated prematurely and all sub-processes - including number assignment - are rolled back.This means that a rollback always goes back to the last COMMIT command of the application, therefore either to the beginning or thelast update (opening of the current DB-LUW - Logical Unit of Work). This means in turn that gaps in a number range only occur whenthe system not only cannot end the process, but also cannot completely roll back existing sub-processes.

¡ In other words, if a rollback occurs, the rollback goes back to the last COMMIT that occurred explicit or implicit, but the NRIV wasalready updated with an unwanted COMMIT

¡  In the standard system, exactly one COMMIT command is used during the LUW. That is, you must now examine the process of theapplication for possible enhancements (user exits, modifications,additional programs (print)) by means of code review or by runtimeanalysis.

Resolution 

l Referring to cause 1:Reduce the buffer size to 1 via transaction SNRO if an ascending numbering is deemed as necessary. This may influence performancesomewhat, but not by much compared to un-buffering as per SAP note 62077. A side effect is generated by an increased use of dialog workprocesses to refill the buffers more often. This should not be a problem for a well-configured system, but for systems already under strain dueto the missing of available work processes could lead to system still stands (see SAP note 920234)

l Referring to cause 2This is normal behavior and is due to the design of the respective transaction.

l Referring to cause 3

Contact SAP support of the respective functional area. An example of the methods used can be seen for financial documents in theSAP note 1522367.

Header Data

1843002 - Gaps and Jumps in Numbering 

Version  2 Validity: 08.05.2013 - active Language  English

Released On  08.05.2013 12:50:40

7/17/2019 SAP_Note_1843002

http://slidepdf.com/reader/full/sapnote1843002 2/2

 

Product

This document is not restricted to a product or product version

References

This document refers to:

SAP Knowledge Base Articles 

SAP Community Network 

Release Status  Released to Customer

Component  BC-SRV-NUM Number Range Management

BC-CST-NU Number Range Buffer 

Priority  Normal

Category  How To

1720411 Why are there so many RF_BELEG entries in transaction SM56 ? 

Buffering Number Ranges and Legal Framework 

Other Components