Chapter 3: Transactional Data

Distribution/Interfaces
Overview
In this chapter, we build transactional data interfaces for a few ALE
scenarios. Although some of the concepts we learned in earlier chapters will
continue to be used for constructing ALE interfaces, we will learn certain new
concepts that are specific to transactional data. One of the main differences
between master data and transactional data interfaces is the triggering of the
output. Whereas master data has mechanisms such as change pointers, and
also the capability of sending data as and when reuired, transactional data
in application areas such as !" and ## rely on message control and output
determination. In se$eral other applications, the output %creation of I"O&s'
is carried out by speciali(ed programs. )his chapter presents the steps
in$ol$ed in configuring both outbound and inbound interfaces. Although these
interfaces are set up for communications with e*ternal %non+,-./' systems,
they can easily be configured for ,-./+,-./ connections as well, based on
the settings that we learned in the pre$ious chapter.
)he two scenarios that we consider are0 %1' An outbound purchase order and
%2' an inbound goods mo$ement transaction. In the case of the outbound
purchase order, we use message control and output determination to ualify
purchase order documents on the !A3/ system for the creation of an I"O&.
)he message type used is O,"E,! for the I"O& type O,"E,!42. )he
output type is configured with a $endor as its partner function. As you may be
aware, a purchase order is a function of purchasing in the #aterials
#anagement %##' module.
)he second scenario prototyped is the inbound goods mo$ement. )his
functionality is typically used when interfacing e*ternal warehouse
management systems with the In$entory #anagement module of !A3/
,-./. In ad$anced scenarios, this interface could also be used for mobile
data entry in warehouses. #essage type W##567 is used in con8unction
with the I"O& type W##5I"419 this is a $ery powerful application interface
where se$eral goods mo$ement types are supported. 7ou can perform
transactions such as goods receipt with or without a purchase order, against
a production order, status change of in$entory %any combination of
unrestricted stoc:, uality inspection, or bloc:ed stoc:', in$entory lost or
found transactions, and so forth. )he goods mo$ement transactions
supported are #51A, #515, #51&, #541, and #5.1. 5y enhancing certain
ALE function modules through customer functions %user e*its', this message
type can also be used for in$entory reconciliation. As we prototype this
application scenario, we are also building an I"O& shell program to generate
I"O&s that will be imported into the ,-./ system. )here, we will also
e*plore the segments a$ailable in that I"O& type.
;ote that in this chapter we only build interfaces in a fashion that is already
deli$ered by !A3/. We will not be enhancing the functionality of these two
message types. %ALE enhancements are dealt with in the ne*t chapter.' It is
important to analy(e the reuirements of the intended interface, and then
prototype the !A3/+deli$ered functionality to e$aluate the fit. As discussed
earlier, in most cases, the !A3/+deli$ered functionality will meet your
reuirements.
Outbound Interface
As mentioned earlier, we first prototype an outbound 3urchase Order9 this
purchase order is a function of the application area 3urchasing in the
#aterials #anagement module. We configure message control and output
determination to trigger an output for the creation of a purchase order I"O&
of type O,"E,!42 based on changes %create, change, line item delete' to a
purchase order. )he message type used is O,"E,! and the corresponding
process code is #E14.
Maintaining the Logical Sste!
<sing the steps described in an earlier chapter, create a new logical system
to represent the e*ternal system we plan to communicate purchase orders to.
Let us call this logical system =3O&>?4441. )his system is the recei$ing
system on behalf of the e*ternal system, while 5@1&L;)414 is the sending
system that we created and allocated in the pre$ious chapter. ;ote that you
could use a logical system pre$iously created to transmit other message
types as well. In order to impro$e understandability, and preclude confusion,
let us use a new logical system for each application area we prototype.
Configuring the Custo!er Model
<se transaction 5"AB to create or maintain the customer distribution model.
>ere, we create a new model, say 3O#O"EL441, where the base logical
system 5@1&L;)414 sends messages of type O,"E,! to system
=3O&>?4441. )he two filter ob8ect types a$ailable to us are E5EL;
%3urchase Order number' and LIC;, %Dendor number'. If need be, it is
possible to use LIC;, filter ob8ect type to send purchase order I"O&s for a
gi$en $endor to a separate logical system and a port associated with itE
simply put, we can differentiate the purchase orders based on the $endor
number. ;ote that we can use the same customer distribution model to
transmit and recei$e different messages from the same or different logical
systems.
Defining a "ort
<sing transaction WE21, let us create a file+based port for creating a file of
purchase order I"O&s. Let us name the port 3O3O,)4441. #aintain the
outbound file parameters by specifying a directory path and file name or file
pattern. Ensure that you can access the specified directory and ser$er by
pinging the ser$er through the chec: button while defining the port. If need
be, you can define a command file whereby a shell script can be triggered at
an ,C& logical destination. )his is especially useful when you need to start
an C)3 process to a remote ser$er. 7ou can maintain ,C& destinations
using transaction SM59. )he port that we created here is referenced in the
partner profile that we maintain in a subseuent step.
Output Deter!ination
In the !" and ## application areas, message control determines the criteria,
timing, and medium of output documents such as purchase order, in$oice,
deli$ery note, shipment notification, and so forth. Output determination is a
comple* lin:age of application ob8ects and concepts, namely &ondition
)ables, Access !euences, Output )ypes, Output "etermination
3rocedures, and &ondition ,ecords. We now step through the $arious
actions that need to be ta:en to configure message control for a purchase
order. !ee Cigure .+1.
#igure 3$% I#? for 3urchasing #essage %Output' "etermination
Crom the ,-./ customi(ing guide %I#?' or transaction SPRO Materials
Management Purchasing Message Determination Message
Determination Condition Table for Messages Define
condition table for purchase order Messages: Display
Condition Table0 Purchase order. )his leads us to a screen with a
parameter for name of a condition table. A pull down on the field displays the
condition tables !A3/ has pro$ided for purchase orders0
42F 3urchasing Output "etermination0
"oc.)ype-3urch.Org-Dendor
42A 3urchasing Output "etermination0 "ocument
)ype
42G 3urchasing Output "etermination0 3urch.
Org.-Dendor for E"I
Let us choose condition table 42A %see Cigure .+2'. )he criterion for selection
of the purchasing output is "ocument )ype. )he condition table consists of
fields selected from a field catalog that has entries of fields that are rele$ant
to the communication of that particular message, namely purchasing output
in this case. )he selected fields form the criteria for the ualification of the
output for further processing. Later, we maintain $alues for the condition table
in condition records. In this case, the selected field is 5!A,)E3urchasing
"ocument )ype. If need be, it is possible to create condition tables with fields
selected based on your reuirements. In certain cases, it is also possible to
add fields to the field catalog, which is based on ob8ects :nown as
communication structures.
#igure 3$& &ondition )able with Cield &atalog and !elected Cield%s'
)he ne*t step is to define an access seuence for the purchase order. )he
access seuence dictates the condition tables used to access condition
records, the seuence of condition tables, and defining the fieldsH contents for
the criteria for accessing the tables. Crom the I#? or transaction SPRO
Materials Management Purchasing Message Determination
Message Determination Access Sequences Define
Access sequence for purchase order. Let us use an e*isting access
seuence %see Cigure .+.'. !euence 4441 uses condition tables 42G, 42F,
and 42A, with 42A being the condition table that we decided to use.
#igure 3$3 Access !euence for 3urchase Order
)he ne*t acti$ity, configuring the output type %message type, as it is :nown in
3urchasing' is an important step that brings together se$eral elements of
message control and specifies the :ind of output that will be generated by the
system based on reuirements specified in the access seuence and
condition records %see Cigure .+B'. )o do this0
#igure 3$' Output )ype for 3urchase Order

I Crom the I#? or transaction SPRO Materials Management
Purchasing Message Determination Message
Determination Message Types Define message types for
purchase order Maintain output types0 Purchase order
I &opy the e*isting output type NE to a new output type !NE
I Enter a description and access seuence of """#

I <nder the general area, choose condition access and multiple
issuing

I <nder &ondition record proposal, choose transmission medium of A for
ALE and time of 10 !end with the ne*t selection run, for e*ample,
,!;A!)44 Online

I &lic: on button 3,O&E!!I;? 3,O?,A#. &reate an entry for !NE, with
medium A, processing program as $SNASTED, and form routine as
A%E&P$'CESS(N)*

I Crom the pre$ious screen, clic: on button 3A,);E, "ECI;I)IO;. &reate
a new entry for output type !NE, medium A, partner function +N for
$endor.

I 7ou may create another entry for partner function DPE"eli$ering 3lant, for
stoc: transfers
I !a$e
)he ne*t step is to indicate the permitted operations for which the output is
acti$ated. )his can be done0

I Crom the I#? or transaction SPRO Materials Management
Purchasing Message Determination Message
Determination Message Types Define message types for
purchase order ,ine-Tuned Control: Purchase 'rder
I &reate a new entry for operation 1E;ew, for output type !NE
I &reate a new entry for operation 2E&hange, for output type !NE
I !a$e
>a$ing configured the output type, it is now essential to lin: it to an output
procedure, also :nown as a message schema. We will use the !A3/+
supplied output determination procedure ,#5EC1. )o do this0

I Crom the I#? or transaction SPRO Materials Management
Purchasing Message Determination Message
Determination Message Schemas Define message schemas
for purchase order Maintain output determination
procedure: Purchase order
I &hoose the procedure $M.E,# and clic: on the button &O;),OL

I Add a new entry for output type !NE with !tep being an incremental
number of the pre$ious number. 7ou can lea$e the field for ,euirement
blan:. )his field places a selection criterion on the output document. If
specified, the document will be a candidate for output processing only if
that reuirement is met.
I !a$e
I ?o to the option Assign Schema to Purchase 'rder

I &reate an entry with . for output, E, as the application, and $M.E,# as
the procedure
I !a$e
)he last step in this process is to create condition records for the tables that
are being accessed in certain seuences that we incorporated in the output
type. )o do this0

I Crom !A3Hs/ main menu, %ogistics Materials Management
Purchasing Master Data Messages Purchase 'rder
Create
I Enter !NE as the output type
I Enter

I &hoose the :ey combinationEPurchasing 'utput Determination:
Document Type

I !pecify the document type, partner functionE+N, medium A for ALE,
timing 1 for processing with ne*t run of ,!;A!)44, and language, for
e*ample E for English
I !a$e
All the preceding steps need to be completed in order for the output to be
triggered for processing by ALE. As you may ha$e reali(ed, there are se$eral
$ariations of the configuration that we completed, especially for specifying
different criteria, search strategies, reuirements, and nature of output. In our
configuration, we adopted a simple approach, using !A3/+deli$ered ob8ects
in most cases. )his boo: does not purport to be a treatise on the
configuration of output determination9 hence, you may use the preceding as a
guideline to configure output determination for purposes of prototyping the
ALE interface. &ontact your functional consultant for more details.
Maintaining the "artner "rofile
As we learned earlier, we need to configure the partner profile that is the
identifier for the e*ternal system. )he partner profile brings together se$eral
elements of the ALE interface and pro$ides a gateway for communications.
In the case of transactional data interfaces in the !" and ## modules, we
ha$e to define additional parameters based on the output determination that
we configured earlier.
Cirst, create a partner profile based on the logical system =3O&>?4441,
with partner type being L!. )o do this0

I )ransaction WE20 or WEDI (D'C Partner Profile/ or SA%E
Communication Manual maintenance of partner profile
Maintain partner profile
I Enter !P'C0)"""# for partner number, and %S for partner type
I &lic: on button &,EA)E
I Enter A%E as partner class, and A as partner status
I !a$e
Outbound "ara!eters )o maintain outbound parameters %see Cigure .+F',
follow these steps0
I Cor partner !P'C0)"""#, clic: on the button O<)5O<;" 3A,A#E)E,!
I &lic: on ;EW E;),IE!

