Create Trading Partners

You can create and manage trading partners. A trading partner is the external business entity with which your company interacts to send or receive business documents, such as orders and invoices, in electronic form.

Trading partner concepts are provided. See Trading Partners.

  1. To create a trading partner in a project.
    1. In the navigation pane, click Projects.
    2. Click the project in which to create the trading partners.
    3. Click B2B B2B icon.
    4. In the Trading partners section, click Add.
  2. To create a trading partner in a standalone environment.
    1. In the navigation pane, click B2B, then Trading partners.

      The Trading partners page is displayed. The Usage column shows the number of agreements associated with the trading partner. Click the entry to show the number of inbound and outbound agreements for that trading partner.


      The Trading partners page shows columns for Name, Usage, and Last updated. Import and Create buttons appear in the upper right corner.

    2. Click Create.
  3. Enter the trading partner name and an optional description. The Identifier field is automatically populated with the name you enter. The values for both must be unique.

    Note:

    The identifier cannot be changed after creation.
  4. Create.

    A details panel is displayed that enables you to configure additional information about the newly created trading partner.

See the following sections:

View Properties

  1. Click Properties to view the same information you entered when you created the new trading partner. Both the name and identifier of a trading partner must be unique across all trading partners.


    The Properties, Contacts, B2B Identifiers, and Transports & Agreements tabs appear at the top. Below are the Name and Description fields. In the upper right is the Save button.

  2. If needed, change the name of the trading partner.

    The trading partner name can be changed at any time. There are valid scenarios for renaming an actively-used trading partner. In the real world, companies change their names, have mergers and acquisitions, sell business units, and so on. You need the ability to reflect the new name here.

    Implications of renaming an active trading partner:

    The trading partner's name is displayed in a column of the Track B2B messages page for messages received from or sent to this trading partner. If you change the name of an actively-used trading partner with one or more runtime messages processed, then any existing messages on the Track B2B messages page still show the old name of the trading partner prior to the renaming. Any new runtime messages record the new name of the trading partner. While this is intentionally done for auditing purposes, when you filter messages by a trading partner, it shows all messages (both old and new) for that trading partner correctly. Old messages show the old name and new messages show the new name.

Select Contacts

You can add ways to contact the trading partner, such as their name, email, phone number, or short message service (SMS) number. The Contact type and Value fields are both free text fields. This enables you to enter custom text. Use this information to contact individuals offline, as needed. The Contacts field is currently provided only for reference and is not used in B2B for Oracle Integration.

  1. Click Contacts.
  2. From the Contact type list, select a method for contacting the trading partner, such as their name, email, phone number, or SMS number. Use this information to contact individuals offline as needed, and not from within B2B for Oracle Integration.
  3. Add a corresponding value, then click Save.


    The Properties, Contacts, B2B Identifiers, and Transports & Agreements tabs appear at the top. Below are the Add Contacts icon, Contact Type list, and Value field. In the upper right is the Save button.

Define B2B Identifiers

You collect identifying information from your external trading partner and enter it on their behalf in the B2B identifiers section. This is very similar, in concept, to the identifiers specified under B2B, then Host profile, and then Identifiers. In a message exchange, the host's identifiers and trading partner's identifiers are used in the role of a sender or receiver, depending on the message direction.

Direction Sender Receiver
Inbound message

Trading Partner

