Коллеги, столкнулись со следующей проблемой: в системе ERP для некоторых табельных номеров не формируется номер кредитора.
По порядку:

1. Мы работаем в модуле SAP HR (GOP), принимаем сотрудников (PA40)
2. В инфотипе 09 Банковская инфо заводим нужные данные (3 осн. цифровых поля в формате: банк. ключ (9 цифр), контрольный ключ (всегда = 40) и счет (20 цифр)
3. Эти данные через интерфейс отправляются в ERP
4. Автоматически система формирует номер кредитора в формате (мы его можем посмотреть через zx_se16)

Как нам объяснили ребята из техподдержки (индусы) - система на стороне ERP комбинирует эти 3 цифровых кода (перемножает, плюсует, делит на 10) и высчитывает итоговую сумму всех остатков. Эту сумму они снова делят на 10. Если эта итоговая цифра = 0, то система формирует номер кредитора без проблем. Если не равно 0, то номер НЕ ФОРМИРУЕТСЯ никак.
Я думала, что это настройки интерфейса, но они утверждают, что это стандарт SAP.

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

Вопрос: действительно ли таков стандарт САП ? На что это влияет, есть ли выход из такой ситуации...

Могу выслать детальные расчеты, примеры...

Что за проверка такая? Похоже на CRC. Вы может данные неверно завели?

Возможно, что действительно для некоторых стран есть такая проверка - правильно ли введен номер счета: на основе БИКА, контролького ключа и номера счета.

Проверьте что люди заведены в РФ, а не в допустим Германии, еще стандарт предписывает номер счета указывать 18 цифр, без "40".

Уф. Обожаю копаться в самых потрохах
За это отвечают функциональные модули на событии 3000.
Это модули SAP-приложения (транзакция fibf).
Работают они, если для страны в таблице T005 активен индикатор t005-xprbk (Индикатор: использовать МодКонтрл для данных банка?).
Он у Вас включен.
Дальше просто. Если у банка отметка ЖИРО-счет отключена, то отработает ФМ FI_CHECK_BANK_ACCOUNT_RU с события 3000 (если ЖИРО включен, то будет ФМ с события 3020, но у Вас, уверен, эта отметка не стоит). В этом модуле прекрасно видно, как всюду мелькает остаток от деления на 10 и все остальные прелести.

DO 23 TIMES.
REFE1 = STRING(1) * BWEIGHTS(1).
REFE2 = REFE1 MOD 10.
SUMME = SUMME + REFE2.

SHIFT STRING.
SHIFT BWEIGHTS.
ENDDO.

Чтобы не приходить в это место, просто уберите индикатор t005-xprbk в настройке стран. Однако насколько это правильно, я оценить, к сожалению, не могу. Данный модуль писался специально под Россию, а в номере банковского счета, как известно, есть вполне конкретная логика.

хмм... Спасибо! Будем пробовать!

а что значит - "вполне конкретная логика в номере банк. счета" ?

Точно не скажу, каждый разряд отвечает за что-то. В 18-значном номере счета присутствует в кодированном виде и валюта, и многое другое.
Вот Вам еще решение.
Когда в конце ФМ проверка не пройдена, идет вызов сообщения AR(124). Стандартно оно с типом "ошибка", однако оно кастомизируемое, то есть настраиваемое.
В транзакции OBA5 замените у него тип в диалоге и в пакетном вводе на "W" или отключите совсем ("-").
Полетят Ваши кредиторы в систему благополучно.

По поводу алгоритма http://eos.ibi.spb.ru/umk/5_12_11/15/15_P3_R1_T3.html

Все же склоняюсь к мнению что данные у вас неверные

Аццкий алгоритм, кстати

Ребята.. спасибо за советы..

Данные верные - HR отдел уже проверил несколько раз.. По этим данным начисляются выплаты..

Ну тогда галку снимайте у страны банка и живите спокойно.
Или ослабьте тип сообщения в OBA5.

Ребята, а в OBA5 какой тип диалога выбирать ?

В диалоге W, в пакетном можно вообще отключить (-).

Ребята, всем спасибо!

Настроили тип сообщения, все отработало. НО оказалось, что действительно у банка существует ДРУГОЙ ВАРИАНТ БИК, который остаток не дает!!!

Так что коллега, который говорил, что данные ошибочны, был таки прав ))))