Enterprise Resource Planning Blogs by SAP
Get insights and updates about cloud ERP and RISE with SAP, SAP S/4HANA and SAP S/4HANA Cloud, and more enterprise management capabilities with SAP blog posts.
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member

Hello,

   

Buffering activation for FI documents brings many questions from customers. SAP has various Notes and WIKIs related this topic, but I decided share with you some specific questions that I have already worked.

   

1 - What kind of GAPS we can have with parallel buffering and how we can document them to the business?

2 - Do we have to run reports RSSNR0S1 and RFVBER00 daily/weekly/yearly?

3 – Can a buffering which has been activated be later deactivated? What is the impact of making this change?

 

4 - What is the recommendation on the Testing which is required to be performed for this buffering?

 

5 - Which is the overall impact of activating number range buffering?

1 - What kind of GAPS we can have with parallel buffering and how we can document them to the business?

A: As described in note 1522367 point 3 "gaps" can occur at fiscal year end if number assignment is year dependent and numbers in buffer is more than 1.
Example parallel buffering with numbers in buffer = 10 and 2 instances: both instances draw 10 numbers. instance 1 = number 100010 to 100019 and instance 2 = number 100020 to 100029. Till year end close 7 documents are posted on instance 1 and 3 documents are posted on instance 2.   So for instance 1 no. from 100017 to 10019 and for instance 2 no. from 100023 to 100029 will not be used. But again these are not real gaps and again there is report RSSNR0S1 for documentation.

2 -  Q: Do we have to run reports RSSNR0S1 and RFVBER00 daily/weekly/yearly?

A: As answers above may have illustrated neither parallel buffering not buffering in ascending order will cause more real gaps than buffered number range object. But of course as developer I cannot give you a recommendation how often reports  RSSNR0S1 and RFVBER00 should be executed. This depends on your system administration and reporting requirements. As said buffering does not cause more update terminations. So there is no need to execute RFVBER00 more often only because of activated buffering. But of course RFVBER00 has to be executed before update terminations will be deleted by your
system administration.

3 – Q: Can a buffering which has been activated be later deactivated? What is the impact of making this change?

A - Yes, number range buffering can be deactivated later. But sure, postings created while number range buffering was activated will show the document numbers derived in the logic of the individual number ranges buffering type.

One possible setting in number range buffering is e.g. SNRO -> RF_Beleg to activate the flag 'parallel buffering' and to set the numbers of buffers to 1.

This means each application server picks one document number of the number range and buffers this one locally. In this way between parallel Application Servers parallel postings are possible. With this setting postings executed within each application server will be serial and chronological, only within different application servers the document numbers will not be derived chronological. In some countries it is said by law, that document numbering needs to be serial, but it is not said if this is related to a complete system and in such cases parallel buffering is an option. This means the local law must be studied carefully
before choosing one of the different buffering types.

4 - Q : What is the recommendation on the Testing which is required to be performed for this buffering?

In case a decision is made, testing is not necessary as this is a common setting which is used by nearly all customers.
You just need to choose a way of buffering, which is allowed by the country specific law of your Company Codes.

5 - Q – Which is the overall impact of activating number range buffering?

A - Depends on the way of buffering. E.g. in case you choose in SNRO the number of buffers with 100, this would mean that your application server will pick 100 document numbers and 100 postings of each number range could be done locally on this application server in parallel. But in case until the next application servers shout down only 70 postings are done, 30 document numbers will be unused, which means you would have a number range gap of 30 document numbers as after booting the application server again this one will increase the actual document numbers setting by 100 and store 100 new document numbers locally. -> but sure you need't choose  100, it is also possible to choose 10 or even 1. The advantages and disadvantages are described in note 1398444 and mentioned notes.

I hope this helps!

Regards,

Raquel