Комментарии по теме

«Инстру­кция по созданию отчёта в тра­нза­кции SQVI»
Олег Точенюк:
Ну это вы погорячились вязать код БЕ заголовка, с кодом БЕ позиции. Код БЕ заголовка отвечает за то, где будет отражена кредиторская задолженность, а код БЕ в позиции отвечает за то, где будет...
«Методика создания варианта тра­нза­кци­и: тра­нза­кция SHD0»
Олег Точенюк:
Как вариант решения проблемы, нашел тут у себя создание системного варианта транзакции MBPM. Думаю в данном случае можно попробовать так тоже сделать.   === Для этого запускаем стандартную...
«Инстру­кция по созданию отчёта в тра­нза­кции SQVI»
Елена Ткаличенко:
Добрый день! Алексей, а можно и мне самопальную инструкцию? Заранее спасибо

База знаний

Вы можете подписаться на эту колонки этого автора, если авторизируетесь или зарегистрируетесь

Транзакция LSMW инструкция по применению. Часть 7

12 ноября 2018, 14:58

Загрузка остатков ОЗМ методом BAPI в транзакции LSMW

Продолжение книги.

Часть 1  Часть 2  Часть 3  Часть 4  Часть 5  Часть 6

В этой главе будет описано использование BAPI-метода на примере загрузки остатков (создание документов материала 561 видом движения). В основе подхода лежит использование типа сообщения MBGMCR, который вызывает BAPI_GOODSMVT_CREATE. BAPI-метод уже был подробно описан в главе 2, поэтому в настоящей главе не будут описываться шаги подробно, а детальное описание будет уделено новой информации. В решении бизнес-задачи мы находимся на этапе загрузки остатков по созданным ОЗМ (рис. 5.1). В примере будет показано, как создать множество документов материалов с несколькими позициями, используя один входной файл.

Рис. 5.1. Задача загрузки остатков в общей схеме задач миграции 

Задача состоит в загрузке начальных остатков по разным субсчетам счета запасов (10-го счета в плане счетов Минфина РФ). В главе будет показан пример использования одного файла для двух входных структур (использование опции Identifying Field Content); будет показан пример использования маски в имени файла (Wildcard option); пример создания и применения параметра селекционного экрана, а также примеры дополнительного ABAP-кода посредством user-defined routines и работа с полями типа DDMY (дата) и AMT1 (сумма).

5. 1. Операционные условия

Требуется прогрузить остатки на склад с помощью 561-го вида движения на основные записи материалов; при этом нужно обеспечить загрузку нескольких позиций документов материала с помощью одного входного файла; также необходимо сделать возможным параллельную загрузку по разным субсчетам (чтобы для разных субсчетов был свой файл на сервере). Вводные данные для загрузки представлены в таблице 5.1. Для загрузки нескольких позиций в документе материала нам нужно использовать две структуры-источника. Однако для этих двух структур мы можем использовать один файл с данными. Для этого часть полей нам придется задублировать в структурах, но дублирования данных при этом не будет.

Табл. 5.1. Используемые переменные поля для загрузки остатков

Пройдемся вручную через MIGO по полям документ материала, обозначенным в таблице 5.1, и создадим документ материала. Созданный документа материала представлен на рис. 5.2.

Рис. 5.2. Создание документа материала для начальной загрузки остатков

5.2. Пошаговое решение задачи

Шаг 1: создание/выбор проекта, подпроекта и объекта

Для создания нового проекта транзакции LSMW будем использовать данные из таблицы 5.2.

Табл. 5.2. Данные для создания объекта LSMW

После указания данных подтверждаем ввод и запускаем проект. Система откроет перед нами основное меню транзакции LSMW.

Шаг 2: параметры метода загрузки: выбор объекта и метода

Дважды щелкаем по пункту меню Maintain Object Attributes. В качестве объекта метода Business Object выбираем BUS2017 (Goods Movement), метод — CREATEFROMDATA (Post Goods Movement) (рис. 5.3).

Рис. 5.3. Указываем объект и метод для использования BAPI-метода

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

Шаг 3: создание структуры источника [данных]

