Chapter 3
About BuyerXpert/SellerXpert Resources
This chapter provides guidelines for setting up your BuyerXpert/SellerXpert resources, also known as business objects. After you have completed the tasks in this chapter, you will be ready to configure the business rules for your organization as described in Chapter 5 "Setting Up Business Rules.
|
Note
|
The information in this chapter is based on the assumption that you have already read the BuyerXpert/SellerXpert Concepts and Release Notes.
|
This chapter contains the following sections:
How Resources Work
BuyerXpert/SellerXpert resources include the following:
Members—organizations, organizational units, users, user groups, locations
Accounting—accounting code segments, accounting code values*
Commodity—commodity code segments, commodity code values*
Business rules
Units of measure—system units of measure, organization units of measure
Additional information fields (AIFs)
Pricing—price lists, price adjustments, column lookup table, order adjustments
Payment—payment types and subtypes, instruments, terms
Approval—approval matrix, model, delegation tables, approval cases*
Shipping
Administrator Resource Privileges
BuyerXpert/SellerXpert administration is a multi-tiered process that works through a matrix of privilege levels associated with three distinct administrator roles: superadmin, orgadmin, selfadmin.
Superadmin (super administrator)
A superadmin can do all that is possible through the administrative utilities and interfaces of BuyerXpert/SellerXpert, including interactive administration and import of data. Has full create-read-update-delete privileges across organizations. This role has no administrative restrictions.
In SellerXpert, the superadmin should always be an authorized representative of the selling organization and never a representative of the buying organization.
Orgadmin (organization administrator)
An orgadmin can administer various resources within the domain of the orgadmin's organization. Has full create-read-update-delete privileges within an organization.
In SellerXpert, the orgadmin is usually an authorized representative of the buying organization. An orgadmin can also be a representative of a selling organization; however, the privilege is restrictive in the range of administrative activities allowed.
Selfadmin (self administrator)
A selfadmin can only administer self and self-related entities and attributes. This is the most restrictive role and is the default.
Each BuyerXpert/SellerXpert resource has an associated privilege table that determines what the administrator is authorized to do with the resource. Each table indicates what privilege each administrator has for the following actions:
Create—Ability to add a new resource of this type.
Read—Ability to view a resource of this type.
Update—Ability to change a resource of this type.
Delete—Ability to delete a resource of this type.
Before acting, BuyerXpert/SellerXpert consults the privilege table to determine how, or if, a directive regarding a particular resource should be acted upon. Appendix B "Resource Privileges" contains the privilege tables for BuyerXpert/SellerXpert resources.
Resource Types
Resources are either system resources or organization resources.
System Resources
System resources are applicable to an the entire BuyerXpert/SellerXpert system. Any organization that is part of the particular BuyerXpert/SellerXpert system, or instance, can use the system resources defined for the instance.
System resources include:
System resources can only be defined (created, updated, deleted) by a superadmin, so if an organization within the system has a business need that requires a change in a system resource, the orgadmin for that organization must contact the superadmin to have such changes made. These changes would then be available to any of the organizations within the system.
Organization Resources
Organization resources are applicable only to a particular organization. Any resource that is not a system resource is an organization resource. Organization resources are defined at the organization level by the designated orgadmin, or by the superadmin.
Membership Resources
Membership management is the process of establishing and maintaining the members of the BuyerXpert/SellerXpert community: the organizations, organizational units, users, user groups, and locations. The membership repository is the lightweight directory access protocol (LDAP) database.
A member is a person or entity that is authorized to access particular BuyerXpert/SellerXpert functions and data. BuyerXpert/SellerXpert members are:
Organizations—Any company, institution, or other entity that operates in the procurement cycle has a collection of organization units, groups, users, and locations.
Organizational units—Hierarchical subdivision of an organization; can be further subdivided into smaller organizational units.
Users—People associated with an organization; user belongs to a single organizational unit.
User groups—A collection of users.
Locations—A destination point for shipping, receiving, billing, and so on.
Member Relationships
The interrelationships between the BuyerXpert/SellerXpert members is what determines access paths to the resources.
An organization has:
An organizational unit belongs to an organization and has:
A user belongs to an organization and is a member of:
Zero to one organizational unit
Zero to many user groups
A location belongs to an organization.
A user group belongs to an organization and has:
Zero to many users as members
Organization
An organization is an enterprise, that is, a business entity that functions as a buyer or seller in the BuyerXpert/SellerXpert system. An organization owns its own resources, which can be completely different from resources in other organizations. An organization can also own other organizations, which may have separate unique resources of their own.
An organization is created by a superadmin.
Organizational Unit
An organizational unit is mechanism for representing the hierarchy of an organization. An organizational unit does not have its own unique resources, but instead uses those that are owned by its parent organization. An organizational unit can have no users (just serving as a placeholder) or many users, and can also be the owner of other organizational units.
An organizational unit can be created by a superadmin or the orgadmin for the organization.
User
A user is a person who uses BuyerXpert/SellerXpert to perform, depending on his role, administrative tasks or procurement tasks. A user who is a member of a business organization is a business-to-business procurement user. In addition, in SellerXpert, a user who is not a member of a business organization but only an unaffiliated registered user is a business-to-consumer user.
Users are created for an organization by a superadmin or the orgadmin for the organization.
User Group
A user group is a collection of users that belongs to an organization. Users within an organization can belong to any user groups that are owned by that organization.
A user group can be any of the following types:
Catalog browser
Catalog manager
Catalog seller
Catalog superadmin
Specifying a user group as one of these types determines the catalog access privileges for the members of that user group. These privileges are discussed in Chapter 7 "Administering Catalogs."
User groups are created for an organization by a superadmin or the orgadmin for the organization.
Location
A location represents a destination point for shipping, receiving, billing, and so on.
Locations are created for an organization by a superadmin or the orgadmin for the organization. In SellerXpert, business-to-consumer user locations are added when the users self register.
*Accounting Code Resources
An accounting code is a multi-segment entity used for assigning the expenses associated with the cost of a line item on an order. Accounting codes are made up of accounting code segments and accounting code values.
*Accounting Code Segments
Accounting code segments are the separate sections of an accounting code. The segments define how an accounting code is to be structured for an organization, that is, what segments will make up an accounting code. A segment might represent the following:
A cost center (such as a department)
An expense code (such as office supplies, facilities maintenance, or legal services)
A project code, or some other useful category (such as a region)
Accounting code segments are defined (created, updated, or deleted) by a superadmin at the system level. An orgadmin can use the Admin interface to:
Example
An organization could have accounting code segments such as department-division-project, which could correspond to accounting code values such as iPlanet-eCommerceApplications-BuyerXpert/SellerXpert.
*Accounting Code Values
Accounting code values are the literal contents of accounting code segments.
These resources can only be administered through the Import utility. When the resource is created using the Import utility, you must explicitly define the organization that owns the resource.
|
Note
|
If the administrator is an orgadmin, the owner of the resource can only be the organization the orgadmin belongs to.
|
Example
Typical accounting code segments are Organization, Group, Commodity, and Project, which might have corresponding values such as iPlanet-eCommerceApplications-Software-BuyerXpert/SellerXpert.ss
*Commodity Code Resources
A commodity code is a multi-segment number used for grouping products and services within an organization. By using commodity codes to classify products, an organization can analyze expenditures and determine the source of purchases. For example, as part of its strategic sourcing efforts, the purchasing department could analyze all purchases of the Clothing commodity, regardless of the department or accounting numbers.
Commodity codes can also play a role in approvals. For example, computer hardware purchases might require approval from the Information Technology department, or vehicle purchases might require a special type of approval.
Commodity codes are made up of commodity code segments and commodity code values.
*Commodity Code Segments
Commodity code segments specify the individual sections of a commodity code. They are organization resources that can be created, updated, or deleted by a superadmin or orgadmin.
An orgadmin or superadmin can use the Admin interface to:
Example
An organization could have commodity code segments such as category-item-material, corresponding to commodity code values such as furniture-chair-leather.
*Commodity Code Values
Commodity code values are the literal contents of the commodity code segments.
These values can only be administered through the Import utility. When a commodity code resource is created using the Import utility, you must explicitly define the organization that owns the resource.
|
Note
|
If the administrator is an orgadmin, the owner of the resource can only be the organization the orgadmin belongs to.
|
Additional Information Field (AIF) Resources
An additional information field (AIF) is a repository for additional information that is required for a line item on a requisition. The purpose of an AIF is to collect further information needed for that item. When an AIF exists for an item, the buyer is prompted to provide information at the time the item is added to a requisition.
For example, the address information on a business card is entered through an AIF. Common examples of AIFs are:
A fixed asset category
An estimated date of service
Address information for a business card
AIFs are system resources that can only be created, updated, or deleted by a superadmin. An orgadmin can view AIFs in order to use them as additional information fields in requisition line items. The maximum number of AIFs that can be assigned to a line item is twenty.
A set of AIFs is created as a system-wide extension of BuyerXpert/SellerXpert during implementation. A subset of this domain can then be set for an organization or for products.
Units of Measure Resources
A unit of measure identifies how the quantity of a product is represented. Some standard units of measure are pounds, kilograms, inches, and centimeters. For example, if you are selling light bulbs, you might define the unit of measure for light bulbs as a pack. However, the unit of measure for the price of light bulbs might be defined for each bulb, while the unit of measure for the light bulbs listed in the catalog might be by the case, or by the pallet.
Unit Class
A unit class is a mechanism for categorizing units according to type. For example, weight, distance, and volume are some of the standard unit classes that are supplied with BuyerXpert/SellerXpert.
Your sellers can define an unlimited number of unit classes. There can be one class for each product group, or one class for each product, or one class for an entire product line. Units can belong to one or more unit classes. This is important for commonly used units, such as Each, which may be used for a variety of products. Standard units can belong to both supplied BuyerXpert/SellerXpert classes and seller-defined classes.
Unit classes enable BuyerXpert/SellerXpert to perform additional validation of input data. For example, by limiting field input to only units of measure in the Weight class, an error message appears if a employee enters Feet as the unit class.
Unit Conversion
Unit conversion is the process of calculating how many of one unit of measure equals another unit of measure, such as the process of converting Each to Case.
Every product must be associated with at least one unit conversion table, which defines the relationship between units and unit classes for each product, product group, or product line.
Units of measure include currencies, and unit conversion tables. Units are defined at the system level as well as at the organization level.
You must assign a unit of measure to each product your organization offers. A unit of measure can belong to one or more classes; however, you can only convert a unit belonging to one class to another unit within the same class. You can define as many units of measure as you require.
Scenario
For each product in the product database, you assign a specific unit class and unit conversion table. For each product and/or SKU (stock keeping unit) in a price list, you assign a unit of measure. When a user selects an item, enters a quantity, and places it in a shopping cart, a unit conversion may take place.
Assume the following:
The product to be purchased is soda.
The soda is sold by the case but priced by the can.
The buyer wants to buy one case of soda.
When the buyer adds the case of soda to the shopping cart, product business rules identify the unit conversion table to use for converting the purchasing unit of measure (a case) to the pricing unit of measure (a can). Once the pricing unit of measure is determined, a price can be calculated for the item.
Units of measure resources include:
System-wide Units of Measure
System units of measure apply to the entire BuyerXpert/SellerXpert system. At the system level, only superadmins can create, update, and delete units of measure. Orgadmins can read and copy them under their own organization.
Units of Measure for Organizations
Organization units of measure apply only to an organization. When units of measure are owned by an organization, they can be created, read, updated, and deleted by the orgadmin of the organization.
Conversion Tables
A unit conversion table is made up of rows, with each row consisting of a unit of a From Unit, a To Unit, and a factor that defines how a particular unit of measure is to be converted to another unit of measure. Some typical units conversions might be:
There are 12 Each units in a Pack.
There are 6 Pack units in a Case.
There are 40 Case units in a Pallet.
There are 12 Pallet units in a Truckload.
A product can be associated with the standard conversion table, making it possible to "chain" conversions. For example, a truckload-to-pallet and pallet-to-case conversion could be specified in the standard conversion table, while a case-to-six-pack unit conversion could be specified in your organization conversion table, thus allowing a truckload-to-six-pack conversion.
A standard unit conversion table is provided with BuyerXpert/SellerXpert.
Pricing Resources
BuyerXpert/SellerXpert supports the following pricing models, any of which can reflect the contractual pricing between your organization and the seller organization:
Price from catalog indicates that the seller has already included the buyer prices directly in the catalog.
Price list model is most appropriate when seller pricing does not vary based on quantity.
Pricing external API model is used when the selling organization wants to use their own pricing engine, achieved by extending the pricing external API class (provided as the value to a separate rule named Pricing_ExtAPI_Setting).
Price List
A price list is a table, similar to a spreadsheet, that contains a row for each product sold in a particular market. Price lists contain all the prices for the products or stock keeping units (SKUs) offered by a seller company. Price lists have start and end dates to indicate when the prices are valid.
Generally, selling organizations provide pre-defined price lists in addition to their catalog of products.
Each row in a price list usually corresponds to a product. You can set pricing at the SKU level, which corresponds to a row in a price list.
The actual price column selected for a specific product or SKU depends on various business rules. Commonly, the column selected for a particular item depends on the quantity or value of the item. For example, if you buy less than ten items, BuyerXpert/SellerXpert uses one price column. If you buy from 10 to 99 items, BuyerXpert/SellerXpert uses a different column, and so forth. Price lists also contain a default column for BuyerXpert/SellerXpert to use if the business rule does not have enough information to evaluate.
A price list contains the pricing data associated with a seller catalog. Price lists are usually resources owned by seller organizations, but created for buyer organizations. From the multi-organizational view, a price list must first be created by the seller company admin. The price list is then assigned to the buying organization to which the price list applies by creating an instance on the Price List rule.
Scenario I: Create Price List*
For a seller organization to create a price list for a buyer organization, the following steps are required:
The seller orgadmin creates a price list under the seller organization.
The seller orgadmin enters the buyer organization name in the created_for field.
|
Note
|
The seller orgadmin can specify multiple organizations in the created_for field.
|
Result:
The buyer orgadmin can access this price list as read only under the buyer organization.
The buyer orgadmin can use this price list in accordance with the buyer organization business rules.
Scenario II. Create Multi-Org Price List
The superadmin can create any number of price lists for the selling organization by creating the price list under the selling organization and entering the buyer organization name(s) in the created_for field.
The superadmin creates a Price List rule instance, specifying a particular price list for the specific buying organization or any level down the buying organization's hierarchy.
Result:
The buyer orgadmin can access this price list as read only under the buyer organization.
The buyer orgadmin can use this price list in accordance with the buyer organization business rules.
Pricing Adjustment
A price adjustment includes discounts, charges, allowances, and promotions. Price adjustments are created by sellers to define buyer-specific product discount prices. To grant buying organizations access to the resources that are created for them, the resource owners can specify which organizations the resource is created for. A pricing adjustment is a change to the price of a particular product after the customer selects the item.
Pricing adjustments are optional. They are only evaluated if the Apply Discount on Specific Order is the pricing rule for a specific order.
A pricing adjustment determines changes to a specific portion of an order, such as a line item gross total or a line item gross price. The end result of applying this adjustment to a gross price is a net price.
Gross price refers to the lookup price from a price list after any customer discount or markup has been applied. The net price refers to the price after the gross price has been adjusted based on pricing adjustments.
Common uses of pricing adjustment are discounts, charges, allowances, and promotions (DCAPs). Examples are listed in Table 3-1.
Table 3-1 Examples of Typical DCAPs
|
Type of Adjustment
|
Description
|
|
Reward
|
Bullwinkle for $14.95 with any purchase greater than $35
|
|
Cross-sells
|
Buy bike, get 20% off helmet
|
|
Straight discount
|
25% off all boys pants
|
|
Additional discount
|
10% off sale price
|
|
Early bird specials
|
30% off from 11:00am to 2:00pm
|
|
Cash discount
|
12% off with cash purchase
|
|
Discounts with limits
|
Turkey: limit 1 with minimum $25 purchase
|
|
Other discounts
|
Not valid with any other discounts or offers
|
|
Valued customer discount
|
20% off next purchase
|
|
Allowances
|
Advertising or promotional allowances
|
|
Charges
|
Breakage, freight, small order, special handling
|
|
Discounts
|
Case quantity, line item, total order, warehouse delivery, "will call"
|
|
Seasonal pricing
|
Special on all Halloween products
|
|
Promotional pricing
|
Seasonal, special offers, 2 for 1
|
|
Manufacturer's rebate
|
Rebate amount
|
Column Lookup Table
A column lookup table is an adjustment based on identifying a specific column in a price list to use for pricing when you don't want to use the default price column. A column lookup table can be used to specify a price list column based on item quantity. For example, if the quantity ordered is between 1 and 10, price list column A is used. If the quantity ordered is between 11 and 50, column B is used, and so forth.
This adjustment is optional. If a column lookup table adjustment is not used, the default price column rule is applied.
Order Adjustments
Discounts and markups are adjustments that define how much of a discount or markup a specific customer receives on a particular order. These adjustment are based on the customer, rather than on a product, and can be defined as a percentage or as an absolute amount. A customer discount or markup is a change to a price list value, and is made regardless of the product selected.
You create a separate adjustment for each different discount and markup percentage or amount. You can assign the same discount and markup to more than one customer.
Example
A large quantity discount is required. In this case, a customer is given a pricing discount proportional to how much the customer purchases. Typically, the size of the discount is based on item quantity, item value, total order quantity, or total order value. For example, if the total order is over $1000, the customer receives a 20% discount.
Payment Resources
Administrators of an organization can administer any payment resources that belong to their own organizations. Self administrators can administer the payment instruments that they personally own.
Payment tables include:
Payment types and subtypes
Payment instruments
Payment Types and Subtypes
A payment type is the method that is allowed for payment. For example, credit card or check. A payment subtype is a further qualification of the payment type. For example, if the payment type is credit card, the payment subtype might be Visa.
Payment Instruments
A payment instrument is the actual account number for a payment type/subtype. For example, the credit card number.
Payment Terms
A payment term is an agreement between the buyer and seller organizations about making a payment for an order created by the buyer. In setting a payment term for a requisition, the buyer agrees to make the payment before the due date, and the seller may agree to give a discount. For example, using the payment term 2/10Net 30, if the order balance is paid within ten days, a 2% discount is applied to the total. Otherwise, the net amount is due within 30 days.
When you set up the payment term, you can set values for the due date of the payment, the prepayment date and corresponding discount (if any), and the duration of which the payment term is valid.
Freight and Shipping Resources
Shipping resources include shipping methods, freight terms, whole order shipping charges, and line amount shipping charges. Orgadmins of an organization can administer any shipping resources that belong to the organization.
|
Note
|
In many instances, freight and shipping charges are recalculated by the seller company. In this case, setting up shipping and freight parameters in BuyerXpert/SellerXpert provides estimated figures only.
|
Shipping resources can be administered through the Admin interface or the Import utility. If the Import utility is used, the administrator will need to specify which organization owns the resource.
Freight Terms
When you define freight terms, you can set values for assigning insurance coverage, FOB, payment type, freight terms code (TAXWARE-specific), freight interstate tax code, and freight intrastate tax code for a specific order. As you set up BuyerXpert/SellerXpert, you must define at least one freight term.
|
Note
|
See your TAXWARE documentation for an explanation of the Interstate Taxability and Intrastate Taxability fields.
|
Shipping Methods
The shipping method identifies how to ship an order. As you set up BuyerXpert/SellerXpert, you must define at least one shipping method.
|
Note
|
Prior to defining a shipping method, you must first define at least one carrier and one freight term if you plan to use these values in your shipping method definition.
|
You can define a shipping method as a combination of a carrier (for example, UPS or FedEx) and a level of service (for example, Overnight, 2nd Day, Ground), or it can be defined as a text string (for example, "Will Call" or "Standard Services"). You can also include the shipping method as input when calculating shipping charges.
Before you can set up shipping methods in BuyerXpert/SellerXpert, you need to understand the terms previously agreed upon by your company and your various sellers.
Shipping Charges
BuyerXpert/SellerXpert allows you to define shipping charges based on many different factors, such as order value, weight, distance, carrier, or level of service. Before you can set up shipping charges in BuyerXpert/SellerXpert, you need to understand the terms previously agreed upon by your company and your various sellers, so that you can implement these terms.
*Approval Resources
Approval resources include:
Approval delegation table
Approval matrix
Approval model
*Approval Delegation Table
An approval delegation table is a resource that delineates who can delegate approval authority to whom. Approvers can delegate their own job to another approver or a group of approvers.
Delegation tables can be administered through the Admin interface or the Import utility. If the Import utility is used, the administrator will need to specify which organization owns the resource and which organizations the resource has been
*Approval Matrix
An approval matrix table is a resource that designates approvers based on accounting codes and commodity codes. The administrator of an approval matrix can specify the organizations for which the resource has been created. This grants read-only access to the orgadmins of the organizations for which the resource is created.
When a requisition enters the approval process, BuyerXpert/SellerXpert consults the approval matrix to determine who to route the requisition to. Usually all approvers receive the requisition in their inboxes simultaneously, but you can configure your approval flow to send the requisition one at a time as they approve.
BuyerXpert comes with the following default approval matrix that may meet your needs. If it does not, refer to Help for instructions on creating your own approval matrix.
Table 3-2 Default Approval Matrix
|
Matrix ID
|
Approve Name
|
Approve Type
|
Segment Value
|
Limit
|
Currency
|
|
1
|
Bob
|
cost center
|
dept=iplanet
|
2000
|
USD
|
|
2
|
Susan
|
commodity
|
dept=iplanet
|
500
|
frfrnc
|
|
3
|
Tony
|
pff-catalog
|
dept=iplanet
|
10000
|
USD
|
|
4
|
Janet
|
cost center
|
dept=iplanet
|
5000
|
USD
|
Approval matrixes can be administered through the Admin interface or the Import utility. If the Import utility is used, the administrator will need to specify which organization owns the resource and which organizations the resource has been created for
*Approval Flow Model
The approval flow identifies how the approval process works for your organization from the time a requisition is submitted for approval until the requisition is approved (or declined) and sent as an order to the seller for fulfillment.
The approval flow is a process that occurs outside of BuyerXpert through the Process Manager application. An approval application program interface (API) serves as the connection between Process Manager and BuyerXpert. Although Process Manager itself is transparent to BuyerXpert users, you must use the Process Manager interface to create the approval flow for your organization.
BuyerXpert comes with a default approval flow that may meet your needs. If it does not, refer to Help for instructions on creating your own approval flow.
Multi-Organizational Structure
BuyerXpert/SellerXpert provides a multi-organizational approach that allows unique business rules to be applied to subdivisions of an enterprise. That is, within a single instance of BuyerXpert/SellerXpert, an enterprise can be divided into multiple organizations or divisions, each of which can have unique access control, catalogs, price lists, approval processes, locales, currencies, bill-to and ship-to locations, adjustments, and payment methods.
Multi-locale and multi-currency functionality allows great flexibility in tailoring BuyerXpert/SellerXpert to the specific profile of your organization.
Multi-Locale
The term multi-locale refers to the situation where multiple locale presentations can be used simultaneously within one BuyerXpert/SellerXpert system. For example, one user may be using French and another German.
Locale settings include:
Language and/or language variant (fr / de / en-us / en-uk)
Number and date formats
Page layout—required to handle string expansion and/or text that reads in directions other than left -> right, top -> down.
Graphics—different graphics may be needed due to page layout or cultural differences
The locale is independent of the currency, and the currency is independent of the locale. For example, locale doesn't determine how many significant digits are shown, and the currency doesn't determine the number format.
Multi-Currency
The term multi-currency refers to support for multiple currencies (Euro, USD and others) within one BuyerXpert/SellerXpert system, even within one requisition. With multi-currency functionality, the preferred currency can be displayed for: