Missing orders in SAP-Gap in number assignment

Question

Hi All,
  We are facing a situation where there is a gap in assignment of order numbers. We do not have any trace of any failed updates in ST22,SM13 etc. Does this mean that we missed only a "number" and not an order? Is there any other transactions that can give some information on this? Do we have any documentation from SAP that talks of a similar isssue?

Answer 1

<b>This is report I used for FI = RFBNUM00</b>
<b>FYI</b>
OSS note # 62077
Symptom
Gaps (jumps) occur when allocating internal numbers.
The status of the number range does not match the number last assigned.
The number assignment does not match the insert sequence.
Additional key words
Document number, Number range, Number range object, Buffering, Current number level, Trip number assignment, Number interval, CO document, CO actual posting, Inspection lot, Material document, Physical inventory document, Production order number, Planned order number, Process order number, Maintenance order number
FB01 VF01 KO88 KE21 KE11 FD01 FK01 XK01 XDN1 MB01 MB0A MB11 MB1A MB1B MB1C MB31 KANK KB11 KB13 KB14 KB41 KB43 KB44 KB21 KB23 KB24 KB31 KB33 KB34 KB51 KB53 KB54 PR01 PR02 PR03 PR04 PR05 XD01 VD01 MK01 SNUM SM56 SNRO VL01 VL02 CO01 CO40 CO41 VA01 MR1M MIRO
Cause and prerequisites
A large number of number range objects are buffered. When buffering a number range object, numbers are not updated individually in the database, rather, the first time a number is requested, a preset group of numbers are reserved in the database (depending on the number range object) numbers and these are made available to the application server in question. The following numbers can then be taken directly from the application server buffer. If the application server buffer is exhausted, new numbers are generated in the database.
The effects described under "Symptom" then result:
If an application server is shut down, the numbers that were left in the buffer (that is, that are not yet assigned) are lost. As a result, there are gaps in the number assignment.
The status of the number range interval reflects the next free number that was not yet transferred to an application server for intermediate buffering. The current number level does not therefore display the number of the "next" object.
The current number level (per server) can be displayed with Transaction SM56. Start Transaction SM56 and branch into the menu 'Goto' -> 'Entries'. In the dialog box, enter the client, the affected number range object (for example, RK_BELEG) and possibly the required subobject (corresponds to the controlling area for the object RK_BELEG).
If several application servers are used, the chronological insert sequence is not determined by the numerical sequence on the individual hosts, due to the separate buffering on the various servers.
Buffering the number range objects has a positive effect on the performance as no database access (on the number range table NRIV) is required for every posting. Furthermore, a serialization of this table (database blocking) is prevented to a large extent so that posting procedures can be carried out in parallel.
Solution
As the number range buffering does not lose any guaranteed attributes, a correction is not required.
If you still require a continuous allocation, you can deactivate the number range buffering deliberately for individual objects.
Proceed as follows:
- Start transaction SNRO and enter the affected object
- Press the 'Change' pushbutton
- Deactivate buffering: Menu 'Edit' -> 'Set buffering' -> 'No   buffering'
- If you only want to change the buffer size, please enter the   corresponding value in the field 'No. of numbers in buffer'
- Save the changes
Please note that this change is a modification. The modification is overwritten as soon as the affected number range object is redelivered - that is, you must check the change manually after every import of a maintenance level.
For the the following number range objects, gaps may cause user insecurity as a sequential numbering is 'expected':
Area CO:
- RK_BELEG   (CO Document)
Caution: Note that the problems described in notes 20965 and 29030 can occur if you deactivate the buffering.
- COPA_IST   (Document number during actual posting)
- COPA_PLAN  (Document number with planned posting)
- COPA_OBJ   (Business segment number)
Area FI:
- DEBITOR    (Customer master data)
- KREDITOR   (Vendor master record data)
Area HR:
- RP_REINR   (Trip numbers)
Area PM, PP, PS
- AUFTRAG    (Order number, Production, Process, Maintenance order
number, network number.)
- QMEL_NR    (Number range message)
Area MM:
- MATBELEG   (Material documents)
- MATERIALNR (Material master)
Area QM:
- QLOSE      (Inspection lots in QM)
- QMEL_NR    (Number range message)
- QMERK      (Completion confirmation number)
- QMERKMALE  (Master inspection characteristics in QSS)
- QMERKRUECK (Completion confirmation number of an inspection
             characteristic in QM results processing)
- QMETHODEN  (Inspection methods in QM)
- ROUTING_Q  (Number ranges for inspection plans)
- QCONTROLCH (Control chart)
Area Workflow:
- EDIDOC     (IDocs)
Number range buffering can be activated or deactivated at any time.
Number range objects that must be continuous due to legal specifications (for example RF_BELEG, RV_BELEG), or due to a corresponding application logic must not be buffered with the buffering type 'Main memory buffering'. Please see also notes 37844 (for RF_BELEG) and 23835 (for RV_BELEG).
Source code corrections
Thanks
SK