You are on page 1of 29

Configuring Message Control and understanding how Message Control works

By Krunal Raichura, Accenture Services Pvt. Ltd


Most SD and MM process use Message Control. The concept of Message control is to generate and manage outputs from an application and control their timing and medium of exchange. Below are the details for configuring the message control and understanding how message control works.

Configuring Message control: Message Control Components: Communication Structure: The communication structure passes application information to the Message control. The communication structure for output determination uses the naming convention as KOMxByy, where x can be K (header structure) or P (Item structure), and yy is two character application ID. The two character application ID can be found from the NACE transaction depending on the application.

The Procedure

A Procedure defines a set of possible outputs for an application. A procedure is assigned a six character name. Several procedures can be defined for an application but only one can be configured as active. A list of procedure can be seen in NACE transaction for the required application.

A procedure has three main attributes: - A List of output types set of outputs that are possible for an application - A Requirement field - A manual flag

Set of Outputs those are possible for applications are listed in the output types.

Manual Flag is set if the output has to be selected by the user manually instead of selecting automatically.

For Sales, Procedures can be assigned to Sales document type using V/43 transaction.

Preconditions are captured in Requirements. These conditions are written in VOFM transaction.

We can write the conditions for the Requirement selected from the above list by creating routine which will start from 900.

ABAP code can be written in the routine for checking the condition.

Output Type: An Output type defines the characteristics and attributes of the output itself. Output type can also be selected from the NACE transaction.

Access sequence is the set of business rules for proposing an output type. If the flag Access to condition is set then the medium and timing are determined from the condition records using access sequence. If the flag is not set then the medium and timing data is taken from the customer master. CannotBeChanged determines whether the output can be edited. Multiple issuing determines whether multiple outputs are permitted. Access Sequence: Access sequence defines a sequence in which the business rules are checked for proposing an output type. A business rule is checked by comparing the values passed in the application data with the values defined in the condition records of the condition table. If a match occurs the business rule is considered satisfied. After a business rule is satisfied the output values from the condition records are used for the output type.

The exclusive or inclusive strategy specifies whether the system should exit after the first match of the business rule against the condition record or should continue to process other business rule in the access sequence. The reason for an inclusive strategy is to have an output type proposed multiple times. However, one of the attributes (partner function, partner number or language) must be different. The system does not allow two output types to have identical values. Condition Tables:

The condition table specifies the key field for a business rule. You use this key to access the condition records for output values such as output medium, partner function, partner number, output language and output time for the message. If the standard condition tables supplied in the system do not meet your requirements, you can create new condition tables. Condition Records: Condition records are inserted in the condition tables. Condition records contain the actual business data against which the business rules are checked to propose an output. They are considered master data maintained by customer. You can create condition records for the each application in NACE transaction by clicking the condition record button for the required application. You will have to select the business rule for which condition record is to be maintained.

Specify the values for the key fields and maintain the output medium, output timing, partner number and partner function for each record and save the entries. Understanding How Message Control works: Message Control is a three step process:

1. Output proposal 2. Output editing 3. Output processing

Output Proposal

When an application is created or changed, after saving the application data the communication structure is filled and is passed to the Message control along with the application id and procedure. The various outputs defined in the procedure are processed one at a time. The output marked as manual will be processed manually by the user. The requirement, if specified for an output type is executed to check if the output meets the requirement. If the requirements are met then further checking continues. If the conditions are not met then the next output type will be processed from the list. The short listed output types are checked for the access condition flag. If the flag is not set then the output medium and timing are determined from the customer master data. If the access condition flag is set then the processing continues for determining the output medium and timing. For these output types the access sequence associated is access for various business rules and determines which of the business rule is satisfied. The values from the communication structure are checked with the values maintained in the condition tables. Output Editing: After the output proposal process is completed, the list of proposed outputs displays on the output control screen of an application as shown below.

To reach he output control screen we can got for Extras ->Output->Edit for sales order or by Goto>Messages for Purchase order. The initial status of these outputs will be 0 (Not Processed) which is displayed as yellow light. The processed outputs will be displayed as green light. For EDI, the partner number in the proposed output is validated against the partner profile entry. The flow chart below explains the Output proposal procedure.

Output Processing: After the final selection of the output is done and the application document is saved, entries are created in the NAST table with application ID, Application document number, output type, output medium, output timing and Status code. If the output is not processed the Status code will have values as 0 (Not processed). The entries in the NAST table are processed by RSNAST00 program. If the entries whose timing is set to immediately, the program will immediately process those entries. For other entries you will have to schedule the program RSNAST00. The RSNAST00 program check the TNAPR table for each entries from NAST table and processes the program associated with the output medium in the TNAPR table. For EDI a Standard routine EDI_PROCESSING exist in RSNASTED program. The EDI_PROCESSING routine reads the Message control record in the partner profile and determines the process code. The process code will be having a Function module which will be having the standard interface for its input and output parameters. The function module will read the application document data and will format the data into the idoc format. The idoc data and the control record from the function modules received through the output parameters will be used by the EDI_PROCESSING program to convert it into physical Idoc. The complete Outbound process with Message control is as shown below:

The setting of the Output mode field in the partner profile is read to determine the timing for dispatching the idoc.

If the mode is set to Transfer Idoc immed. then the idoc is immediately passed to the operating system and if the mode is set to Collect Idoc then the Idoc is not immediately passed to the operating system until the RSEOUT00 program is executed explicitly. If the flag for Start subsystem is set then the subsystem program name is read from port definition and the subsystem program is started.

Purchase Order IDOC NEU Output Type Configuration


For this you have to carry following steps: 1. Create the PORT in WE21 ( Transactional port ). 2. In WE20 create the partner profile for vendor for which you are creating the PO. In this profile in outbound parameter accessing the message type ORDERS. In basic type assign /NFM/ORDERS05. In port, assign the port you have created. In Message control tab assign application EF , MESSAGE TYPE NEU AND PROCESS CODE ORDE. 3. In nace create the condition record for neu with medium 6 and date/time as 3. If it configured for EDI and Distribution Model , now check condition record in T.code:MN06{ if you are getting for one PO, you should get for other PO also) Also check the following config. details for Output of Purchase Order 1. Condition Table SPRO --> Material Management--> Purchasing -> Message -> Output Control->Condition Tables->Define Condition Table for Purchase Order Select: Purchasing Doc. Type, Purch. Organization, Vendor 2. Access Sequences SPRO -> Material Management-> Purchasing -> Message -> Output Control->Access Sequences->Define Condition Table for Purchase Order 3. Message Type SPRO -> Material Management-> Purchasing -> Message -> Output Control->Message Types>Define Message Type for Purchase Order{NEU} 4. Message Determination Schemas 4.1. Message Determination Schemas SPRO -> Material Management-> Purchasing -> Message -> Output Control->Message

Schema->Define Message Schema for Purchase Order-> Maintain Message Determination Schema 4.2. Assign Schema to Purchase Order SPRO -> Material Management-> Purchasing -> Message -> Output Control->Message Schema->Define Message Schema for Purchase Order-> Assign Schema to Purchase Order 5. Partner Roles per Message Type SPRO -> Material Management-> Purchasing -> Message -> Output Control-> Partner Roles per Message Type ->Define Partner Role for Purchase Order 6. Condition Record Navigation Path: SAP Menu-> Logistics -> Material Management -> Purchasing-> Master data>Messages-> Purchase Order-> MN04-> Create ,,,use medium '6' Now you create PO (ME21N) and save it and then release. Also check in NACE t.code for standard SAP environment (program 'SAPFM06P', FORM routine 'ENTRY_NEU' and form 'MEDRUCK') as the processing routines and for the output type for default values, a communication strategy needs to be maintained in the Customizing that supports . You can find the definition of the communication strategy in the Customizing via the following path: (SPRO -> IMG -> SAP Web Application Server -> Basic Services -> Message Control -> Define Communication Strategy).

Output Determination in Inventory Management (IM) This is a really good link. http://wiki.sdn.sap.com/wiki/display/ERPSCM/Output+Determination+in+Inventory+Management+(IM) #OutputDeterminationinInventoryManagement%28IM%29-1.Aboutthisdocument

Added by Haiko Emmerling , last edited by Haiko Emmerling on Mar 25, 2009 Labels: (None)

Content
Content 1. About this document 2. General information 3. Output records for a material document (table NAST) 4. Print version for transaction (T158-WEVER) 5. Field 'Print' (RM07M-XNAPR) 6. Print indicator for movement type (T156-KZDRU) 7. Output type (WE01, MLFH...) 8. Message schema (ME0001) 9. Condition table 10. Condition records 11. Access sequence 12. Layout sets (SAPScript) 13. Collective slips 14. Requirements 15. Number of GR/GI slips (MSEG-WEANZ) 16. Labels 17. Partner functions 18. Missing part mails 19. Mail text 20. GR/GI slips for stock transfers 21. Multiple accounting sheet 22. Language 23. Printer determination 24. Trouble-Shooting guide for non-developers 25. Trouble-Shooting guide with debugging 26. Terminology 27. SAP Notes

1. About this document


This document describes the output determination in Inventory Management.

Chapter 3 deals with the program logic and is intended to developers. Chapters 4 to 23 describe the single elements of output determination. Some are purely MM-IM, others are general output determination

