1398444 - Buffering the document number assignment for RF_BELEG

Posted 2020-10-13 茱丽叶

 

Version	7		Type	SAP Note
Release Status	Released for Customer		Language	English
Responsible	Volker Kleinhenz ( D024958 )		Masterlanguage	German
Processor	Volker Kleinhenz ( D024958 )		Last Changed On	13.02.2017 12:37:36
Component	FI-GL-GL-A ( Posting/Clearing )		Created On	21.10.2009 14:58:06
Other Components	FI-AP-AP-A ( Posting/Clearing/Special General Ledger ) FI-AP-AP-J ( Integration/Accounting Interface ) FI-AR-AR-A ( Posting/Clearing/Special General Ledger ) FI-AR-AR-J ( Integration/Accounting Interface )

Symptom

This note contains frequently asked questions about buffering the document number assignment in financial accounting (number range object RF_BELEG).

Other Terms

SNRO, SNUM, NRIV, NRIV_LOKAL, NRIVSHADOW, NUMBER_GET_NEXT, RF_GET_DOCUMENT_NUMBER, FI document number assignment, lock waits, deadlock, CJ8G, 00001170, RKO7CO88, DBIF_RSQL_SQL_ERROR, CX_SY_OPEN_SQL_DB, READ_NRIV, ORA-00060, SAPLSNR3, LSNR3F01, FAQ

Solution

Questions:

1. When and why should you consider buffering?

2. Which buffering types are there and what are the advantages and disadvantages?

3. Should the object RF_BELEG be buffered?

4. Which buffering type should be used for RF_BELEG?

5. How do I activate the buffering?

6. Can the buffering be activated for certain company codes only?

7. How can I activate the pseudo ascending document number assignment?

8. Where can I find more information about Business Transaction Event 00001170?

9. When is the entry date and time set in the FI document?

1. When and why should you consider buffering?
The document number is assigned in chronologically ascending order based on the table NRIV. For this, the table NRIV is locked until the application (LUW) is terminated by either a COMMIT WORK or ROLLBACK (see also Note 639754). Another application cannot take a document number during this time.
The update is called by the COMMIT WORK and the document number is assigned permanently. In the case of a rollback, the document number that was just used is not assigned and is available for the next posting in NRIV again.
This lock guarantees a choronologically ascending assignment of the document number without gaps. However, the lock causes a serialization in the table NRIV, which can seriously impair the system performance (see also Note 678501). There are performance problems in particular in the case of parallel batch processes, as the lock is held for a very long time here.
There are two solutions for this:

• No parallel processing

• Buffering of the number range object RF_BELEG

In S/4 HANA, as of Support Package 1 of Release S/4HANA 1610, parallel buffering with pseudo-ascending document number assignment (so-called Italian solution) is used by default.For more information about buffering in S/4 HANA, please see SAP Note 2376829 - FAQ: Buffering for number range object RF_BELEG in S/4HANA.

2. Which buffering types are there and what are the advantages and disadvantages?
There are the following buffering types whose advantages and disadvantages are described in Note 504875:

• Main memory

• Local buffering

• Local buffering with work process ID (details in Note 179224)

• Parallel buffering (Note 599157)

• Parallel buffering with pseudo ascending document number assignment (Note 840901)

3. Should the object RF_BELEG be buffered?
Legal regulations basically require a consecutive and complete entry of all business transactions. On the one hand, there are no concrete legal requirements in many countries or accounting principles regarding the sequence of the FI document number assignment. However, there are also rules depending on the business process.
A general statement is not possible because of the numerous legal regulations or local accounting principles. Therefore the activation of the buffering must be reconciled with the financial accounting department.

4. Which buffering type should be used for RF_BELEG?
The buffering in the main memory should not be used, because gap-free document number assignment cannot be guaranteed.

Because the local buffering does not sufficiently solve the performance problems and the document number assignment is not performed chronologically, the local buffering is not recommended either.

In the case of the local buffering with work process ID (Note 179224), the document number assignment is performed per application server and work process using the table NRIV_LOKAL. The document numbers are basically assigned without gaps, but not chronologically to the document entry or posting. In addition, gaps may occur in the document number assignment at the end of a fiscal year if not all numbers in NRIV_LOKAL were used up.
However, these can be documented using the report RSSNR0A1.
For an efficient document number assignment in parallel batch processes, the quantity of numbers selected in the buffer must not be too small. If too large a quantity of numbers is selected in the buffer, a smaller number range can be quickly exhausted if there are several application processes.
Because of this disadvantage, this type of buffering is to be used only if the parallel buffering is not available.

