WF The EDI Interface - Basis
`
`The following Help Topics are available:
`
`For Help on Help, Press F1
`
`Version
`
`SAP-00000513
`
`

`
`Version
`Prepared for R/3 Release 2.2.
`May 94
`
`SAP-00000514
`
`

`
`Copyrights
`
`@1994 SAP AG. All rights reserved.
`Neither this documentation nor any part of it may be copied or reproduced in any form or by any
`means or translated into another language, without the prior consent of SAP AG.
`SAP AG makes no warranties or representations with respect to the content hereof and specifically
`disclaims any implied warranties of merchantability or fitness for any particular purpose. SAP AG
`assumes no responsibility for any errors that may appear in this document. The information
`contained in this document is subject to change without notice. SAP AG reserves the right to
`make any such changes without obligation to notify any person of such revision or changes. SAP
`AG makes no commitment to keep the information contained herein up to date.
`
`SAP-00000515
`
`

`
`The EDI interface - general description
`
`This section provides an overview of the EDI interface.
`
`SAP-00000516
`
`

`
`The EDI architecture
`EDI stands for Electronic Data Interchange, and is the electronic exchange of structured data
`between different applications. The EDI architecture consists of:
`¯ EDI-enabled applications
`They support the automatic processing of business transactions.
`¯ EDI interface
`It has been designed as an open interface. The technical and administrative aspects can
`therefore be separated from the application-specific aspects. The EDI interface consists of the
`Intermediate Document types and function modules that form the interface to the application.
`¯ EDI subsystem
`It converts the Intermediate Document types to EDI message types and vice versa. This
`element of the EDI architecture is not provided by SAP.
`The following figure displays the EDI architecture.
`
`!I
`
`MM
`(Customer)
`
`SD
`(Vendor)
`
`SAP-00000517
`
`

`
`KThe Intermediate Document type
`
`The main component of the EDI interface is the Intermediate Document type. The Intermediate
`Document type is an SAP standard that determines the structure and the format of the data for
`electronic transmission. It was developed taking into account format and value set of the fields
`from the SAP applications and from the data element directories of the EDIFACT and ANSI X12
`standards. There are different Intermediate Document types. Each Intermediate Document type
`represents a series of related business documents.
`An Intermediate Document type is:
`¯ partner-independent
`¯
`identical for inbound and outbound processing
`¯ depends only on the message types
`¯
`independent of EDI standards
`¯
`independent of subsets
`
`EDI message
`ORDERSa J ~nte ~j,,~t I Purchase°rderw
`
`rmediate Document tyo,°
`
`ORDCHG c
`
`SAP document
`
`Order confirmation y I
`
`I ouo,o,,oo
`
`EDI SUBSYSTEM
`
`EDI INTERFACE
`
`APPLICATION
`
`An Intermediate Document type comprises the following three record types:
`¯
`control record
`¯ data records
`¯
`status records
`The control record is the same for all Intermediate Document types. The field contents of a
`control record uniquely identify an Intermediate Document. An Intermediate Document is an
`Intermediate Document type which has been filled with data.
`The data records consist of a key part and the data part or segment. The key part contains
`information that uniquely identifies a segment - for example, assignment to an Intermediate
`Document, segment name, segment number, hierarchy level, etc. The field contents of the
`segment are the data from the SAP application (such as purchase order or order confirmation).
`The data records that contain the application data differ for the individual Intermediate Document
`types.
`The status records form a history of the individual states an Intermediate Document passes
`through before the data is made available to the respective application or passed on to the trading
`partner via the EDI subsystem.
`
`SAP-00000518
`
`

