0% found this document useful (0 votes)
5 views9 pages

Partner Definition

The document outlines the process for defining EDI partners and managing inbound and outbound messages using transaction WE20. It details the steps for creating partner definitions, including specifying partner types, message settings, and error notification procedures. Additionally, it provides guidance on using partner templates to streamline the configuration of multiple EDI partners.

Uploaded by

BimalKumarBarik
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
5 views9 pages

Partner Definition

The document outlines the process for defining EDI partners and managing inbound and outbound messages using transaction WE20. It details the steps for creating partner definitions, including specifying partner types, message settings, and error notification procedures. Additionally, it provides guidance on using partner templates to streamline the configuration of multiple EDI partners.

Uploaded by

BimalKumarBarik
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 9

Partner Definition

Transaction: WE20
Partner definition is where you control both inbound and outbound EDI message. You specify which
messages are allowed for which partners, which ports (WE21) are used, and when the IDocs will be
pushed outbound to your EDI Solution.

Basically, partners are defined at two levels -- partner and partner message.

At the partner level, you specify the partner, the partner type (i.e., customer), and the default business
user who will receive error tasks associated with this partner. At the partner message level, you define
all the messages you'll electronically exchange with this partner. Here you'll specify the technical ports,
message timing, the business user to notify if an error occurs for this partner and message, and other
details.

Note: This topic primarily focuses on the customer (KU) partner definition over a FILE port, so some
things may be a little different if you're setting up another partner type. Please feel free to expand this
topic, as necessary, to include helpful information.

Screen Usage
Creating a Partner
1. First determine your partner type. If your partner is a customer, select customer in the left pane. If
it's a vendor, select vendor, etc.
2. Click the new icon ( ) to create a new partner
3. Choose the partner number. If you're creating a customer partner record, for instance, this will
be the SAP customer number.
4. Tab: Post processing: permitted agent
1. If an error occurs, some business users need to be notified via workflow. Based on the
organizational hierarchy you created, choose the recipient type, recipient (and language)
where error tasks will be sent.
5. Tab: Classification
1. Partner class can be left blank. It's not used in the default system.
2. Partner status should be set to "A" for "Active" if you plan to use this partner. Otherwise,
choose "I" for "Inactive"
3. Archv means whatever you want it to mean. Just left it unchecked.
6. Tab: Telephony
1. Fill in this information if you care to; it's neither required nor necessary in the default
system.
7. Click save ( ) to create the partner.
8. Now you can create inbound and outbound partner messages

Creating an Inbound Partner Message

On the partner screen, click the new row ( ) button under the "Inbound Parameters" grid. The inbound
parameter screen is then shown:
Note: The first seven fields (the ones not on a tab) are the keys to this record. Each of these must exactly
match the incoming IDoc in order for SAP to determine the partner. See the Inbound Partner
Determination topic later in this document for more information.

