Microsoft Solution for Supplier Enablement

NOTE: These guides were written in 2002.

It's pushing Microsoft BizTalk Accelerator for Suppliers (AFS)

Other MSSE Guides: Architecture Guide

 Introduction

Microsoft Corporation

Service Release 1, May 2002

Applies to:
 Microsoft Solution for Supplier Enablement
 Microsoft Commerce Server 2002
 Microsoft BizTalk Server 2002

Summary: Learn about the business context for the Microsoft Solution for Supplier Enablement (MSSE). The five guides that constitute this documentation set: Architecture Guide, Deployment Guide, Operations Guide, Services Guide, and Support Guide are introduced.

Contents

Introduction
Shopping Scenarios
Business Background
Overview OF MSSE Guides
URL Resources
Glossary

Introduction

The Microsoft® Solution for Supplier Enablement (MSSE) was developed in response to emerging e-business models that have transformed business-to-business (B2B) e-commerce, especially corporate procurement processes, from a paper intensive manual process to an automated, seamless process that connects both suppliers and buyers. It is an integrated business-to-business solution that uses Extensible Markup Language (XML) to empower suppliers to effectively extend their selling capabilities through the Internet.

MSSE makes it easy for businesses of any size to transact business through multiple electronic sales channels, such as marketplaces, procurement applications, and directly through the Web. These interactions include the exchange of electronic product catalogs and purchase orders between trading partners. The term trading partner has emerged as a generic term for a variety of relationships within the B2B space.

MSSE also enables functionality (known as remote shopping) that empowers the supplier and enhances the online shopping experience by allowing a buyer to access a supplier Web site during a shopping session. MSSE provides:

• An accelerator application for enabling inter-company business processes.
• A Web application that enables a supplier to set up a B2B commerce presence, including connectivity to marketplaces and other trading partners.
• Out-of-the-box XML standards to enable e-commerce trading.
• Tools for mapping and translating one XML standard to another.

Using extensible Internet-standard protocols and formats that are far easier to develop, deploy, and maintain than traditional integration solutions, MSSE provides a significant opportunity for businesses of all sizes to implement deep integration of business processes both within and across corporate boundaries. This allows businesses to stay competitive with emergent e-commerce trends.

Although there are many technical challenges that face suppliers who need to trade electronically, the business problems and requirements are perhaps as pervasive as the technical challenges.

This introduction discusses the problems and business requirements that have led to the development of the MSSE. It includes an overview of emergent B2B e-commerce business processes, such as e-procurement and e-marketplaces. It then describes the specific issues facing suppliers of all sizes and discusses enabling suppliers to get into the B2B arena. The chapter concludes with a high-level summary of the business requirements that have been taken into consideration for the design of the MSSE.

Shopping Scenarios

The Microsoft Solution for Supplier Enablement (MSSE) involves the following business entities, named from the perspective of product suppliers:

• Suppliers. Suppliers are the businesses toward which this solution is targeted. Suppliers have products and/or services to sell (hereafter called simply "products"), and one of the emerging ways in which they sell their products is through trading partners. Trading partners offer these products to buyers on behalf of the suppliers.
• Trading Partners. Trading partners receive information about products from suppliers in the form of electronic product catalogs. Trading partners present the information in the product catalogs to buyers. When these buyers decide to purchase products in these catalogs, the trading partners forward the purchase requests to the suppliers in the form of electronic purchase orders.
• Buyers. Buyers have access to the product information presented by trading partners. Often, the products are a combination of the products offered by multiple suppliers. As the buyers decide which products to buy, they are not necessarily aware of the supplier of that product.

There are two basic scenarios for the shopping sessions in which the buyers engage, either with or without what is known in the MSSE as "remote shopping." Remote shopping describes a process in which the buyer is re-directed to a "remote" shopping session on the supplier Web site during a shopping session with the trading partner. Once the remote shopping session has ended, the products chosen (or configured) on the supplier Web site are displayed in the shopping basket in the shopping session with the trading partner.

These scenarios are discussed in the following sections.

Shopping Scenario Without Remote Shopping

The following figure illustrates a shopping scenario that does not involve remote shopping.

Figure 1

The basic steps in this scenario are as follows:

1. The supplier sends an XML product catalog to the trading partner.
2. The buyer begins a shopping session using the buyer application presented by the trading partner. The buyer application might be a Web site, or it might be another form of an electronic procurement application. The nature of the buyer application is not particularly relevant to the supplier.
3. The buyer eventually ends the shopping session by checking out.
4. Assuming that the buyer purchased one or more products from the supplier's product catalog, the trading partner constructs an XML purchase order and sends it to the supplier.
5. The supplier sends an XML purchase order response to the trading partner, acknowledging receipt of the purchase order.

Shopping Scenario With Remote Shopping

The following figure illustrates a shopping scenario that involves remote shopping. The Microsoft BizTalk™ Accelerator for Suppliers (AFS) Service Release 1 Solution Site is the Web site based on Commerce Server that includes the ASP pages used for remote shopping.

