Goods Movements with the Batch-Input Interface

Last saved: 21.02.2001 (JKr) This document describes issues related to the posting of goods movements using batch-input. It concentrates on the standard program RM07MMBL to create a batch session out of a sequential file. Program RM07RRES for reservations has emerged by copying and follows the same principles. Additionally general hints related to batch-inputs are given. Goods Movements....................................................................................................................................................1 with the.....................................................................................................................................................................1 Batch-Input Interface................................................................................................................................................1 1 Overview................................................................................................................................................................2 2 Data structure.........................................................................................................................................................2 3 Data source.............................................................................................................................................................3 4 Creation of the batch-session with RM07MMBL..................................................................................................4 5 Description of the screen sequence........................................................................................................................6 6 Working with batch-input sessions........................................................................................................................7 7 Using RM07MMBL for own purposes..................................................................................................................9 8 Manually created batch-sessions (SHDB, Batch-Input Recorder).......................................................................10 9 Miscellaneous issues............................................................................................................................................10

Goods Movements with the Batch-Input Interface

Page 1/11

1 Overview
Batch-Input is a method to operate SAP transactions in an automated way. A batch-input session is a sequence of keystrokes and data to be entered into fields on screens. The posting logic of the underlying program is not affected, unless the program explicitly wishes to react differently (using SY-BINPT as indicator for batch-input operation). SAP provides a standard program to post goods movements using batch-input. This program RM07MMBL operates on the transactions MB01 (goods receipt for purchase order), MB31 (goods receipt for production order) and MB11 (other movements). The data for this program usually are read from a file placed on the filesystem of the application server and are used to create a batch-session to post the movements.

2 Data structure
The movement data which are to be posted have to be in the layout of the DDIC-structure BMSEG. The file on the application server contains multiple rows of data in this flat format. There is no hierarchical structure as in other components (e.g. material master). All data are contained in this single structure, even the header data. The program RM07MMBL decides by change detection of header relevant information when to start a new material document. Field which cause a material document change are given in RM07MMBL, definition of structure WEWA_HEADER. Currently these are: TCODE, BLDAT, BUDAT, XBLNR, FRBNR, BKTXT, WEVER, MTSNR, XABLN (field LDEST is never used) as genuine header fields and BWART, LIFNR as position dependent fields which also create a new material document. In contrary to what is generally expected for the input format, there also is no "no data"-symbol. Even if the basis documentation states that unused fields have to be filled with a "/", this is not the case for our program. Unused fields have to stay blank. Our program checks for the field to be NOT INITIAL before writing it to screen. This makes it impossible for our program to clear prefilled data on the screen. A correction of this issue is not possible due to compatibility with the installed base. To demonstrate the necessary file structure, lets assume the structure BMSEG would look like this (in reality its different, this is just for demonstration): Field MAPPE TCODE BLDAT BUDAT WEVER BWART MATNR ERFMG ERFME ... Type CHAR CHAR DATS DATS CHAR CHAR CHAR CHAR UNIT Length 12 20 8 8 1 3 18 17 3 Description Session name Transaction code Document date Posting date Print version Movement type Material number Quantity Unit