`
`APPLICATION
`
`INTERMEDIATE DOC.TYPE
`I Control record
`III Data ricord
`
`Key part Segment
`
`An Intermediate Document contains the data from an SAP document (for example, from a purchase
`order) and - if necessary - derived data. The derived data is read from other areas (for example,
`master data). An example of an Intermediate Document can be found in the Appendix.
`The number of available Intermediate Document types depends on the release. The following
`Intermediate Document types are offered in Release 2.1:
`purchase order
`¯ ORD_ID01
`order change
`order confirmation
`quotation
`request for quotation
`¯
`invoice
`INV ID01
`For additional information about the Intermediate Document type, please refer to WF - EDI
`Intermediate Document.
`
`SAP-00000519
`
`

`
`EDI subsystem: requirements
`
`The EDI interface manages all aspects involved in converting application data to an Intermediate
`Document (SAP standard) and vice versa.
`The technical aspects - those aspects involving EDI technology and EDI standards - are handled by
`the EDI subsystem. With regard to the applications which are to be supported, the following is
`required from the EDI subsystem.
`Functionality
`¯ Mapping
`The conversion of Intermediate Documents to EDI messages and vice versa is performed by the
`EDI subsystem. The mapping of Intermediate Document fields onto data elements of the EDI
`messages is managed there.
`¯ Syntax check
`The EDI subsystem is responsible for the syntactic correctness of generated and received data.
`¯ Generating standard-specific envelopes
`Formatting of the data for transmission is carried out by the EDI subsystem. The data is sorted
`and provided with "envelopes" and "addresses", which ensures that the transmission conforms
`to defined standards.
`Partner-specific processing and code conversion
`The EDI subsystem supports partner-specific adaptations and code conversions that are
`required during translation of the structures.
`Interchange and Functional Acknowledgement
`The EDI subsystem generates and sends Functional Acknowledgements for received
`messages, and processes received Functional Acknowledgements and links them with the
`transmitted messages. Administration (monitoring) of the Functional Acknowledgements is
`also performed by the EDI subsystem.
`¯ Retransmission
`The identical repetition of a complete interchange and selective repetition of individual EDI
`messages is controlled by the EDI subsystem; the information is forwarded to the EDI interface
`via status records.
`¯ Status control and report
`The monitoring of the success or failure of the conversion and transmission of EDI messages
`and received acknowledgements is managed by the EDI subsystem.
`¯ Archiving
`The EDI subsystem manages the archiving of original EDI messages and interchange files. In
`particular, the EDI subsystem must fulfill the legal requirements regarding security and retention
`times, which differ in the individual countries.
`¯ Partner profile
`The EDI subsystem manages all agreements, which are involved in conversion and
`communication, in partner profiles.
`External communication
`The EDI subsystem is responsible for physically transmitting the EDI messages.
`
`¯
`
`SAP-00000520
`
`

`
`¯ Support of real-time EDI
`¯ File transfer
`Interchange must either take place via NFS (Network File System), or the EDI subsystem must
`be running on the same computer as the SAP System.
`Service
`¯ Consulting in all matters involving EDI and the EDI subsystem
`¯ Training on the EDI subsystem
`¯ Hotline support for problems occurring in EDI processing
`The suppliers of the EDI subsystems are responsible for providing the above services.
`
`SAP-00000521
`
`

`
`The data flow in outbound processing
`
`This section will introduce the path that the data takes - from document entry in the application, via
`the message default from Message Control to its transfer to the EDI subsystem as an Intermediate
`Document.
`Message Control plays an important role during outbound processing. It offers interfaces to all
`available output media and enables automatic message dispatch.
`The role of the Message Control record during the electronic transmission of a document is also
`described.
`
`SAP application
`
`Purchase order
`
`l
`
`Message Control ]
`
`Message Control
`record
`
`EDI interface
`
`Intermediate
`Document
`
`I EDI subsystem I
`
`SAP-00000522
`
`