The parallel buffering (Note 599157) solves the problems of the local buffering with work process ID for parallel batch processes.
The quantity of numbers in the buffer can therefore be reduced to 1. The document number assignment comes as close as possible to the behavior of the unbuffered assignment from NRIV, because the number is assigned without gaps and basically in chronologically ascending order. In the case of a rollback, the document number is available again in the buffer table NRIVSHADOW and is used for the next document on this application server and work process. In this exception, the document number assignment is no longer performed in chronologically ascending order. Gaps in the document number assignment should only be explained by update terminations, as in the case of the unbuffered document number assignment. You can use the report RFVBER00 for this.

Logically, the document number assignment performs better if a larger quantity of numbers is used in the buffer - 10, for example. However, the document numbers are then not assigned in a chronologically ascending order. The numbers that are still in the buffer are documented as in the enhanced local buffering, but here it is performed using the report RSSNR0S1. Gaps cannot be explained exclusively by means of RFVBER00.

Parallel buffering with pseudo-ascending document number assignment (SAP Note 840901) is a special case of parallel buffering - the so-called Italian solution. Buffer size 1 is automatically used, regardless of the quantity of numbers used in the buffer in transaction SNUM. In the case of a rollback, the assigned document number is no longer available. These gaps can also be documented with the report RSSNR0S1 using the table NRIV_RESTE or NRIV_DOCU (as of SAP Note 2022364). The document numbers are assigned in a chronologically ascending order to costs of a detectable document number gap. For more information, see the information on parallel buffering in the SAP Help Portal.

Due to the advantages of parallel buffering, it should be used for the number range object RF_BELEG. Since the document number assignment performs well even with a buffer size of 1 and comes pretty close to the unbuffered assignment, it is recommended from an accounting perspective.
In some countries, the documents of one day must have a higher number than the documents of the previous day. This kind of legal regulations can be adhered to only with the pseudo ascending document number assignment.

5. How do I activate the buffering?
The buffering is activated globally in transaction SNRO or SNUM - this applies for all clients, company codes and business transactions.

6. Can the buffering be activated for certain company codes only?
As dealt with in question 3, there are different rules for document number assignment. This ranges from generally valid, undefined requirements to detailed regulations at business process level.
The use of the buffering per company code, number range or fiscal year is only indirectly possible. First, the buffering must be set in transaction SNRO. It is a prerequisite that the number range object RF_BELEG is buffered. The number of numbers in the buffer must be greater than 0 because otherwise the document number assignment is not buffered.

You can use the process Business Transaction Event (BTE) 00001170 to avoid the buffering of RF_BELEG set in SNRO. For this, the export parameter E_NO_BUFFER must be set to ‘X‘. This can be done independently of the company code (I_COMPANY), number range interval (I_RANGE) and fiscal year (I_YEAR). Because the number range interval is assigned to the document type (transaction OBA7), it is possible to use the buffering for certain business processes and company codes only, in which the serialization in NRIV (see question 1) leads to problems.

To prevent the number assignment being inadvertently buffered, we recommend the following procedure:
1. Implement the customer-specific function module for BTE 00001170 and activate the BTE (transaction FIBF).
2. Globally activate the buffering in SNRO.

Also make sure to leave the fields for the country and the application indicator empty when you assign your function module to the BTE 00001170. If this is not the case, the system does not call your function module, and the buffering set in transaction SNRO is used for all number ranges, company codes, and fiscal years.

7. How can I activate the pseudo ascending document number assignment?
Parallel buffering must be set in transaction SNRO.
In BTE 00001170, the export parameter E_NO_BUFFER must be set to ‘S‘ instead of ‘X‘. This can be done regardless of number range, company code and fiscal year. It is then possible to use the pseudo ascending document number assignment only if legally required.

8. Where can I find more information about Business Transaction Event 00001170?
You can find documentation for Business Transaction Events in the Implementation Guide (transaction SPRO) under
Financial Accounting -> Financial Accounting Global Settings -> Business Transaction Events
or
Financial Accounting (New) -> Financial Accounting Global Settings (New) -> Tools -> Customer Enhancements -> Business Transaction Events

For more information about BTE 00001170, please use transaction BERP.

9. When is the entry date and time set in the FI document?
In FI, the time (BKPF-CPUTM = SY-UZEIT) is set during posting (more precisely at the event PROJECT) before the document number assignment and before the update is called. The entry time of the FI document must be available for other components, as these are partially used there.
In the case of the pseudo ascending document number assignment, a document with an earlier entry time may receive a higher document number. This is the case if other accounting components require a longer runtime after the time is set than for a document with a later entry time. However, this can also happen with an unbuffered number range.