Generic Vendor business object

The generic Vendor business object contains values that correspond to a Vendor master record or object in an application. The values include accounting, address, bank, contact, credit, foreign trade, payment, profile, purchasing, receiving, related vendor, shipping, and tax data.

IBM defines a Vendor as any business partner with whom a company maintains at least relationship number 1 and possibly one or more of relationships 2 - 4:

Business object attributes
Relationship Description
1 Buys products or services from the vendor
2 Receives products from the vendor
3 Receives invoices from the vendor for products or services
4 Pays the vendor for products or services

IBM further defines a Vendor as the entity that exists at the highest level of the company's Vendor hierarchy, the Vendor that is referenced in Purchase Order Processing. This high-level Vendor is often referred to as the primary Vendor.

In most applications, the primary Vendor can fulfill all of these relationships. However, if a Vendor record or object fulfills only relationships 2-4, IBM does not represent the record as a Vendor business object. Instead, it represents such a record as the generic VendorPartner business object.

VendorPartner represents an entity that is related to the primary Vendor. The entity can be another Vendor object (such as a Supplier or InvoicingFrom) or it can be an associated address (such as Invoicing or Receiving). The IBM Vendor business object contains a reference to each of its related VendorPartner business objects.

Note: Each Vendor business object has only one address, which is the primary Vendor address. All other addresses (such as shipping or billing) must be represented as VendorPartner business objects.

Ways of storing vendor relationships

Different applications store Vendor relationship information in one of two different ways:

Relationships stored as addresses

Some Customer Interaction Management (CIM) or Enterprise Resource Planning (ERP) applications store a Vendor's partner data as dependent records. In other words, this data does not exist independently of the Vendor data and can be accessed only through their parent Vendor object. These are not used by more than one primary Vendor.

When working with these applications in IBM WebSphere Business Integration Server Express Plus Express Plus, each record is represented as a VendorPartner business object. Because the record is dependent upon the Vendor, it is created only after the parent primary Vendor is created. Synchronization occurs as a multi-step process in which IBM WebSphere Business Integration Server Express Plus:

  1. Creates the Vendor business object
  2. Creates the VendorPartner business objects
  3. Updates the relationships between the Vendor and its related VendorPartners

Relationships stored as objects

Some CIM and ERP applications store Vendor data in a hierarchy of independent objects. The Vendor role at the top of the hierarchy represents the Vendor with whom an order can be placed. This primary Vendor links to other Vendor objects through roles. These roles consist of, but are not limited to, Supplier, Vendor, Invoicing From, Payee, and Alternate Payee.

Figure 1 illustrates a typical primary Vendor with its relationship to other Vendor objects.

Figure 1. Typical Vendor hierarchy

In these applications, the subordinate Vendor objects can be associated with more than one primary Vendor and can be created before the primary Vendor is created. Because the primary Vendor stores the links to its related Vendors, the subordinate Vendors must exist before the primary Vendor can contain the links to them.

When working with these applications in IBM WebSphere Business Integration Server Express Plus Express Plus, each subordinate Vendor is represented as a VendorPartner business object. Synchronization occurs as a multi-step process in which IBM WebSphere Business Integration Server Express Plus:

  1. Creates the VendorPartner business objects
  2. Creates the Vendor business object with references to each VendorPartner's unique identifier

Note: IBM has designed the Vendor and VendorPartner business objects so that the relationship between a primary Vendor and its subordinate Vendor or address is always stored in the parent object (that is, the Vendor business object references the VendorPartner business object). Applications that store the relationship in the child object must be configured to trigger an application-specific business object that maps to the Vendor business object.

Vendor type categorization

Because requisitions must reference a primary Vendor and billing documents are sent only to Vendors who play an Invoicing From role, IBM categorizes every Vendor and VendorPartner business object by type. The type represents the way the Vendor or address is defined in the application.

To allow an application to handle each Vendor type in its own way, the generic Vendor business object allows only one type for each Vendor and VendorPartner business object. This type is stored as an attribute (VendorType or VendorPartnerType).

Due to the way IBM has defined a Vendor, the value of VendorType on the Vendor business object is typically Vendor and the value of VendorPartnerType on the VendorPartner object can be any other type (such as Supplier, InvoicingFrom, Payee, or AlternatePayee). Therefore, a Vendor can be a Supplier Vendor or a InvoicingFrom Vendor, but not both.

Note: The value of the VendorType or VendorPartnerType attribute cannot be changed after the Vendor data has been created in a destination application. However, for those applications that support role functions, Vendor and VendorPartner allow a Vendor object to assume additional (non-primary) roles.

Extension of types through role functions

Some applications allow Vendor objects to serve as more than one type by using what is known as the "Role Function". For example, a primary Vendor might reference itself so that it can also act as the Supplier and InvoicingFrom Vendor. Such an application would create the object as a Vendor that references itself as the InvoicingFrom and Supplier.

