This document is intended to explain how Year is selected when asking for a number.
- Number Range object is defined as Year-Dependant (in SNRO configuration, To-Year flag is selected). Field Year means until that year; so, in case there’s a range with year 9999, this means until 9999.
- Object has defined Financial Year 9999; but a new interval is created with FY 2050 (due to business requirements).
- When calling Number Range functionality NUMBER_GET_NEXT, it returns year 2050 instead of 9999.
Which will be selected FY?
In case of year dependent intervals, the following could happen:
- If a "catch all" interval exists (e.g. year 9999)
- and for the first time a new, current year dependent interval is accessed (e.g. 2050)
- and the number range object is configured for "parallel buffering" or "main memory buffering"
Then numbers from the wrong interval (9999) may be returned, instead of the new accessed interval.
There was an error, solved by Note 3064894 - NUM: dynamical creation of year dependent intervals (The correction is available in kernel releases 753 onwards only).
If the year 9999 (or any higher year than actual year) is buffered, a number from year 9999 will be automatically returned, even if in the meantime there is an interval with better or exact fit (in this particular example, year 2050 fits better).
For example, in instance 1 there is a buffer entry with year 9999 on instance 2 there’s no entry.
- If you draw a number from instance 1 you get a number from year 9999.
- If you draw a number from instance 2 you get a number from 2050. Until buffer is not reset on instance 1, numbers will be returned from year 9999.
There is a new correction to it with a kernel parameter described in this Note 3064894. This way, the kernel function ‘ThNoRead’ will return the correct year, in this case 2050.
In this case, when Number Range functionality was being called, there were different valid intervals. Calling Number Range functionality for Fiscal Year 2021, will include until year 2050, but also until year 9999.
The right outcome should be 2050. The year determination will be performed by the kernel, that's why
CALL 'ThNoRead' ID 'BNRIV' FIELD ls_bnriv.
should return the value 2050. This is the expected behavior, because the year means until year, and year 2050 is a better fit for year 2021 than 9999.
If correction from Note 3064894 is not implemented, and there are buffered numbers for year 9999, they will be returned (even if there’s a new interval that better fits, such as 2050, or a new interval that exactly fits, such as 2021).
How can this be changed?
- Implementing Note 3064894.
This way, the kernel function ThNoRead will return the correct year, in this case 2050.
With this option set it does not take the existing year entry from the buffer but checks whether it is still valid.
- If application server is restarted; or the buffer is manually reset; a new package of numbers will be loaded in the buffer. In this case, with correct “To Year” information.
- Note that there will still be numbers created with 9999 year and new numbers created for 2022. This should be considered based on application needs.
Note: “Differentiation by Financial Years”
It is possible to differentiate an interval by financial years. The specified financial year is always the upper time limit, the To Financial Year.
For example: if a number range object is differentiated by the “To Financial Year”, and it has interval 1 defined for the years 2023 and 2025.
>> An application table entry with the financial year 2006 will be assigned a number from the interval with the “To Year” 2013;
>> And an entry with the financial year 2024 will be assigned a number from the interval with the “To Year” 2015.