concepts. The chapters may be used as reference when dealing with a special part of the output determination. They contain general explanations as well as technical descriptions.

Chapters 24/25 concentrate on troubleshooting. The first part gives a list of important breakpoints and checks. The second part is organized in the major symptoms that arise when dealing with issues about output determination in MM-IM area. Chapter 26 contains a list of all output determination terms in German and English.

2. General information
The output determination (also called message control) generates output records (messages) for a material document. The messages can be GR/GI slips (e.g. output type WE01), mails (output type MLFH for missing part mails) or even workflow events (not in standard but can be customized by customer). The output determination program is a central functionality outside MM-IM. It is also used by MM-PUR, SD etc. CSS component for the central program (if bug is not due to calling application like MM-IM): CA-GTF-BS-MC Principle: The application using the output determination provides the output determination program with application data (like plant, storage location) through communication structures (MM-IM: communication structures KOMKBME for header data and KOMPBME for item data). The output determination program uses these application data to determine - with the help of extremely flexible and complex tables - whether an output type is relevant or not. If an output type can be found for the given criteria (application data), an output record will be generated. For more information about Customizing of Output determination see IMG.

3. Output records for a material document (table NAST)


The output records are stored in table NAST. Table Key: Field name Field description Field value used in MM-IM

KAPPL

Application

'ME' (Constant for MM-IM)

OBJKY

Object key

Is composed of: - MBLNR Material document number - MJAHR Material document year - ZEILE Material document item

KSCHL

Output type

Examples: WE01, WE02, WE03, WA01, MLGR, MLFH

Automatic output records Usually output records are generated in the background during a goods movement, if customizing is set correctly. The user does not bother to see which output types will be found. Technical process (only for ABAP developers): In SAPMM07M the following routines are processed: 1. In Form-Routine DRUCK_PRUEFEN (MM07MFD0) field MKPF-WEVER is set depending on the print field (RM07M-XNAPR) and the default print version (T158-WEVER) or the print version chosen on the initial screen.

2. 3.

The print indicator of the movement type is read from table T156 (T156-KZDRU) In BUCHEN_NUMMERNVERGABE a few routines are processed: KOPFDIALOGSTRUKTUR_FUELLEN: Header data from MKPF (like transaction type VGART, Version WEVER) are given to the communication structure KOMKBME. POSIDIALOGSTRUKTUR_FUELLEN: Item data from MSEG (e.g. print indicator of movement type T156-KZDRU, plant, storage location) are given to communication structure KOMPBME. Both communication structures KOMKBME and KOMPBME will be transmitted to the output determination and are used for reading the condition tables.

4.

MESSAGING: here the actual output determination is processed. The output types that have been found relevant are stored in internal table XNAST. In BUCHEN_AUSFUEHREN function module MB_MESSAGE_UPDATE is called in dialog. First it replaces the mail variables in dialog with function module RV_MESSAGES_MAIL_REPLACE. This is necessary for goods movements posted with MB_CREATE_GOODS_MOVEMENT because MB_POST_DOCUMENT resets all internal tables (MB_MOVEMENTS_REFRESH is called) and we need the internal tables to fill the mail variables (notes 205951 + 213264). Then it sets a PERFORM ON COMMIT, which itself sets a CALL FUNCTION IN UPDATE TASK. This is necessary to ensure that data such as batch classification data or QM inspection lot are available for printing.

5.

In the update task the output records from internal table XNAST are written in DB table NAST. Table NAST is linked to table MSEG through the object key. Manual output records If customizing is not set correctly, it might be necessary to enter the output type manually during creation (MB01) or change (MB02) of material document. Menue: Detail > More functions > Messages/Output (also available as pushbutton from 4.0 on) Technical process when working with the output maintenance full screen: If the users calls the full screen of output maintenance before posting, the output determination will not be processed in BUCHEN_NUMMERNVERGABE. It will already be processed before sending the full screen. That way, it is possible to display the output types that have been found automatically. NACHRICHTEN_PFLEGE (MM07MFM0)

NACHRICHT_ERZEUGEN KOPFDIALOGSTRUKTUR_FUELLEN (MKPF -> KOMKBME) POSIDIALOGSTRUKTUR_FUELLEN (MSEG -> KOMPBME) MESSAGING (output determination) RV_MESSAGES_MAINTENANCE: sends the output maintenance full screen (not MM-IM) In MB01 all output records will be renumbered in BUCHEN_NUMMERNVERGABE and given to the update task in BUCHEN_AUSFUEHREN through function module MB_MESSAGE_UPDATE. In MB02 function module MB_MESSAGE_UPDATE is called directly after the output maintenance. You can recognize manual output records in table NAST with field NAST-MANUE (check with SE16) MIGO In Release 4.6B and 4.6C we do not have the output maintenance screen. Therefore it is not possible to enter manual output types. In material document display it is possible to start the automatic output determination with a checkbox 'Print' in the header general data. It is also possible to get to the output full screen in display mode. Why is it not possible to maintain output types manually in MIGO?