In this example, the VendorType would be Vendor, and the Vendor business object would have two Role Functions, Supplier and InvoicingFrom. The role functions are stored in Vendor's RoleUsage child business object. VendorPartner also contains a RoleUsage child business object, which allows a subordinate Vendor or address to have more than one function.

For more information on application-specific business objects, refer to the specific application business object's reference page.

Note: A primary Vendor usually can not serve as a Vendor role for another primary Vendor. Therefore, even applications that allow this relationship may require configuration to represent a primary Vendor as the InvoicingFrom for another Vendor.

In summary, Type indicates the kind of Vendor and Function indicates the kind of roles it plays.

Process for representing organizational views

In some applications, each Vendor object is associated with multiple organizations. For example, a company may buy from Vendor X from both its US and Ireland engineering organizations. Applications that store multiple organizations for each Vendor may store all general Vendor information at the top level and organization-specific information at a subordinate level.

Figure 2 illustrates such an organizational hierarchy.

Figure 2. Vendor with multiple organizations

Because the generic Vendor business object contains data for only one organization per Vendor, each extension of a Vendor into an organization requires separate instances of the Vendor business object.

For example, given the organizations illustrated for Vendor X, synchronizing data for both engineering organizations would involve the following steps in IBM WebSphere Business Integration Server Express Plus:

Therefore, if the source application represents Vendor data with multiple organizations, the source connector must create an event for each unique organization's data.

Implementation notes

If you are synchronizing from a source application that stores multiple organizations to a destination application that stores a single organization, you have the following implementation options:

Business object structure

Vendor is a hierarchical business object. Figure 3 illustrates its child business objects.

Figure 3. Vendor child business objects

Vendor header business object

Vendor contains information about the primary Vendor. It contains such information as the Vendor's name, ID number as used in the application, and a user-entered number or alphanumeric identifier for the vendor. Vendor contains the following child business objects:

Business object attributes
Child business object Description Cardinality
VendorAddress Contains the address information for the primary Vendor. VendorAddress contains PhoneInfo and RoleUsage.
PhoneInfo
  • As a child of VendorAddress, contains phone information for the primary Vendor address.
  • As a child of VendorContact, contains phone information for the primary Vendor contact.
n
RoleUsage
  • As a child of VendorAddress: contains the Role functions of the primary Vendor's address. For example, if the primary Vendor also functions as the InvoicingFrom and Payee for itself, RoleUsage contains those roles.
  • As a child of RelatedVendorRef: contains the Role functions of any associated Vendor partners or addresses that are linked to the primary Vendor. For example, if a subordinate Vendor or an address functions as more than one role, RoleUsage contains those roles.
n
VendorContact Contains the reference to any associated Vendor contacts that are linked to the primary Vendor. VendorContact contains PhoneInfo. n
RelatedVendorRef Contains the reference to any associated Vendor partners or addresses that are linked to the primary Vendor. RelatedVendorRef contains VendorAddress, which contains PhoneInfo and RoleUsage. Note: This object contains only the reference to the associated entity and not the values for the entity. n
VendorInformation

Contains all the child business objects that represent Vendor information:

  • VendorAccountingData
  • VendorBankData
  • VendorPaymentData
  • VendorProfileData
  • VendorPurchasingData
  • VendorReceivingData
  • VendorTaxData
  • Notes
1
VendorAccountingData A child of VendorInformation: contains data that qualifies the vendor as a legal entity in that it has its own set of financial books. 1
VendorBankData A child of VendorInformation: contains such banking data for the primary Vendor as the bank's country and number, the bank account number and type, and a flag that indicates whether there is collection authorization. n
VendorPaymentData A child of VendorInformation: contains the vendor's payment data, including the freight terms, payment terms, and invoice and payment currency information. 1
VendorProfileData A child of VendorInformation: contains such marketing data about the primary Vendor as its total revenue, number of employees, stock symbol, standards organization, web site address, type of ownership (for example, Public or Private), and industry. 1
VendorPurchasingData A child of VendorInformation: contains the vendor's purchasing organization data, including the purchasing organizational unit, freight terms, payment terms, minimum and maximum order values, and purchase order handling flags. 1
VendorReceivingData A child of VendorInformation: contains the vendor's receiving data, including the purchasing organizational unit, flags for shipping enforcement and whether receipts or inspection are required, and receipt routing information. 1
VendorTaxData A child of VendorInformation: contains such tax data for the primary Vendor as its tax identifier, code, and jurisdiction and a flag that indicates whether the Vendor requires a 1099 form. VendorTaxData contains VendorTaxExemptLicenseData. 1
VendorTaxExemptLicenseData A child of VendorTaxData: contains the exemption licenses for the SoldTo Vendor. n
Notes A child of VendorInformation: contains notes for the Vendor. Examples are Supplier instructions and Invoice handling instructions. n

Supported verbs

The generic Vendor business object supports the following verbs:

Examining the object

For a listing of the generic Vendor business object's attributes, System Manager or Process Designer Express.

Related References

Copyright IBM Corp. 1997, 2004