Всем привет. Столкнулись с проблемой ведения р/с для Китая (длина более 20 символов). Сделали запись р/с в три поля (по ноте рекомендуют два, но суть дела не меняет).
Столкнулись с проверкой на уникальность.
Поясню. Ввели р/с №1, длина 25 символов. Вводим р/с №2, длина 25 символов - первые 20 символов = первым 20 символам р/с№1. SAP выдает ошибку, считает, что мы вводим дубль р/с.

Нашел кусок стандарта:

p.s. Даже если мы сделаем по ноте, т.е. будем записывать р/с в два поля, то проверка на уникальность опять отработает только по первым 18 символам.
Буду очень признателен за любые идеи

Идея хорошая, но это полностью не исключит возможностей дубля, т.к. отличия могут быть не только в последних 18 символах...

Забавно, кстати.
Но, похоже, никак Вы это не обойдете.
В BUP_CHECK_BANK_ACCOUNTS все сравнения идут только по BANKS, BANKL, BANKN и BKONT.
Никаких запасных путей Вам там не оставили.
Правда можно заметить, что для IBAN все же отдельную ветку предусмотели, но в приоритете все равно опять же проверка по номеру счету, как я понял после прочтения кода.

Мое предложение простое - попробуйте схитрить.
Поскольку счет длинный и Вам все равно придется потом его лепить через custom при формировании платежа, сделайте в BANKN первый символ техническим, он будет вашим нумератором.
Или даже лучше BKONT. То есть он будет 01, 02 и пр. Остаток номера записывайте в Ref number.
Когда будете лепить номер для платежей, BKONT игнорируйте и лепите из BANKN и Ref.
При этом проверка уникальности в рамках одного партнера будет гарантирована за счет различного значения BKONT.

Спасибо за подсказки. Но в случае ввода тех. символов - всегда будет вероятность дублирования р\с - что тоже не есть гуд.
поменять местами поля записи - сохраняется риск ошибки при дублировании нескольких символов.
Приняли решение править стандартный код - вставим еще строку с проверкой нового поля таблицы, понимаю, что решение не очень, но время поджимает.

Вот это как раз можно решить собственной проверкой через расширение.
Поскольку верно утверждение о том, что стандартная проверка в случае Китая не работает И должна быть обойдена, то верно и утверждение о том, что реализовать нужно свою проверку. В ней можно перебирать имеющиеся записи в BUT0BK и в случае дублирования выкидывать сообщение.
Можно, конечно, и стандартный код долбануть, хозяин барин не потеряйте потом просто.