1. Key Fields
1. Partner Number. Can't be altered; inherited from the partner.
2. Partner Type. Can't be altered; inherited from the partner.
3. Partner Function. Generally, this will be SP for sold-to party; although in some complex
situations you may need to use a different partner function (this is fairly rare on inbound;
however, it's more common for outbound)
4. Message Type. See section "Common Inbound Partner Message Settings" below.
5. Message Code. Leave blank (see "Notes and Tips" section below)
6. Message Function. Leave blank.
7. Test. Generally, leave this unchecked since test transactions can't be processed
inbound.
2. Tab: Inbound Options
1. Process Code. See section "Common Inbound Partner Message Settings" below.
2. Syntax Check. Check this field so that SAP syntax checks the IDoc and stops if it
encounters an error.
3. Processing by Function Module.
1. Trigger immediately: Select if you want the function module invoked
immediately to process the IDoc.
2. Trigger by background program: Select this if immediacy isn't critical, and
you'll process these IDocs according to a schedule. Note: If you select
"background," you are responsible for scheduling the inbound processing
program (RBDAPP01) to run.
3. Tab: Post-processing Permitted Agent
1. If an error occurs, some business users need to be notified via workflow. Based on the
organizational hierarchy you created, choose the recipient type, recipient (and language)
where error tasks will be sent.
2. Note: This overrides the default you defined at the partner level for this message.
4. Tab: Telephony
1. Fill in this information if you care to; it's neither required nor necessary in the default
system.

Creating an Outbound Partner Message

On the partner screen, click the new row ( ) button under the Outbound Parameters grid. The
outbound parameter screen is then shown:
1. Key Fields
1. Partner Number. Can't be altered; copied from the partner.
2. Partner Type. Can't be altered; copied from the partner.
3. Partner Function. The function (vendor, sold-to, bank, etc) the partner number above
plays with regard to this message. (for SD transactions, this is generally SP -- sold-to
party; although you can also select bill-to, ship-to, etc)
4. Message Type. See section "Common Outbound Partner Message Settings" below.
5. Message Code. Generally, leave blank.
6. Message Function. Generally, leave blank.
7. Test. Generally, leave this unchecked.
2. Tab: Outbound Options
1. Receiver Port: Select the port where SAP will drop off the outbound IDocs.
2. Packet Size: (ALE only) Sets the number of IDocs that will be sent per RFC.
3. Output Mode
1. Timing
1. Transfer IDoc Immediately: Select if you want SAP to immediately write
the IDoc to the port for receipt by the translator.
2. Collect IDocs: Select this if immediacy isn't critical, and you'll process
these IDocs according to a schedule. Note: If you select this you are
responsible for scheduling the outbound processing program
(RSEOUT00) to run.
2. Subsystem trigger (non-ALE)
1. Start Subsystem: Select if you want SAP to trigger the EDI subsystem
defined for the receiver port. Note: For this to work, the port must specify
(a) an RFC destination to start the subsystem and (b) that automatic
starting of the subsystem is possible.
2. Do not Start Subsystem: Just drop off the IDocs and let the subsystem
pick up the documents according to its own schedule.
4. Basic Type: Specifies the particular IDoc type you will send outbound (i.e., ORDERS04,
INVOIC02, etc)
5. Extension: If you have extended the IDoc type above and want to use that extension,
then specify it here.
6. View: If you have created a view to eliminate unneeded parts of the IDoc and want to use
that view, then specify it here.
7. Syntax Check: Check this to stop IDocs with syntax errors.
8. Segment release in this IDoc: By default, the system pulls the latest released segment
definitions when building outbound IDocs. Using this setting, however, you can speciy
with SAP release to use when pulling segment defintions (i.e., "46C"). To prevent
breaking EDI during a upgrade, it's a good idea to specify the current version here.
3. Tab: Message Control
1. See section "Common Outbound Partner Message Settings" below
4. Tab: Post-processing Permitted Agent
1. If an error occurs, some business users need to be notified via workflow. Based on the
organizational hierarchy you created, choose the recipient type, recipient (and language)
where error tasks will be sent.
2. Note: This overrides the default you defined at the partner level for this message.
5. Tab: Telephony
1. Fill in this information if you care to; it's neither required nor necessary in the default
system.
6. Tab: EDI Standard
1. Fill in this information if you care to; it's neither required nor necessary in the default
system.

Notes and Tips


Inbound Partner Determination
On inbound, partner determination is performed based on the IDoc control record, and these
corresponding seven key fields within each partner definition record:
1. Partner
1. Number
2. Type
3. Function
2. Message
1. Type
2. Code
3. Function
3. Test Switch

Common Inbound Partner Message Settings

Goal Type Process Code


Sales order ORDERS ORDE
Sales order change ORDCHGORDC
Invoice (MM) INVOIC INVFL or INVF
Invoice (FI) INVOIC INVF
PO Confirmation ORDRSP ORDR
Payment Advice REMADV REMA or REMC
Delivery Schedule DELINS DELI
Ship Notice DESADV DELS
Financial
FINSTA FINS
Statement

Common Outbound Partner Message Settings

Applicatio Message
Goal Type Basic Type Process Code
n Type
Delivery: Shipping
DESADV DELVRY03 V2 LALE DELV
Notification
Sales order confirmation ORDRSPORDERS04V1 BA00 SD10
Invoice INVOIC INVOIC02 V3 RDD0 SD09

Inbound Message Code Fields


The message code field, generally, is useless except for one thing.

If two different groups in your company handle sales orders for the same partner, then you can use the
message code field to differentiate them and route them to different groups if there's an error.

To do this:
1. Create two inbound partner message entries for the same partner and message type
2. On the first entry:
1. Leave the Message Code field blank
2. Select the group who will handle errors for the first set of transactions in the "Post
processing Permitted agent" tab.
3. On the second entry
1. Populate the Message Code field with a value (you can choose one)
2. Select the group who will handle errors for the second set of transactions in the "Post
processing Permitted agent" tab.
4. In your translator, specify that the mapping to the message code field is dependent on data within
the actual EDI transaction. For instance, if the BEG01=SA, leave the message code field (in the
IDoc header) blank; otherwise, populate it with the value you chose.
5. If an error occurs, now SAP will route the error to the correct group based on the rules you
specified.

Creating and Using a Partner Template


If you have several EDI partners, you'll want to ensure that they are setup in a similar fashion. Using a
template makes configuration faster, and it reduces the chance of errors.

Generally, you'll want to configure all messages possible on your partner template; then, when you create
the actual partners you only need to delete the unnecessary messages.

To setup a partner template:

1. Transaction: SPRO
2. Path: Basis Components / Basis Services / IDoc Interface - Electronic Data Interchange / Set
Default Values for Partner Profiles
3. Specify the messages and message parameters for both inbound and outbound.

To use a partner template:

1. Transaction: WE20
2. Create a new partner ( ) and enter the partner number and partner type fields.
3. Menu: Utilities -> Fast Data Entry
4. Select direction: Inbox or Outbox.
5. Select (by clicking on the gray boxes) the logical messages you want to copy. For outbound
messages, you will be prompted for the outbound port.
6. Click the green check box to copy the messages.

You might also like