I Enter '$DE$S for message type, P'P'$T"""# for recei$er port,
'$DE$S"1 for I"O& type
I !elect the radio+buttons &OLLE&) I"O&! and do not start subsystem
I !a$e
#igure 3$( Outbound 3arameters for 3urchase Order
Message Control )o maintain the message control parameters of the
partner profile %see Cigure .+A', follow these steps0
I Cor partner profile !P'C0)"""#, clic: on button #E!!A?E &O;),OL
I &lic: on button ;EW E;),IE!
I Enter E, for Application, and !NE for Output type
I Enter '$DE$S for message type, and ME#" for 3rocess code
I !a$e

I &reate another #essage control entry for Application E,, Output type
!NE, with the Change message chec:bo* selected. <se '$DE$S for
message type and ME#" for 3rocess code. )his entry is for accepting
changes to purchase orders.
I !a$e
#igure 3$) #essage &ontrol for 3urchase Order
*or+ing the Interface
>a$ing completed all the configuration reuired for generating 3urchase
Order outbound I"O&s, we now proceed with the e*citing tas: of testing the
interface. )here are three steps in$ol$ed in this tas:0

1. &reate or change a purchase order. Ensure that an output %message' has
been generated of type !NE.
2. 3rocess the preceding output to create an I"O&.
.. "ispatch the I"O& to the e*ternal system.
In order to create purchase orders, use transaction ME21 %Dendor :nown' or
from !A3/ main menu %ogistics Materials Management
Purchasing Purchase 'rder Create +endor 2no3n* 7ou
can also use transaction ME25EDendor un:nown. Enter a document type
that is $alid for message control9 that is, enter a purchase order document
type that was used for creating condition records during the configuration of
output determination. Enter the material number, uantity, plant, storage
location, unit price, and the li:e, for the purchase order. Ensure that the line
item has been accepted. )o see if the output record has been created0
I Crom the purchase order o$er$iew screen 0eader Messages

I )here should be an entry for output type !NE with medium A for ALE,
partner function +N for $endor, language E for English, and status of 4. )he
status $alue 4 indicates that the output record created has not yet been
processed
I !a$e the purchase order
I As you can see in Cigure .+G, if the document has been changed, you will
see the flag set for the last column C0N). Only if there e*ists an entry in
the partner profileHs message control for change messages will the output
be processed into an I"O& in such a situation
#igure 3$, Output %message' ,ecord for 3urchase Order
"rocessing Output When an output record is created based on the output
determination that we configured, an entry is created in the ;A!) table. )his
table stores output records for all applications using message control. ;ote
that this is not a table specific to ALE, but for the application per se. )he
;A!) table also stores the status of the output record, namely9 4, for not yet
processed9 1, for processed successfully9 2, for processed with errors9 and .,
for inacti$e. 3rograms that process output based on message control, access
the ;A!) table with function modules to gather control information such as
the ob8ect :ey %the purchase order number, for e*ample'. !ubseuently,
these programs generate the output in a particular medium, as defined in the
output record. After ha$ing created the output, the ;A!) table is updated
with the correct status of the output record.
In order to process the output record we created earlier, follow these steps0

I E*ecute program ,!;A!)44 or from WEDI Test 'utbound from
NAST or transaction WE15

I Enter E, for Output application, !NE for Output type, and A for Output
medium
I E*ecute

