Сбой при нумерации кредиторов

sap_nar

Добрый день.

Как найти и исправить причины по сбоям при порядковой нумерации кредиторов?
Например: (в Таблице LFA1)
№пп №кредитора
1 0001
2 0004
3 0005
4 0006

p.s. Удаление ОЗ кредиторов не было, т.к. отсутствует доступ на транзакцию.

darkduck

Могу только подозревать, что был технический сбой/дамп при создании кредитора между моментов "выдачи" номера из диапазона и моментом сохранения.
Есть, конечно, еще вариант, что между кредиторами 1 и 4 сбросились буфера на сервере, поэтому номера из буфера были утеряны. Но слишком маленькая разница в номерах для такого случая, да и номера кредиторов вроде как не буферизуются.

Yozhhhhh

Я тоже думаю, что там просто мотается нумератор. Скорее всего, произошло прерывание в создании основной записи кредитора. Счетчик интервала промотался вперед, но до сохранения дело не дошло. Теоретически можно попробовать заполнить дырку, назначив вместо внутренней нумерации внешнюю. Потом создать 2, 3, 4 кредиторов. Потом вернуть внутреннюю. Но я точно не могу сказать, позволит ли система баловаться сменой внутренняя/внешняя. А так ли критично, что образовалась дыра?

sap_nar

Ситуация повторяется уже в течение нескольких лет. Поначалу думал, что были удалены ОЗ кредиторов.
Проводя анализ последние месяцы, обнаружил, что удаления и ДАМПов не было, но порядок нумерации не соблюдается.

Rygor

Цитата:

обнаружил, что удаления и ДАМПов не было, но порядок нумерации не соблюдается.

Yozhhhhh написал:

Я тоже думаю, что там просто мотается нумератор.

Это не обязательно удаление или Дампы. Недавно у заказчика сталкивался с аналогичной ситуацией, но для создания фин. сделок.
Для создания сделок была создана Z программа, которая брала новый номер сделки, а потом уже обрабатывалась логика создания и заполнения полей. Когда что-то заполнялось неправильно, обработчик выдавал красную ошибку. Пользователя откидывало на момент ввода данных, но счетчик обратно не отматывался. И вся обработка начиналась сначала
Так что смотрите так же Z программы для создания Кредиторов.

Looker

sap_nar написал:

Ситуация повторяется уже в течение нескольких лет. Поначалу думал, что были удалены ОЗ кредиторов.
Проводя анализ последние месяцы, обнаружил, что удаления и ДАМПов не было, но порядок нумерации не соблюдается.

+1
эту картину наблюдал лет 10 назад на свеже установленных системах
за номером 1 идет 4
разбираться не стал, но никаких сбоев, дампов и т.д. не было
ситуация повторялась из раза в раз
считайте, что это фича программы

Yozhhhhh

Я тут с утра покопался ради интереса, кажется, нашел.
Номер контрагента получается обычным CALL FUNCTION 'NUMBER_GET_NEXT' в MF02KFK0, тут ничего подозрительного.
А вот дальше зацените.
perform modify_account_number, внутри него call method g_additional_data->modify_account_number, дальше CALL BADI l_badi->MODIFY_ACCOUNT_NUMBER.
И, наконец, FI_PSO_CONTROL_DIGIT_APPEND.
Это какая-то хитрая приблуда, которая после присвоения номера способна его заменить. Всюду фигурируют какие-то интересные таблицы наподобие PSOAC01 "ПарамНастройки местной власти (метод контрольных цифр)". Смотрю на все эти фразы и складывается ощущение, что в зависимости от некоего активного метода контрольных цифр номер, который вернет нумератор, систему не устроит и она его заменит. Что-то наподобие контрольных цифр в расчетном счете.

Наверное, при желании можно докопаться до истины:) Но я могу и ошибаться. Хотя я, конечно, ума не приложу, чем номер 2 настолько криминален, а 4 - уже хорошо:)))

Yozhhhhh

Решил создать кредитора 2

В перечисленные выше функции система заходить не хотела, поскольку в PSOAC01 у меня значение 'KREDITOR' отсутствует.
Притворился, что у меня эта фишка активна.
В результате каких-то (честно скажу непонятных) манипуляций над номером (система смещала что-то, вычитала, делила, смотрела остаток от деления) двойка была заменена на 27

