Здравствуйте.

Вот какая ситуация:
в транзакции есть 2 поля: кол-во и ед.изм (в них можно например записать 5 месяцев или 12 лет и т.д.), а в таблице это хранится в одном поле типа char25 и выглядет вот так "DUR#######MONTHтут_семь_пробеловX##" - в таком представлении можно прочитать ед. изм -- месяц (MONTH). Если перевести в код ASCII, то будет выглядеть так
"4455520000000000021C4D4F4E544820202020202020580000"
и тогда уже можно будет прочитать кол-во -- 21 (перед C4 )

В дебаггере при просмотре
"DUR#######MONTHтут_семь_пробеловX##" пишется в строке "значение",
а "4455520000000000021C4D4F4E544820202020202020580000" - в строке "шестнадцатиричный код"

Вопрос: как программно из "DUR#######MONTHтут_семь_пробеловX##" получить "21 месяц"?

P.S. Речь о стандарте: таблица SCAPPTSEG, поле TXT_PUB_ID, тр. CRMD_BUS2000115
тут_семь_пробелов - пришлось вписать потому как большое количество пробелов превращается в один

Опечаточка: не 21, а 02 1С, и это отнюдь не двадцать один месяц!
А по сути выделить подстроку с 7 по 10 байт и, если они действительно представляют собой целое, то с помощью assign ... casting преобразовать в int4.

Было бы неплохо найти место, где эта строка расщепляется в стандарте. Тогда всё встанет на свои места. Может даже структурка есть в словаре, куда это хозяйство присваивается и автоматически разбивается на поля.

Посмотрел в Solution Manager'e, там поле SCAPPTSEG-TXT_PUB_ID заполняется текстовой строкой, похожей на base64: rxyQoDmepaAcm}ha1anRhW

45 55 20 00 00 00 00 00 21 C4 D4F4E544820202020202020580000

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

Это не опечатка, но корректнее с моей стороны было бы написать просто "перед С". А 21 - это сто пудов количество месяцев, проверено опытным путем: если в заказе 150 месяцев, то 4455520000000000150C4D4F4E544820202020202020580000; если 11725- то 4455520000000011725C4D4F4E544820202020202020580000.

Спасибо за ответы. Проблема уже решена: добрые люди подсказали использовать метод cl_xms_main=>convert_string_to_xstring.

исходно было
44 55 52 00 00 00 00 00 02 1C 4D4F4E544820202020202020580000

Неважно, как было.
Очевидно же, что 4D = 'M', 4F = 'O', ...