I 7ou will recei$e informational messages regarding the success of the
action, along with an I"O& number
<sing transaction WE02 or WE05, chec: the I"O&s created by the preceding
process. Inspect the data segments to ensure that the I"O& was populated
with the correct information.
Dispatching IDOCs ;ow that we ha$e created purchase order I"O&s on the
,-./ system, we need to dispatch it to the e*ternal system. !ince we
defined the port 3O3O,)4441 as a file+based port, we will be creating a file
of purchase order I"O&s that can be sent to the e*ternal system. )o do this0

I E*ecute program ,!EO<)44 or transaction WEDI Test 'utbound
from (D'C or transaction WE14

I Enter selection criteria such as message type, partner details of recei$er,
port of recei$er, and so forth
I E*ecute

I 7ou should recei$e an informational message indicating the number of
I"O&s processed
&hec: the directory on the ser$er designated to recei$e the file, as
configured in the port 3O3O,)4441. !A3/ should ha$e created a file with
the name or pattern specified in the port definition. 5rowse the fileHs contents
and ensure that it is the data that should ha$e been created.
)his file can be sent across to the other system by means of an C)3 or other such utility. )he
process can be automated by specifying a command file %shell script' at an ,C& logical destination
that gets triggered after the creation of the file. It is also possible to define the port as a transactional
,C& port, and in$o:e programs %third+party software' that will communicate the I"O& to the
e*ternal system. )his software may also be capable of translating the I"O& into the format reuired
by the e*ternal system. We discuss these options further in a later chapter.
Inbound Interface
In this section, we prototype an inbound interface0 a goods mo$ement
interface from an e*ternal warehouse management system to !A3/ ,-.Hs/
In$entory #anagement module. )he ALE message type used is W##567
with a corresponding I"O& type of W##5I"41. )his functionality in !A3/
was originally designed to wor: with a warehouse system for mobile data
entry of stoc:s. <pon entry of data on the mobile terminal, e*ternal software
would transmit the data to the !A3/ ser$er where it would get formatted into
an I"O&, and imported into the ,-./ system using t,C& for posting to the
application. As you can see, ALE is capable of handling real+time or pseudo+
real+time interfaces to e*ternal systems or other ,-./ systems, using
transactional ,C& connections. )he goods mo$ement interface that is being
configured and tested here can be set up in se$eral ways to suit your
reuirements. W##567 is a powerful message type that supports many
mo$ement types and goods mo$ement transactions, including and not limited
to goods receipt with or without a purchase order, goods receipt against
production orders, in$entory lost and found transactions, and in$entory status
change.
)here are a few limitations of this message type, too. Cor e*ample, e$en
though the goods mo$ement I"O& has the capability of creating a material
batch when creating a material document, it does not create its
corresponding batch characteristic $alues. )o accomplish this functionality,
you need to enhance the ALE functionality by e*tending the I"O& and writing
code in the customer functions %user e*its' pro$ided by !A3/. %I"O&
e*tensions and ALE enhancements are discussed in the ne*t chapter.' Also,
in order to use this interface for in$entory reconciliation, you ha$e to enhance
the functionality by adding code in the !A3/+pro$ided customer functions.
>owe$er, as you will disco$er, this interface pro$ides se$eral powerful
functions.
?enerally spea:ing, the steps described below should be sufficient to set up
ALE in order to prototype an inbound interface. An important reuirement to
successfully prototype an ALE interface is to understand the business needs,
in$estigate the capabilities of the message type and ALE function modules by
understanding the purpose of the data segments, and testing it with
$ariations of data based on different application scenarios.
An important element in inbound interfaces is the process code. )he process
code, which is maintained in the inbound parameters of the partner profile,
determines the application function module that is to be in$o:ed for further
processing or for posting the document to the application. )his function
module also contains code that triggers error processing through
components such as Wor:flow. Cor e*ample, W##5 is the process code
that is used for this interface, and it in$o:es function module
LJI"O&JI;3<)JW##567. As discussed earlier, this function module has
customer functions %user e*its' that can be enhanced to add or modify its
functionality.
7ou can browse or maintain process codes by0 WEDI Control
(nbound process codes (nbound 3ith A%E ser4ice/ for
inbound interfaces9 for outbound, WEDI Control 'utbound process
codes 'utbound 3ith A%E ser4ice. Or, you can use transactions
WE42 and WE41, respecti$ely.
Let us proceed with the configuration for our inbound ALE interface.
Maintaining the Logical Sste!
&reate a logical system to represent the e*ternal system. In this case, the
e*ternal systemHs logical system will be the sender system, while the base
logical system %5@1&L;)414' will be the recei$ing system. )o do this0

I Crom SALE .asic Configuration Set up logical systems
Maintain logical systems. %)his is a client+independent acti$ity.'
I &lic: on button ;EW E;),IE!