`
`KMessage Control
`
`In the purchasing and sales systems, outbound messages are handled by a Message Control
`record. This log record is created under certain conditions; these are either derived from the
`master data of the respective application system or can be set by Message Control.
`In the following, we assume that the message default is determined by Message Control.
`A!terrlatj~es [Qr ~be r~essaqe defau!t describes how to set the message default using the master
`data from MM and SD.
`
`The task of Message Control
`
`The "Message Control" module controls how many documents of a certain type are output when
`and via which media. In this context, the two terms "message" and "output type" will be used with
`the meanings listed below:
`Message (output)
`Contents of the document (e.g. order confirmation, invoice, dunning notice)
`Output type
`Output media (e.g. printer, fax, EDI)
`
`Data flow in condition evaluation
`
`Message Control is a service program for other applications. The programs used to format and
`dispatch messages are managed in tables. The conditions determining when messages are sent
`are often very complex and, in addition, depend on the individual customer situation. To formulate
`these conditions, Message Control uses the condition technique.
`Generally, this involves defining a series of data constellations (conditions) which cause specific
`actions (for example, EDI dispatch of an order confirmation) if they match the current application
`data.
`
`SAP-00000523
`
`

`
`SAP application
`Application object
`
`Communication
`structures
`
`is
`assigned
`to
`
`~calls
`
`transfers data
`
`I I
`
`Condition evaluation
`
`~writes
`
`Message status
`
`Condition componentI
`
`checks
`processes
`
`IC°nditi°n II
`
`table I J
`
`I
`
`processed ~assigned status
`
`Message processing
`
`~starts
`
`Processing program I
`
`!!~\\
`
`EDI Fax Mail Telex CPIC ...
`
`¯ .. Print
`
`The condition components have the following hierarchical structure:
`
`SAP-00000524
`
`

`
`Application
`
`Scheme
`
`Condition type
`
`Access sequence
`
`ICustomer order I
`
`management
`
`/l~l~i~Q~°tati°n ’ ’ ’ 1
`
`I Or0er l--t--
`__l
`i °r°°r !
`/!\
`I ooo I
`
`confirmation ~
`
`Access to
`condition table
`
`001
`
`x Sales organization
`x Customer number
`
`x Sales organization
`
`The condition technique is represented by a hierarchy of condition components.
`Scheme
`A list of messages (for example, RFQ messages, order messages) for which the conditions
`determining a dispatch are checked simultaneously. Condition evaluation is always applied
`within a scheme. The name of the scheme is defined in the application, not its contents: they
`are determined dynamically. The subsystem always processes all the condition types in a
`scheme.
`Note
`Which scheme is valid at which time is managed by the business applications.
`Condition type
`The respective message for which a partner and an output medium are to be determined and
`the contents defined (for example, BA00 order confirmation, AF00 request for quotation, AN00
`quotation).
`Access sequence
`The search strategy the system uses to determine valid default values for the respective
`message. It determines which application data is used to access one or more condition tables.
`Condition table
`It contains the respective data constellations for which a message default (for example, dispatch
`of the order confirmation X via EDI) is triggered in cases where access was successful using the
`keys defined via the access sequence.
`
`SAP-00000525
`
`

`
`KCondition evaluation strategies
`
`If a business application transfers a scheme to Message Control for condition evaluation, all the
`condition types of the scheme are processed. In the example shown in the above figure
`"Hierarchy of the condition components", these are the condition types "order confirmation" and
`"internal mail" in the scheme "order".
`Each condition type in the scheme can be assigned a condition. This condition is formulated as an
`ABAP/4 code. The value of the system return code at the end of the condition determines whether
`or not condition tables are accessed for this message. If the result is negative, processing in the
`scheme is continued.
`In the condition evaluation of a condition type, its access sequence is processed. All condition
`tables of this access sequence are accessed sequentially.
`In the example in the above figure "Hierarchy of the condition components", there are two condition
`tables (001 and 002) for the access sequence 0001 and therefore for the message "order
`confirmation".
`Access to the condition tables within an access sequence can be assigned a condition. This
`condition is formulated as an ABAP/4 code. The value of the system return code at the end of the
`condition determines whether the table is accessed. If the result is negative, processing in the
`access sequence is continued.
`In the example in the above figure "Hierarchy of the condition components", no conditions are
`provided for condition types or table accesses.
`The access sequence of the order confirmation refers, in sequence, to the tables listed below, with
`the appropriate keys:
`Table Key
`
`Condition table 001
`
`Sales organization
`Customer number
`
`Condition table 002
`
`Sales organization
`
`All value pairs sales organization/customer number, for which a particular order confirmation is to
`be sent, can now be maintained in condition table 001.
`Example of condition table 001
`Sales Customer Partner
`organi- number
`function
`zation
`
`Language Trans-
`mission
`time
`
`Output
`type
`
`0001
`
`Company1 Sold-to
`party
`
`0001 Company2 Sold-to
`party
`
`2 Fax
`
`German
`
`Immed.
`
`6 EDI
`
`German Night
`
`General definitions can be made in condition table 002 for order confirmations in sales
`organizations.
`Example of condition table 002
`
`SAP-00000526
`
`

