Infor LN & Baan Tip: Performance improvement by setting the First Free Number Cache (tcmcs0651m000)
Many transactions in all kinds of modules use order numbers or serial numbers. These order numbers are most often automatically generated. In the Number Groups (tcmcs0151m000) session you can define groups of order numbers used for dedicated areas. A Number Group is a group of the first free number series that you can assign to a specific use. All the numbers that Infor LN generates in the number groups that are dedicated to the same purpose are unique.
All the first free numbers are stored in the table tcmcs050.
As many different processes can request a free number from the number groups, we often see delays in the performance, due to locking on the first free number records. This locking issue can have a severe impact on the performance of huge batch-type transactions, but also on the performance perceived by individual users in many areas in LN.
For example:
- Processing warehouse transactions. Single or in-batch
- Completing / closing orders
- Backflushing of production orders
- Generate Order Planning
- Cost calculation and warehouse revaluation
How this performance can be improved?
Resolution
In the Number Groups (tcmcs0151m000) session you can open the details of a specific Number Group (tcmcs0651m000) or start the session stand-alone.
In the Number Group, you define the Series with the related First Free Numbers. Per Serie in the First Free Number, you have the option to define the Cache Size.
This Cache size is defaulted on a value of 0 (zero). A cache size of zero means No Cache.
How does the First Free Number caching works:
- When the Cache Size is zero:
With this setting a process requests a Free Number from the Serie and the first free number is issued to the process. But the first free number record is not updated yet. At the moment the requesting process is finished, without errors, it reports back that the number is used and the first free number record is updated.
All the time that the process is working on the transactions the first free number record is locked. If another process is requesting a free number from the same series, it must wait (retries) until the record is updated and released by the previous process. This is the locking which is causing delays in the other processes.
- Setting the Cache Size to a higher value then zero activates the caching.
When the Cache Size is set to 1 or higher, the requested free number is sent to the requesting process, the first free number is updated, with the number as defined in the Cache size, and the record is saved.
It does not wait until the requesting process has reported back that is finished, with or without errors. In this way the record is immediately released and no locking will occur. If another process is requesting a free number, it does not need to wait until the free number record is released by the earlier process.
If the process is ended with errors and therefor the number is not used, this number from the series is lost. This can result in gaps in the numbering.
When the cache size is greater than 1, for example it is set to 5, the requesting process receives 5 free numbers. Even if it only needs less than 5. In this way the process only has to request for a new free number after it has used the first 5 numbers from the cache. This will also speedup the process in case of large batch transactions.
For ‘warehouse integration users’, like for example Factory Track or WMS users we advise to set the cache size to 5.
Note that financial documents are not based on number group series / first free numbers. Instead they are based on transaction type series, for which the caching functionality does not exist. Financial documents, like sales invoices, bank transactions, are thus not cached.
The caching is especially important to improve the performance of all logistical processes.
It is strongly recommended (mandatory) to set the Cache Size for all Number Groups to a minimum of 1.