Figure 2

The basic steps in this scenario are as follows:

1. The supplier sends an XML product catalog to the trading partner.
2. The buyer begins a shopping session using the buyer application presented by the trading partner. The buyer application might be a Web site, or it might be another form of an electronic procurement application. The nature of the buyer application is not particularly relevant to the supplier.
3. The buyer performs an action that initiates a remote shopping session on the supplier Web site.
4. The buyer engages in a remote shopping session on the supplier Web site, choosing products or perhaps configuring a product chosen in the trading partner buyer application. Because the AFS Solution Site is a Web site, the buyer application is either re-directed to this Web site or a separate browser is opened for the remote shopping session.
5. The buyer ends the remote shopping session on the supplier Web site, returning to the shopping session in the trading partner buyer application.
6. The supplier completes the remote shopping session by returning information about the products chosen (or configured) to the trading partner buyer application.
7. The buyer eventually ends the shopping session by checking out.
8. Assuming that the buyer purchased one or more products from the supplier's product catalog, the trading partner constructs an XML purchase order and sends it to the supplier.
9. The supplier sends an XML purchase order response to the trading partner, acknowledging receipt of the purchase order.

   Note The shopping session in the trading partner buyer application can include more than one remote shopping session on the same or different supplier Web site.

Business Background

Overview

Enabling suppliers of all sizes to begin conducting their business electronically over the Internet is a logical next step to address the needs of large company efforts to improve their corporate procurement processes. Many large companies like Microsoft have already implemented corporate procurement solutions, resulting in dramatic cost savings and improved efficiency. Additionally, many companies (sometimes called market makers) have begun implementing both private and public electronic marketplaces to improve their supply chains and introduce new revenue sources. The success of these solutions largely depends on their ability to achieve a critical mass of participants (mainly suppliers) that have the ability to produce and consume data — data that is often of varying quality, timeliness, and format. Traditionally, such solutions were built using Electronic Data Interchange (EDI). EDI has seen some success, but has proven a costly and difficult standard to implement and has not reached broad acceptance to date.

Buyers and market makers have been working to automate their supplier networks. Large buyers often have thousands of suppliers that range from very small and simple to very large, complex selling organizations. As these buyers and market makers identify ways to communicate and trade with suppliers electronically, they have had only limited success getting their suppliers to invest in solutions and participate for several reasons:

1. Poor value proposition for the supplier. Many buyers have simply asked their suppliers to invest in technology solutions and participate without educating them on the potential benefits and how to leverage the latest offerings to avoid negative implications, such as commoditization or loss of brand recognition.
2. Cost. Most available solutions for integration are very expensive to purchase and even more expensive to implement and maintain.
3. Functionality. Many of the solutions that are currently available only provide a small piece of what is required for a supplier to remain empowered and achieve the benefits of trading electronically. For example, many solutions offer the tools to connect and exchange data, yet offer no sell-side functionality, database, catalog, or application-level features that expose the buyers to the true value offered by the supplier.
4. Proprietary nature. Many of the solutions being offered only connect the supplier to one particular buyer or market maker, or to only one type of platform or standard. A truly empowered supplier needs one solution that can connect to all of their buyers; regardless of the electronic channel (e-procurement, marketplaces, direct) or technology platform those buyers may use to make purchases. Many standards exist horizontally and vertically, and technology solutions must have the ability to leverage common standards to be effective.
5. Limited range of solution. Most solutions that have been made available to suppliers have been targeted at a particular size or type of organization and skill set. For example, many solutions are targeted only at large suppliers with significant budget, IT resources, and skills. These solutions are not well suited for medium and small suppliers, or those wanting a fast time to market, because they require complex customization or contract programming to implement.

Microsoft is working to help solve these problems in the following ways:

1. By providing support for multiple XML standards in Microsoft BizTalk Accelerator for Suppliers (AFS) and in subsequent products so that suppliers may connect to all trading partners using a single software solution.
2. Leveraging the existing portfolio of platform and Microsoft Windows Server System servers technologies such as Windows 2000 (operating system, application server), BizTalk Server 2002 (XML-based integration and workflow), Commerce Server 2002 (catalog, order processing, personalization, analytics), and SQL Server 2000 (database, business intelligence) to provide a range of solutions that scale to the largest enterprise while remaining easy to implement and be cost effective for smaller organizations.
3. Leveraging the growing expertise of Microsoft Consulting Services (MCS) in the e-business arena.
4. Leveraging the Microsoft community of technology and implementation partners.

Connecting corporate procurement systems and electronic marketplaces used by buyers and suppliers is becoming easier and less costly. AFS enables both buyers and suppliers to quickly buy, sell, and trade products and/or services in a low cost, effective, and electronic way. AFS demonstrates how to enable suppliers to exchange XML documents and trade with buyers through multiple sales channels. The same approach and the techniques demonstrated in AFS can be leveraged to exchange a variety of other documents and messages between buyer and supplier applications.

