Создал Z-таблицу с двумя текстовыми полями. Одно из них ключевое.

Разрешил ведение.

Technical settings.

Echancement Category

Типы полей выбирал разные, сейчас остановился на том, что первое имеет тип TEXT40, второе TEXT_11.

Если вводить данные в SE16 (OLD), то всё вводится замечательно, глюков никаких нет, но там нельзя вводить записи массово.

В SE16N есть нюансы. Я пробовал в двух разных системах. В первой (тестовой) разрешено ведение мандантно-независимых таблиц, поэтому там таблица без поля MANDT (оно по смыслу не нужно). Во второй системе к этим двум полям добавлено поле MANDT с типом CLNT, чтобы можно было таблицу вести в SE16N.

В первой системе если вводить значения с клавиатуры, то всё вводится и сохраняется замечательно. Если вставлять из буфера обмена и в данных нет русских букв (а только латинские и или цифры), то тоже всё вставляется и потом сохраняется успешно.

Глюки начинаются если вставлять данные из буфера обмена. При этом они бывают двух видов. Если вставлять по одной строчке, то такие данные просто не сохраняются. Как вроде их нет. Кнопка SAVE нажимается, код PAI и PBO отрабатывает, но в базу ничего не попадает. Если вставлять сразу несколько строчек, то вставляется нормально, а при сохранении оно меняет все русские буквы на # и потом выскакивает окошко с ошибкой, что я пытаюсь вставить записи с одинаковыми ключами.

Во второй системе глюков с русскими буквами нет, но SE16N считает, что длина обеих полей 1 символ. То есть не даёт ввести больше одной буквы. Если редактировать существующую запись (введённую, например в SE16), то можно только удалять в ней символы (пока их больше одного).

Обе системы ERP6, unicode.

Судя по всему дело было в 2 вещах.

1. После прогона отчёта BALVBUFDEL SE16N стала воспринимать актуальный размер полей.
2. В той системе, где были клюки с преобразованием ввода, я вводил данные, работая через цитрикс. Когда вошёл напрямую, глюк исчез.

Вопрос снят.