Переходим к пункту Maintain Source Structures. Создаем структуры ZDOCHEAD (Заголовок документа материала) и ZDOCITEM (Позиции документа материала). Система отобразит экран, как на рис. 5.4. Затем сохраняем и выходим, чтобы перейти к следующему шагу.

Рис. 5.4. Созданная структура загрузки данных 

Шаг 4: ведение полей структуры источника [данных]

Щелкаем дважды по пункту Maintain Source Fields. Ставим курсор на структуру ZDOCHEAD (Заголовок документа материала) и нажимаем на кнопку Table Maintenance (рис. 5.5). Поля для структур ZDOCHEAD и ZDOCITEM приведены в таблице 5.3. При заполнении типов данных полей обратим внимание, что для даты имеется три формата DDMY, DMDY, DYMD, при этом каждый из форматов может быть как с разделителем, так и без него. Для суммы имеется четыре формата: AMT1, AMT2, AMT3, AMT4. Из описания видно, чем отличаются форматы (рис. 5.6).

Табл. 5.3. Поля структуры источника ZDOCHEAD (заголовок документа материала)

Рис. 5.5. Используем ввод через таблицу (Table Maintenance)

Рис. 5.6. Пояснение к форматам даты и суммы в транзакции LSMW

После заполнения данных касательно полей структур система отобразит экран, как показано на рис. 5.7.

Рис. 5.7. Входные структуры с полями

На этом шаге нам нужно заполнить атрибут Identifying Filed Content в заголовочной и позиционной структурах. Это поле позволит нам использовать один файл для двух структур. Использование одного файла удобнее и надежнее, чем использование двух. Поле, которое позволит нам различить заголовок и позицию, будет HEAD_OR_ITEM. Дважды щелкаем по этому полю для структуры ZDOCHEAD, система отобразит экран, в котором мы укажем значение для поля Identifying Field Content — HEAD (рис. 5.8).

Рис. 5.8. Заполнение поля Identifying Field Content для структуры ZDOCHEAD значением HEAD

Затем проделаем похожие действия, но для структуры ZDOCITEM поля HEAD_OR_ITEM. Дважды щелкнем по этому полю и укажем значение для поля Identifying Field Content — ITEM (рис. 5.9).

Рис. 5.9. Заполнение поля Identifying Field Content для структуры ZDOCITEM значением ITEM

Нам необходимо вывести поле TESTRUN на селекционный экран. Для этого дважды щелкаем по полю TESTRUN в структуре ZDOCHEAD и отмечаем галкой атрибут Selection Parameter for Import/Convert Data (рис. 5.10).

Рис. 5.10. Обозначаем поле в качестве селекционного параметра экрана

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

Шаг 5: соответствие структур источника данных и записи

Дважды щелкаем по шагу Maintain Structure Relations. Создаем соответствие структур, как показано на экране (рис. 5.11). Сохраняем, выходим, переходим к следующему шагу.

Рис. 5.11. Присвоение структуры входного файла и внутренних структур и структур типа сообщения

Шаг 6: мэппинг (соответствие) полей источника [данных] и полей структур BAPI и User-defined routines

Дважды щелкаем по шагу Maintain Field Mapping and Conversion Rules. На данном шаге производим мэппинг полей входного файла и структуры BAPI. Предварительно с помощью кнопки Layout откроем дополнительные области, где можно указать ABAP-код (рис. 5.12).

Рис. 5.12. Открываем поля для дополнительного ABAP-кода

Пройдемся по блокам и полям и произведем мэппинг; данные для мэппинга приведены в таблицах 5.4.а–5.4.б.

Табл. 5.4.а. Мэппинг полей структур BAPI и входного файла

Табл. 5.4.б. Мэппинг полей структур BAPI и входного файла

Чтобы присвоить фиксированное значение (Fixed Value) полю, нужно поставить курсор на поле и нажать на кнопку Fixed Value, в открывшемся поле ввести переменную (если она не существует, то система предложит создать ее) (рис. 5.13).

Рис. 5.13. Указание Fixed Value (фиксированного значения) для поля

Также заметим, что мы можем вести подпрограммы для всего проекта (так называемые user defined routines) и ABAP-routines для конкретного загрузчика, которые доступны в самом конце загрузчика (рис. 5.14).

Рис. 5.14. Место в загрузчике для ABAP-подпрограмм, специфичных для отдельного объекта LSMW (загрузчика)

В нашем случае мы будем создавать подпрограмму, общую для всего проекта, то есть в пункте меню Maintain Fixed Values, Translations, User-Defined Routines (рис. 5.15).

Рис. 5.15. Пункт меню Maintain Fixed Values, Translations, User-Defined Routines

Мы сослались на несколько фиксированных значений (Fixed Value) и одну подпрограмму (User defined routines). Чтобы задать значение для Fixed Value, нужно поставить курсор на нужное Fixed Value и нажать пиктограмму Change / Изменить (рис. 5.16), затем ввести нужное описание и значение.

Рис. 5.16. Задаем описание и значение для FixedValue TARGET_PLANT

Данные по остальным фиксированным значениям (Fixed Value) приведены в таблице 5.5.

Табл. 5.5. Данные по фиксированным значениям (Fixed Value)

Обратим внимание, что на экране фиксированное значение может идентифицироваться, например, как MOVE_CODE, а вот обращение к ней в программе происходит по имени переменной fv_move_code (то есть добавляется префикс fv).

Теперь переходим к определенной пользователем подпрограмме SKIP_RECORD. Назначение этой подпрограммы — правильно указать системе, что текущую запись нужно пропустить. В нашем случае запись — это позиция документа материала, а транзакция — весь документ материала. Мы пропускаем весь документ материала в случае, если единица измерения на входе отсутствует хотя бы в одной позиции. Ставим курсор на нужную нам User-Defined Routines и переходим к изменению с помощью пиктограммы Change / Изменить (кнопка с карандашом) (рис. 5.17).

Рис. 5.17. Переходим к редактированию подпрограммы skip_rec

Обратим внимание, что техническое имя подпрограммы — ur_SKIP_REC. Нужный код для подпрограммы приведен в таблице 6. Обратим внимание и на то, что ни одну из переменных мы не определяем. Переменные g_skip_record, g_transfer_record, g_skip_transaction и g_transfer_transaction специально служат для целей пропуска записей и определены глобально; равно как и константы yes и no (таблица 5.6).

Табл. 5.6. Код для user-defined routines SKIP_REC

Затем сохраняем и переходим к основному меню транзакции LSMW (рис. 5.18).

Рис. 5.18. Сохранение user-defined routines

После создания нужных fixed values и user-defined routines полезным будет вернуться в шаг Maintain Field Mapping and Conversion Rules и нажать кнопку Check Syntax (рис. 5.19).

Рис. 5.19. Проверка синтаксиса программы

В случае наличия ошибок система откроет ABAP-редактор, в котором необходимо снова запустить проверку программы, и тогда система явно укажет, в чем ошибка. В нашем случае ошибок нет, но сообщение могло бы выглядеть, как показано на рис. 5.20.

Рис. 5.20. Пример сообщения об ошибке в ABAP-редакторе

Теперь можно переходить к следующему шагу для указания входного файла и его параметров.

Шаг 7: указание пути к файлу

Прежде чем указывать путь к файлу, необходимо создать файлы по нужному нам формату. Для создания входного файла будем использовать Excel. Первую строку в Excel заполним техническими именами полей входной структуры. А строки, начиная со 2-й, заполним уже конкретными значениями. В нашем случае у нас может быть несколько входных файлов, так как данные по каждому субсчету мы будем хранить в отдельном файле. Для разделения файлов мы будем использовать Wildcard. При этом для заполнения заголовка и позиций документа материала мы будем использовать один и тот же файл. На рис. 5.21 показан файл для загрузки субсчета 10–01, а на рис. 5.22 показан файл для загрузки субсчета 10–08. Как видно, формат файлов одинаков, но данные в них разные и контроль за данными также будет осуществляться по-разному.

Рис. 5.21. Пример заполнения входного шаблона по субсчету 10–01 (сырье и материалы)

С помощью атрибута HEAD_OR_ITEM мы сделали разделение строк на данные заголовка и данные позиции. Таким образом, мы можем использовать один и тот же файл для наполнения данных заголовка и данных позиций и при этом загружать более чем одну позицию в документе материала. А за счет того что часть столбцов мы продублировали в позиционной структуре, мы можем себе позволить вести файл в табличном формате. Дважды щелкнем по Specify Files (рис. 5.22).

Рис. 5.22. Пример заполнения входного шаблона по субсчету 10–08 (строительные материалы) на отдельной вкладке

Начнем с создания Wildcard (масок для файлов). Поставим курсор на ветке Wildcard value и нажмем кнопку Create / Создать (рис. 5.24). Последовательно создадим Wildcard, указанные в таблице 5.7.

Рис. 5.23. Переходим к шагу Specify files ( указание файлов)

Рис. 5.24. Создание Wildcard value (маска для имени файла)

Табл. 5.7. Данные для создаваемых Wildcard value

Теперь перейдем непосредственно к указанию параметров считываемого файла на фронтэнде. Поставим курсор на ветку On the PC (Frontend) и нажмем кнопку Create / Создать (рис. 5.25).

Рис. 5.25. Переходим к указанию параметров входного файла с фронтэнда 

В качестве пути к файлу укажем C:\004\LSMW\ZDOCHEAD_*.txt. Обратим внимание на символ * (звездочка): этот символ будет подменяться на выбранное значение из Wildcard. То есть для загрузки данных для Wildcard 10_01 система будет искать файл на компьютере с адресом C:\004\LSMW\ZDOCHEAD_10_01.txt, а для 10_08 — C:\004\LSMW\ZDOCHEAD_10_08.txt. Нам обязательно нужно отметить опцию Data for Multiple Source Structures (Seq. File), снять галочку с атрибута Field Names at Start of File и отметить Field Order Matches Source Structure Definition. В качестве разделителя будем использовать Tabulator.

Замечу также, что опция Field Names at Start of File и опция Data for Multiple Source Structures (Seq. File) не могут быть указаны одновременно. Система не позволит загрузить файл с такими параметрами (рис. 5.27). Но это не мешает нам оставить заголовки в первой строки файла. Так как заголовок не содержит в поле Identifying Field Content ни HEAD, ни ITEM, то он не будет принят как входные данные для загрузки.

Рис. 5.26. Указываем параметры файла-источника для нескольких структур с указанием Wildcard Value

Рис. 5.27. Проверка на невозможность одновременного указания опций Field Names at Start of File и Data for Multiple Source Structures (Seq. File) при чтении файла

После указания параметров входного файла мы обязательно должны указать использование Wildcard для файлов на сервере, иначе файлы будут затирать друг друга и реальная загрузка данных будет идти только по последнему файлу. Дважды щелкаем по ветке Imported Data и в имени файла указываем символ * (звездочка) (рис. 5.28).

Рис. 5.28. Указываем опцию Wildcard для файла Imported Data на сервере

Аналогично поступаем для файла Converted Data (рис. 5.29).

Рис. 5.29. Указываем опцию Wildcard для файла Converted Data на сервере

В конечном итоге экран будет выглядеть, как представлено на рис. 5.30.

Рис. 5.30. Экран шага Specify Files после указания всех параметров

Затем мы сохраним данные в Excel в блокноте в формате .txt (можно выполнить операцию Save As — Сохранить как; а можно просто копировать данные Ctrl+C -> Ctrl+V). На выходе должны получиться два файла в формате txt с табуляторами в качестве разделителей с адресами C:\004\LSMW\ZDOCHEAD_10_01.txt и C:\004\LSMW\ZDOCHEAD_10_08.txt (рис. 5.31 и рис. 5.32).

Рис. 5.31. Результат пересохранения данных из Excel в текстовый файл с разделителями для Wildcard 10_01 

Рис. 5.32. Результат пересохранения данных из Excel в текстовый файл с разделителями для Wildcard 10_08

Обратим внимание, что в файле ~10_08.txt мы указали дату и количество в двух разных форматах. Нам это пригодится на этапе чтения файла. Мы указали параметры входного файла и создали файлы на жестком диске. Сохраняем данные и переходим к следующему шагу.

Шаг 8: присвоение файла и структуры источника [данных]

