Product Information
Number Range Buffer – Why We Sometimes See Skips in The Number Range for Business Partners
Hello SAP S/4HANA Cloud Community,
I work on the LO-MD-BP component for SAP S/4HANA Cloud and I wanted to share some information on a topic for which I have seen a couple of incidents. The topic of this blog is on why do we sometimes see skips in the number range for Business Partners so I thought that I’d share the information for the benefit of our community. In this blog, I’ll explain how buffering works and the reasons behind it being active for the creation of Business Partners.
In a S/4HANA Cloud system for the creation of Business Partners the number range object is “BU_PARTNER” and this number range object has Buffering enabled with the numbers being loaded into the buffer is 10.
When the system buffers a number range object, it does not update numbers individually in the database but reserves a preset group of numbers (depending on the number range object) in the database the first time a number is requested and makes these numbers available to the application server in question.
For explanation purposes I’ve added an example of how the system could load the numbers into the buffer in that 10 numbers when we are creating a Business Partner(s), the system takes 10 numbers (let us assume 10000005 – 10000014) and keeps them in a buffer. Now if we keep creating BPs in the same session, no gaps will occur. It will take the numbers one by one from the buffer and create the BP, meaning it will create the ten BP’s as 10000005, 10000006, 10000007, 10000008, 10000009, 10000010, 10000011, 10000012, 10000013 and 10000014.
If however, you leave the session without using up all of the numbers which have been loaded into the buffer or when different users try to create BP at the same time. Then you might see gaps in the number range e.g. 10000005, 10000006, 10000007, 10000015, 10000027 etc.
This is the SAP standard number assigning behaviour for the Business Partner.
The benefits of buffering are as below:
1. Buffering the number range objects has a positive effect on performance because the system no longer has to access the database (number range table NRIV) for each posting. The number interval buffer is in the Shared Memory of the application server. Each buffer is used to store the external number intervals and a certain number (subinterval) of the internal number intervals.
2. Database accesses are always subject to the database transaction mechanism. Once an application has assigned a number for one user, a second user cannot assign a number until the first user has executed a commit operation on the database. The application blocks further assignment, and the second user has to wait until the commit has been executed.
3. A serialisation of this table (database locking) is prevented to a large extent so that posting procedures can be carried out in parallel.
For these reasons, we have not delivered an SSCUI which allows the deactivation of number range buffering for Business Partners in SAP S/4HANA Cloud. There is also an old SAP On-Premise note 62077 also explains the same reasonings.
Kind Regards,
Stephen Ward
SAP S/4HANA Cloud Product Support
Stephen Ward although NR buffering is very old concept but this blog is good refresher for cloud, thanks.
Thanks for sharing. Just to clarify 102296 works independently in Q and P so you need to pay attention where you do this.
Good to know Info!
Thanks Setphen π Is there something like this for billing as well?
Hi Vijayendra Tiwari
I wouldn't be an expert in Billing but I have looked into this morning and I have found that the numbering of billing documents is sequential due to legal requirements. This would mean that such a buffer of 10 would not be used for billing documents (I double-checked the Billing Number range object RF_BELEG on an internal test system and it is set to 1 to be continuous).
Meaning, that for Billing Documents if there is a gap in the numbering something has gone wrong and Support would need to be contacted. This should be rare in the Cloud Solution as the number range customising is restricted.
Nancy Guo , is there anything further which you would add from a Billing perspective?
Kind Regards,
Stephen
Stephen Ward Thanks π
The number range object for billing document is RV_BELEG. The number in buffer is set to 1 on S/4HANA Cloud system. So I think Stephen is correct.
Thank you Stephen for sharing this blog.
Thanks for sharing this!
Thank you Stephen for summarizing this topic.
Very good explanation, thank you Stephen!
Good explanation. Pretty useful. Thanks Stephen.
very good insight. thanks for sharing.
Thanks Stephen for sharing this, this happens the same when crearing purchasing related document for example PO.
Nice blog Stephen π This behavior applies to multiple number ranges.
Thanks for the post! I tought it could be this kind of parallel processing/buffer thing or there are ghosts/gnomes in our system. It is good to validate non-existence of ghosts in this case π
Thanks Enes Yalcin, I think that this is my favourite comment π
Thanks Stephen for sharing this. What is the recommended approach to avoid losing the numbers and assign them. Is parallel buffering recommended or shall we use main memory with reducing the size of number of buffers.
Hi Debashish Bhowmik, in the S/4HANA Cloud system this kind of buffering is always active and cannot be deactivated or reduced. If you find large gaps in your number ranges where many numbers have been lost then an option would be to set back theΒ number range in the SSCUI 102296 - Define Number Ranges, pay attention to the changes you make though as SSCUI 102296 works independently in Q and P
we are facing issue Number ranges change automatically can anyone know why this happening
Hi Hafiz Nasir,
Did this start happening recently? if so then please take a look at the KBA 3056325 - Customization of Business Partner Number ranges and Groups lost or overwritten after Q Upgrade to CE 2105
Kind Regards,
Stephen
yes dear we are change the OS time 30 mint past then this is happening
This is such an informative post. Thank you, Stephen!