Driving Factors

A number of different factors are driving the push toward enabling suppliers of all sizes to engage in electronic data exchange. Some of these factors are related to business issues, and others are related to technological advancements. These two types of factors are discussed separately in the remainder of this section.

Business Factors

The following business factors play a role in the increasing interest in supplier enablement, all of which are motivated by the need to increase revenue and stay competitive:

• Customer retention. In response to the general push towards new electronic sales channels, businesses of all sizes must pursue these sales channels if they wish to retain and increase their customer base. In some cases, large or influential buyers are requiring their suppliers to convert to electronic solutions. If the supplier does not convert to electronic solutions, the supplier may run the risk of losing the buyer's business altogether.
• Operational efficiency. An important aspect of remaining competitive is related to competitive pricing. Reducing overhead plays an important role in keeping prices low. Shifting towards automated, electronic sales channels is a very effective way to reduce the costs associated with making sales. Also, moving data electronically can greatly reduce problems with accuracy (such as order entry errors), further increasing efficiency.
• Customer service. Customer service is enhanced through supplier enablement. Specifically, improvements made by supplier enablement contribute to the overall increase in the operational efficiency of the sales organization. The increase in efficiency is a direct result of the decreasing likelihood that errors occur as automation is applied throughout the entire purchasing process. Advanced features, such as remote shopping, provide richer interaction and foster a relationship between buyer and supplier that allows the supplier to analyze and understand what buyers want.
• Increased revenue. One of the most important benefits of any technology investment is its ability to affect the overall revenue of a supplier. Increased revenue is the primary driver of solutions that empower suppliers to interact with their customers in a richer and easier way. Gaining new customers by moving quickly into new electronic markets can also lead to increased sales and revenue.
• Leverage existing IT assets. Suppliers that already use Commerce Server 2002 and its associated infrastructure will benefit due to compatibility with the AFS implementation.
• Global reach. Suppliers can more easily reach global markets by trading electronically.

Technological Factors

The following technological factors play a role in the increasing interest in supplier enablement, all of which are related to easing the technological difficulties associated with implementing such solutions:

• Data Representation. The emergence of XML as a leading mechanism for the representation of data is an important technological factor in the growing importance of supplier enablement. XML allows data to be represented in a way that can be easily interpreted by disparate systems, allowing for more cost-effective integration than was previously possible.

  One of the key functions of the Microsoft platform (specifically BizTalk Server 2002) is to provide a generic mechanism for transforming one XML format to another XML format. Because Microsoft BizTalk Accelerator for Suppliers (AFS) leverages BizTalk Server for this purpose, AFS is easily extensible to new XML formats, Electronic Data Exchange (EDI), and other standards.

• Application Integration. Integrating with existing systems (such as ERP, CRM, and supply chain systems running on various platforms) is becoming more straightforward with new software packages such as BizTalk Server. BizTalk Server defines a standard for application integration components (AICs). AICs are a type of COM object specifically designed to work within the BizTalk Framework and fill the role of integrating with existing systems.
• Universal Description, Discovery, and Integration (UDDI). UDDI is an industry initiative started by Microsoft, IBM, and Ariba. It provides businesses with a standard interface for programmatically describing their Web services and discovering Web services provided by others. As the functionality comprising supplier enablement expands over the coming years, the role of UDDI will become increasingly important.
• Sell-Side Advancements. The ability to sell effectively through the Internet has increased dramatically in the past several years. New technologies, including XML catalog representation, catalog management (including custom catalogs and custom pricing), order processing, personalization, and business analytics have made effective selling a much more realistic option in business-to-business (B2B) e-commerce. Prior to these advancements, supplier participation consisted mostly of data exchange with little opportunity to enhance the customer relationship. These new technologies, provided by Microsoft Commerce Server 2002, are an important part of most supplier enablement solutions.

Trading Partners

Trading partners are anyone to whom you sell your products and/or services, including buyers, other suppliers, and marketplaces. In order for a trading partner to know what products and/or services you are offering for sale, you provide them with an electronic version of your product catalog. When a user of a trading partner buyer application makes a purchase from your catalog, the trading partner sends you an electronic version of a purchase order, which you fulfill using established procedures.

Microsoft BizTalk Accelerator for Suppliers (AFS) provides the means to engage in these types of transactions with any trading partner that uses XML messages for exchanging product catalogs, remote shopping, and accepting purchase orders.

AFS leverages BizTalk Server (BTS) to transform XML documents to and from the formats defined by these standards and the corresponding Commerce Server XML formats. BTS can be re-configured to transform XML documents into other standards, or different versions of the supported standards. This point is important because it emphasizes that AFS can serve as a starting point for developing solutions that extend far beyond the specific solutions that it demonstrates as it is delivered.

The three types of trading partners that are relevant to supplier enablement are buyers, peer-to-peer trading partners, and electronic marketplaces. The remainder of this section describes these types of trading partners and their characteristics.

