MIGO

(Materials management Inventory management GOods movements)

A short introduction to problem solving

Version 2.0, 04.09.2001

1 OVERVIEW........................................................................................................................................................2

2 CLASSES AND METHODS: DON’T PANIC!............................................................................................2

3 TRANSACTION DESIGN.............................................................................................................................2

4 DATA STRUCTURES....................................................................................................................................3

5 USEFUL BREAKPOINTS.............................................................................................................................3
5.1 EVALUATION OF OK-CODES.....................................................................................................................3
5.2 APPENDING AND CHANGING LINES............................................................................................................3
5.3 READING A REFERENCE DOCUMENT..........................................................................................................3
5.3.1 Purchase order.................................................................................................................................3
5.3.2 Material document............................................................................................................................4
5.4 CALL TO MB_CREATE_GOODS_MOVEMENT...................................................................................4
5.5 ADDING MESSAGES TO THE LOG................................................................................................................4
6 SCREEN MODIFICATION..........................................................................................................................4
6.1 SETTINGS IN CUSTOMIZING........................................................................................................................4
6.2 RUNTIME....................................................................................................................................................4
7 DEBUGGING AIDS.......................................................................................................................................5

8 WATCHPOINTS / FIELD CONTENT........................................................................................................5

9 MIGO IS A NEW TRANSACTION.............................................................................................................6

9.1 ... BUT HAS PARTLY THE OLD BEHAVIOR...................................................................................................6
9.2 ... and sometimes has new behavior..........................................................................................................6
1 Overview
MIGO is the enjoy transaction of materials management to carry out goods movements. It has been designed in
Release 4.6A to be a substitute for MB01, MB0A, MB03, MBRL, MBNL, MBST and MBSF.
This document gives in short form an introduction into transaction MIGO and useful hints how to proceed in
case of problems. It describes the transaction in the coding state of Release 4.6B. The full sized design document
can be found in SAPNet with the alias MMINT in the section of InventoryManagement (Specification and
Design).
The things said here only partly apply to Release 4.6A because the coding design has been completely altered for
the sake of maintenance costs.

2 Classes and Methods: Don’t panic!

MIGO has been written using ABAP Objects, but there is nothing to be worried about. Obscure things like
inheritance, polymorphism and operator overloading, which may come into mind when hearing the phrase OO,
are used extremely rare (in screen modification).
The most “unusual” fact is that instead of PERFORM we write CALL METHOD. Methods have an interface as
function modules do, so the importing and exporting parameters can be specified with their name instead of their
position in an endless list of parameters as in FORMs. In fact, a method is equivalent to a function module and a
class is equivalent to a function group.
There are nearly no global variables in MIGO. All information is kept only where it belongs to and transferred
via clearly defined interfaces. Most data in MIGO are local, so there will be only marginal problems with
missing CLEARs or REFRESHs.

3 Transaction design
The most important class in MIGO is the kernel, which implements the business logic behind the screen
representation of the data. The display of these data and the user interaction are performed by viewers, which are
e.g. the table control, the detail screen and the first line.
These viewers interact with the kernel using its public methods defined in LMIGOKE1. For example the method
LINE_GET delivers a position of the material document to be displayed on screen. Table control and detail
screen use this method to get the data in their PBO modules. In PAI, they update the model using
LINE_MODIFY.
All components are linked together by a common framework which allows communication between the classes
using messages and the reception of user interaction in form of OK-Codes (buttons, listboxes, double click).
The posting is executed by the function module MB_CREATE_GOODS_MOVEMENTS. All errors this function
currently has will also appear in documents posted by MIGO. These errors are the result of general problems in
the old module pool SAPMM07M and are not MIGO specific.
Table control Detail screen Other Viewers
Message: e.g. item_detail_open no. 3

Message: e.g. item_detail_open no. 3

PAI PBO
PBO header_modify PBO
header_get line_modify PAI PAI
line_get …
…
…