I Enter the name of the logical system, say ?OO"!#D)41, and a
description
I !a$e
As mentioned earlier, you can use a logical system for multiple message
types for both inbound and outbound interfaces, as long as the correct
parameters are maintained in the partner profile that is based on this logical
system. >owe$er, for better understandability, error handling, and
maintenance, it is better to represent each system with its own logical system
and partner profile.
-ote It is not necessary to maintain the customer distribution model in
this case. It would be needed if communicating with a remote
,-./ system. In such a case, you would distribute the customer
model from the remote system to this ,-./ system. Also, for the
purposes of this configuration and testing wherein we will be
importing a file of I"O&s, it is not reuired to maintain the port
definition.
Maintaining the "artner "rofile
)he ne*t step in the process is to create a partner profile for the e*ternal
system, based on the logical system that we configured. )his partner profile
will tie together the $arious ALE ob8ects and settings, and pro$ide a gateway
for communications. In this e*ample, we configure only the inbound
parameters, since message control and outbound parameters do not apply.
;ote that you can use a partner profile %and its logical system' for defining
multiple inbound and outbound messages. 3roceed as follows %see Cigure .+
K'0
#igure 3$. Inbound 3arameters for ?oods #o$ement Interface

I E*ecute transaction WE20 or WEDI I"O& Partner profile or
SALE Communication Manual maintenance of partner
profiles Maintain partner profiles
I Enter )''DSM+T"# for 3artner number, %S for 3artner type
I &lic: on button &,EA)E
I Enter A%E for 3artner class, and A for 3artner status
I !a$e. )he partner has been created
I &lic: on button I;5O<;" 3A,A#E)E,!
I &lic: on button ;EW E;),IE!
I Enter 5MM.67 for message type, and 5MM. for 3rocess code

I )he chec:bo* for Synta8 Chec2 should be chec:ed. )his implies that
the synta* of the inbound I"O& imported into the system will be chec:ed9
that is, it will $alidate the segments, hierarchy, and other structure+related
rules that are defined in the I"O& type. As you will see later, it is our
responsibility to maintain the synta* and integrity of the I"O& type. An
error message will be issued if the I"O& fails the synta* chec:9 this
applies to both the inbound and outbound I"O& types. Cor your
information, synta* data for an I"O& type can be found in table E"I!7;.

I <nder Processing options, choose the radio+button 3,O&E!!
I##E"IA)EL7. )his implies that the I"O& data will be posted to the
application during the process of importing it into the system. In case you
choose the option .ac2ground processing/ no o4erride 3ith
e8press flag or .ac2ground processing/ o4erride possible
3ith e8press flag, then you ha$e to schedule program ,5"A3341 to
post the I"O& created in status ABE,eady to be passed to application.
)his mysterious e*press flag is applicable only to inbound I"O&s, and is
specified on the E"I"& record of an I"O& in the field E63,!!. If this field
has a $alue of 6, and if the processing option in the partner profile is set
to .ac2ground processing/ o4erride possible 3ith e8press
flag, then that particular I"O& is processed immediately.
I !a$e
)he partner profile has now been configured for the inbound goods
mo$ement interface.
*or+ing the Interface
>a$ing completed the ALE configuration for the interface, we now launch into
the e*citing tas: of testing it. In the case of outbound interfaces, it is easy to
test the setup since the data either e*ists in !A3/ or can be created with
minimal effort. >owe$er, with inbound ALE interfaces, we ha$e to create the
I"O& and import it into !A3/ for further processing. Cor purposes of testing
and prototyping, this can be easily achie$ed by writing a simple A5A3-B
program that creates a file of I"O&s, which can then be imported into !A3/
through normal channels. Also, after ha$ing prototyped the interface, it is
important to create a mapping document that relates the record layout of the
e*ternal system to the I"O& type. It is possible to use a mapping
tool-translation software that con$erts the e*ternal system records to I"O&s.
!ome mapping software products ha$e been certified by !A3/ for purposes
of ALE-E"I interfaces. )hey also are euipped with ALE Adapters that lin:
with the ,-./ system, thereby pro$iding a seamless interface with the
e*ternal system. We discuss the role of mapping tools in &hapter A.
Creating an IDOC Shell "rogra! In order to test our interface, we need to
create an A5A3-B program that will produce I"O&s. Also, to successfully
prototype the interface, it is important to understand the $arious segments of
the I"O& type and its fields. Cor e*ample, certain $alues of a particular field
could influence the application to process data in a preset manner, or e$en
incorrectly. ,ead the documentation on that I"O& type %transaction WE60'
thoroughly before prototyping the interface.
)he W##5I"41 I"O& type consists of two segments0 %1' E2#567> for
header data and %2' E2#567I for item data. 5oth are mandatory segments,
and e$ery I"O& should be comprised of one E2#567> E"I"" record
followed by one or more E2#567I E"I"" records. Of course, each I"O&
will also ha$e as its first record the E"I"& record. )he header segment
consists of fields such as posting date, document date, document reference
number and te*t, transaction code, and so forth, while the detail segment has
se$eral fields that reuire information such as material number, mo$ement
type, plant, storage location, purchase order number, uantity, units of
measure, and so on. %!ee Appendi* C for details of the W##5I"41 I"O&
type.' )here are certain flags on the E2#567I segment that indicate or
control the processing of the document in the !A3/ application. Cor
e*ample, field E2#567I+@=5EW should ha$e a $alue of 5 for goods
receipt against a purchase order, and C for a production order. If the
interface is handling large $olumes of data, or if it is a business reuirement,
you could pac:age se$eral detail lines for one single header, gi$en that all
detail items ha$e the same transaction code9 howe$er, from a technical
perspecti$e, this is not essential.
Let us inspect the general structure of this I"O& shell program. )he first
record being written in the file is the E"I"& record, which contains control
information about the I"O& such as client, direction, sender partner details,
recei$er partner details, ports, message type, I"O& type, and so forth. %!ee
Appendi* E for details on I"O& record structures.' %;ote that the port name
by default has to ha$e the $alue !A3/L!I"M, where L!I"M is the name of
the instance. Cor e*ample, if the instance is 5@1, then the port name would
be !A35@1.' E"I"" records follow the E"I"& record created. We first
populate the :ey information of the E"I"" record structure such as segment
name. 7ou can lea$e fields li:e segment number and hierarchy le$el blan:,
as they will be resol$ed by !A3/ when the I"O& is added to the system.
)hen, the !"A)A segment is formatted with E2#567> header data and
mo$ed into field !"A)A of the E"I"" record. )his record is then written to
the file. )he same operation is repeated for E2#567I detail lines, and the
E"I"" records are written to the file. )his completes the creation of one
I"O& in the file. If need be, you can create se$eral such I"O&s in the same
file with different sets of data. !ee the source listing in Cigure .+N.