We assume that a user only has to maintain manual output types because the customizing is not set correctly. There is no real justification for having to maintain manual output types. Deleting output records Output records are linked to the material document through the object key and are therefore deleted during the archiving of the material documents. Output determination processing: overview

4. Print version for transaction (T158-WEVER)


Radio buttons on initial screen of MB01 There are 3 print versions ('1', '2', '3'). The description of the print versions (individual slip, collective slip) is only correct if the customizing is set as SAP recommends. If the customer creates a condition record for an individual slip with the version 3 (collective slip), he will get an individual slip when the users chooses radio button 'collective slip'. Default-Version (T158-WEVER): determines which print version is set on initial screen of transaction. If field 'Print' is not set, the version will be cleared. That way the system will not find any condition record and will not print any slip. MB_CREATE_GOODS_MOVEMENT Because MB_CREATE works without initial screen, we always use default version for transaction from T158. If printing with MB_CREATE does not work, check that the IMKPF transaction has a print version in T158. In case of goods receipt for purchase orders with multiple account assignments, the default version of T158 in only used if '1' or '2'. In case of collective slips, the version is changed to '1' after application of note 442706 in order to be consistent with the dialogue (transaction MB01). MIGO In transaction MIGO the print version is available since note 315434.

5. Field 'Print' (RM07M-XNAPR)


Check box on initial screen and header data screen of MB01. Is set from user parameter NDR = X. X has to be written in capital letters, otherwise basis error 00002 'please enter valid value' on initial screen. With this field it is possible to deactivate the printing of GR/GI slips (but not to deactivate mails) Technically the field is used in Form routine DRUCK_PRUEFEN (MM07MFD0) to reset the print version (MKPF-WEVER). That way all output types working with the print version are deactivated. Caution: deactivation of output determination not possible ! With the field 'Print' it is not possible to deactivate the output determination completely. The output determination is always processed, even if field 'Print' is not set, because it still might be necessary to generate some mails. The output determination can only be deactivated through coding modification. Caution: field 'Print' only works for condition tables with version ! If the customer uses own condition tables without the version, the field 'Print' will have no effect. The system will find a condition record and will print a slip. Explained in note 205450. Setting of field 'Print' and user name in MB_CREATE_GOODS_MOVEMENT Because MB_CREATE_GOODS_MOVEMENT works without initial screen, field 'Print' is set exclusively from the parameter ID NDR of a user record. It is possible to give MB_CREATE_GOODS_MOVEMENT a user name for print in field IMKPF-PR_USNAM (if initial, the system works with IMKPF-USNAM. If IMKPF-USNAM is initial, the system works with SY-UNAME). The value of parameter NDR is read directly from the user data (table USR05) and not through GET PARAMETER NDR, because the user might work parallely with MB11 and there change the parameter NDR from field RM07M-XNAPR. If printing with MB_CREATE_GOODS_MOVEMENT does not work, check the user has parameter NDR = X.

Selecting or deselecting NDR does not react like a selection ON/OFF in a transaction if you use a BAPI. The parameter and the BAPI are in two different memories. The BAPI cannot then recognize that the parameter has been deselected. MIGO The field still exists as header data (field GOHEAD-XNAPR on header tabstrip 'General').

6. Print indicator for movement type (T156-KZDRU)


Because most movement types do not need a specific GR/GI slip, we do not use the movement type directly in the condition tables. Instead we use the print indicator from table T156.

Most movement types have print indicator '1' (normal GR/GI slip). Mvt 122 has print indicator '2' to distinguish a return delivery slip from a GR slip. Mvt 541 has print indicator '3' because it needs a special condition table with debit/credit indicator (SHKZG) so that only one line is printed and not the automatic line. Mvt 501 has print indicator '6' (4.0) because it is possible to create 501M lines in MB01. MB01 prints normally a GR slip with PO data (mvt 101 uses output type WE01), but mvt 501 needs a GR slip without PO data (output type WA01). As both mvt types use the same condition table, it was necessary to distinguish them with the print indicator.

7. Output type (WE01, MLFH...)


The output type determines what kind of output (slip, mail, workflow event) is generated. Output types for GR/GI slips are directly linked to a SAPScript layout set and to a read routine in table TNAPR. Individual slips and collective slips have different output types because they use different layout sets and have different read routines. Furthermore the output type has a printer parameter (7, 9, U, X) that is used for the printer determination. For more information see IMG. Common errors:

Customer has assigned the wrong program to an output type in table TNAPR. For example he wants to have PO data on the slip but uses the routine for other goods receipt Customer has entered an own read program in TNAPR that does not work. Always check table TNAPR when analysing an output type issue.

8. Message schema (ME0001)


A schema gathers all output types that have to be checked by the output determination. In Inventory Management we use only one schema 'ME0001'. The schema is a program constant and cannot be changed by the customer. The customer can add his own output types to our standard schema. The output determination program loops over all output types that are defined in the schema and tries to find a condition record for that output type in the corresponding condition table. In the schema it is possible to define a requirement for an output type. For example, collective slips need requirement 173 so that they will be printed for the first line only. For that purpose the Form routine KOBED_173 (in SAPLV61B) is processed.

9. Condition table
A condition table contains the criteria that are relevant for an output type. Our normal condition table is B072 for normal GR/GI slips (can be displayed with SE16). Table key:

KAPPL Application (always 'ME')

VGART Transaction type (WE, WA, WR) from T158. Never use WO because we do not print slips for MB04. The transaction type cannot be changed by the customer. WEVER Print version from T158 (1 and 2 for individual slip, 3 for collective slip) KZDRU Print indicator for movement type (1, 2, 3, 6) Mails and mvt 541 have their own condition tables. Customer may create an own condition table but SAP doesn't recommend it. New field in field catalog A customer may create a condition table with all fields that are contained in our field catalog. The field catalog is defines in table KOMK and is filtered for each application in table T681F. It is filled by our communication structures KOMKBME and KOMPBME. Customer may add and fill new fields as we have user-exits for all communication structures, but they have to add the fields to the application field catalog (table T681F, can be maintained with transaction NACE)

10. Condition records


Condition records are entries in condition tables. Example: table B072 (application: always 'ME') VGART WEVER KZDRU Output type

WE

WE01 (used for 101 individual slip)

WA

WA01 (used for 201 individual slip)

WA

WA03 (used for 201 collective slip)

In IMG you can find a list of condition records that have to be created by the customer if he wants to use the standard settings. Common error: Create a condition record with transaction type WA and output type WE*. That way he gets a GR slip with empty PO data. Always check in the condition table B072 (with SE16) if the condition records have been created as described in IMG and if customer output types are used. It gives you a hint if customer has understood the output determination and uses own output types. You can also check which output types he uses as a lot of customers only create condition records for the output types they use. No transportation of output records: Output records are master data with automatic numbering. When you create a condition record in Customizing (transaction MN21), the system creates an entry in table B072 with a condition number (e.g. 4711). The condition number refers to the master data in table NACH (with key 4711). It is not possible to transport the condition records because the record 4711 might already exist in the target system and refer to another condition table than B072. If you have transported a condition record manually (transport of B072 entry or NACH entry), you have an inconsistency in table NACH which can cause MN21 to abort. The transported entries need to be deleted with a correction program and re-created manually with MN21. This is not a hotline problem as this is a wrong customer transport.

11. Access sequence


The access sequence is the link between output type and condition table. In the output type you enter an access sequence (e.g. 0003). The access sequence contains the condition table that will be checked for the output type.

Theoretically it is possible to assign several condition tables to an access sequence but this is not necessary in MM-IM. So you will always find a 1:1 relationship between condition table and access sequence.

12. Layout sets (SAPScript)


You can find the layout set used for an output type in table TNAPR. Our standard layout sets begin with WESCHEIN*, WASCHEIN*. We recommend the customer to copy our standard layout set (Z...) if he needs additional fields. Our read routines in table TNAPR fill all MKPF, MSEG and PO data fields. The customer does not need an own read program if he uses fields from these tables. If he needs own form routines (e.g. to read the batch classification data), he can implement an exit-routine directly in the layout set (using /: PERFORM as SAPscript command). Transaction: SE71, layout set: e.g. WESCHEINVERS1 for output type WE01 Connection between text element of layout set and print program A layout set has windows (e.g. MAIN) and a window has text elements (e.g. W1LGMAT, W1VERBRMAT). A text element represent a few lines that will be printed together (e.g. W1LGMAT for item information in case of PO without account assignment, W1VERBRMAT for item information in case of PO with account assignment). The print programs (e.g. SAPM07DR, form ENTRY_WE01) calls the following function modules to work with the layout set:

OPEN_FORM: to open the layout set and give the printer data START_FORM: to give the language WRITE_FORM (e.g. EXPORTING ELEMENT = 'W1LGMAT' to print a particular text element. CONTROL_FORM: e.g. to start a new page, a new window CLOSE_FORM to close the layout set and be able to open a new one. Two OPEN_FORMs without a CLOSE_FORM = update termination in RV_MESSAGES_UPDATE. Because the text elements are called by the program (in call funtion WRITE_FORM exporting element ...) the customer may copy a layout set but still has to make sure that the text elements called by program still exist in his layout set. When a text element is called, all fields to be printed should have already been read by the program. As we read all data (like MKPF, MSEG, EKPO) before calling text elements in standard, there is practically no risk that a field is empty when the text element is being processed. As we fill the complete work area for MSEG, EKPO etc. the customer may add any field from these tables in a text element. Only text element for the window KOPF (header data) have a delayed process (not during WRITE_FORM but after the whole page has been processed. For that reason, it was necessary to store the work area in 'old' fields in the routines HELPDATA1 and HELPDATA2 in SAPM07DR. For the customer it means that you cannot add an MSEG field in the window KOPF because you will always get the data from the next item and not from the current item.

13. Collective slips


We have 3 collective slips: WE03, WA03, WLB3 (used for 541). A collective slip contains all items of a material document. It would be logical to have a collective slip at material document level but we do only output determination at item level. That is why we create a collective slip for item 0001. Common customer errors: Collective slip printed for all items: A collective slip is printed for all items. Solution: customer has deleted the requirement 173 for WE03, WA03, WLB3 in the schema. Header of collective slips contains data from the last item: In a collective slip it is not possible to add an MSEG field to the header data because you will always have the data of the last item. You

can only add an item field in the text element processing the item data.

14. Requirements
Requirements are small coding parts (usually IF condition with subsequent setting of a return code) that are used in addition to the condition table check. If a condition record is found for an output type but the requirement is not fulfilled, the output type will not be generated. Requirements are assigned to an output type in the schema table. They can be maintained with transaction VOFM (also accessible in Customizing). We use requirements for collective slips and mails. For example, collective slips need requirement 173 so that they will be printed for the first line only. For that purpose the Form routine KOBED_173 (in SAPLV61B) is processed. You can find the coding of a requirement either with SE80 for program SAPLV61B or with VOFM. See also common error for collective slips. No print if empty requirement: If an output type has a requirement that is not used, it might happen that the output record will not generated. The technical reason is that the program SAPLV61B checks the return code (SY-SUBRC = 0) after the execution of a requirement. So if a return code was set (SY-SUBRC <> 0) before a requirement, the system considers that the requirement gives a return code and thus is not fulfilled. Solution: remove the requirement from the output type if the requirement is empty or always set SY-SUBRC = 0 in the requirement.. If you use your own requirements, do not forget to reset the return code (SY-SUBRC = 0) if the requirement is fulfilled.

15. Number of GR/GI slips (MSEG-WEANZ)


Used only for individual slips because it depends on material. Output types: WE01, WE02, WF01, WF02. The idea is to print a number of slips that corresponds to number of pallets delivered. If a material always has a fixed quantity by pallet, you can maintain it in the material master (quantity GR slips on storage location view). It will be proposed in MB01. WEANZ is recalculated when the quantity is distributed among storage locations. Note 432947. Set in program SAPM07DR, Forms AUSGABE_WE01, AUSGABE_WE02 etc.(Include M07DRAUS). MIGO: WEANZ is processed for all goods movements, but in the print programs it is only implemented in the GR slips WE01 and WE02. Which output types can use WEANZ to calculate the number of slips/labels? In the print program there are only two kind of output types working with field WEANZ:

Individual GR slips WE01 and WE02: in form ENTRY_WE01 and ENTRY_WE02 we perform the slip printing as many times as indicated in WEANZ. The field is not active in a collective slip as it is an item information. If item 1 says 10 slips and item 2 says 4 slips, how many collective slips should we print? It does not make sense in a collective slip.

Labels: field MSEG-WEANZ can be used for the determination of the number of copies (table T159E see below) for all goods movements in MIGO since note 333860. In MBxx transactions, it works only for goods receipts as WEANZ is not filled for goods issues.

16. Labels

There is an own customizing step for setting label printout. The idea is that you have a layout set with text element ETIKETT. The system determines the number of labels to be printed from the item quantity and prints the same quantity of text elements (called by WRITE_FORM). In each text element you have the same text. That is why the text for the label printout is not defined in the layout set but in a separate text. Furthermore you can maintain a label type and a label form in the material master. Both fields are used in the condition tables for layout set.

Application object (defined in table TTXOB, standard MM07ET): here you can find the text ID (table TTXID standard 7001), text name and layout set (standard RM07ETIKETT). All data are maintained in table T159O. We recommend to keep the standard object, text id

and text name.

Label text: report RM07METI to maintain the label text (used for all text elements of the layout set) Label types and forms (used in condition tables for labels) Number of copies: here you can define which quantity field (e.g. MSEG-MENGE or MSEG-ERFMG) will be used to calculate the number of copies (table T159E). A customer wanted to use field VM07M-ANZGEB (number of containers in QM), but not possible because it is not an MSEG field and the program SAPM07DR can only work with DB fields. A modification was proposed in M07DRETI, form ETI_DRUCK (read ANZGEB from table QALS to set field ANZAHL1. Another customer wanted to use field MSEG-WEANZ but it does not work in case of GI (or reversal GIs) in MBxx transactions, see chapter WEANZ above. In MIGO it should work for all goods movements since note 333860 as we always calculate WEANZ. Labels and collective slips (output type WEE3): There is no such thing as a collective label. If you use print version 3 and you have created the condition records as recommended in Customizing, you will get one output record for WE03 for the first item and one WEE3 for each item. You will thus have one collective slip with all items and individual labels for each item. The content of WEE1, WEE2 and WEE3 is exactly the same, they all use form routine ETI_DRUCK. If you enter requirement 173 for WEE3 and hope to get one collective label, you will only get labels for the first item with data of the first item. To transport label texts, use report RSTXR3TR. Form routines in SAPM07DR: ETI_DRUCK (include M07DRETI): here the number of copies is calculated from T159O and the text is read in perform ETIKETTENTEXT_LESEN. The text element ETIKETT is called (call function'WRITE_FORM' exporting element = 'ETIKETT') in forms WRITE_LINES and WRITE_LAST..

17. Partner functions


We only use two partner functions for mails in MM-IM. We do not use any partner functions for slips. The partner functions are set by the program in MM07MFN0, POSIDIALOGSTRUKTUR_FUELLEN, call function KOMPBME_FUELLEN. We use the technical partner functions MP for MLGR and DP for MLFH. Partner function is language-dependent! In table TPAUM you can find the translation of the partner function in different languages.

18. Missing part mails


A lot of customers have problem customizing the missing part mails because they not only have to customize the output determination but also the missing part check itself. For detailed information see IMG of missing parts and output determination The missing part mail is a kind of availability check. We check during a goods receipt if the material is missing for some MRP requirements in the past. In MRP customizing you can define a time horizon to determine how far in the past the system has to check the MRP requirements. In MENGE_PRUEFEN > FEHLTEILE_PRUEFEN we call an MRP function module that gives us a list of non fulfilled MRP requirements for the material. If a material has non fulfilled requirements, we send a mail to the MRP controller If the customer does not get the message 'Material is a missing part', the problem will not be a MM-IM but an MRP problem. Set a breakpoint in FEHLTEILE_PRUEFEN (FM07MEF0), function module MISSING_PARTS_CHECK. If you do not get to the breakpoint, it means the missing part is not active (wrong customer setting)

If you get to the breakpoint but the function module does not export an internal table with the list of MRP requirements, it means either the material is not a missing part or wrong customer setting in MRP.

If you get a list of MRP requirements from the function module but the customer does not get any mail or gets an empty mail, this is an MM-IM problem (usually wrong customizing of output determination). If the customer gets a mail for a movement type for which he does not want any or if he has performance problems, it is possible to deactivate the missing part checks in table T156S (T156SC from 4.6 on) with the checking rule ** (note 102248). Missing Parts mail: overview

19. Mail text

You can find examples of mail texts in IMG. Common errors: Mail variables not replaced in mail: In the old SAPSpript editor (SE71), the text variables (e.g. MSEG-MATNR) were defined directly in the text as &MSEG-MATNR&. In the new editor you cannot enter the text variable directly in the editor, youneed to add the text variables through the menue..Make sure the fields you add to the layout set are defined as a variable and not as text in the layout set. In transaction SE71 it should blink when you click on it. See also notes 205951 and 213264 (bug in MB_MESSAGE_UPDATE) Text changes do not appear in mail: Before 4.6B all mail texts were defined at output type level. Since 4.6B it is possible to define a mail text at output type level and at condition record level. When you create a condition, the mail text from the output type is internally copied to the output record. So if you change the mail text at output type level, you need to delete the condition record and recreate it in order to get the text changes to the condition record.

20. GR/GI slips for stock transfers


Usually the customer wants to have only one GI slip for stock transfers (on the supplying side only), but if he uses individual slips (WA01, WA02), he will get automatically two. In order to get only one, he has to make the slips dependent from the debit/credit indicator. This is explained in consulting note 86725. In the customer uses a collective slip, he will get only the items for the supplying side, because we make a check in the program that the item has not been created automatically (MSEG-XAUTO in form LESEN_WAS).

21. Multiple accounting sheet


If the PO has multiple accounting, we print automatically an accounting sheet together with the individual slip. The accounting sheet is printed on a separate layout set MB_MFKTO and contains the detail of the accounting.

Quantities on the accounting sheet: the quantity is the quantity planned in the purchase order because we cannot decide how to distribute the quantity ourselves. It has to be done by the GR clerk. Collective slip: not possible with multiple accounting, we switch automatically to individual slip (since note 15839) Layout set MB_MFKTO: customizable since 4.5B only. Customizing is possible via an entry in table T159N for program M07DRKTO.

22. Language
Has to be set when calling START_FORM, otherwise termination RV_MESSAGE_UPDATE. Can be set dynamically by program SAPM07DR from T001W language. Can also be set by customer in condition record.

23. Printer determination


See IMG and check list 2 from note 426554.

24. Trouble-Shooting guide for non-developers


Bear in mind that the majority of printing problems are attributable to incorrect Customizing or to the use of user-defined developments. Problems which arise as a result cannot be dealt with by Support. If you require help with troubleshooting, you can call our Remote Consulting Service. Before you enter an OSS message for SAP Support, make sure that there are no errors in Customizing or a user-defined development is not involved.

In OSS you will find two notes that will help you checking the output determination in your system:

note 426554: check lists for output determination and printer determination for goods movements note 426648: check list for missing part mails

25. Trouble-Shooting guide with debugging


Use this troubleshooting guide only if your are familiar with ABAP programming and debugging. Important checks:

Do you use own condition tables? Check 1) Customizing MM-IM >Output Determination > Output types: note access sequence. 2) Access sequence: check condition table. Standard tables range from 070 to 079. Customer range is 5xx. If a customer uses own condition tables and the system cannot find any output record or finds too many of them, this is a consulting problem.

Do you use own print program? Check in Customizing MM-IM > Output Determination > Assign forms and programs (or SE16 table TNAPR). Routines like ENTRY_ZE01 or program ZM07MDR are not standard. It might explain that a NAST record will not be printed or has wrong data. Important programs:

SAPLV61B: output determination program SAPM07DR: print program (reads all data per SELECT on database and calls SAPScript layout set. Important Form-Routines for breakpoints: MM07MFD0, DRUCK_PRUEFEN: the version (MKPF-WEVER) is set depending on field RM07M-XNAPR and default version in T158. Field RM07M-XNAPR itself is set on first screen (dialog) or from parameter NDR (MB_CREATE).

MM07MFN0, KOPFDIALOGSTRUKTUR_FUELLEN and POSIDIALOGSTRUKTUR_FUELLEN communication structures KOMKBME and KOMPBME are given to the output determination interface. There you can check the version (MKPF-WEVER), the print indicator (T156-KZDRU) and the transaction type (MKPF-VGART)

MB_CREATE_GOODS_MOVEMENT: the user given in IMKPF-PR_UNAME or IMKPF-USNAM is used for reading parameter NDR in DRUCK_PRUEFEN and is used for the printer determination in LV61BF0P,PRINTER_PARAMETER_LESEN

LV61BF0N, NACHRICHTENSTATUS_SCHREIBEN the output determination program loops over all output types and tries to find a condition record. If a condition record is found (IF XKNUMH NE SPACE), an entry is added to internal table XNAST.

LV61BF0P, PRINTER_PARAMETER_LESEN The printer is found in tables TNAD7 and TNAD9 (CASE INDEX. WHEN '7'. WHEN '9'). MM07MFB9, BUCHEN_AUSFUEHREN, CALL FUNCTION RV_MESSAGES_GET can be used to check the internal table XNAST just before posting (before commit work) SAPM07DR, Form ENTRY_... the data is read from the database (using SELECT *) by the print program. The print routine also calls the layout set and the text elements that have to be printed.

MM07MFT0 for mails only reads the data and fills mail text. Set parameter for mail processing (call transaction) Tips:

Even if an output record from NAST has been printed immediately in the update task, it is possible to repeat the output with MB90 and debug the print program in dialog. It is not possible to debug the print program SAPM07DR during the posting of a material document as it is processed in the update task. If an update termination RV_MESSAGE_UPDATE occurs during the creation of a material document, change the processing time 4 (immediately) to 3. That way the material document will be posted without update termination and you will be able to debug SAPM07DR in dialog using MB90. List of symptoms:

Symptom 1 No output record created for material document

Symptom 2 GR/GI slip is printed on wrong printer

Symptom 3 Update termination in RV_MESSAGE_UPDATE

Symptom 4 Wrong data is printed on GR/GI slip

Symptom 5 No mail MLFH

Symptom 6 Mail MLFH is sent without text or to wrong recipient or cannot be processed with CO06

Symptom 7 GR/GI slip is printed although field 'Print' is not set (note 205450)

Symptom 1: nothing gets printed

Symp tom 2: Wron g print er