Kernel
Tasks:
read order, purchase order;
prepare data for function module
MB_CREATE_GOODS_MOVEMENT;
insert, change data;
hold data
etc.

Framework

Tasks:
handle ok_codes: ok_codes are passed to other screen elements. They themselves start specific actions (e.g. table
control)
handle messages: Messages are used to send information about changes to other components.
Screen elements (components) that have registered on specific messages will start specific actions.
4 Data structures
The material document is stored in private kernel data called PS_GOHEAD (header data) and PT_GOITEM (table
of the item data). Some dependent data are kept in PT_GOFREIGHT_KERNEL (freight vendors for a PO-
position), PT_GOSERIAL_KERNEL (serial numbers) and PT_COCANCEL (additional data for cancellation of
material documents).
"Private" means that you cannot access these data in the debugger unless you are within the kernel.

5 Useful breakpoints
5.1 Evaluation of OK-Codes
To see the reaction for an OK-code, the best break-point is method OKCODE_DISPATCH in LMIGOFR2. This
method is called at the end of the main carrier dynpro 0001. At this time, all PAI modules of the viewers have
been executed so that the data in the model are synchronized with the data on screen.
In the table PT_REGISTERED_OKCODES, you can see which components have registered to OK-Codes, and
with the coding line
CALL METHOD ls_registered_okcode-component->okcode_handler
EXPORTING
i_okcode = l_okcode.

the framework calls the handler methods of the components which have registered. In these handlers, the action
takes place.

5.2 Appending and changing lines

All changes to the item data maintained in the kernel use the method LINE_MODIFY located in LMIGOKL1. It
is called from the reading routine for reference documents as well as from the dynpro elements in PAI. It checks
whether the incoming line data have been modified with respect to the data currently in PT_GOITEM (or are
entirely new).
If there is a change, the method LINE_CHECK is called. The name is a little bit misleading. In fact, nothing is
"checked" at all. LINE_CHECK derives all kind of dependent data, e.g. it reads the material master for the
MATNR, plant data for WERKS, and so on.
Some things happen in a routine LINE_CHECK_WITH_GLOBAL_COUNTER. These are actions which operate
on data linked to external applications. To have a pointer from the line in MIGO to the outside, we use a field
called GLOBAL_COUNTER. This is a unique identification of a line in PT_GOITEM. Every time a line is
appended, it is assigned a new number. This number is never changed or renumbered (we will avoid such dramas
as with YMBUZ, ZEILZ, ZEILO and URZEI in SAPMM07M). Data from external applications (e.g. serial
numbers, import, QM-certificate) are entered with this number as a key so these applications can find and assign
their data later on during the posting process.

5.3 Reading a reference document

In LMIGOKD4 you will find the method REF_DOCUMENT_READ. It is called if a reference document
(purchase order, confirmation, transport, material document, ...) is to be read.
By placing a break-point here, you can debug the entire process, branching into the specific reading routines
partly described below.

5.3.1 Purchase order

Purchase orders are read either when creating a goods movement with reference to them or with reference to a
material document with KZBEW = B.
In the first case, MIGO starts with method PURCHASE_ORDER_GET in LMIGOKP1, which first reads the data
from purchasing in PURCHASE_ORDER_READ_DATA using the function modules
ME_READ_HEADER_GOODS_RECEIPT and ME_READ_ITEM_GOODS_RECEIPT. If MIGO shows wrong
data, it’s useful to check here whether we get the right data from MM-PUR. These data are then appended to the
kernel (and hence to the data visible on screen) in PURCHASE_ORDER_FILL_DATA using method
LINE_MODIFY.
Reading purchase orders to enrich material documents is triggered by PURCHASE_ORDER_FILL_MATDOC
from within the reading routine for material documents.

5.3.2 Material document

Material documents are read for purposes of cancellation, display, return or subsequent delivery. This takes place
in MATERIALDOCUMENT_GET in LMIGOKM1. It gets the data from function modules, moves them into the
GOITEM-structure and appends them with LINE_MODIFY.

5.4 Call to MB_CREATE_GOODS_MOVEMENT