Так что предлагаю автору поставить точку в MF02KFK0 при вызове подпрограммы modify_account_number и дальше самому насладиться процессом.
Почти уверен, что это происходит именно здесь.
На всякий случай предлагаю проверить таблицу PSOAC01, если ли там запись OBJECT = 'KREDITOR'. Если есть, то почти точно именно эта штука порождает пропуски.

p.s. Посмотрел в IMG, где это настраивается, почитал справку к внедрению, вроде бы там вообще речь не о том идет, о чем я написал :oops:

но все равно есть смысл попробовать поотлаживать это место.

sap_nar

Добрый день.

Предположительно причина из-за буферизации, в ноте 1919449 указана:
Буферизация - увеличивает производительность сервера и документы не теряют своих свойств. Тем не менее, это может привести к пробелы во внутренней нумерации и иногда цифры не могут быть назначены непрерывно. Но это не приведет к несогласованности в системе.

Решение: При необходимости можно отключить буферизацию:
Транзакция: SNRO.
Объект: KREDITOR.
Нажмите кнопку "Изменить".
Редактирование -> Настройка буферизаций -> Нет буферизации.
Сохраните изменения.

sap_nar

Теперь, надо понять. Чем чревато отключение буферизации по кредиторам?
Т.к. при отключение программа угрожает:

Цитата:

Вы собираетесь изменить вид буферизации. Это может привести к правовым последствиям и
повлиять на производительность. Проверьте, какой вид буферизации является оптимальным для этого
объекта диапазона номеров.

darkduck

Проверил в своей системе.
Действительно, буферизация для кредиторов у меня включена, но размер буфера - 5 номеров. Это не может быть объяснением для дырки между номерами 1 и 4.

Человек

darkduck написал:

Проверил в своей системе.
Действительно, буферизация для кредиторов у меня включена, но размер буфера - 5 номеров. Это не может быть объяснением для дырки между номерами 1 и 4.

Не совсем понятно - у вас те же пробелы в нумерации что и у топикстатера? Буферизация работает следующим образом на каждом из существующих серверов приложений резервируется набор номеров соответствующий размеру буфера - потом сервер перегружается и у вас появляются пробелы в нумерации т.к. следующий раз резервация номеров происходит с конечных границ диапазона не важно был он вычерпан или нет. Так что если размер буфера у топикстатера 4 тогда gap между 1 и 4 объясним именно этим.

darkduck

У меня такой проблемы нет, по крайней мере никто не поднимает такой проблемы со стороны бизнеса.
Смысл моего предыдущего сообщения в том, что стандартный буфер (а у меня никто этой настройки не трогал) - 5, поэтому проблема 1-4 не может быть вызвана буферизацией. И лучше в этом случае настройку буферов не трогать.

sap_nar

darkduck написал:

Проверил в своей системе.
Действительно, буферизация для кредиторов у меня включена, но размер буфера - 5 номеров. Это не может быть объяснением для дырки между номерами 1 и 4.

Это и указана в ноте:

Цитата:

Sympom:
The Vendor numbers are not continuously assigned. For example,
There are gaps (missing Vendor numbers) in Vendor numbers.
Resolution
If Your business requirements are that the internal number has to be continuous, please consider disable buffering for Object type KREDITOR. In order to do this, please follow these steps:
T-code SNRO.
Enter Object type KREDITOR.
Press "Change" button.
Edit -> Set up buffering -> No buffering.
Save the change.

darkduck

Я понимаю, что указано в ноте.
Однако, если у Вас буферизация настроена на 5 записей, то при первом обращении к диапазону номеров в него будут помещены номера с 1, 2, 3, 4, 5. Вы создаете кредитора с номером 1, в буфере остаются номера 2, 3, 4, 5. Если по каким-либо причинам Ваш буфер сбрасывается, например, при перезагрузке сервера, то указанные номера теряются. Новое обращение к диапазону номеров дает значения 6, 7, 8, 9, 10. Будет создан кредитор с номером 6.
Таким образом, стандартной буферизацией в 5 единиц нельзя объяснить пропуск номеров 2 и 3 при существовании кредиторов 1 и 4. Раз нельзя объяснить, значит, буферизация здесь не виновата. И нечего ее трогать.

Сбой при нумерации кредиторов

Кто сейчас на конференции