`
`Sales Partner
`organi- function
`zation
`
`0001
`
`0002
`
`Sold-to
`party
`
`Sold-to
`party
`
`Output
`type
`
`Language Transmission
`time
`
`1 Print
`
`English
`
`Immed.
`
`1 Print
`
`English
`
`Immed.
`
`Note
`Access to a condition table within an access sequence can have an exit criterion, which determines
`whether condition evaluation should be ended within the access sequence after the first successful
`access to a record for a condition type (exclusive) or whether the search should be continued
`(inclusive).
`
`"Exclusive access sequence" strategy
`
`If you define an exit criterion, this signifies the following (based on the example in the above figure
`"Hierarchy of the condition components"):
`In sales organizations 0001 and 0002, an order confirmation is normally printed immediately in
`English upon order entry, and addressed to the sold-to party. If, however, the sold-to party in
`sales organization 0001 is "company 1", order entry will cause the order confirmation to be faxed in
`German, and not printed. If the sold-to party in sales organization 0001 is "company 2", the order
`confirmation will be dispatched per EDI, with German text, and not printed.
`In the process, condition table 001 is evaluated before condition table 002.
`
`"Inclusive access sequence" strategy
`
`If this exit criterion has not been defined, this has the following effect in the example in the above
`figure "Hierarchy of the condition components":
`In sales organizations 0001 and 0002, the order confirmation is normally printed immediately in
`English upon order entry, and addressed to the sold-to party. If, however, the sold-to party in
`sales organization 0001 is "company 1", a fax is also sent in German. If the sold-to party is
`"company 2", an order confirmation is also sent via EDI the following night in German.
`Caution
`Documents of a condition type for an object can be processed several times if you leave out the
`exit criterion in the access sequence. The documents must be distinguished by the Message
`Control record key.
`Documents of the same condition type, which are to be dispatched at the same time, must be
`distinguished by at least one of the following attributes:
`- Partner function
`- Partner number
`-
`Language
`The "inclusive access sequence" strategy arrives at the above result because the Message Control
`records that were found are distinguished by language.
`
`"Scheme" (inclusive) strategy
`
`If messages are to be sent for an object which are not distinguished by partner function, partner
`
`SAP-00000527
`
`

`
`number, or language, different condition types must be used in Message Control to implement this.
`For example, if a sold-to party is to receive an order confirmation both in printed form as well as via
`EDI, this means that a message for an object (a customer order) is to be sent to a specific partner,
`in a specific language, but using different methods.
`Message Control, and therefore the condition technique, require different condition types to
`represent this situation. They are linked in the scheme. It is not possible to specify an exit
`criterion. In order to represent the EDI and print dispatch, it is possible to define the condition
`components shown in the figure below.
`
`management
`
`ICustomer order I
`/\
`I OrOer I
`
`Application
`
`Scheme
`
`Condition type
`
`Access sequence
`
`condition table
`
`confirmation
`EDI
`
`Order I
`confirmation
`Print
`
`/ /
`
`~ ~
`
`I Order
`i 0oo,i i oo0~ i
`. xSa,e or an,za ,on I
`I
`I× Sales organization
`
`x Sales organization
`× Customer number
`
`× Customer number
`
`In the example, the sold-to party "company 3", for which interchange via EDI was defined, should
`now receive the order confirmation via EDI. In the initial phase, however, the order confirmation is
`also to be printed and sent by mail. The following condition record is therefore created for the
`condition type "order confirmation EDI":
`Example of condition table EDI
`Sales Customer Partner
`organi- number
`function
`zation
`
`Output
`type
`
`Language
`
`0001 Company3 Sold-to
`party
`
`EDI
`
`English
`
`SAP-00000528
`
`

`
`The following condition record is defined additionally for the condition type "order confirmation
`print":
`Example of condition table print
`Sales Customer Partner
`organi- number
`function
`zation
`
`Output
`type
`
`Language
`
`0001 Company3 Sold-to
`party
`
`Print
`
`English
`
`Once the test phase with the sold-to party "company 3" has been completed, the condition record
`can be deleted. Communication now takes place via EDI.
`
`SAP-00000529
`
`

`
`Dispatching data via the EDI interface
`
`Before you start
`
`To be able to dispatch messages via the EDI interface, you must have maintained the following
`areas:
`Connected the EDI interface with an EDI subsystem
`A description of how the two systems can be linked is contained in WF - EDI Intermediate
`Document.
`The port description
`Here you describe the characteristics of the EDI subsystem that is connected to the SAP
`System. For more information, refer to Port description.
`The partner profile for outbound messages
`In the partner profile for outbound messages, you define which documents you want to
`exchange as EDI messages with which trading partner. This is described in detail in Defining=__.
`~rofile for outbound messa~.
`The message default
`In MM Customizing, you can define whether you want to use a standardized message default or
`a message default from Message Control.
`In SD Customizing, you can define whether a message default is taken from the customer
`master record or from Message Control.
`This is described in detail in A!~ernatiyes ~Qr th~ message ~lefau!t.
`¯ Program RSNAST00 must be set and scheduled.
`Note
`Partners that you have defined in the partner profiles will not be sent documents via EDI until you
`have maintained the condition table. There are two ways to activate a partner profile:
`First maintain the partner profile and then the
`condition table. All partners are activated when
`the condition table is maintained.
`First maintain the condition table and then the
`partner profile, thus activating the partners
`one after the other.
`
`Timing
`
`There are three areas in which you can determine the timing of the Electronic Data Interchange:
`¯
`in Message Control, via the dispatch time
`¯
`in the partner profile of the EDI interface via the output mode
`¯
`in the EDI subsystem
`In Message Control, you can specify the following times in the appropriate condition tables:
`1 Dispatch during next selection run
`2 Dispatch at specified time
`3 Explicit request
`
`SAP-00000530
`
`

`
`4 Immediately
`In the partner profile, you can specify which mode is to be used to process the Intermediate
`Documents:
`1 A single Intermediate Document is written to an outbound file, and the EDI subsystem is started.
`2 A single Intermediate Document is written to an outbound file, and the EDI subsystem runs
`according to its schedule.
`3 Several Intermediate Documents are written to an outbound file, and the EDI subsystem is
`started.
`4 Several Intermediate Documents are written to an outbound file, and the EDI subsystem runs
`according to its schedule.
`For output mode 2 and 4, you must define a schedule for the EDI subsystem.
`Note
`Only output modes 1 and 3 ensure that control of the data passes from the SAP System to the EDI
`subsystem at the precise time defined.
`The priorities, modes, and schedules of these three areas are maintained independently. This
`means that checks are not performed by one area on either of the other two.
`The following table suggests ways of coordinating the times in the three areas:
`Strategy for dispatching data
`Application Message Control EDI interface EDI subsystem
`
`Save
`Save
`Save
`Save
`Save
`
`Priority = 4
`Priority = 4
`Priority = 1
`Priority = 1
`Priority = 1
`
`Out3ut mode = 1
`Out3ut mode = 2
`Out3ut mode = 1
`Out3ut mode = 3
`Out3ut mode = 4
`
`Real-time
`Fast batch
`Fast batch
`Batch
`Batch
`
`Note
`Please ensure that the priorities, modes, and schedules in these three areas are appropriately
`coordinated for the strategy you use for dispatching documents.
`
`Dispatching a purchase order via the EDI interface
`
`Trading partner A enters a purchase order that he wants to dispatch to trading partner B.
`Depending on the setting in Message Control, it is called immediately from the update task or
`according to the schedule for condition evaluation.
`Message Control finds the program for message preparation in table TNAPR. The program
`RSNASTED contains the subroutine EDI_PROCESSING EDI. The EDI interface program
`RSNASTED is called for each message which is to be prepared.
`RSNASTED reads the partner profile, determines the process type for the document data, and calls
`the selection module of the application. This module selects the application data for the process
`type determined and generates an Intermediate Document. RSNASTED then generates links
`between the objects created during processing:
`¯ SAP document (purchase order)
`¯ Message Control record
`
`SAP-00000531
`
`

`
`¯
`
`Intermediate Document
`
`Application I
`
`RSNAST00
`
`!
`
`RSNASTED
`
`R~°Nd;s’T+2 I I ME D I I R;doJT40
`
`1 1
`
`EDI subsystem I
`
`The Intermediate Document is assigned the processing status "Intermediate Document created".
`The Intermediate Document is now located in the SAP data base, and is thus available in the SAP
`System for information purposes and for support in case of exception handling. The Intermediate
`Document is then written to a file - either by itself or with other Intermediate Documents -
`depending on the output mode selected. The name and the directory of the file or the name of a
`function module that forms the name and directory dynamically has already been entered in the
`
`The subsequent processing steps now take place, depending on the output mode you have
`selected in the partner profile. For output mode 1 or 2, program RSNASTED passes the
`documents on individually. In output modes 3 and 4, several documents are passed on together
`by program RSEOUT00, according to the selection criteria.
`Note
`Program RSEOUT00 must therefore be scheduled with the selection criteria. Examples of
`selection criteria are receiver and EDI subsystem.
`
`SAP-00000532
`
`

`
`Active programs during the transfer
`Single transfer
`
`Collective transfer
`
`Start EDIOutput mode = 1 Output mode = 3
`subsystem RSNASTED RSEOUT00
`
`Schedule for
`EDI subsystem
`
`Output mode = 2
`RSNASTED RSEOUT00
`
`Output mode = 4
`
`The EDI subsystem later sends status messages in a file to the EDI interface; the Intermediate
`Document number is used to identify it. The EDI subsystem determines the time it returns the
`status messages. Every status record must contain the Intermediate Document number referred
`to by the status record. In this way, the link can be created to the Intermediate Document and the
`application document in the EDI interface.
`
`Error handling
`
`If an error occurs during processing of the outbound data, the person responsible is informed via
`SAPmail. This also applies when an error occurs during the transfer of status records from the
`EDI subsystem.
`If the status records were transferred successfully but contain an error status, the person
`responsible is also informed via SAPmail.
`The EDI interface takes the name of the person responsible for exception situations from the
`partner profile. If it is not possible to read the partner profile, the name of the person responsible is
`determined from the process type assigned to the outbound processing for this partner and
`message type.
`The first case (exception situation during transfer of application data) should be processed by the
`person responsible. The information about the trading partner (partner profile) and the document
`are the decisive factors for processing the situation.
`The second case (exception situation during transfer of the status records) indicates a technical
`problem that should be processed by a system administrator. The administrator responsible
`should be entered for the process type (see ~s _t_y.p_es p;f_.
`outbound messages).
`
`SAP-00000533
`
`