MIGO does not execute the material movements posting by itself, but uses the well known function module
MB_CREATE_GOODS_MOVEMENT for this purpose. The interface is filled in the method
GOODS_MOVEMENT_FILL in LMIGOKG1, the call to the function is executed in DOCUMENT_OPERATION in
LMIGOKD1.
If you encounter a problem which is not visible in MIGO but occurs when posting the document (e.g. not filled
fields in the material document, update of the wrong ASN, unusual error messages), check whether
MB_CREATE_GOODS_MOVEMENT is called with a properly filled interface. If this is the case, the issue is not
MIGO related.

5.5 Adding messages to the log

During the posting process, warnings and errors are appended to the Application Log, a basis tool to display
these messages later on in list form.
Every time a warning is to be issued, the function module MICK_MESSAGE_ADD has to be called. Errors stop
the execution of MB_CREATE_GOODS_MOVEMENT and arrive in the output structure EMSEG, from where they
are collected and appended to the log by the method GOODS_MOVEMENT_ERROR_HANDLING in LMIGOKG2.
When pressing "Check", all warnings and errors are shown. With "Post", the document will post if there are no
errors. Warnings are irrelevant in this case, unless the posting stops with an error. In this case the log will show
everything collected up to this point, including the warnings.

6 Screen modification
6.1 Settings in customizing
Some (not all) screen fields and buttons can be modified by the customer using the basis tool SFAC. In MIGO
(4.6B), there are two groups: The header fields and the fields in the detail screen (group 0001, access via
transaction OMJX) and the fields in the table control and the buttons underneath (group 0002, access via
transaction OMJY). Here the customer can disable fields or buttons. Please note that settings for the detail fields,
especially the attribute required, are evaluated only if the detail screen is opened.
The fields GRUND (reason for movement) and KONTO (account) are controlled as before via the movement
type customizing (table T156, fields KZGRU and KZKON).

6.2 Runtime
Each MIGO class which has dynpros on screen is derived from the base class LCL_MIGO_SCREENOBJECT. In
this class, the coding which runs on all screen is laid down. It checks whether the cursor is currently on this
screen and keeps its position for later use. Then it evaluates the customizing settings.
Fields in the header are additionally derived from LCL_MIGO_HEADEROBJECT. In this class, first the things
said above are done (with CALL METHOD SUPER->PBO), then the fieldmodification method for header fields
is called.
The same applies the detail fields with LCL_MIGO_DETAILOBJECT.
The field modification routines, located in LMIGOSM3 to LMIGOSM9, are divided in modifications depending
on GROUP2 (field specific rules, e.g. CHARG disabled if material not batch managed) and GROUP3 (basic
rules, e.g. field disabled in display mode when empty).

