MM Goods Movements With the Batch-Input Interface

7/28/2019 MM Goods Movements With the Batch-Input Interface

1/11

Goods Movements

with theBatch-Input Interface

Last saved: 21.02.2001 (JKr)

This document describes issues related to the posting of goods movements using batch-input. It concentrates onthe 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.....................................................................................................................................................................1Batch-Input Interface................................................................................................................................................1

1 Overview................................................................................................................................................................22 Data structure.........................................................................................................................................................2

3 Data source.............................................................................................................................................................34 Creation of the batch-session with RM07MMBL................................................................................................. .4

5 Description of the screen sequence........................................................................................................................66 Working with batch-input sessions........................................................................................................................7

7 Using RM07MMBL for own purposes..................................................................................................................9

8 Manually created batch-sessions (SHDB, Batch-Input Recorder)...................................................................... .109 Miscellaneous issues............................................................................................................................................10

Goods Movements with the Batch-Input Interface Page 1/11


2/11

1 OverviewBatch-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-inputoperation).

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 productionorder) and MB11 (other movements).

The data for this program usually are read from a file placed on the filesystem of the application server and areused to create a batch-session to post the movements.

2 Data structureThe movement data which are to be posted have to be in the layout of the DDIC-structure BMSEG. The file onthe 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 thissingle 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 issueis 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 realityits different, this is just for demonstration):

Field Type Length Description

MAPPE CHAR 12 Session name

TCODE CHAR 20 Transaction code

BLDAT DATS 8 Document date

BUDAT DATS 8 Posting date

WEVER CHAR 1 Print version

BWART CHAR 3 Movement type

MATNR CHAR 18 Material number

ERFMG CHAR 17 Quantity

ERFME UNIT 3 Unit

...

Each line in the file needs to have this structure (technically the line read from file is just MOVE-ed to aninternal structure of type BMSEG.

SESSION1 MB11 2000123120001231 561JKMAT 10,5 LSESSION1 MB11 2000123120001231 561QLAROH 56 STSESSION1 MB11 2000123020001230 501JKMAT 1 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 definedto have length 20.

Behind the posting date there is a space. This is the content for field WEVER. It remains blank.



3/11

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, ifthe 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 mightresult 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 fieldwill 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 sourceThe data to be processed by RM07MMBL need to be placed in a "sequential file" on the application serverwhere RM07MMBL is started. The phrase "sequential file" just means a real file on the filesystem of thecomputer, 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

"\". 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 logicalpath. 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 becauseit violates the filename rules.

As transaction FILE operates on client independent tables, it is not possible to maintain data in the support-package 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 goodsmovements (and 120 for reservations). This transaction allows to create, change and view the file contents.



4/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 operationshave 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.



5/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-checksduring 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 ofthe 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 createdand filled with the data from YWEWA. As a general rule, an entry in the session table is done if the value inYWEWA 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).



6/11

5 Description of the screen sequenceThe screen sequence which RM07MMBL uses is quite different from online processing. It will never work withthe 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 22082000MKPF-BLDAT 22082000RM07M-XNUVR XBDC_OKCODE VOR

With the special OK-Code VOR (in the menu: Edit/Default values) it brings up a popup to set the movementtype, plant, storage locationSAPMM07M 1403

RM07M-BWARTWA 561RM07M-WERKS 0001RM07M-LGORT 0001BDC_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 JKMATMSEG-WERKS 0001MSEG-LGORT 0001MSEG-ERFMG 5MSEG-ERFME STBDC_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 /08Now the popup is there and as there is no new position, it is terminated with F12.SAPMM07M 1403

BDC_OKCODE /12The 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 0410BDC_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 theaccounting 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 movementtransactions which is visible only if SY-BINPT = 'X' and defaults to 'X': It's name is RM07M-XFULL.



7/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 doesnot 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 beenintroduced 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. Automaticlines 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 manytimes. 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 amaterial 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 theserial 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 anew note should be created.

6 Working with batch-input sessions

6.1 Session overview

In transaction SM35, batch-input sessions are shown.



8/11

From here, they can be executed. This can be done in online mode (useful for test purposes), in dark mode withstop 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 linesand 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 darkcheckbox, to some otherwise deactivated menu functions and to the fun with the accounting screen), the flag SY-

BINPT 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 break-

point here.



9/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-sessionimmediately 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 also9.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 waitsuntil the posting is completed.

This is useful in order to avoid all update processes to be occupied by update requests from a single batch-inputsession 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. thetransactions whose update failed are marked as faulty and can be reprocessed.

7 Using RM07MMBL for own purposesIn cases where it is necessary to post a large number of goods movements which cannot or should not be donewith 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 ownprogram using the function modules.

The data to be posted have to be filled into an internal table of structure BMSEG and exported to memory idCPIC_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

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

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 dols_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



10/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 ofa 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 beplayed. 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 storagelocation 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). Thebatch-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 stillbelieves 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 correctdata 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 anABAP 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 ofMBxx only has a single COMMIT WORK.

However there are components of R/3 which sometimes need to generate coding upon the first movement for anew 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 hasbeen 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 anexample 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 itwill 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 COMMITWORK 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.



11/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 ) 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.


Documents

MM Goods Movements With the Batch-Input Interface