Добрый день!
Прошу помощи вот в какой ситуации.
Делаю загрузчик при помощи LSMW. При считывании данных из файла внезапно оказывается наполовину обрезанным одно из полей. Все последующие (те, что правее в файле) LSMW вообще отказывается видеть.
Опережая ваши догадки о неверном выборе длины поля, укажу следующее.
У меня в файле есть столбцы, не подлежащие загрузке. Я их удаляю. После этого мое обрезанное поле оказывается практически целым. Значение в этом столбце оказалось увеличенным на длину удаленных строк.

Пример.
Так выглядит файл:
БЕ Инфо Поле1 Поле2 Поле3
БЕ11 инф1 123 1234567890 123

Так выглядит Read Data в LSMW:
БЕ Инфо Поле1 Поле2 Поле3
БЕ11 инф1 123 12345

Удаляю столбец "Справ. инфо" из файла, заново считываю:
БЕ Инфо Поле1 Поле2 Поле3
БЕ11 инф1 123 123456789

Такое чувство, что есть ограничение на длину входного файла. Но файл у меня достаточно маленький, обрезает примерно на 60 символе. Есть загрузчики, работающие с гораздо большими файлами. В файле нет кавычек. "Generate Read Program" не спасает.
Впервые с подобным сталкиваюсь. Пожалуйста, помогите

А ну-ка не поленитесь и расскажите, как расставлены галки в разделе "Выбрать файл".
LSMW очень чутко реагирует на галки, расставленные там.
Проверьте: TABULATOR = 'X' (radio)
Field names at start of file = 'X' (check)
Field order matches source structure definition = ПУСТО (check)

Попробуйте установить вот такое.
В противном случае система берет поля в том порядке, как они использованы в рекординге (если используется batch input).
На 99 процентов ошибка там.

Спасибо за участие, Yozhhhhh. Нет, дело не в этом.


Косяк не в порядке полей. Если я какой-нибудь "непомещающийся невидимый" левый столбец помещаю правее, его становится видно в "Display Read Data". А тот, что уехал в результате направо - не видно.

Смотрю вот отладку сгенерированной программы импорта. В <L_UPLOAD_TABLE> уже обрезаются все строки. Что на размерность этой таблицы влияет - понять не сумел

Тогда даже не знаю, чем Вам помочь.
У Вас абсолютно обычная задача и LSMW ничего не обрезает никогда.
Ограничений подобных не существует.
Попробуйте повторить все этапы LSMW с самого начала.

Повторял - не помогло.
Имеет значение, что я заполняю Z-таблицу в Z-транзакции ее ведения?

Не думаю. Если проблема возникает еще до пакетного ввода по считанному файлу, то есть на этапе чтения из txt и разноски по полям структуры, то становится даже не важно, Z это или нет. Это "движок" самой LSMW.
Мозговой штурм:
1. Вы txt файл создаете? Фраза "непомещающиеся невидимые столбцы" смущает. На листе Excel нет скрытых столбцов? При генерации текстового файла Excel берет все столбцы. Скрытые тоже. Возьмите вообще чистый лист, закиньте туда данные. Только те столбцы, какие нужны. В первой строке имена полей, латинские. Ровно те, какие указаны в структуре, созданной для данного subproject. Сделайте везде текстовый формат. Еще до заполнения листа данными. Оставьте в общем формате только суммы. Сохраните его в формате Unicode текстовый с разделителями. Зайдите в файл, убедитесь, что разделителем выступает табулятор, а в конце нет пустых строк. Если есть, удалите.
2. Далее, по самой структуре. В ней сделайте все (!!!) поля типа C (char). Если сомневаетесь по длине своего максимального значения, то указывайте с запасом, но не более, чем позволит поле экранного ввода. Только суммы оставьте AMT13(2). В структуре сделайте только те поля, которые берутся из файла.
3. В рекординге (у вас же batch?) на первом этапе оставьте только те имена полей, которые есть в структуре. Там, где значение идет дефолтом, затрите имя поля.
4. Откройте правила мэппинга. Сделайте автоматическую интерпретацию. Если есть какой-то abap, проверьте, не приводит ли он к обрезкам.

Перед Вами кристально чистый LSMW, который не может не работать.
Тут никакого колдовства быть не может. Написать LSMW можно на саму LSMW Если этот файл не загрузится, пишите.