7 Debugging aids
During runtime, you can activate an active debugging aid. To do so, place the cursor into the free line below the
listboxes in the middle of the left listbox and perform a right mouse click. Here you can activate the secret
Toolbar.
This toolbar provides a button to jump directly to a breakpoint in the kernel, giving you direct access to all kernel
variables (even the private ones) without having to start the debugger with /h.
You can also activate the Trace, which opens an amodal window. Here you can specify which events to trace. If
you activate trace of OK-Codes, messages and receivers and then read a purchase order by entering the number
and pressing enter, you will see this result (comments added):
135509: OKCODE : OK_GO : |
The GUI has send the OK-Code OK_GO.
135509: : OK ----> OK_GO : MIGO_STATUS |
This OK-Code is forwarded to MIGO_STATUS.
135509: OKCODE : MIGO_OK_GO : |
135509: : OK ----> MIGO_OK_GO : MIGO_FIRSTLINE |
The OK-Code is remapped from the status to MIGO_OK_GO and send to the first line.
135509: MIGO_KERNEL : KERNEL_STATUS_CHANGED : |
135509: : MSG ---> KERNEL_STATUS_CHANGED: MIGO_TREE |
135509: : MSG ---> KERNEL_STATUS_CHANGED: MIGO_FIRSTLINE |
135509: : MSG ---> KERNEL_STATUS_CHANGED: MIGO_STATUS |
The first line has called the kernel method to read the purchase order. After doing that, the kernel sends out a message that its status has
changed. This message is evaluated by the tree (which knows that e.g. parked documents now cannot be selected any more) and the first line
which grays out the listboxes for action and reference document. The STATUS opens the buttons to “Check” and “Post”.
135509: MIGO_KERNEL : NEW_DOCUMENT : R01 |
135509: : MSG ---> NEW_DOCUMENT : MIGO_TREE |
135509: : MSG ---> NEW_DOCUMENT : MIGO_PREDOCUMENT |
135509: : MSG ---> NEW_DOCUMENT : MIGO_FIRSTLINE |
135509: : MSG ---> NEW_DOCUMENT : MIGO_TITLEBAR |
135509: : MSG ---> NEW_DOCUMENT : MIGO_STATUS |
The kernel also sends out a message indicating that a new document of type R01 (purchase order) has arrived. This is needed e.g. by the tree
to include it into the list, the titlebar to show the number.
135509: MIGO_KERNEL : KERNEL_DOC_LOGLEVEL : |
135509: : MSG ---> KERNEL_DOC_LOGLEVEL : MIGO_FIRSTLINE |
Finally, the kernel gives the log-icon in the first line an update with the new state.

If you do not need the trace any longer, deactivate all things that can be traced in the trace window (this is
important in customer systems as otherwise the trace will be written, even if not displayed), deactivate the trace
in the toolbar and close the toolbar using the EXIT-button. If you forget this, all users with the same username
will also be surprised by the trace.

8 Watchpoints / Field content

In transaction MIGO it’s hard to analyze the data in fields / internal tables / structures, because most of them are
not defined global. Most of them are defined in the ‘definition source code’ of a class. All classes work like
‘function groups’,so that the data is not global. Therefore a simple watchpoint cannot work!
To set a watchpoint or to see the content of a field / structure / table, you have to enter this in the debugger:
[class] -> [table / structure / field]
[class] => [static class] -> [table / structure / field]

With this trick you are able to analyze all data from wherever you are in MIGO. Here are some examples for
useful watchpoints:
 Table PT_GOITEM:
lcl_migo_globals=>kernel->pt_goitem
 A certain field of table PT_GOITEM can be seen with:
lcl_migo_globals=>kernel->pt_goitem[1]-charg (field CHARG in first line of PT_GOITEM)
  Table PT_FIELDSELECTION:
lcl_migo_screenmodification=>t_fieldselection
 To analyze, if a field is visible / input / invisible:
lcl_migo_screenmodification=>t_fieldselection[3]-table[27]-work
(Third line in table t_fieldselection, 27th field [ field CHARG]. WORK is the actual status of the
fieldselection for this field [ see documentation ‘MIGO fieldselection 46C’])
 Structure S_STATUS:
lcl_migo_globals=>kernel->s_status
 Structure S_ACTION:
lcl_migo_globals=>kernel->s_action
 Structure S_CONTROL:
lcl_migo_globals=>kernel->s_control

9 MIGO is a new transaction

9.1 ... but has partly the old behavior
Some "errors" reports for transaction MIGO are no errors because the business process is not supported at all.
Therefore, check with the old transactions if the effect is the same. If yes, it's no MIGO error.

9.2 ... and sometimes has new behavior

Some patterns customers got used to in the old transactions are not longer applicable due to the new design.
Most prominently there are these points:
 There are no more popup coming up for e.g. batch classification in foreground or shipping instruction
compliance. There are no unrequested popups in MIGO at all.
 Some things are not yet supported by MIGO. Those known are stated in the release information, e.g. the
inoperability with generic articles or full products (Retail). Also goods movements with subcontracting
components have the limitation that the components are not accessible in MIGO. If a component is batch
managed, the batch determination for it needs to run completely in the background, otherwise the posting
will fail.