`
`The data flow in inbound processing
`
`This section describes the path taken by the data, which the EDI subsystem transfers as
`Intermediate Documents to the EDI interface, until it becomes available in the appropriate
`application.
`Workflow Management plays an important role during inbound processing. Rules are used to
`control the flow of business processes and flexibly support the path to the application.
`The role of Workflow Management during inbound processing will be explained.
`
`EDI subsystem J
`
`Intermediate
`Document
`
`EDI interface
`
`~m
`
`Intermediate Document
`+ process
`
`Workflow ManagementI
`
`SAP document
`
`I SAP application
`
`LiQks.in.ED.I..iQb.o.und.p.r.o..c.~.s.sJQg
`Re..c.e.i.v.J~g.d.at a..yia.t b.e..E DH nt .e.d.~c.e.
`
`SAP-00000534
`
`

`
`KWorkflow Management
`
`Workflow Management is used for automatic control and monitoring of business processes of all
`types. It closes the gap in control between the transfer of inbound documents to the SAP System
`and their subsequent posting in one of the applications. It supports the definition of rules that
`enable you to design user interaction to suit your specific needs. It represents the basis for
`automatic EDI inbound processing by allowing exception situations to be handled flexibly and
`quickly, taking advantage of user experience.
`Various process types are supported in the standard SAP System. The process type defines the
`rules according to which a business process is to be handled, and also takes branches and loops
`into account. A network describing the business process is created.
`
`Each inbound message is assigned a process type in the EDI interface.
`A process is an object with a static and a dynamic aspect. The data structures of the process
`represent the static aspect, while the behavior of the process, its transitions, forms the dynamic
`aspect.
`A process consists of the following parts:
`¯ Control record
`The control record identifies a process x, and contains, for example, the process number, the
`process type, the current status, and the name of the person responsible.
`¯ Activity
`A process is linked to various activities that lead to subsequent processing. Some of these
`activities trigger user interaction via SAPmail.
`¯ Status log
`Every status that the process passes through during processing is logged and retained in the
`process.
`¯ Object linking
`A process is always linked to all the objects that are created during processing. As such,
`flexible navigation between all objects involved is possible via the process.
`
`SAP-00000535
`
`