[quote="Yozhhhhh]Не думаю. Если проблема возникает еще до пакетного ввода по считанному файлу, то есть на этапе чтения из txt и разноски по полям структуры, то становится даже не важно, Z это или нет. Это "движок" самой LSMW.
[/quote]

Спасибо! Проблема решилась. Дело было в другом.
Долгое копание в отладке привело к ответу. Хитрый SAP считывает из файла столько символов, сколько описано в структуре. В моем случае BUKRS (4)+MWSKZ(2)+...=X. Вот после этих X символов и началась обрезка. Я пользовался рекомендациями выделять под поля в структуре ровно столько символов, сколько нужно, без "запаса". В случае с "ненужными" полями посреди файла и обнаруживается такой затык. Так что можно увеличивать длину полей, добавлять фиктивные поля в структуру или допиливать программу импорта.
Надеюсь, мой опыт кому-нибудь пригодится

Вы немного лукавите. При выставленных галках (как было на Вашем скриншоте) система берет данные из второй строки (первый оставляет под заголовок) и НЕ учитывает порядок следования столбцов. Это означает, что LSMW будет искать столбец по его наименованию, порядок следования не важен. Поэтому Вы можете их перемещать сколько угодно.
Дальше все просто. Значением является то, что стоит между двумя знаками разделителей. Наконец, в загрузку подставляется то число символов, которое указано в длине поля в объявлении структуры. Система не залазит за пределы разделителя никогда.

Это означает, что если при перемешивании столбцов Вы получали другой расклад, то система забирала значение не из объявленного столбца ИЛИ в файле были проблемы с разделителем. А структура действительно может содержать технические поля. Например, для их использования в ABAP-обработке другого поля.

Судя по вашим наблюдениям LSMW уже на HANA портировали...

Так и есть, программа ищет столбец по его наименованию. Вот только сначала построчно считывает файл. Длина импортируемой строки равна сумме длин всех полей, описанных в структуре "Source Fields". Если незагружаемых столбцов много, то [s]левые[/s] правые конечно же столбцы из-за этого могут не попасть в считанную таблицу <l_upload_table>. Размерность этой таблицы определяется описанными полями. Уже в этой <l_upload_table> программа ищет столбец по наименованию.
Как определить проблемы с разделителем? Сохранял из Экселя в txt с разделителями табуляции. Аналогично описывал файл в Specify File. Открывал файл в Ворде с непечатыемыми знаками - все ок.

Что значит "система забирала значение не из объявленного столбца"? Конечно у меня есть в файле необъявленные в структуре столбцы - я о них и говорил, там просто информация для справки

Но из это следует, что если есть ХОТЯ БЫ ОДИН незагружаемый столбец, то Вы всегда лишались бы части символов в загружаемой строке. Лишались ровно такого количества символов, какое было в незагружаемых столбцах. Признаться, я всегда гружу только те столбцы, которые нужны для структуры, остальное - дефолтом. Мне стало интересно. Я проверю в своей системе - нашпигую таблицу загрузки лишними столбцами в начале и в середине.

Исключите случай, когда в структуре у Вас на сумму отведено 12 знаков, а в файле 1 рубль
У меня в общем-то тоже практически всегда лишних столбцов нет. А сейчас есть столбцы исключительно для подстановки в какие-нибудь формулы. Удалять их - увеличивать риск ошибиться. Поэтому я решил грузить "как есть"

И все же система сделала, как я себе и представлял.
Для начала я добавил в Excel столбец с заголовком, которого в структуре не было вообще. Туда забил строчку из стихотворения Некрасова. Система вывела информационное сообщение "Not all field names of file .... defined in the source fields." Значение из этого столбца система проигнорировала. Она не "кушала" оттуда символов, куда бы я его ни помещал - ни в начале, ни в середине.
После этого я добавил это поле в структуру. Умышленно сделал его очень короткой длины (10 символов, при этом длина значения в столбце было намного больше). Система его распознала и взяла оттуда ровно столько, сколько было нужно - 10 символов. Остальные значения опять же не пострадали и не обрезались.

Моя картина мира не пострадала

А столбцы, расположенные правее строк Некрасова, все корректно обработались? Не обрезались? Имею в виду столбцы, описанные в структуре