NUMBER_GET_NEXT — NUMBER_GET_NEXT Function Module
NUMBER_GET_NEXT returns the next available number from a number range interval maintained via SNRO. It is released for customer use and is the standard way to draw document, order, or custom key numbers. Its critical behavior: the number is consumed immediately on call, independent of the database commit, so a rolled-back LUW still loses that number, creating a permanent gap.
This page covers NUMBER_GET_NEXT, the standard function module for pulling the next number from a number range object defined in SNRO. It focuses on the exception handling that is routinely skipped, the commit-independence of number draws that causes gapped sequences, and where responsibility sits between Basis, application teams, and developers when numbering breaks.
Published 16 Sept 2026· 1,065 words
What it does
NUMBER_GET_NEXT retrieves the next available number, or a block of numbers, from an interval belonging to a number range object created and maintained through transaction SNRO. It is a released, RFC-enabled function module and is the standard entry point custom developments use to draw sequential keys for Z-tables, custom document types, or any object needing gapless-looking but not commit-safe numbering. Application areas such as FI, SD, and MM wrap this same mechanism inside their own number range determination logic rather than calling it directly, because document type, fiscal year, and buffering rules add complexity on top. For custom objects it is called directly and is the normal, supported pattern.
Parameters
- NR_RANGE_NR (importing, mandatory) - the two-character interval identifier as defined in SNRO for the object.
- OBJECT (importing, mandatory) - the name of the number range object.
- SUBOBJECT (importing, optional) - required only if the object is defined with subobjects, e.g. per plant or company code.
- TOYEAR (importing, optional) - the fiscal or calendar year, required for year-dependent number ranges.
- IGNORE_BUFFER (importing, optional) - flag to bypass the number range buffer and read/update the database interval directly.
- QUANTITY (importing, optional, default 1) - number of numbers requested in one call, useful for reserving a block.
- NUMBER (exporting) - character field holding the first number of the returned block.
- QUANTITY (exporting) - actual quantity granted, which can be lower than requested if the interval overflows.
- RETURNCODE (exporting) - set to '1' when the last number in the interval has just been issued, a warning signal rather than an exception.
Exceptions
- INTERVAL_NOT_FOUND - the interval number passed does not exist for the object/subobject/year combination; usually a typo in NR_RANGE_NR or a missing SNRO entry for that year. Swallowed, the caller gets an unpredictable NUMBER value or a dump elsewhere.
- OBJECT_NOT_FOUND - the number range object itself was never created in SNRO, common with custom objects that were only defined in the data dictionary but never registered as number range objects. Silently ignoring this means every call downstream fails identically.
- NUMBER_RANGE_NOT_INTERN - the interval is flagged as external (user enters the key manually) and cannot be drawn from automatically. Calling this function on an external interval is a design mismatch, not a runtime fluke.
- QUANTITY_IS_0 or QUANTITY_IS_NOT_1 - the QUANTITY parameter was set to zero, or to a value other than 1 for an object that does not support blocks. Trapping this without correcting the call just masks a logic error in the caller.
- INTERVAL_OVERFLOW - the interval is exhausted; no more numbers are available. If this is swallowed, the process either aborts on a later insert with a duplicate or null key, or silently reuses numbers if custom fallback logic is present, which corrupts data integrity.
- BUFFER_OVERFLOW - the number range buffer ran out of pre-fetched numbers faster than it could refill, typically under heavy parallel load; ignoring it risks the same downstream symptom as INTERVAL_OVERFLOW.
How to call it safely
Call NUMBER_GET_NEXT inside a TRY/CATCH or classic EXCEPTIONS clause, checking every exception listed rather than only INTERVAL_OVERFLOW. After a successful call, immediately test RETURNCODE for '1' and raise an operational alert or trigger interval extension logic before the interval is actually exhausted on the next call. If QUANTITY was requested as a block, compare the exporting QUANTITY against what was requested, since a smaller number may have been returned near the end of the interval. Do not wrap the call in a database commit or rollback boundary expecting the number to be released back to the pool; it will not be.
ECC vs S/4HANA
NUMBER_GET_NEXT is unchanged in S/4HANA and remains released for customer use; number range objects are still maintained through SNRO. It carries no clean-core replacement for custom Z-object numbering, and direct calls for genuinely custom objects remain the supported approach. For standard business objects such as sales documents or FI postings, calling this function module directly instead of going through the application's own number range determination is discouraged in both ECC and S/4HANA, since it bypasses document-type-specific logic layered on top.
Common pitfalls
- Treating the draw as transactional: a number is consumed the instant the function module runs, whether or not the enclosing LUW ever commits. A user cancelling a document mid-creation still burns the number, leaving permanent gaps that support desks mistake for data loss.
- Ignoring RETURNCODE '1' assuming an exception will fire when the interval is actually full; the exception only fires on the call after the last number is already gone, so batch jobs can fail unexpectedly at month end.
- Setting IGNORE_BUFFER to bypass buffering as a quick fix for perceived gaps, which reintroduces database-level locking contention on the interval row and slows concurrent document creation dramatically.
- Requesting a block via QUANTITY on an object never designed to support blocks, triggering QUANTITY_IS_NOT_1 in production only under load when a developer's single-user test never exercised it.
- Rolling a custom retry loop that decrements and reuses a 'failed' number after catching an exception, which produces duplicate keys the first time two processes retry at the same moment.
Whose problem this is
The number range object definition and interval maintenance in SNRO belongs to the functional or Basis team that owns the underlying business object, since extending an exhausted interval is a configuration change with authorization implications. Correct exception handling and commit-safe usage in custom code is squarely the calling developer's responsibility; a gap in a sequence is not, by itself, a bug in NUMBER_GET_NEXT.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-function-modules/number-get-nextERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.