`
`I
`II
`I’
`
`I
`
`I
`
`Process object
`
`Control record I
`
`Activity
`
`Status log
`
`Object linking
`
`Mail to
`user X
`
`Message Control record J
`SAP document
`I
`EDI Intermediate Document J--
`
`From the initial state, a process passes through various states before it reaches the final state. An
`activity is performed in each state. The result of this determines the transition or subsequent state.
`The sequence of activities leads to the final state, therefore completing the process.
`
`SAP-00000536
`
`

`
`KLinks in EDI inbound processing
`
`All objects are linked via the process. A user can therefore use the object currently being
`accessed to reach the process. All other objects (the Intermediate Document, for example) can
`then be accessed from the process.
`The link structure
`Process - 1
`
`Interm. Doc. 243
`
`Process-1
`
`Order 45000097
`
`The objects are divided into object types, according to their contents and supporting functions.
`The object type therefore specifies the area in the data base and the access method for an object.
`For example, the following object types are supported for the standard EDI interface:
`¯ Object type Message Control record
`NASTOBJ
`(outbound only)
`IDOC
`VBAK
`EKKO
`VBRK
`FILENAME_U
`(for technical
`errors)
`
`¯ Object type Intermediate Document
`¯ Object type sales document
`¯ Object type purchasing document
`¯ Object type invoice
`¯ Object type path name
`(directory and file)
`
`SAP-00000537
`
`

`
`Receiving data via the EDI interface
`
`Before you start
`
`To be able to receive messages via the EDI interface, you must have maintained the following
`areas:
`¯ Connected the SAP EDI interface with an EDI subsystem
`A description of this is contained in WF - EDI Intermediate Document.
`¯ The Po~_description
`Here you describe the characteristics of the EDI subsystem that is connected to the SAP
`System. For more information, refer to Port description.
`¯ The partner profile for inbound messages
`In the partner profile for inbound messages, you define which documents you want to receive as
`EDI messages from which trading partner. This is described in detail in Creatinq._a.partner
`profile for inbound messa~.
`¯ Settings for Workflow Management
`Process types for EDI inbound processing are delivered with the EDI interface as default
`settings. Each process type must be assigned a responsible person who should be informed in
`case of error. In addition, Workflow Management must be scheduled as a job. This can be
`done as follows via the SAP initial menu:
`
`Tools -~ Administration
`
`Administration -~ Process technology
`
`Process control --~ Queue.
`An exact description is contained in .Se~.inq Workflow Manactement_.
`
`Process types for inbound messages
`
`The following process types exist for inbound documents. The name of a person responsible, who
`will be notified in case of error, must be entered in Workflow Management for these process types.
`This person will be contacted by Workflow Management if a responsible person cannot be
`determined from the partner profile.
`EDI INPUT
`A process of this type is generated for every inbound document. The process is specified further
`in the EDI interface during the course of processing.
`SD_REQOTE
`Request for quotation
`SD ORDERS
`Order
`ME ORDRSP
`Order confirmation
`EDI INPMAN
`A process of this type is generated for the inbound processing of message types whose automatic
`
`SAP-00000538
`
`

`
`processing is not yet supported. The Intermediate Document is saved and sent to the person
`responsible via SAPmail.
`EDI INPPRC
`A process of this type is generated when an error occurs during processing of the inbound file, or if
`an error occurred when reading the Intermediate Document, such that the Intermediate Document
`can only be created without a check.
`The system then branches to a process of type EDI_ERROR.
`EDI ERROR
`Error process
`
`Data flow
`
`The EDI subsystem writes the data as Intermediate Documents, in Intermediate Document format,
`to an inbound file.
`The EDI subsystem triggers the SAP System, and transfers the directory and name of the file
`containing the data. The EDI interface is activated. (Program RSEINB00 is called.) This
`program first reads the control record of the first Intermediate Document. It then checks whether
`an EDI partner profile exists for the partner who is listed as sender in the control record.
`After the control record is read, the data records of the Intermediate Document are read and written
`to the SAP data base. A process of type EDI_INPUT is then immediately generated and tranferred
`to Workflow Management.
`
`E