Trading Partner Procurement Applications. Microsoft BizTalk Accelerator for Suppliers (AFS), as delivered, supports catalog publishing, remote shopping, and purchase order reception functionality for the xCBL 3.0/SAP OCI 2.0, cXML 1.1, cXML 1.2, and SAP XML standards.

The following table lists the procurement applications with which AFS has been tested.

Note Marketplaces/procurement applications and the corresponding enablement of suppliers are relatively new, as are the standards that support this effort. The XML standards supported by AFS are considered works-in-progress and are subject to change on a fairly frequent basis. For more information, see Business Issues in AFS Online Help.

Buyers

Buyers are an important group to consider because they are often the driving factor in the move towards electronic selling for a supplier. Buyers are looking to consolidate and improve operational processes in their supply chains and most importantly, lower costs. They are willing to make long-term investments in electronic procurement and supply chain automation in order achieve to these goals.

Buyers will sometimes influence or even pressure suppliers to interact electronically as part of their procurement process. Some buyers are willing to drop long term relationships with suppliers if they do not have the capabilities to interact with new electronic procurement applications being implemented by the buyers. The change in the business landscape is forcing many suppliers to rethink their strategies, prioritizing and focusing many of their efforts around the requirements associated with electronic trading.

Large-sized buyers that have an in-house corporate procurement process are automating the ways in which their procurement process receives data. They may have traditional Electronic Data Interchange (EDI) interactions with a number of suppliers, but are now embracing XML as their primary or exclusive data interchange format. As new technologies, like BizTalk Mapper in BizTalk Server 2002, ease the mapping of one data format into others, suppliers are finding it easier and more cost effective to exchange electronic data and trade with a wider range of customers using a wide variety of platforms and technologies.

Large-sized buyers interact and trade with their suppliers in two primary ways: using their in-house electronic procurement applications for peer-to-peer interaction, and through electronic marketplaces that bring together multiple buyers and sellers in one community.

Medium-sized buyers use either in-house or outsourced procurement applications. Outsourcing is hosted either by a marketplace or an application service provider (ASP). Suppliers may find it necessary to offer their products and/or services through particular marketplaces in order to sell to these buyers.

Smaller buyers that buy electronically tend to buy directly from the supplier Web site or through a marketplace. The following sections contain specific details about peer-to-peer trading partners and marketplaces.

Peer-to-Peer Trading Partners

Peer-to-peer trading for a supplier usually involves interacting directly with the applications used by their customers without using an intermediary such as a market maker or marketplace.

From the perspective of AFS, the company implementing the provided functionality is considered the supplier, and the company purchasing those products and/or services provided by the supplier is the (peer-to-peer) trading partner.

In other words, the supplier makes their products known to the peer-to-peer trading partner by publishing an electronic catalog. The trading partner makes those products available to the buyers using some form of buyer application. These buyers are typically employees of the trading partner organization. When buyers purchase those products, the trading partner assembles an electronic purchase order and sends it to the supplier for fulfillment.

Remote shopping can be an effective model for peer-to-peer trading. The shopping itself occurs on Web sites maintained by the suppliers, but the purchased products are gathered into a single basket in the trading partner buyer application, and can traverse the other steps in the procurement process (such as approval) together.

If a supplier wants to sell to trading partners capable of sending and receiving electronic business documents that use the xCBL 3.0, SAP XML, cXML 1.1, or cXML 1.2 standards, they can use AFS with little or no modification to begin trading with that partner. If the prospective trading partner uses a different standard, or a different version of the supported standards, the supplier can use AFS as a starting point to implement the necessary modifications to begin trading.

Marketplaces

Marketplaces are a particular type of trading partner. In general, a marketplace is run by a large buyer or market maker and often provides a consolidated online shopping experience for multiple trading partners. Early examples of marketplaces were most often in a particular vertical market. The current trend is towards private marketplaces, run by a large buyer within their particular community of suppliers. Marketplaces often aggregate catalogs from different suppliers and allow multiple buyers to interact with those suppliers. The suppliers periodically publish their catalogs to the marketplace in an XML format that the marketplace can automatically process and aggregate with the products and/or services from other suppliers.

An advantage that marketplaces offer their users is the opportunity to purchase products and/or services from different suppliers in a single transaction. In some marketplaces, when a purchase is made, the marketplace creates a purchase order for each supplier with one or more products and/or services included in the purchase, and sends those purchase orders to the relevant suppliers for fulfillment.

The first marketplaces were attracted to the value proposition of enhancing the corporate procurement applications used by large companies. With multiple buyers and their associated suppliers trading amongst each other for a fee, the market maker running the marketplace could see significant return, after the marketplace achieved liquidity. The most difficult challenge faced in this approach is the process of engaging and electronically enabling those thousands of suppliers. Supplier organization size varies and each has its own unique set of issues related to interacting with both marketplaces and other sales channels.