(The trading partner's identifiers are used as Sender ID or From Party.)

Your company (that is, the host)

(Host identifiers are used as Receiver ID or To Party.)

Outbound message

Your Company (that is, the host)

(Host identifiers are used as Sender ID or From Party.)

Trading Partner

(The trading partner's identifiers are used as Receiver ID or To Party.)

B2B identifiers defined here are used in two places:
  • Transports
  • Outbound agreements
Understand the following details about how the identifier is used.
  • The following table lists where each type of identifier is used and its purpose.
    Identifier Type Where Used Purpose Value Restrictions
    Application Partner ID Implicitly used by all outbound agreements (** See the note at the bottom of the table.) Optionally used as an alternate way to specify which trading partner to which to route an outbound message.

    For an outbound message, you can specify either a Trading Partner ID or an Application Partner ID for trading partner identification. See Create Backend Integrations for more details on this usage.

    		N/A
    AS2 Identifier Trading partners, then Transports & agreements, then AS2, then AS2 identifiers, and then Partner's identifier

    Mandatory only when the AS2 transport protocol is used.

    This identifier type is not used for the FTP transport protocol.

    For an outbound message, this value is inserted as the AS2-To HTTP header of the AS2 message.

    For an inbound message, this value is used for validation against the AS2-From header of the incoming message.

    Up to 128 printable ASCII characters except double quotes or backslashes. It can be any value agreed upon with the trading partner as a value with which you can identify the trading partner.

    The value is case sensitive.
    EDI Interchange ID Trading Partner, then Outbound agreements, then Select trading partner identifiers

    Also used implicitly for all inbound agreements (** see the note)

    Mandatory for all EDI data formats. This identifier is used as either the Interchange Sender or Receiver ID field of the interchange envelope (ISA segment for X12, and UNB segment for EDIFACT).

    For an outbound message, this value is inserted as the Interchange Receiver ID.

    For an inbound message, this identifier is used as the Interchange Sender ID to identity a trading partner as a sender of a message. If the EDI Interchange ID on its own does not uniquely identify a trading partner, it is used in combination with the EDI Group ID to locate a unique trading partner.

    Up to 15 characters for X12.

    Up to 35 characters for EDIFACT.

    The value is case-sensitive and must not contain any of the delimiter characters.
    EDI Interchange ID Qualifier Same as above.

    Mandatory for X12 and optional for EDIFACT. This identifier is used as the Interchange Sender or Receiver ID Qualifier field of the interchange envelope of the EDI payload.

    It is a code to indicate the category of the value specified in the EDI Interchange ID (for example, DUNS number, IATA number, and so on).

    For an outbound message, this value is inserted as the Interchange Receiver ID Qualifier.

    For an inbound message, the value is not currently used (if it were used, it would be treated as the Interchange Sender ID Qualifier).

    Must be exactly two characters for X12. The value must be from an X12 code list. See EDI Standards Reference. A generic sample value for X12 is ZZ.

    Up to four characters for EDIFACT. The value must be from an EDIFACT code list (https://www.gefeg.com/jswg/cl/v3/11b/cl3.htm). A generic sample value for EDIFACT is ZZZ.

    The value is case sensitive and must not contain any delimiter characters.
    EDI Interchange Internal ID Same as above. Only used for EDIFACT, and in that too, it is optional.

    EDIFACT defines this field as an identification (for example, a division, branch or computer system/process) specified by the sender of the interchange to be included if agreed by the recipient in response interchanges to facilitate internal routing.

    For an outbound message, this value is inserted as the EDI Interchange Internal ID field in the EDIFACT UNB envelope.

    For an inbound message, this value is not used.

    Up to 35 characters for EDIFACT.

    The value is case sensitive and must not contain any delimiter characters.
    EDI Interchange Internal Sub ID Same as above.

    Only used for EDIFACT syntax version 4. In that, it is also optional.

    EDIFACT defines this field as the sublevel of sender internal identification when further sublevel identification is required.

    For an outbound message, this value is inserted as the EDI Interchange Internal Sub ID field in the EDIFACT UNB envelope, only if the message follows the Syntax Version 4 (which is the default).

    For an inbound message, this value is not used.

    Up to 35 characters for EDIFACT.

    The value is case sensitive and must not contain any of the delimiter characters.
    EDI Group ID Same as above.

    This is mandatory for X12 and optional for EDIFACT.

    EDIFACT defines this field as an identification of the sender's division, department, and so on from which a group of messages is sent.

    X12 has a similar definition.

    For an outbound X12 message, this value is inserted in the GS segment as the Application Receiver's Code.

    For an outbound EDIFACT message, this value is inserted in the UNG segment as the Receiver's Identification (a UNG is only generated when this identifier is selected in an outbound agreement; otherwise, not).

    For an inbound message, this value is used only in case the EDI Interchange ID, on its own, is not enough to uniquely identify a trading partner. In that case, a combination of the EDI Interchange ID and the EDI Group ID is used to locate a unique trading partner.

    Minimum of two characters and up to 15 characters for X12.

    Up to 35 characters for EDIFACT.

    The value is case sensitive and must not contain any delimiter characters.
    EDI Group ID Qualifier Same as above. Only used for EDIFACT. In that, it is optional.

    It is a code to indicate the category of the value specified in the EDI Group ID (for example, DUNS number, IATA number, and so on).

    Only used for an outbound message, to insert as EDI Group ID Qualifier, if specified.

    Up to four characters for EDIFACT. The value must be from an EDIFACT code list (https://www.gefeg.com/jswg/cl/v3/11b/cl3.htm). A generic sample value is ZZZ.

    The value is case sensitive and must not contain any delimiter characters.
    DUNS Same as above.

    Only used for RosettaNet.

    		A nine digit, numerical value.
    LocationID Same as above. This is a free text field and used to populate the Service Header if it is provided. Free text field.
    Name Same as above. This identifier is used in the Partner’s identifier and Host identifier fields when defining the transport. For example:
    • Partner’s identifier: Used as the Responder Party ID for outbound messages and as the expected Initiator Party ID for inbound messages. The identifier type is used as the Party ID type.
    • Host identifier: Used as the Initiator Party ID for outbound messages and as the expected Responder Party ID for inbound messages. The identifier type is used as the Party ID type.
    		Free text field.
    Role Same as above. This identifier is used to populate the Initiator/Responder role fields in the AS4 message. Free text field.

    Note:

    ** An implicit usage means you don't explicitly select the identifier in an inbound or outbound agreement. Instead, when you deploy an agreement, the identifier is automatically used in the runtime processing.
  • Used B2B identifiers are protected:

    You cannot delete trading partner's B2B identifiers that are explicitly referenced in transports or agreements. The associations must be removed from the transports or agreements before you can delete an identifier from the trading partner's B2B identifiers section.

  • Multiple identifiers of the same type:

    The concept is similar to defining multiple identifiers in the host profile.

    You may add multiple B2B identifiers of the same identifier type. For example, you may want to add identifiers based on X12, X12 HIPAA, EDIFACT, or RosettaNet usage, based on business units within the trading partner, or based on an environment such as development, test, production, and so on. The combination of identifier type and value must be unique. This validation is enforced in the user interface.

    Even though you may define multiple identifiers of the same type, in outbound agreements, you must select specific unique types so that B2B knows exactly which identifiers to insert in an outbound message without ambiguity.

  • Updating values and applying changes to runtime:
    You can update existing trading partner's B2B identifier values at any time. However, they are not used in runtime B2B processing, until:
    • Each transport where an identifier value was referenced is redeployed.
    • Each outbound agreement where an identifier value was referenced is redeployed.
    • For B2B identifiers that are implicitly used, any of the agreements is redeployed (it can be any one of the inbound or outbound agreements).

    Redeployment is a life cycle action available for transports and agreements. It applies changes to the runtime, on-the-fly, without disruption of message processing.

  1. Click B2B identifiers to define the identifiers that uniquely identify a trading partner. This information is similar to what you defined for the host. See Define the Host Profile.
  2. Select an identifier name and specify a value. You can specify multiple name and value pairs. If no identifiers are defined, click Add Install icon to add a new identifier, selecting an identifier type and entering a value.
  3. In the Control numbers section, enter the initial control numbers in the Interchange, Group, and Transaction fields. These numbers are automatically incremented within the ISA and GS segments for each external trading partner. This feature is only applicable for outbound X12, X12 HIPAA, RosettaNet, and EDIFACT documents.

    For example, assume the last control number used for trading partner A in a development environment was 100004. When migrating to a test environment, they want to start incrementing the initial control number for trading partner A with 200001. This eliminates the possibility of duplicate control numbers and enables them to identify the environment from which EDI messages are being sent.


    The Properties, Contacts, B2B identifiers (which is selected), and Transports & agreements tabs appear at the top. Below is the B2B Identifiers title and plus (add) icon, Below is a table with columns for B2B Identifier and Value. To the right is the Control numbers section, with fields for Interchange, Group, and Transaction.

  4. Click Save.

Watch a video to learn more: