При прокачке инфо-куба возникла ошибка, которая выглядит вот так:



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

Возникает вопрос, а что же не так с этой записью. Есть подозрение на последний символ типа "с".
Но также непонятно, есть ли что-то еще за ним, потому что, как видно из скрина, там стоит пробел.
В окне Диагностики вообще фигурирует какой-то амперсанд, хотя возможно это фрагмент сообщения.

Взяв за основу шестнадцатиричный код, я попробовал его преобразовать в символьный вид, то есть получить вот это значение: '18795/191с '

Однако, если ввести в HexWorshop: 00 31 00 38 00 37 00 39 00 39 00 35 00 2F 00 31 00 39 00 31 04 41 (там еще в конце подозрительный пробел, даже для гекс-кода, но его игнорим), то получается .1.8.7.9.9.5./.1.9.1.A

То есть на конце А, но не "с".

В целом, возникают следующие вопросы:
1. Есть ли способ более грамотно расшифровать гекс-строку и получить именно ту строку, которая приведена в ошибке.
И тем самым понять что это за символ такой в конце. И вообще в нём ли дело.

2. Как можно было бы исправить эту ошибку. Нужно ли создавать DTP ошибок, или может быть можно просто через стэк ввести нужное значение.

Добрый день, посмотрите вот это.

Хотя, проблемы с непечатными символами я тут не вижу, попробуйте добавить "с" (строчная буква "с" нашего алфавита) в разрешенные символы в транзакции RSKC.
Разобрался: в данной ситуации SAP русский символ "c" (строчная буква русского алфавита), который интерпритируется в HEX как "0441" разбивает на hex-коды 04 и 41, что соответствует - "04" - непечатный символ END OF TRANSMISSION (EOT) (на который ругается система) и 41 - латинская "A".

ИМХО, заглушки делать в BW - дело последнее, пусть ответственный правит поле в исходной системе и потом перезагружать в BW. А то потом поле криво у них же где-нибудь и вылезет на форме печатной или еще где-нибудь.

Да тут вполне может быть что такой номер является правильным с точки зрения бизнеса

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

а если этот номер будет потом использоваться как какой-нить ссылочный ключ? тогда будет поблема в поиске ошибок

нет, я про:

А с чего бы unicode-символу разбиваться на 2 отдельных?
В общем, тут я сам себе противоречу... не доказано, ведь, что там есть левый символ, вернее, судя по HEx, его там нет.

Пусть сначала покажет, что там у него в RSKC.

AlexanderGamov, спасибо, это действительно русская маленькая "с".
Подскажите, только, как вы это определили что именно 0441?
Вот если в текстовом редакторе вбить русскую с, и посмотреть в гекс режиме, то получается 0A F1, например.
Если в Hex Worshop вбить 0441 то получается .A в принципе, это то о чем вы говорили, но как сопоставить .A и с?

refeline, в RSKC есть большие русские буквы, так что задача решена вставкой функции UPPERCASE в трансформацию.
Кстати, тут возникает побочный вопрос, почему в этой транзакции только 72 разрешенных символа. Почему не больше.

А вот если бы это была какая-нибудь кракозябра, которой в RSPC нет (и там все вакантные места уже заполнены), вот тогда действительно непонятно, что нужно было бы делать...
Ну, кроме как стучать по рукам тем, кто вбил ее в источнике, и чтобы они правили значение.

Добрый день, в ОС Windows есть стандартная программа "Таблица символов" (%windir%\system32\charmap.exe). Соответственно коды символов я смотрю там.

AlexanderGamov, вопрос с кодировками прояснён, благодарю.

А вообще, наверное нужно создавать некий класс, который бы брал любой кривой символ и превращал его в нечто разрешенное из RSKC.
Но четкого представления, как это можно сделать у меня нет, так, лишь некоторые подозрения. Любые подсказки на этот счет приветствуются )