A more recent trend concerns marketplaces serving as a portal for suppliers. This leads to marketplaces interacting with other marketplaces so that suppliers only need to publish their catalogs to a single marketplace and their product data gets propagated to other marketplaces.

Remote shopping, although more complicated, is also becoming a common feature in supplier software provided by some marketplaces. Remote shopping helps to combat the tendency toward generic product presentation that is inherent in an aggregated scenario. For more information about remote shopping, see Remote Shopping Feature.

Marketplaces support a wide variety of business models — too many to fully enumerate in this overview. The following lists introduces some of this variety:

• Some marketplaces only provide simple matchmaking services: helping buyers and suppliers find each other to begin trading relationships. Once matched, the buyers and suppliers are free to trade as peers outside the marketplace.
• A marketplace might play a relatively minor role in bringing the supplier and buyer together. Remote shopping could be implemented in a very broad sense, such that all of the shopping occurs on the respective supplier Web sites. Purchases would still be consolidated in the marketplace basket, but billing might be left solely to the supplier, based on the received purchase order.
• Marketplaces may function to achieve volume discounts by aggregating purchases from many buyers into a single purchase order. A problem with this approach is the redistribution of goods.
• Marketplaces might provide a mechanism through which each supplier can choose the buyers to whom their catalogs are made available. There is likely to be some choice that allows all buyers to be chosen.
• Some marketplaces control nearly every facet of the process, from shopping and ordering to collaboration, payment, financing, logistics, and other Web services.

Sales Channels

Sales channels are the means by which you make your products and/or services available to buyers. Traditional sales channels such as retail stores and mail order using paper catalogs are non-electronic and are therefore not covered in this document. Electronic sales channels have become increasingly popular and practical for businesses with the advent of the Internet.

The following figure shows the sales channels that are relevant to e-commerce in general, and Commerce Server 2002 in particular, including the new sales channels enabled by MSSE.

Figure 3

The preceding figure shows the following different electronic sales channels. The various trading interactions are shown as arrows labeled A through H. The interactions associated with each sales channel are identified within parenthesis at the beginning of each description. The interactions (and associated supplier Web site) that are enabled by AFS are shaded and are shown as double arrows to indicate that the enabled interaction relationship is not reciprocal; catalogs can be published and orders received, but not vice versa.

• Retail Web site shopping. (A) This sales channel is normal retail e-commerce and is provided by the Retail Solution Site that is available for Commerce Server or its equivalent. This type of Web site can be used by individual business customers, as well as by consumers. Although AFS is not required for this sales channel, AFS includes a Solution Site that can be used for retail Web site shopping.
• Supplier Web site shopping. (B) This sales channel exists in situations where a supplier has made a business arrangement with a trading partner under which trading partner users have authorized access to the supplier Web site. The Web site is not available to the general public. It is typical for pricing discounts to be included based on the prospect of volume sales.

  The Supplier Solution Site that is available for Commerce Server provides this sales channel. Although AFS is not required for this sales channel, the Solution Site included with AFS can easily serve this purpose.

• In-house corporate procurement using peer-to-peer trading. (C, D) This sales channel exists in situations where a supplier uploads their catalog to, or allows remote shopping from, a corporate procurement application being run by a trading partner, making their products and/or services available through the corresponding buyer applications.

  MSSE enables this sales channel.

• In-house corporate procurement using marketplace trading. (C, E, F, H) This sales channel exists in situations where a supplier uploads their catalog to, or allows remote shopping from, a marketplace to which a corporate procurement application connects, making their products and/or services available to the corresponding buyer applications. (This scenario need not involve two marketplaces, as shown in the figure, but this scenario can involve one marketplace exchanging data with other marketplaces).

  MSSE enables this sales channel.

• Outsourced corporate procurement using marketplace trading. (E, G, H) This sales channel exists in situations where a supplier uploads their catalog to a marketplace that hosts a procurement application itself, allowing buying organizations to avoid hosting their own procurement application. (Again, this scenario need not involve two marketplaces. As shown in the figure, it is the marketplace that indirectly receives the catalog data that is hosting the procurement application.)

  MSSE enables this sales channel.

The last three sales channels above are enabled by MSSE. With minimal effort, MSSE enables these sales channels for trading partners whose procurement applications use the xCBL 3.0, SAP XML, cXML 1.1, or cXML 1.2 standard. With additional effort, MSSE could be modified to work with other standards.

The remainder of this section further describes the different types of sales channels and considers characteristics of each type that are important to supplier enablement.

Traditional Sales Channels

Some traditional sales channels are:

• Retail stores
• Printed catalogs, including mail-order catalogs
• 1-800 telephone numbers
• Door-to-door
• Bulk mailing
• Telemarketing

Despite the fact that the electronic sales channels are not going to completely replace the traditional sales channels anytime soon, it has become clear that they are capturing a larger and larger share of the market in a relatively short period of time. Especially in the realm of industrial suppliers, the move towards replacement of the traditional sales channels with their electronic equivalent is accelerating, and in many cases, is being mandated by buyers as a prerequisite to continued commerce.

