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.
IDOC'S OUTBOUND TRIGGER PART 3
Sending IDocs Via RSNASTED

Standard R/3 provides you with powerful routines, to trigger, prepare and send out IDocs in a
controlled way. There are only a few rare cases, where you do not want to send IDocs the standard
way.

The ABAP RSNAST00 is the standard routine to send IDocs from entries in the message control. This
program can be called directly, from a batch routine with variant or you can call the FORM
einzelnachricht_screen(RSNAST00) from any other program, while having the structure NAST
correctly filled with all necessary information.

If there is an entry in table NAST, RSNAST00 looks up the associated processing

routine in table TNAPR. If it is to send an IDoc with standard means, this will
usually be the routine RSNASTED(EDI_PROCESSING) or RSNASTED(ALE_PROCESSING) in the case of
ALE distribution.

RSNASTED itself determines the associated IDoc outbound function module,

executes it to fill the EDIDx tables and passes the prepared IDoc to the port.

You can call the standard processing routines from any ABAP, by executing the
following call to the routine. You only have to make sure that the structure NAST is
declared with the tables statement in the calling routine and that you fill at least the key part and
the routine (TNAPR) information before.

TABLES NAST.
NAST-MANDT = SY-MANDT.
NAST-KSCHL = 'ZEDIK'.
NAST-KAPPL = 'V1'.
NAST-OBJKY = '0012345678'.
NAST-PARNR = 'D012345678'.
PERFORM einzelnachricht_screen(RSNAST00).

Calling einzelnachricht_screen determines how the message is processed.

If you want to force the IDoc-processing you can call it directly:

TNAPR-PROGN = ''.
TNAPR-ROUTN = 'ENTRY'.
PERFORM edi_processing(RSNASTED).