Partner Profile 1.

Defining a Partner Profile Partner profiles are a prerequisite for data exchange. This involves defining who can exchange messages with the SAP system and using which port. Use The partner profile contains parameters that define the electronic interchange of data with a partner via that IDoc interface. 2. Partner Profile : t/code is WE20. This is very important configuration for establishing communication settings between 2 business partners. With whom we r exchanging information, their details we need to maintain i.e Partner Number Partner Type Partner Function Message Type Process Code Reciever port .......... These all details need to be maintainded in Partner Profile. the partner profiles are client dependent and must be configured in each client that ALE is used.

Creating an Outbound Partner Profile

Here you must enter the data manually. Alternatively, you can also transfer the default values from Customizing.
...

If you are not yet on the change screen of your desired partner, choose SAP Menu Tools IDoc Interface/ALE Administration Runtime Settings Partner Agreement (WE20).
...

1.

Position the mouse on your partner in the required partner type node. Choose the Outbound Parameter table.

in

Key Fields 2. You have already determined partner number and partner type in general partner processing. The partner function from the master data defines the addressee, that is, it is used for further classification purposes. If you have selected outbound processing under Message Control (MC), the function must be identical to the corresponding Message Control field. Otherwise, it is optional.

Partner A (customer 1110) wants to order a material from partner B (vendor 1014). Partner B is of the partner type LI (vendor) and must choose the Message Control value VD (vendor) as the partner function because orders must always be processed using Message Control. 3. Specify the business process with the logical message, within which the IDoc type is used. The logical message is described by three parameters: The message type is based on EDIFACT message types: For example, a purchase order is of type ORDERS. You can further divide the message type with the optional fields message code and message function. 4. Configure the test indicator if you want to send the message as a test.

Message, partner and test indicator are the seven key fields of the outbound partner profiles (the client comes in addition to these). Also see the graphic at the end of this section. Other Fields 5. In the Outbound options tab page, you can determine whether IDocs are forwarded immediately to the receiving system. You should ensure that your entries are compatible with the Message Control priorities, if you have chosen outbound processing under Message Control. A list of recommended combinations is provided in the section Outbound Processing Under MC: Procedure. You have already defined the Recipient port in Port definition. If a port of type TRFC is used, the Queue Processing field is visible. You can use the indicator to specify whether IDocs are to be sent with qRFC. This sending technique is only possible for recipient SAP systems as of SAP Web AS 6.20.

6. 7.

You should only set this flag if it is really necessary that the IDocs sent are received in the receiving system in the same sequence as they were sent by the sender system. Queuing can cause posting delays in the receiving system, because an IDoc in the queue cannot be posted. In this case, the following IDocs in the queue cannot be posted until the error is resolved. 8. If you have set the Queue Processing indicator, the Rule Name field, which you must then also maintain, appears as well. The rule name defines the rules for queue names. You can specify these rules in the transaction qRFC IDoc Queue Name Rules (WE85).

9.

Specify the IDoc type as the Basic type with or without extension. If you want to use a view of your IDoc type (for example, to improve the performance), specify this here. The figure below shows the m-to-n relationship between logical messages (business meaning) and IDoc types (technical format). Message 1, for example, is always assigned to one IDoc type, while message 3 is assigned to two IDoc types. IDoc type 2, in turn, is also assigned to 2 logical messages.

10.

The segment release specifies the release from which the segment definitions (not the IDoc type definition) originates. We recommend that you leave this field blank so that the most recent segment definition is used. 11. You can propose an EDI standard, version and EDI message type for the receiving system in the tab page EDI Standard. Most subsystems, however, should be able to determine these EDI settings themselves (from the logical message). 12. You can define permitted agents for cases in which exceptions occur. This entry overrides the entry in the general partner profiles. Depending on the message, therefore, the exception can be handled by different agents of the same partner. 13. You can specify whether syntax errors are to be ignored or are to lead to a processing error (Cancel Processing flag under syntax check in the tab page outbound options). For more information about exception handling and permitted agents, refer to the following section: Exception Handling 14. If your hardware supports it, create partner and message specific telephony data for outbound IDocs. For more information, see General Partner Profile.

Graphic: Outbound partner profile fields (general) Key fields are shown in gray. The values for partner, message and test indicator (and client) therefore provide a unique ID for the IDoc type in outbound processing.

http://search.sap.com/ui/#query=dbrefresh+errors&startindex=1&filter=scm_a_site(scm_v_Site11) http://scn.sap.com/thread/202339 http://learnsapbasis.blogspot.in/2011/02/listener-issues-tnsadmin-parameter.html http://sapbasis.wordpress.com/tag/print/