Retail Web Sites

Retail Web sites are now commonplace. Most large retailers have discovered that an online presence is necessary to remain competitive, particularly those that have traditionally had a strong mail-order presence.

Because retail Web site shopping does not require the trading partner (the user) to have any software other than a browser, it tends to be considered outside the domain of supplier enablement. There are no catalogs to be uploaded, or purchase orders to be received and processed.

However, with the increasing popularity of remote shopping retail Web sites can play a role in a supplier enablement scenario. Shopping usually begins in a procurement application, run by a trading partner, that contains an uploaded catalog from the supplier. But at some point the user can jump to the (retail) Web site run by the supplier for a more precisely controlled shopping experience, perhaps for product configuration or product availability confirmation. When complete, the user returns to the procurement application where the chosen or configured products are now shown prior to the completion of the purchase.

Microsoft BizTalk Accelerator for Suppliers (AFS) includes a fully functional remote shopping-enabled Solution Site that is based on the Retail Solution Site. This new Solution Site combines direct Web site shopping and remote shopping functionality into a single Web site. The new and replacement ASP pages in the AFS Solution Site (available in the AFS SDK) can be used as the basis for adding remote shopping functionality to an existing Solution Site. For more information about implementing remote shopping, see Remote Shopping in AFS Online Help.

Supplier Web Sites

Supplier Web sites are a variation on retail Web sites that are generally targeted to a wholesale or discount situation. As with retail Web sites, the trading partner (the user) is not required to have any software other than a browser. Therefore, the supplier Web site scenario is similarly not the target scenario of supplier enablement.

Unlike retail Web sites, the trading partner is typically required to be a well-known, pre-approved buyer that must be authenticated to the supplier Web site using a login mechanism. But as with retail Web sites, a supplier Web site could play a role in remote shopping.

Peer-to-Peer Trading

Peer-to-peer trading constitutes a sales channel in which a supplier conducts business with a procurement application run by one of their trading partners, without involving any third party or intermediary. Their buyer application may or may not qualify as a procurement application, depending on the degree of other process functionality included (such as order approval, and so on). It might be as simple as a Web site through which they offer your products and/or services for sale. You publish your catalog data to the trading partner; however, the means through which that data is made available to buyers is up to the trading partner.

The fact that your products and/or services are made available through their buyer application is important, and is what distinguishes this sales channel from a supplier Web site.

If remote shopping is implemented, buyers will actually access and interact with your catalog data from two sources:

• The catalog data published to the procurement application. In this environment, the presentation of products is not under your control.
• Directly on your Web site where remote shopping has been implemented. In this environment, you retain control of the shopping experience and branding.

The MSSE implements three key supplier enablement features: catalog publishing, remote shopping, and purchase order reception. For more information about these features, see the MSSE Architecture Guide.

Marketplace Trading

Marketplace trading constitutes a sales channel through which your products and/or services are made available on what is known as a business-to-business (B2B) marketplace or B2B exchange (other names include Hub, e-Hub, industry-sponsored marketplace (ISM), e-market, and so on). Marketplaces are businesses that exist primarily to consolidate the products and/or services offered by a number of different suppliers, often related to a particular industry or large buyer. Operationally, it can be quite similar to a peer-to-peer trading situation. You publish your product catalogs to the marketplace, after which the presentation of that data to the marketplace users is their responsibility. If remote shopping is implemented, the users may end up directly browsing your Web site during their shopping session, but eventually are returned to the marketplace buyer application to continue shopping and eventually to checkout. When your products are purchased through the marketplace, you receive an electronic purchase order to communicate those purchases and initiate your order fulfillment mechanisms.

Marketplaces need not be a separate business dedicated to that purpose. Marketplace software vendors sell marketplace software to large companies so that they can set up private marketplaces. In such scenarios, the users are general or procurement-specific employees of the large company who purchase various products and/or services in the course of accomplishing their work. The suppliers are the various companies from whom those purchases are made.

Historically, employees of the large company searched for the necessary products in printed catalogs, and entered the relevant data into their corporate procurement systems (where available) to initiate the purchase process. Increasingly, suppliers are being mandated or influenced to participate in the electronic private marketplace, replacing the printed catalogs, and the marketplace software is being integrated directly with the procurement systems.

Marketplaces represent a very broad spectrum of business models. Sometimes marketplaces are little more than facilitators between buyers and sellers. In other scenarios, marketplaces perform consolidation of purchase orders and billing.

Overview OF MSSE Guides

This section briefly describes each of the Microsoft Solution for Supplier Enablement (MSSE) guides.

Architecture Guide Overview

The MSSE Architecture Guide provides information about the architecture of the MSSE and its underlying product, Microsoft BizTalk Accelerator for Suppliers (AFS).

Deployment Guide Overview