-ote In case of message types corresponding to I"O& types that can be
used for both outbound and inbound processing, you can use
transaction WE12 to modify the I"O& file for inbound processing.
Cor this, you must first create the outbound file.
#igure 3$/ Sa!ple IDOC Shell "rogra!
$EP'$T !5MM.67#*
9
999999999999999999999999999999999999999999999999999999999999999999999999
999This is an (D'C shell program to create 5MM.(D"# (Docs
for 999
999 the )oods Mo4ement interface bet3een an e8ternal
3arehouse 999
999 management system and SAP $:;<s (n4entory Management
module* 999
999999999999999999999999999999999999999999999999999999999999999999999999
TA.%ES :
E1M.670/ = 5MM.(D"# (Doc type<s header
segment
E1M.67(* = 5MM.(D"# (Doc type<s detail
segment
9 idoc control record
DATA: .E)(N ', (D'C&C'NT$'%*
(NC%DE ST$CT$E ED(&DC*
DATA: END ', (D'C&C'NT$'%*
9 idoc data record
DATA: .E)(N ', (NT&ED(DD*
(NC%DE ST$CT$E ED(&DD*
DATA: END ', (NT&ED(DD*
9
PA$AMETE$S:
9 SAP (M (nbound Test file of (Docs
'T,(%E>?"@ T7PE C %'5E$ CASE = output filename
DE,A%T
A:home:raBcast:in4adBC"*tst<*
9
STA$T-',-SE%ECT('N*
9
99999 'pen the output file
9
'PEN DATASET 'T,(%E ,'$ 'TPT (N TE6T M'DE*
(, S7-S.$C NE "*
5$(TE: : AError opening outfileD</ S7-S.$C*
E6(T*
END(,*
9999999
C%EA$: (D'C&C'NT$'%/ (NT&ED(DD*
999999999999999999999999999999999999999999999999999999999999999999999999
9 SET C'NT$'% +A$(A.%ES AND 5$(TE C'NT$'% $EC'$D
99999999999999999999999999999999999999999999999999999999999999999
9
(D'C&C'NT$'%-TA.NAM E AED(&DC<* =Table
name
(D'C&C'NT$'%-MANDT E S7-MANDT* =Client
(D'C&C'NT$'%-D'C$E% E S7-SAP$%* =SAP
release
9 (D'C&C'NT$'%-D'CNM E =edi doc
number
(D'C&C'NT$'%-D'CT7P E A5MM.(D"#<* =(D'C type
(D'C&C'NT$'%-D($ECT E A1<* =Direction
(D'C&C'NT$'%-$C+P'$ E ASAP.F#<* =$ecei4er
Port
(D'C&C'NT$'%-$C+P$T E A%S<* =$ecei4er
Partner Type
(D'C&C'NT$'%-$C+P$N E A.F#C%NT"#"<* =$ecei4er
Partner
(D'C&C'NT$'%-SNDP'$ E ASAP.F#<* =Sender
port
(D'C&C'NT$'%-SNDP$T E A%S<* =Partner
Type for sender
(D'C&C'NT$'%-SNDP$N E A)''DSM+T"#<* =Sender
Partner
(D'C&C'NT$'%-SNDP,C E SPACE* =Sender
Partner/ function
(D'C&C'NT$'%-MEST7P E A5MM.67<* =Message
type
(D'C&C'NT$'%-(D'CT7P E A5MM.(D"#<* =(D'C type
9 (D'C&C'NT$'%-C(MT7P E =E8tension
type
9 (D'C&C'NT$'%-SE$(A% E =Serial
number for serlGn
9
T$ANS,E$ (D'C&C'NT$'% T' 'T,(%E* =3rite
control record
(, S7-S.$C NE "*
5$(TE: : AE$$'$ ED(DC #<*
END(,*
99999999999999999999999999999999999999999999999999999999999999999
99999999999999999999999999999999999999999999999999999999999999999
C%EA$ (NT&ED(DD*
(NT&ED(DD-TA.NAM E AED(&DD<*
(NT&ED(DD-SE)NAM E AE1M.670<*
9 (NT&ED(DD-SE)NM E
9 (NT&ED(DD-PS)NM E
9 (NT&ED(DD-0%E+E% E
9
C%EA$: E1M.670*
9
E1M.670-.%DAT E A#HHI"I1C<* = I Document date in
document
E1M.670-.DAT E A#HHI"I1C<* = I Posting data in
document
E1M.670-6.%N$ E Atestgood<* = #J $eference
document number
E1M.670-.FT6T E Atestgdsrecp<* = 1C Document header
te8t
9E1M.670-,$.N$ C0A$ C #J Number of bill
of lading
9E1M.670-6A.%N C0A$ C #" )oods
receipt:issue slip
E1M.670-TC'DE E AM.#C<* = C0A$ C ? Session: Current
transaction
9
(NT&ED(DD-SDATA E E1M.670*
9
T$ANS,E$ (NT&ED(DD T' 'T,(%E*
(, S7-S.$C NE "*
5$(TE: : AError 3riting ED(DD #<*
END(,*
9
C%EA$ (NT&ED(DD*
(NT&ED(DD-TA.NAM E AED(&DD<*
(NT&ED(DD-SE)NAM E AE1M.67(<*
9 (NT&ED(DD-SE)NM E
9 (NT&ED(DD-PS)NM E
9 (NT&ED(DD-0%E+E% E
9
C%EA$ E1M.67(*
9
91M.67(-.EAF! C0A$ C # (ndicator:
line already e
91M.67(-6ST'. C0A$ C # ,lag:
$e4erse posting
E1M.67(-MATN$ E A""""""TESTMATE$(A%<* =rial number
E1M.67(-5E$FS E AP%NT<* = C0A$ C ? Plant
E1M.67(-%)'$T E A"""#<* = Storage
%ocation
E1M.67(-C0A$) E ATEST.TC0<* = .atch
number
E1M.67(-.5A$T E ACJ#<* = ; Mo4ement
type >in4entory@
91M.67(-(NSMF E AS<* = C0A$ C # stoc2 type
91M.67(-S'.F! C0A$ C # Special
stoc2 indicator
91M.67(-F!+.$ C0A$ C # (ndicator:
consumption po
91M.67(-%(,N$ C0A$ C #" +endor
>creditor@ account
91M.67(-FNN$ C0A$ C #" Customer
number
91M.67(-FDA, C0A$ C #" Sales order
number
91M.67(-FDP'S C0A$ C J (tem number
in customer or
91M.67(-FDE(N C0A$ C ? Scheduling
of customer or
91M.67(-S0F!) C0A$ C #
Debit:credit indicator
91M.67(-5AE$S C0A$ C C Currency
2ey
91M.67(-DM.T$ C0A$ C #C Amount in
local currency
91M.67(-.5TA$ C0A$ C #" +aluation
type
E1M.67(-E$,M) E ACCC*"""<* = Kuantity in
unit of entry
E1M.67(-E$,ME E ACS<* = C0A$ C ; nit of
entry in char*for
91M.67(-.PMN) C0A$ C #C Kuantity in
order price q
91M.67(-.P$ME C0A$ C ; 'rder price
quantity unit
91M.67(-E.E%N E = #" Purchasing
docum
91M.67(-E.E%P E = C (tem number
of purchasing
91M.67(-E%(F! E A6<* = C0A$ C # =Deli4ery
completedL indi
91M.67(-S)T6T C0A$ C C" %ine item
te8t
91M.67(-5EMP, C0A$ C #1 )oods
recipient
91M.67(-A.%AD C0A$ C 1C nloading
point
91M.67(-F'ST% C0A$ C #" Cost center
91M.67(-A,N$ E = #1 'rder
Number
91M.67(-AN%N# C0A$ C #1 Asset main
number
91M.67(-AN%N1 C0A$ C ? Asset sub-
number
91M.67(-$SNM C0A$ C #" Number of
reser4ation : d
91M.67(-$SP'S C0A$ C ? (tem number
of reser4ation
91M.67(-F!EA$ C0A$ C # (ndicator:
final issue for
91M.67(-MMAT C0A$ C #I
$ecei4ing:issuing material
91M.67(-M5$F E = C0A$ C ? $ecei4ing
Plant:(ssuing P
91M.67(-M%)' E A A* = C ?
$ecei4ing:(ssuing Storage
91M.67(-MC0A C0A$ C #"
$ecei4ing:(ssuing .atch
91M.67(-F!.E5 E = C0A$ C # Mo4ement
(ndicator
91M.67(-5EN. C0A$ C # (ndicator:
goods receipt
91M.67(-%)NM C0A$ C ; 5arehouse
number:comple8
91M.67(-%)T7P C0A$ C ; Storage
type
91M.67(-%)P%A C0A$ C #" Storage bin
91M.67(-)$ND E = ?
(ndicator:$eason for )ood
91M.67(-E+E$S C0A$ C 1 Shipping
instructions
91M.67(-E+E$E C0A$ C 1 Compliance
3ith shipping
91M.67(-(MFE7 C0A$ C I (nternal
2ey for real est
91M.67(-FST$) C0A$ C #1 Cost obBect
91M.67(-PA'.MN$ C0A$ C #" Number for
business segment
91M.67(-P$CT$ C0A$ C #" Profit
center
91M.67(-PS&PSP&PN$ C0A$ C I ProBect
structure plan el
91M.67(-NP%N$ C0A$ C #1 Net3or2
number for account
91M.67(-A,P% C0A$ C #" Planning
number for trans
91M.67(-AP%!% C0A$ C I Counter for
distinguishing
91M.67(-A,PS C0A$ C ? Number of
order item in C
91M.67(-+PTN$ C0A$ C #" Partner
account number
91M.67(-,(P'S C0A$ C #? Commitment
item
91M.67(-)S.E$ C0A$ C ? .usiness
area
91M.67(-.STM) C0A$ C #C )oods
receipt quantity in
91M.67(-.STME C0A$ C ; 'rder unit
91M.67(-E6.5$ C0A$ C #C Posting
amount in local c
91M.67(-F'NT' C0A$ C #" ):% account
number
91M.67(-$S0F! C0A$ C #
Debit:credit indicator
91M.67(-.DMN) C0A$ C #C $equirement
quantity in C
91M.67(-ENMN) C0A$ C #C (ssued
quantity in char*f
91M.67(-KP%'S C0A$ C #1 (nspection
lot number in
91M.67(-M!ST C0A$ C # Status of
recei4ing batch
91M.67(-M!S C0A$ C # Status 2ey
of transfer batch
91M.67(-M.A$ C0A$ C #" +aluation
type of transfer
99M.67(-MS'F C0A$ C # Special
stoc2 indicator f
91M.67(-%,.MA C0A$ C ? ,iscal year
of a reference
91M.67(-%,.N$ C0A$ C #" Document
number of a reference
91M.67(-%,P'S C0A$ C ? (tem in a
reference document
91M.67(-SMA0$ C0A$ C ? Material
document year in
91M.67(-SM.%N C0A$ C #" Number of a
material document
91M.67(-SM.%P C0A$ C ? (tem in
material document
91M.67(-E6+F5 C0A$ C #C Sales 4alue
specified e8t
91M.67(-KM&!STD C0A$ C # .atch
status 3ith status
91M.67(-P'SN$ C0A$ C J Deli4ery
item for subsystem
91M.67(-+.E%N C0A$ C #" Deli4ery
91M.67(-KM&M!ST C0A$ C # Status of
recei4* batch 3
91M.67(-.5%+S C0A$ C ; Mo4ement
type for 5hse Mg
91M.67(-M$E! E A A* = C0A$ C C NME$AT'$
,'$ C'N+E$T(N)
91M.67(-M$EN E A A* = C0A$ C C DEN'M(NAT'$
,'$ C'N+E$S('N
91M.67(-+,DAT E A A* = I E6P($AT('N
DATE '$ .EST-.
91M.67(-DA.$! DATS D I $eference
date for account
9
99999999999999999999999999999999 3rite ED(DD record
9999999999999
(NT&ED(DD-SDATA E E1M.67(*
T$ANS,E$ (NT&ED(DD T' 'T,(%E*
(, S7-S.$C NE "*
5$(TE: : AE$$'$ ED(DD 1<*
END(,*
99999999999999999999999999999999999999999999999999999999999999999
9
I!porting the IDOC >a$ing created the file of I"O&-s using the shell
program, we are now ready to import the I"O& into the ,-./ system. )his is
accomplished by using an !A3/ standard program ,!EI;544. )o do this0
I E*ecute program ,!EI;544
I Enter the directory path and name of the I"O& file
I E*ecute

I 7ou should recei$e an informational message that the file was transferred
to the ALE layer
<sing transaction WE02 or WE05, display the I"O& that was created. Ensure
that its status is F.Eapplication document posted. ,emember that we had
chosen the processing option to be immediate. If we had opted for
5ac:ground processing, we would need to e*ecute program ,5"A3341 in
order to post the I"O& to the application. ;ote that the I"O& goes through
many statuses, namely F4EI"O& added, ABEI"O& ready to be passed to
application, A2EI"O& passed to application, and F.Eapplication document
posted.
As you may ha$e reali(ed by reading this section, transactional data ALE
interfaces can be configured and prototyped without much difficulty, and
within a short period of time. >owe$er, it is important to identify the business
reuirements of the interface and attempt to fit the needs with standard ALE
functionality. If gaps e*ist in !A3/+deli$ered ALE functionality, we can
o$ercome it by enhancing ALE function modules and-or I"O& e*tensions.
)hese procedures are discussed in the ne*t chapter.
<pon browsing the message types a$ailable in the ,-./ system %see
Appendi* 5 or transaction WE81', you will find that there are o$er 244 areas in
!A3/ that are supported by ALE functionality. #ost of them are for
transactional data such as the ones we prototyped in this section. )hey span
almost all the application modules in !A3/. Also, as we will learn in &hapter
F, we can create new ALE functions with a relati$ely minimal effort if need be.
As part of the high+le$el design process for ,-./ implementations, it is
important to consider the powerful and robust ALE scenarios delivered by
!A3/ in order to reduce implementation costs and efforts, and put in place a
reliable system.