Each line in the file needs to have this structure (technically the line read from file is just MOVE-ed to an internal structure of type BMSEG.
SESSION1 SESSION1 SESSION1 MB11 MB11 MB11 2000123120001231 561JKMAT 2000123120001231 561QLAROH 2000123020001230 501JKMAT 10,5 56 1 L ST L

This file will create a batch-session named "SESSION1". This sessions contains two transactions MB11 (two because the date changed). The first transaction will contain two items. Remarks:

The four character transaction code MB11 is followed by 16 spaces as the field BMSEG-TCODE is defined to have length 20. Behind the posting date there is a space. This is the content for field WEVER. It remains blank. Page 2/11

Goods Movements with the Batch-Input Interface

Date fields are always to be given in internal representation, i.e. YYYYMMDD. During the creation of the session, basis converts these data to a representation according to the user settings for the date format (but omitting the separators). Example: If the user setting is DD.MM.YYYY, the batch-session will send DDMMYYYY to the screen, if the user setting is MM/DD/YYYY, the batch-session will send MMDDYYYY to screen. Note that the session cannot be played if the user playing the session has a different setting. This might result in error 00 064 (Invalid date). The quantity has to be specified in the same format which has to be entered on screen. Here, the comma is the decimal separator. This is a difference to the convention for IDoc-data.

For the structure BMSEG, the same rules as for BAPI-structures should be applied. As the insertion of a field will invalidate all existing files which use fields on the right-hand side of this field, fields should only be appended. The structure BMSEG also contains the customer include CI_COBL. It is a fact that the fields in CI_COBL are not evaluated by RM07MMBL and therefore this include is completely superfluous.

3 Data source
The data to be processed by RM07MMBL need to be placed in a "sequential file" on the application server where RM07MMBL is started. The phrase "sequential file" just means a real file on the filesystem of the computer, and nothing to be found in the R/3 database.

3.1

From the logical filename to the physical filename

The file is addressed in RM07MMBL with a "logical filename", which defaults to MM_INVENTORY_MANAGEMENT_GOODS_MOVEMENT. To see which file is really accessed with this name, the customizing in transaction FILE needs to be evaluated. In the "Definition of logical files, client independent" the logical filename is assigned a description, a physical filename (usually "mmgoods", a file format (ASC), a working area (MM, do not know what this is used for) and finally the "logical path". Behind the "logical path" an assignment to a physical path can be found, which is dependent on the operating system of the application server. This can be determined in "System Status". In the physical pathname, variables may be used, e.g. in U9B the path TMP evaluates for WINDOWS_NT to "<P=DIR_TEMP>\<FILENAME>". Here, FILENAME will be replaced by "mmgoods" and "P=DIR_TEMP" will be replaced by the temporary path filename, which the systems administrator has to set up. For WINDOWS_NT, this probably will be "C:\TEMP\", for UNIX "/tmp/". Attention: There is an exception to the just described rules: Some time ago the file handling has been changed. Before, it was possible to assign a physical filename directly to the logical filename, without using the logical path. If this setting is still present, the system returns this old filename immediately. Check the (obsolete) table FILENAME for the given logical filename. If the field FILEEXTERN is filled, its contents will be returned, even if the operating system has been changed. Result: If the table is filled with e.g. "/tmp/mmgoods" and the application server is a windows platform, this file cannot be accessed, simply because it violates the filename rules. As transaction FILE operates on client independent tables, it is not possible to maintain data in the supportpackage systems (this applies to the P- as to the U-systems). So creating a personal test file is impossible without using SE16, which should be avoided.

3.2

Creating test data

To view the contents of the sequential file which RM07MMBL will process and to manipulate it, the transaction SXDA (from release 4.6 it is SXDB) is very recommendable. The "data transfer object" is 110 for goods movements (and 120 for reservations). This transaction allows to create, change and view the file contents.

Goods Movements with the Batch-Input Interface

Page 3/11

When creating a file, it is automatically prefilled with a single line whose data are derived from some fixed settings. In the edit mode, the transaction allows a manipulation of the file:

After placing the cursor, it is possible to edit, view, delete and copy lines. In the edit mode, the structure of BMSEG is shown:

The data have to be entered in the form how they would be entered on screen. After completion of a line item, press "Transfer data". This will return to the file-edit screen, where the file can be saved.

3.3

Files are server dependent

Please note that the created/modified file is located on the file system of the application server the operations have been executed on. Working on another server, it might be that the data are completely different.

4 Creation of the batch-session with RM07MMBL

4.1 Initial screen
The report RM07MMBL can be started from within SXDA/SXDB or directly.

Goods Movements with the Batch-Input Interface

Page 4/11

The parameters are: Name of logical file: The file which this report will work on. Note that files are application server dependent. See 3.3. Max. number of items: Maximum number of line positions in a material document. If exceeded, RM07MMBL will create a new document. User name in document: The name of the user who will be in the batch-session. The authority-checks during playing of the session will be done using this name. This parameter is routed through to the form MAPPE_OEFFNEN in a totally funny way. Be surprised! Issue log: After having created the session, the report will show a list of the created session from which one may branch directly to SM35. Hold processed sessions: A control flag which is transferred to the session. It causes the session not to be deleted after successful posting. This is useful to evaluate the session log which contains all messages issued during the processing and especially the created material numbers (which are published as S-messages). Test data: If this flag is set, RM07MMBL does not read the logical file, but tries to overwrite it with data it retrieves from table T159A. This table, together with a separate maintenance view, were the predecessors of the capabilities of SXDA/SXDB. The method is obsolete and incomplete and should not be used any more.

4.2

Program flow

At the event START-OF-SELECTION, the logical file is read and copied into the internal table YWEWA, which is used during the rest of the program. In event END-OF-SELECTION, this internal table is processed line by line using form MAPPE_AUFBAUEN. The coding with MHDAT, HSDAT and VFDAT is dangerous nonsense (in my opinion). Finally, the document and session are closed and the protocol is issued. In Form MAPPE_AUFBAUEN, the conditions for a change of session and/or document are checked. Then the session if opened if necessary and the screens are processed. RM07MMBL can handle the transaction codes MB01, MB11 and MB31 which are processed in forms POSITION_MBxx. Here, the single dynpros are created and filled with the data from YWEWA. As a general rule, an entry in the session table is done if the value in YWEWA is not initial.

4.3

Output screen

The protocol shows a list of the created sessions.

Double clicking in a session will start SM35 where the session can be processed (6.1).

Goods Movements with the Batch-Input Interface

Page 5/11

5 Description of the screen sequence

The screen sequence which RM07MMBL uses is quite different from online processing. It will never work with the overview list (where several items can be entered on the same screen) because table-controls and step-loops cannot be handled by batch-input. As every line entered in the overview screens process the detail screen anyway (in dark-mode), this is no performance loss.

5.1

Example

To give an overview over the general screen sequence, we have a look at a simple stock uploading procedure. On the initial screen, only the data relevant for the entire document are filled. Movement type, plant and storage location do not belong to them. SAPMM07M 0400 MKPF-BUDAT 22082000 MKPF-BLDAT 22082000 RM07M-XNUVR X BDC_OKCODE VOR With the special OK-Code VOR (in the menu: Edit/Default values) it brings up a popup to set the movement type, plant, storage location SAPMM07M 1403 RM07M-BWARTWA 561 RM07M-WERKS 0001 RM07M-LGORT 0001 BDC_OKCODE /08 The OK-Code /08 (meaning = key F8) is "New item" brings the system directly to the detail screen of a new position (the list screen is omitted). SAPMM07M 0410 MSEG-MATNR JKMAT MSEG-WERKS 0001 MSEG-LGORT 0001 MSEG-ERFMG 5 MSEG-ERFME ST BDC_OKCODE VOR Every detail screen data entry is ended with the OK-Code VOR, which will bring up the popup for a new set of movement type, plant, But before this popup is sent, the accounting screen will appear. It is filled whatever accounting data are available in YWEWA and then confirmed with F8. SAPLKACB 0002 BDC_OKCODE /08 Now the popup is there and as there is no new position, it is terminated with F12. SAPMM07M 1403 BDC_OKCODE /12 The system now shows returns to the detail screen (same position as before because popup 1403 did not press "New item". It is finished with F12 (Cancel). SAPMM07M 0410 BDC_OKCODE /12 As a result, the system is in the screen where all items are shown ready to post. The last code is F11 (post). SAPMM07M 0420 BDC_OKCODE /11

5.2

Handling of the accounting screen

The accounting screen (by historical reasons also called the "coding block") is the screen area used to enter the accounting information. It is not programmed by us but an external component. It's design and field collection depends on decisions of CO. For some fields, it is necessary to press a button on the accounting screen to see all necessary fields. This is a situation not suitable for batch-input. The answer is a checkbox on the initial screen of the goods movement transactions which is visible only if SY-BINPT = 'X' and defaults to 'X': It's name is RM07M-XFULL.

Goods Movements with the Batch-Input Interface

Page 6/11

If this is set (as is the default case in batch-input), the accounting screen will not be visible as subscreen, but will appear as popup with all available accounting fields, so that RM07MMBL can freely fill its data into the popup (SAPLKACB/0002). To make it even more complicated, BMSEG contains a field NO_CO_BLOC. If this is set, RM07MMBL does not fill data for the accounting screen. It is impossible to give advice when to set it or not (I cannot understand what the thoughts might have been). If errors with the accounting screen appear and there are no accounting data to be filled, maybe setting this flag might be a nice idea. It is also absolutely possible that this flag has been introduced for a single special customer problem which either was no error at all or is resolved otherwise in the meantime. I do not know.

5.3

Automatic lines (subcontracting, retail)

The batch-input session is executed totally blind by the system. It cannot react on unexpected events. Automatic lines are unexpected in this way, as their appearance is unknown to the batch-session (it cannot distinguish between normal PO's and subcontracting PO's), the number of components to be processed is unknown and RM07MMBL does not provide mechanisms to provide data for the components (hierarchical data structure). The most critical part here is the accounting screen, which is sent automatically after each position (also e.g. after the 543) which disturbs the screen sequence. Another case are missing data for the components (batch, production date, ...). Therefore, generally such business processes are not supported by RM07MMBL. In the course of time, two workaround-solutions (modification) have been developed: Note 40176: This note addressed subcontracting POs by trying to find out how many components are proposed from MM-PUR and pressing the "Continue"-button on the accounting-screen popup this many times. It must not be said that this solution is extremely unstable. Much better is the approach from... Note 305635: The indicator NO_COBL_BLOC, introduced with note 67657 (whose meaning in this note could not be understood) is reused in order to skip the batch-input behavior of the accounting-screen completely, i.e. it does not send a popup, but is classically embedded into our screens. As long as no accounting data are to be entered, and as long as the detail processing goes through without errors, this note can make RM07MMBL work for all automatic line problems.

5.4

Serial numbers

A serialized material causes SAPMM07M to call function modules from component LO-MD-SM which sends a popup to enter serial numbers. This is an unexpected screen sequence, too. The communication structure BMSEG contains field SERNR. But instead of simply expecting the popup if this field is filled (and that way laying the responsibility onto the creator if the sequential file to know whether a material is serialized), RM07MMBL checks whether the material is serial number managed (direct access to MARC after first converting the material number from external to internal representation) and then checking the serial number profile in table T377 for entry MMSL with activity 03 (mandatory serialization). I consider this checks as superfluous and even incorrect, because optional serialization is not supported. Maybe a new note should be created.

6 Working with batch-input sessions

6.1 Session overview
In transaction SM35, batch-input sessions are shown.

Goods Movements with the Batch-Input Interface

Page 7/11

From here, they can be executed. This can be done in online mode (useful for test purposes), in dark mode with stop in error case or completely in background.

The regularly flagged indicator "Dynpro standard size" reduces the size of the screen to the fixed size of 22 lines and 84 columns. This standard size is necessary to ensure a predictable number of table-control or step-loop lines for transactions which use these elements.

6.2

Displaying session contents

In SM35, the "Analysis"-button allows to view the single transactions and their screens. To get a better overview, use function "Session Print session contents". One may send this data to spool only without printing immediately to view it or to download it to the local PC (when working in remote systems). The resulting list shows all screens, the filled fields and the OK-codes which are executed, so that this list can be used together with the batch-input simulation (see 6.3) to manually play a session.

6.3

Simulating Batch-Input for SAPMM07M

To make SAPMM07M believe that a batch-input session is being played (giving full access to the usually dark checkbox, to some otherwise deactivated menu functions and to the fun with the accounting screen), the flag SYBINPT must be set at the earliest possible moment during the transaction MBxx. This can happen in module TRANSAKTIONS_INIT(MM07MO00). Report MBDEBUG can activate a breakpoint here. Goods Movements with the Batch-Input Interface Page 8/11

6.4

Terminating sessions

When executing a batch-input session, entering /N in the command code field does not have the desired result. It terminates the current transaction (marking it as faulty so it can be reprocessed) and the batch-session immediately moves forward to the next transaction in the session. In a multi-transaction session is does not work. Instead, use OK-code /BEND. It terminates the entire session. The status management of the batch-input processor ensures that only a COMMIT WORK causes a transaction to be marked successfully posted (see also 9.1).

6.5

Update strategy

Batch-input sessions use the standard update process (unless the application coding explicitly uses SET UPDATE TASK LOCAL), but they do it in synchronous mode, i.e. after the COMMIT WORK the session waits until the posting is completed. This is useful in order to avoid all update processes to be occupied by update requests from a single batch-input session being executed. It also avoids locking problems if identical business objects are accessed in short order. As another consequence errors in the update process (update termination) are logged in the session log, i.e. the transactions whose update failed are marked as faulty and can be reprocessed.

7 Using RM07MMBL for own purposes

In cases where it is necessary to post a large number of goods movements which cannot or should not be done with a program using MB_CREATE_GOODS_MOVEMENT or BAPI_GOODSMVT_CREATE (e.g. when correcting inconsistencies), RM07MMBL can be used to create a batch session to post the documents. The advantage is that batch-input provides a sophisticated mechanism for error handling and ensures that each transaction is posted exactly once, a demand which requires a lot of handicraft work to realize in an own program using the function modules. The data to be posted have to be filled into an internal table of structure BMSEG and exported to memory id CPIC_YWEWA with the name YWEWA. A submitted RM07MMBL reads this memory segment and if something is found, the logical file is not accessed and the report uses the internal YWEWA. Note: Due to a program error (?) in RM07MMBL, the flag XKEEP (Hold processed sessions) is not evaluated when working with memory data. They really created crazy programs, didnt they.

7.1

Example
REPORT zkremp_batch. DATA: ls_bmseg TYPE bmseg, lt_bmseg TYPE STANDARD TABLE OF bmseg. START-OF-SELECTION. ls_bmseg-mappe = 'KREMP1'. ls_bmseg-tcode = 'MB11'. ls_bmseg-budat = sy-datum. "Internal representation will do ls_bmseg-bldat = sy-datum. DO 10 TIMES. ls_bmseg-erfmg = sy-index. "Demonstration! ls_bmseg-bktxt = sy-index. "Forces new document! ls_bmseg-bwart = '561'. ls_bmseg-matnr = 'JKMAT'. ls_bmseg-werks = '0001'. ls_bmseg-lgort = '0001'. APPEND ls_bmseg TO lt_bmseg. ENDDO. * These names are mandatory: * XXXXX XXXXXXXXXX

This program creates a batch-input session which posts 10 material documents.

Goods Movements with the Batch-Input Interface

Page 9/11

EXPORT ywewa = lt_bmseg TO MEMORY ID 'CPIC_YWEWA'. SUBMIT rm07mmbl AND RETURN. WRITE: 'Finished'.

8 Manually created batch-sessions (SHDB, Batch-Input Recorder)

With transaction SHDB, batch-sessions can be created manually. This transaction traces the online execution of a transaction and can create a batch-input session or an ABAP program to create such a session.

8.1

Entries made on the detail screen in error conditions

Due to the complicated screen handling of MM-IM, sessions created with the recorder sometimes cannot be played. This is no program error, but a handling error which emerges from our coding. Example: A goods movement with transaction MB11 is recorded. After entering movement type and plant on the first screen, enter is pressed. On the overview screen (SAPMM07M/0421), material, quantity and storage location are entered. Because the material requires the input of an expiry date, the system jumps to the detail screen (SAPMM07M/0410) and requests this input. The date is entered and the document posted. In the created session, it can be seen that the batch-recorder noted the expiry date as entered on the overview screen, which is definitively wrong. What happened? For all lines on the overview screen, the detail screen is processed in dark mode (SUPPRESS DIALOG). The batch-recorder does not see these dynpros (see note 329953). If an error occurs on one of these screens, basis terminates the dark processing and shows the screen. The batch-recorder only sees the input of the fields, but still believes it is on the overview screen. As a result, if the session is executed, the error "Field MSEG-MHDAT not present in screen SAPMM07M 0421" is issued. The generally recommended way to create batch-input sessions avoids the overview screen to enter and correct data and always uses the detail screens (the button "Copy+Detail" is useful here).

8.2

Creating a program body from SHDB

With SHDB, it is possible to create a recording (which is the pre-step of a batch-input session) and create an ABAP program from that recording. This program can then be modified to use another data-source (the generated code has the data from the recording in hard-wired form). This method is useful to create a mass batch-input for other transactions than MBxx.

9 Miscellaneous issues
9.1 COMMIT WORK causes incomplete sessions
A batch session is finished as soon as the statement COMMIT WORK occurs. The normal program flow of MBxx only has a single COMMIT WORK. However there are components of R/3 which sometimes need to generate coding upon the first movement for a new object (e.g. business area, cost calculation) which they finish after coding generation with a commit. As a result, the session is successfully posted, but no material document has been created. If no message at all has been sent up to this point, the basis message 00 355 is issued (transaction successfully finished). The correct behavior is to terminate processing of such routines in batch mode, but this is not in our hands. As an example please see note 307007 from CO-PA. It is difficult to find these coding parts, because one may see the effect only after it has already happened, and it will not happen once again because now the generation has been done. A way described by BASIS is to use the dynpro-trace to identify the additional COMMIT WORKs. There is no way to set a break-point for COMMIT WORK outside MM-IM coding or to activate a COMMIT-lock in our coding. Before playing the session, activate the trace for the process which will process the session (if the session is submitted to background, usually the first work process in order of process number will be selected) in SM50, menu function Process Trace Active components. Then choose trace level 2 and activate only Scrn.proc.. Press Change. Now the process is marked yellow in SM50. Goods Movements with the Batch-Input Interface Page 10/11

After having played the session, deactivate the trace in the same way by pressing Default Values Change. The trace file can be evaluated also in SM50 and shows all module calls and also the COMMIT WORK events.

9.2

Errors, warnings and I-messages during batch-input

An error-message which is issued on screen (i.e. it is not caught with EXCEPTIONS ERROR_MESSAGE) causes a transaction to be terminated and marked as faulty. A reprocessing is possible. If a batch-input session contains multiple transactions, the next transaction is executed. Warnings and I-messages appear when playing a batch-input session in foreground, but are ignored with respect to the additional operating steps. Keystrokes to close the message boxes are not part of the session.

9.3

Debugging when playing a batch-input session

If the debugger is called (either by /H, by break-point in the source or MBDEBUG), the new screen (the debugger-screen) causes the batch-input processor to issue the message 00 344 (No batch input data for screen <screen> <dynnr>) is issued, whereas the indicated screen is the screen of the debugger. However, as soon as the screen sequence arrives at the expected screen, the processing resumes without errors.

Goods Movements with the Batch-Input Interface

Page 11/11