Дважды щелкаем по шагу Assign Files. На этом шаге нужно присвоить входящие файлы и структуры источника. В нашем случае у нас один входной файл, но две структуры. Система не будет выполнять автоматическое присвоение файлов. Ставим курсор на ветку ZDOCHEAD и нажимаем кнопку Assignment (рис. 5.33). Повторяем эти же действия для ветки ZDOCITEM. ZDOCITEM. Итоговый экран присвоения будет выглядеть, как показано на рис. 5.34. Сохраняем и возвращаемся к обзору шагов, чтобы перейти к следующему шагу.

Рис. 5.33. Присвоение файла внутренней структуре источника

Рис. 5.34. Один входной файл присвоен нескольким внутренним структурам-источникам

Шаг 9: чтение данных и просмотр считанных данных

С этого этапа можно сказать, что начинаются повторяемые шаги (которые нужно будет выполнять для каждой загрузки данных). Дважды щелкаем по шагу Read Data. Сделаем пояснения к полям, представленным на экране на рис. 5.35.

Рис. 5.35. Экран при запуске шага Read Data

Поле Transaction Number. Мы можем указать номера транзакций (в нашем случае транзакция соответствует номеру документа материала), которые мы будем считывать. Данное поле рекомендуется заполнять при первом считывании файла (чтобы сразу не читать весь файл).

Флажки Value Fields -> 1234.56 и Data Value -> YYYYMMDD могут сразу преобразовать данные по числовым значениям и дате во внутренний формат SAP. Рекомендую всегда устанавливать эти параметры, чтобы не иметь в дальнейшем никаких проблем с полями данного типа. Чтобы показать эффект этих параметров, продемонстрируем результат с преобразованием и без него.

При считывании без преобразования данные из файла останутся ровно в том же формате, какими они были в файле (рис. 5.36). При считывании данных с преобразованием данные из файла будут преобразованы во внутренний формат SAP: число будет без разделителей разрядов и с точкой в качестве десятичного разделителя (рис. 5.37).

Рис. 5.36. Результат считывания числового поля и даты без преобразования: когда флажки Value Fields -> 1234.56 и Data Value -> YYYYMMDD не отмечены 

Рис. 5.37. Результат считывания числового поля и даты с преобразованием: когда флажки Value Fields -> 1234.56 и Data Value -> YYYYMMDD отмечены

Поле ZDOCHEAD-TESTRUN (Testrun Indi) (рис. 5.35) появилось на экране, так как мы на шаге 4 (рис. 5.10) указали явно на необходимость вывода этого поля. С помощью этого поля мы можем заполнить параметр входной структуры E1MBGMCR-TESTRUN.

Селекционные параметры Value for '*' in File Name появились на экране, так как мы указали значения для Wildcard на шаге Specify Files. Если мы не заполним это поле, то система будет пытаться считать все возможные файлы для всех масок (всех Widcard value). С помощью множественного выбора мы можем указать несколько файлов (рис. 5.38).

Рис. 5.38. Указываем несколько файлов для считывания с помощью нескольких widlcard

Просмотр считанных данных выполняем в пункте Display Read Data (рис. 5.39). На этапе считывания система также запросит значения Wildcard для файла, который будет показан. Здесь можно указать только одно значение (рис. 5.40). Мы видим, что система корректно считала и сгруппировала данные (рис. 5.41). Просматриваем данные и переходим к следующему шагу.

Рис. 5.39. Запускаем просмотр считанных данных и указываем нужное значение для Wildcard value

Рис. 5.40. Результат считывания и группировки данных

Рис. 5.41. Экран Convert Data

Шаг 10: конвертация данных и просмотр конвертированных данных

Дважды щелкаем по шагу Convert Data в основном перечне шагов транзакции LSMW. На экране Convert Data система отобразит сходные поля. Сделаем пояснение к полям, которые отсутствовали на шаге Read Data (рис. 5.41).

Опция Create File предполагает предварительное создание файлов перед генерацией IDoc. Альтернативной опцией является Create IDocs Directly, которая предполагает создание IDoc сразу. Поле Number of IDocs per Package координирует передачу данных за один вызов обработки IDoc. Если IDoc сам по себе включает довольно много данных (более 100 заполненных полей), то разумно уменьшать этот параметр; если же IDoc содержит небольшое количество полей (менее 20), то можно увеличивать этот параметр. Насколько уменьшать и увеличивать — зависит от конкретной системы и планируемой загрузки системы в момент непосредственной загрузки данных. На этом шаге также стоит иметь в виду функцию Execute in Background (рис. 5.42). Фоновая массовая обработка данных менее ресурсоемка для системы при прочих равных условиях. Фоновая обработка может быть сделана и в другое время (запланировать загрузку на 2 часа позже текущего времени, например).

