Похоже на бред, все равно постараюсь все изложить как можно понятнее, может кто то сталкивался или я гоню...

Создал свой объект номеров (он у меня с подобъектом - завод). Сам диапазон номеров в разрезе подобъекта один (01 0000000001 9999999999 текущий 600 например). Так вот. Звонит мне консультант и говорит, что вчера работало все, текущий номер 6хх, при создании выдает по порядку, все ок. Сегодня выдает 20, 21, 22 хотя условия создания такие, что счетчик должен продолжать выдавать по порядку 6хх. Захожу, по этим же пользователем. Смотрю. Делаю все тоже самое. Все нормально выдает 6хх. Создает он – опять 23, 24 и тд (криво). Система/мандант тот же, пользователь тот же 100%. В отладчике говорил ему что делать, на вход NUMBER_GET_NEXT подается все ровно, все как у меня, но номер у него левый выдает, а у меня правильный. Разные только машины (но это не важно, он пересаживался на другую, не работало также), еще может быть мы попали на разные аппликэйшн сервера, у нас их три (но это уже не важно, в тот момент я не догадался посмотреть). В SNRO все в норме показывает у обоих(текущий номер в смысле). В sm56 текущий номер у меня одно пишет - 6хх, у него - 2х. Буфер не сбрасывал. Потом каким то чудом у него вдруг счетчик выдал правильный номер и больше сбоя не было пока. Может быть кто то сталкивался с таким, меня беспокоит то что это может произойти еще раз?

Смотрел эти ноты, ответов не нашел.
Note 920234 - Mechanism to fill the number range buffer
Note 919785 - Problems when filling number range buffer

Так и не понял диапазон буфферизирован? и если да то каким способом?
и если буфферизирован то как раз таки очень важно на какой сервер приложений зашел пользователь.

Да, буферизован - "буферизация в ОЗУ" по умолчанию. Число номер в буфере 10.

С другой стороны, а как же стандартные объекты номеров с буферизацией...

В том, что начало нормально работать, вижу два варианта:
- в буфере сервера пользователя "закончились" неправильные номера
- пользователь зашёл в систему на другой сервер, с правильными номерами в буфере.

Совершенно верно, потому что консультант в реальном времени "крутил счетчик" не выходя из системы. Теперь как эти неправильные номера могли попасть в буфер? Может это как то связанно в апп сервером?

Вот что пишет BC414:

Скорее всего дело в том, что на 2-й сервер давно не заходили пользователи, которые используют программу с присвоением этого диапазона номеров

Сижу читаю хелп, курс, анализирую свою ситуацию, прикидываю и так и эдак, ну не сходится у меня в голове, сильно не пинайте... Как я понял, для моего случая нельзя использовать буферизацию, потому что у меня слишком большая интенсивность получения номеров, маленький размер буфера в следствие чего и получаются эти GAPS?

Потому что несколько серверов приложений;)
Посмотри ноты 840901 - Parallel buffering and pseudo ascending number assignment, 1398444 - Buffering the document number assignment for RF_BELEG

Удав, спасибо.
Всем спасибо!