The MSSE Deployment Guide provides detailed instructions about how to successfully deploy the MSSE on several different scales, including a large-scale deployment. This includes instructions about installing and configuring the various Microsoft Windows Server System products that are used by the MSSE.

Operations Guide Overview

The MSSE Operations Guide provides information about the ongoing task of running a business using the MSSE, including troubleshooting information.

Services Guide Overview

The MSSE Services Guide provides information about the process of undertaking an MSSE deployment. It describes tasks related to planning, development, and stabilization.

Support Guide Overview

The MSSE Support Guide provides information about how the MSSE is supported by Microsoft.

URL Resources

The following URL provides additional information:

Microsoft Solution for Supplier Enablement:

http://www.microsoft.com/business/solutions/MSSE/

Glossary

The following terminology relates to the Microsoft Solution for Supplier Enablement. Familiarity with this terminology will be useful in understanding this solution.

Ariba

A software company that sells a procurement application, runs a marketplace (Ariba CSN), and sells a marketplace platform. These products use the cXML standard.

Application Integration Component (AIC)

A special type of COM component in Microsoft BizTalk Server that implements the IBizTalkAppIntegration interface, and optionally implements the IPipelineComponent and IPipelineComponentAdmin interfaces. When you configure a messaging port to handle a document, you can choose to pass the document to a custom AIC.

BizTalk Editor

A tool with which you can create, edit, and manage document specifications. Using BizTalk Editor you can create a document specification based on a specification template, an existing schema, certain types of document instances, or a blank specification.

BizTalk Mapper

A tool with which you can create map files that define the correspondence between the records and fields in one specification and the records and fields in another specification. A map file contains an Extensible Stylesheet Language (XSL) style sheet that is used by BizTalk Server to perform the transformation described in the map file.

BizTalk Messaging Manager

A graphical user interface that can be used to configure BizTalk Messaging Services to exchange documents between trading partners and applications of the home organization.

BizTalk Orchestration Designer

A design tool used to graphically describe long running, loosely coupled business processes. This graphical representation is then used to produce an XLANG schedule that will be used to run the automated business process.

buyer application

A software application through which a buyer can browse catalogs and purchase products found in those catalogs. Sometimes a buyer application is an Internet application consisting of a browser and a Web site.

catalog publishing

In Microsoft BizTalk Accelerator for Suppliers (AFS), the process of exporting catalog data, converting it to either xCBL 3.0, cXML 1.1, or cXML 1.2 format, and then sending it to a trading partner.

channel

A set of properties that directs BizTalk Server through the appropriate steps to process documents. Channel properties include a source organization or application, a document definition, a map file, and field and document tracking settings.

Clarus

A software company that sells a procurement application and marketplace platform. These products use the cXML standard.

Commerce One

A software company that sells a procurement application, runs a marketplace (Commerce One Global Trading Network), and sells a marketplace platform. These products use the xCBL standard and the SAP Open Catalog Interface (OCI) for remote shopping.

Commerce Server Business Desk

An extensible, Web-based site management tool available in Microsoft Commerce Server 2002 that hosts business management modules you use to manage and analyze your commerce sites.

credential domain

An identification of the type of supplier identifier in use. The Dun & Bradstreet Data Universal Numbering System (DUNS) is a common credential domain.

cXML

(Commerce Extensible Markup Language) A streamlined standard for the exchange of XML-based business documents. For more information, see http://www.cxml.org/.

document definition

A set of properties used by BizTalk Server to represent an inbound or outbound document and that might provide a pointer to a specification. A specification defines the document structure, document type, and version. However, a pointer from the document definition to a specification is not required.

document specification

A BizTalk Server-specific XML schema. Document specifications are created in BizTalk Editor and can be based on industry standards (such as EDIFACT, X12, and XML) or on flat files (delimited, positional, or delimited and positional). BizTalk Mapper uses document specifications, opened as source specifications and destination specifications, to create map files.

Document Type Definition (DTD)

A standard definition that specifies which elements and attributes might be present in other elements and attributes and that specifies any constraints on their ordering, frequency, and content.

DUNS Number

Dun & Bradstreet Data Universal Numbering System. The D&B D-U-N-S Number provides unique identifiers of single business entities, while linking corporate family structures together. "DUNS" or "DunAndBradstreet" is a common credential domain.

envelope (as used in BizTalk Server)

A set of properties that can represent the transport information for a document. An envelope associated with an inbound document provides BizTalk Server with the information that it needs to interpret the submitted document. For example, the envelope can contain a pointer to the document definition. An envelope associated with an outbound document gives BizTalk Server the information that it needs to create the document. Envelope properties are optional for most file formats.

Extensible Stylesheet Language (XSL)

A style sheet format for XML documents. XSL is used to define the display of XML in the same way that Cascading Style Sheets (CSSs) are used to define the display of HTML. BizTalk Server uses XSL as a translation language between two specifications.

home organization

An object that represents your business in BizTalk Messaging Manager. The home organization is created for you when BizTalk Server 2002 is installed. Only the home organization can have applications.