Рис. 5.42. Функция фоновой обработки конвертированных данных

Указываем нужный нам Wildcard value и запускаем конвертацию данных (рис. 5.43).

Рис. 5.43. Указываем Wildcard Wild и запускаем конвертацию данных

Просмотр конвертированных данных выполняется в пункте Display Converted Data. На этапе просмотра нам также нужно указать Wildcard value (рис. 5.44). На этом шаге можем убедиться, что система правильно сконвертировала данные, например, добавила ведущие нули к номерам материалов и указала правильные Fixed Value (рис. 5.45).

Рис. 5.44. Запуск просмотра результата конвертации данных

Рис. 5.45. Результат корректной конвертации: установлены ведущие нули в номере материала и указаны правильные значения из Fixed Value

Шаг 11: запуск генерации и обработки IDoc

Дважды щелкаем по шагу Start IDoc Generation в основном перечне шагов. Указываем нужные значения для Wildcard value и запускам генерацию IDoc (рис. 5.46).

Рис. 5.46. Запуск создания IDOC на основе конвертированного файла

Для обработки IDoc запускаем пункт из основного меню транзакции LSMW Start IDoc Processing (транзакция BD20, программа RBDAPP01) (рис. 5.47).

Рис. 5.47. Запуск обработки созданных IDoc

На этом шаге также полезно иметь в виду функцию Execute in Background (рис. 5.48).

Рис. 5.48. Возможность запуска обработки IDoc в фоновом режиме

Дальнейшие шаги — для ознакомления с результатами загрузки.

С помощью пункта основного меню Create IDoc Overview мы можем посмотреть список созданных IDoc и их статус (по сути это транзакция WE02 программа: RSEIDOC2) (рис. 5.49).

Рис. 5.49. Список IDoc со статусами

C помощью пункта основного меню Start IDoc Follow-Up мы можем запустить повторную обработку IDoc, упавших в ошибку. Перезапуск возможен не для любого вида ошибок, а только для некоторых статусов (рис. 5.50).

Рис. 5.50. Экран для перезапуска IDoc

5.3. Заключение

В этой главе мы детально рассмотрели использование BAPI-метода, использование Wildcard и возможность использования одного файла для нескольких структур. Как видно, с помощью метода BAPI можно довольно быстро и просто выполнить загрузку документов материалов с несколькими позициями.

Продолжение следует.

Об авторе

Олег Башкатов — консультант-разработчик по функционалу SAP SD, MM, RCM, SAP EWM. Обладает опытом работы с SAP-продуктами с 2008 года. Принимал участие как в полномасштабных проектах (все стадии от анализа, концепта до конфигурации и поддержки продуктивной эксплуатации), так и в roll-out проектах (консультирование по локальной специфике) как на территории России, так и за рубежом. Имеет сертификаты:

1. P_SD_65 (SAP Certified Application Professional — Order Fulfillment with SAP ERP 6.0 EhP5);

2. C_TAW12_731 (SAP Certified Development Associate — ABAP with SAP Net Weaver 7.31).

Успешно осуществил настройку модулей MM, SD, RCM, PS, а также проводил разработки более чем у 7 заказчиков, среди которых такие предприятия, как ООО «Сименс», ПАО «МОЭСК», ПАО «ФСК ЕЭС», ПАО «Северсталь», ООО «Марс», ПАО «Группа Черкизово», ТОО «SINOOIL». Имеет собственные разработки для SAP ERP. Сайт автора: http://www.olegbash.ru/



В данной колонке публикуются главы из книги Олега Башкатова "Транзакция LSMW инструкция по применению"

  

   

   

    

Ключевые слова : Transaction Codes

Функциональная область : Информационные технологии / IT, Basis, ABAP

Ролевое назначение : SAP Консультант / Consultant, Ключевой пользователь / Expert