sapnote_0000840901

8/13/2019 sapnote_0000840901

http://slidepdf.com/reader/full/sapnote0000840901 1/3

04.07.2011 Page 1 of 3

SAP Note 840901 - Parallel buffering and pseudo ascendingnumber assignment

Note Language: English Version: 5 Validity: Valid Since 17.05.2006

Summary

Symptom

You are running or would like to run 'parallel buffering' for number ranges

in accordance with Note 599157.

For legal reasons, it is sometimes necessary for numbers to be assigned in

continuous chronological ascending order.

However, it is not logically possible to assign numbers that are

simultaneously continuous, chronological and buffered.

For this reason, this note offers you a solution that can still fulfill the

legal requirements.

Other terms

NRIVSHADOW, parallel buffering, Italy

Reason and PrerequisitesFor number range intervals that are not buffered, a lock is set on the

interval as soon as a number has been assigned. This lock is only removed

again once the application that has taken the number ends the LUW (Logical

Unit of Work) with a COMMIT or a ROLLBACK.

This ensures that if there is a rollback, the number that was just taken is

available to the next application, and therefore continuity is guaranteed.

In addition, the next highest number in the interval can only be assigned

once the first number is definitively assigned. This ensures that the

system strictly adheres to the ascending order.

A huge disadvantage of this lock is that the application sometimes requires

a very long time between assigning the number and the final COMMIT, and

this has a considerable effect on system performance (see Note 678501).

Solution

Thus, it is clear that it is logically impossible to assign numbers in a

continuous chronological ascending order with a buffer. However, the new

buffering type fulfills this requirement as far as possible.

It is not always possible to strictly adhere to an ascending order, so we

use the term pseudo ascending:For example: Process A takes a number (buffered) and processes further

whilst waiting for a COMMIT; Process B later also takes a number (buffered,

higher) but sets its COMMIT earlier than A.

Depending on when the application sets a time stamp, the time stamp may

contradict the ascending order. (Note that if these time stamps are set in

the update task, parallel updating may result in the same situation, with

or without buffering of number range objects.) However, in most cases, it

is sufficient if a lower number is not assigned the next day.

To ensure that there are no gaps, a number that was already assigned in the

buffer is made available again in both the enhanced local buffering and in

the parallel buffering, in case there is a rollback in the application due

to a problem IN THE FOREGROUND. (However, if the rollback occurs in the

update task, the numbers are lost forever, regardless of whether they were

buffered or not). Thus, the aim is to stop these numbers from being lost;

in order to prevent the lower numbers from interrupting the ascending

sequence, however, they should also no longer be used.

The system recognizes these numbers and (instead of using them fordocuments) writes them into a database table (NRIV_RESTE) so that they can

be documented (Report RSSNR0S1).

8/13/2019 sapnote_0000840901


04.07.2011 Page 2 of 3


This special case of parallel buffering cannot be activated using

Customizing, but requires a modification involving an exit in the

application. Refer to the FI Note 834257, for example.

USEREXIT_NUMBER_RANGE can be activated for SD (RV_BELEG), as in Note

363901, but using the parameter NO_BUFFER = 'S' rather than the parameter

NO_BUFFER = 'X'.

The prerequisite for this is that you implement the relevant Support

Package (Note 599157).

You must use transaction SNUM to set the buffering of the number range

object to parallel buffering.

In addition, the number assignment (function module NUMBER_GET_NEXT) is

called with the parameter IGNORE_BUFFER = 'S'. (This call must always be

the same for the same interval.) This automatically sets the buffer size to

1 and the numbers that are rolled back are no longer used. If they are

still in the buffer, they are written into NRIV_RESTE. When a number is

requested, a new number is assigned.

You can use Notes 449030, 599157 and 834257 to activate this solution for

the number range object RF_BELEG.

Header Data

Release Status: Released for Customer

Released on: 17.05.2006 14:18:21

Master Language: German

Priority: Correction with medium priorityCategory: Advance development

Primary Component: BC-SRV-NUM Number Range Management

Valid Releases

Software Component Release From

Release

To

Release

and

Subsequent

SAP_BASIS 46 46C 46C

SAP_BASIS 60 620 640 X



Related Notes

Number Short Text

1398444 Buffering the document number assignment for RF_BELEG

1091025 DATA_OFFSET_TOO_LARGE in SAPLSNR3

834257 FI document number assignment: Buffering using BTE 1170

363901 Country-specific buffering RV_BELEG/number assignment in SD

Attachments

8/13/2019 sapnote_0000840901


04.07.2011 Page 3 of 3


File

Type

File Name Language Size

HTM Buffering_FOR_ITALY.htm E 27 KB

Documents

sapnote_0000840901