map

An XML file that defines the correspondence between the records and fields in one specification and the records and fields in another specification. A map contains an Extensible Stylesheet Language (XSL) style sheet that is used by BizTalk Server to perform the transformation described in the map. Maps are created in BizTalk Mapper.

marketplace

A particular type of trading partner that specializes in aggregating the catalogs of various suppliers, providing a single environment in which users can shop from the combined set of products. When purchases are made, marketplaces send purchase orders to the relevant suppliers for fulfillment.

marketplace trading

A type of electronic trading enabled by Microsoft BizTalk Accelerator for Suppliers (AFS), characterized by a supplier publishing catalogs to, and receiving purchase orders from, a company (marketplace) that intends to make those products available to third parties for purchase. Also, marketplaces sometimes offer other services such as logistics and financing of transactions.

marketplace platform vendors

A company that sells marketplace software platforms to other companies so that they can set up and run their own marketplaces.

messaging port

A set of properties that specify how a document is transported to a destination organization or application. BizTalk Server uses messaging ports so that it can correctly process and transmit submitted documents. Messaging port properties include transport services, destination organization or application, security settings, and envelope settings.

organization

A trading partner or a business unit within a trading partner, or, in the case of the home organization, your own business.

peer-to-peer trading

A type of electronic trading enabled by Microsoft BizTalk Accelerator for Suppliers (AFS), characterized by a supplier publishing catalogs to, and receiving purchase orders from, another company that intends to use the purchased products themselves.

procurement application

A software application that manages the process of buying products. These aspects can include the imposition of spending limits, the routing of requisitions for approval before the generation of purchase orders, and so on.

Such applications are often referred to as Enterprise Resource Planning (ERP) applications.

Punchout

The name used by Ariba, and cXML in general, for remote shopping.

purchase order reception

In Microsoft BizTalk Accelerator for Suppliers (AFS), the process of receiving an XML purchase order from a trading partner in either xCBL 3.0, cXML 1.1, cXML 1.2, or SAP XML format, and then processing it into the Commerce Server database in which orders are stored.

remote shopping

A buyer application feature in which a user is temporarily redirected to the Web site of the original supplier of the product or service, where shopping or product configuration continues in a richer environment, and can eventually lead to the user purchasing one or more of those products or services through the trading partner buyer application.

RoundTrip

The name used by Commerce One for remote shopping.

sales channel

A particular way that a supplier makes their products and/or services available for sale. For example, a retail Web site, a marketplace, and so on.

SAP Interface Repository

The XML-based Interface Repository (IFR) is part of the Internet Business Framework. Its aim is to publish all standard SAP interfaces centrally as XML interfaces in agreement on W3C standards and to provide the customer with the necessary infrastructure for business scenarios.

SAP OCI 2.0

The version of the Open Catalog Interface (OCI) standard produced by Commerce One and SAP, and used for remote shopping, with which AFS has been tested.

shared secret

A value that trading partners use like a password to authenticate their suppliers.

supplier identifier

An identifier for a supplier, unique within a given, specified credential domain. For example, if the credential domain is specified as "DunAndBradstreet", the supplier identifier will be the 9-digit DUNS number of the supplier.

Tap Out

The name used by Clarus for remote shopping.

trading partner

In Microsoft BizTalk Accelerator for Suppliers (AFS), another business with which your business exchanges electronic data. Specifically, you publish electronic catalogs to your trading partners so that they can offer your products for sale on their Web sites, and you receive electronic purchase orders that communicate those sales to you for fulfillment.

Universal Standard Products and Services Classification (UNSPSC)

A commodity classification coding scheme.

Web Distributed Authoring and Versioning (WebDAV)

An extension to the HTTP 1.1 standard that exposes a hierarchical file storage media, such as a file system, over an HTTP connection. WebDAV locks documents to prevent users from accidentally overwriting changes made by others. It also enables users to share and work with server-based documents regardless of their authoring tools, platforms, or the type of Web servers on which the files are stored.

xCBL

(XML Common Business Library) A robust standard for the exchange of XML-based business documents. For more information, see http://www.xcbl.org/.

XLANG language

A language that describes the logical sequencing of business processes, as well as the implementation of the business process by using various application services. The XLANG language is expressed in XML.

XLANG schedule

Specific business processes expressed in the XLANG language. An XLANG schedule is saved with the file extension .skx.

XLANG schedule drawing

A drawing that represents a business process. In BizTalk Orchestration Designer, a drawing, after it is complete, can be compiled and run as an XLANG schedule. An XLANG schedule drawing is saved with the file extension .skv.

XML Data Reduced (XDR)

An XML schema dialect proposed by Microsoft and submitted to the World Wide Web Consortium (W3C) in 1998. Like XML-Data, XDR is a syntax for Extensible Markup Language (XML) schemas that define the characteristics of an XML document. XDR is a subset of XML-Data.

XSL

See Extensible Stylesheet Language.