Methods and Apparatus for Processing Catalog Spot Buys

Abstract

In one embodiment, a method comprises: receiving a procurement request for an item; determining whether the item is in a contracted catalog; processing the procurement request per a first set of procurement rules if the item is in the contract catalog; and processing the procurement request per a second set of procurement rules if the item is not in the contract catalog. The second set of procurement rules include procurement rules that are in the first set of procurement rules. In some embodiments, the method further comprises tracking the procurement requests for items not in the contract catalog. In some embodiments, the method further comprises analyzing the tracked procurement requests; and adding a tracked item to the contracted catalog based on the tracked procurement requests meeting a first set of criteria.

Description

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of United States Provisional Patent Application Ser. No. 62/005,856, filed on May 30, 2014, which is incorporated herein by reference in its entirety.

BACKGROUND

The present disclosure relates to methods and apparatus for procurement, and in particular, to methods and apparatus for processing catalog spot buys.

Unless otherwise indicated herein, the approaches described in this section are not admitted to be prior art by inclusion in this section.

Businesses use procurement applications to implement business defined procurement or buying processes for catalog-based purchases. Procurement applications provide ways for business users to find items from catalog and follow the procurement process to complete the purchase. These business processes are focused on biggest chunk of total spend with contracted suppliers. The process is not optimized for spend on non-contract catalog purchases. There is a need for systems and methods that optimize catalog-based non-contract spend to co-exist with contract-based catalog spend.

Large enterprises use procurement applications offered by vendors to implement policies that govern how catalog-based items are bought on behalf of the company. These applications provide ways for business users to find items from catalog. These catalogs come from preferred vendors and are approved by the procurement department. The procurement department enables the strategic catalogs from a set of preferred suppliers and vendors. The procurement department sources these catalogs based on past demand and other criteria. However business users have business needs that are ad-hoc, one-time purchases. Procurement departments do not strategically source such items because their need is not known beforehand or there is a low return on investment to support investing time and resources sourcing such purchases. The end result is that this ad-hoc, one-time spend may not follow company defined procurement/buying process. Furthermore business users have to follow one process to purchase items from catalog under contract and a different process to purchase items out of contract. This results in confusion, poor buying experience for business users, and procurement department having low to no visibility in spot buy spend from non-contracted catalog. This one-time, ad-hoc spend is also referred to as “spot buys” herein.

One of the main problems associated with spot buys is low return on investment for the procurement department to source one-time, ad-hoc spend catalog items. These spends are unpredictable; hence the procurement department cannot beforehand decide and define the sourcing strategy. The procurement department instead focuses on strategically sourcing items that they know beforehand company may buy as part of operations and sales.

In the absence of a well-defined business process business users fulfill their ad-hoc needs in various ways. In a first example, the business user may submit a request to procurement department to buy on their behalf. The procurement department has to fulfill this need by spending time and resource on random/arbitrary needs. In a second example, the business user may buy off of the Internet or other retailers and expense the purchase. In a third example, the user may buy but not expense the purchase.

Some applications allow business users to find catalog items by providing search and browse functionality on a contracted catalog, allowing a business user to find contracted catalog items and purchase them. Some procurement applications allow for adding arbitrary catalog items from online marketplaces such as Amazon to the shopping cart. But none of the existing applications/solutions provide controls to integrate a contracted catalog with a non-contracted catalog.

Thus, there is a need for improved processing catalog spot buys. The present invention solves these and other problems by providing methods and apparatus for processing catalog spot buys.

SUMMARY

Embodiments of the present disclosure improve processing catalog spot buys. In one embodiment, the present disclosure includes a method comprising: receiving a procurement request for an item; determining whether the item is in a contracted catalog; processing the procurement request per a first set of procurement rules if the item is in the contract catalog; and processing the procurement request per a second set of procurement rules if the item is not in the contract catalog.

In some embodiments, the second set of procurement rules include procurement rules that are in the first set of procurement rules.

In some embodiments, the method further comprises tracking the procurement requests for items not in the contract catalog.

In some embodiments, the method further comprises analyzing the tracked procurement requests; and adding a tracked item to the contracted catalog based on the tracked procurement requests meeting a first set of criteria.

In some embodiments, the method further comprises analyzing the tracked procurement requests; and determining categories of items based on the tracked procurement request; and adding a tracked item to the contracted catalog based on the tracked procurement requests meeting criteria.

In some embodiments, the method further comprises analyzing the tracked procurement requests; and adding a tracked item to the contracted catalog based on the tracked procurement requests meeting a first set of criteria.

In some embodiments, the method further comprises analyzing the tracked procurement requests; receiving a search query for a spot buy item; and adjusting the search results based on the analyzed tracked procurement requests.

In some embodiments, the present disclosure includes a non-transitory computer-readable storage medium containing instructions, that when executed, control a computer system to be configured for receiving a procurement request for an item; determining whether the item is in a contracted catalog; processing the procurement request per a first set of procurement rules if the item is in the contract catalog; and processing the procurement request per a second set of procurement rules if the item is not in the contract catalog.

In some embodiments, the present disclosure includes a computer implemented system comprises one or more computer processors; and a non-transitory computer-readable storage medium comprising instructions, that when executed, control the one or more computer processors to be configured for: receiving a procurement request for an item; determining whether the item is in a contracted catalog; processing the procurement request per a first set of procurement rules if the item is in the contract catalog; and processing the procurement request per a second set of procurement rules if the item is not in the contract catalog.

The following detailed description and accompanying drawings provide a better understanding of the nature and advantages of the present invention.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a block diagram of a procurement system for catalog spot buying according to some embodiments.

FIG. 2 illustrates a block diagram of a spot buy module of a procurement system for catalog spot buying according to some embodiments.

FIG. 3 illustrates a block diagram of a procurement system for catalog spot buying according to some embodiments.

FIG. 4 illustrates a data flow diagram for a shopping process according to some embodiments.

FIG. 5 illustrates a data flow diagram for a requisitioning process according to some embodiments.

FIG. 6 illustrates a data flow diagram for an order processing process according to some embodiments.

FIG. 7 illustrates a data flow diagram for a return order processing process according to some embodiments.

FIG. 8 illustrates a process flow diagram for procurement according to some embodiments.

FIG. 9 illustrates an exemplary computer system according to some embodiments.

DETAILED DESCRIPTION

Described herein are techniques for methods and apparatus for processing catalog spot buys. In the following description, for purposes of explanation, numerous examples and specific details are set forth in order to provide a thorough understanding of the present invention. It will be evident, however, to one skilled in the art that the present invention as defined by the claims may include some or all of the features in these examples alone or in combination with other features described below, and may further include modifications and equivalents of the features and concepts described herein.

Described herein are techniques that include controls and processes to bring contract and non-contract spend under a procurement process and system.

FIG. 1 illustrates a block diagram of a procurement system 100 for catalog spot buying according to some embodiments. Procurement system 100 comprises a procurement application 102, a spot buy module 104, a contracted catalog 106, a non-contracted catalog 108 and online market places 110.

In various embodiments, procurement application 102 includes processes that allow contracted catalog 106 and non-contracted catalog 108 to coexist in the procurement system 100 based on procurement policies. The procurement policies may include regional rules, departmental rules, user level rules, category level rules, combinations, etc. These rules can be defined for various reasons including existing relationships with preferred vendors, category goals, company goals, or company policies.

In a first illustrative example, a first company has sourced an information technology (IT) accessories catalog in the United States but the company lacks the resources to create an equivalent catalog for its branches in other countries. The first company can define a rule that allows users outside of the United States to purchase IT accessories from any non-preferred vendor.

In a second illustrative example, a second company has strong relationships with a vendor in specific category (e.g., maintenance, repair and operations (MRO)). Business users must buy MRO items from the preferred vendor to optimize the price. However, the second company may not have strong relationship in other categories, such as office supplies. Procurement system 100 may give business users of the second company the option of using other (e.g., non-preferred) vendors for those items.

Although procurement system 100 is described for procurement of items, procurement system 100 may be used for procurement of services.

Procurement application 102 processes search inquiries for items for purchase (e.g., spot buys or non-spot buys), requisitions for items, orders for items, and returns. Procurement application 102 processes procurement for contracted items in contracted catalog 106. In some embodiments, procurement application 102 has an index of contracted items and does not need to search contracted catalog 106 to make the determination. Procurement application 102 processes procurement of spot buys through spot buy module 104. In response to procurement requests for non-cataloged items, spot buy module 104 may process the procurement through non-contracted catalog 108 or in online market places 110. Spot buy module 104 may communicate with contracted catalog 106 to procure items or add items to the contracted catalog 106.

FIG. 2 illustrates a block diagram of spot buy module 104 according to some embodiments. Spot buy module 104 comprises an application programming interface (API) 202, a user interface module 204, a reporting interface module 206, a search module 208, a procurement rules module 210, a tracking module 212, a self-learning module 214, a non-contract catalog 216, and a contract catalog 218.

Application programming interface (API) 202 includes the APIs for the procurement process of spot buy module 104. Some or all of these APIs may be the same or similar to APIs of procurement application 102. Some of the APIs are described below in conjunction with FIGS. 4-7.

User interface 204 is a procurement user interface that provides information to help a user pick the best item based on various criteria. The criteria may include, for example, experience of other users from the user's company buying the same item from the non-preferred vendor, and experience of other users from my company with the non-preferred vendor, or experience of other business users on the procurement system 100. Various user interfaces (such as search results page and confirmation pages) are used in the flows described below in conjunction with FIGS. 4-7.

Reporting interface module 206 is a procurement user interface that provides reports to a user, procurement agent, or management of information related to spot buys, such as search metrics or procurement metrics.

Search module 208 processes search queries of spot buys from users and generates search results that are provided to user interface 204 for communication with the user. Search module 208 may include a relevance engine that sorts the search result based on procurement defined rules. In certain situations, the relevance engine may direct business users (from a specific company) to items from a specific seller. For example, a company has not sourced a certain item (in this example, tablet cases”), and business users may buy the tablet cases from many sellers. Over a period of time enough, the relevance engine detects that the tablet cases have being bought from a particular seller by business users from the company. The relevance engine may adjust the search results to make this particular seller's content more relevant in the search result. The end goal could be that this seller who was not a preferred seller for the company to begin with turns into a preferred seller based on spend volume. The relevance engine (in conjunction with the tracking module 212) causes the company to start sourcing tablet cases from this particular seller.

Procurement rules module 210 processes the rules and procurement policies for the spot buys. The procurement policies may include regional rules, departmental rules, user level rules, category level rules, combinations, etc. These rules can be defined for various reasons including existing relationships with preferred vendors, category goals, company goals, or company policies. The rules may define the implementation of search and browsing behavior across contract 218 and non-contract catalog 216. The rules may be based on existing contracts with preferred vendors, location, category (e.g., laptop computers), or user.

Tracking module 212 detects, records and tracks some or all of the activity related to spot buys. The tracked activity provides visibility into which non-preferred spot buy suppliers to turn into preferred suppliers. The tracked activity also provides visibility into which categories to strategically source based on buying across contract spend and non-contract spend.

Self-learning module 214 analyzes the tracked activity of tracking module 212 and determines whether to make a non-contracted item from a particular seller or sellers a contracted catalog. Self-learning module 214 federates the catalog items from various non-contracted sources including online marketplaces and ecommerce retailers.

Non-contract catalog 216 may be the non-contracted catalog 108. Contract catalog 218 may be the contracted catalog 106.

Spot buy module 104 brings contracted spend and non-contracted spend under the procurement processes of procurement system 100, and, in some instances, integrates contracted spend and non-contracted spend. This is facilitated based on procurement rules in procurement rules module 210. With the non-contract spend under control of procurement system 100, the speed of procurement of spot buys increases. Procurement system 100 makes it easier for business users to purchase spot buy content by following the procurement process. Tracking module 212 provides data for a spot buy sourcing strategy to procurement department. Tracking module 212 provides data for a procurement department to facilitate better spot buying from non-contracted catalog from preferred vendors as well as non-preferred vendors.

Processes of spot buys by procurement system 100 are next described.

FIG. 3 illustrates a block diagram of a procurement system 300 for catalog spot buying according to some embodiments. Procurement system 300 is an example implementation of procurement system 100. Procurement system 300 may be used to provide catalog based spot buy functionality in an enterprise and to procurement application users: The user adds a non-catalog item (in this example, a spot buy) to its requisition for a procurement agent to fulfill. The procurement agent may fulfill the order by collaborating with a preferred supplier, or buy on an e-commerce site. In some instances, the user buys using the e-commerce site or a physical store, and expenses the item. The procurement agent enters the order details into the procurement system 300. Procurement system 300 generates reports for review to identify items that can be put under contact.

Procurement system 300 comprises a procurement application 302, a business network 304, an electronic commerce marketplace (e-marketplace) 306, and a payment application 308. Procurement application 302 may be, for example, the procurement application 104.

The e-marketplace 306 may be, for example, an eBay® Marketplace or Amazon® Marketplace. The e-marketplace 306 comprises a public catalog 332, a catalog management module 334, a seller tools module 336, and an order processing module 338. Public catalog 332 provides a catalog that buyers can buy from. Catalog management module 334 processes search requests, orders, price requests and the like for items in public catalog 332. The seller tools module 336 include tools for sellers to manage catalog content, such as updating prices or availability. Order processing module 338 provides capabilities for processing the orders, such as payment processing, order routing, cancel order processing, dispute management, and the like.

Payment application 308 processes payment of ordered items and refunds for returned items. Payment application 308 may be, for example, an online payment provider, such as PayPal® or Alipay. Payment application 308 comprises a payment processing module 342, a settlement & disputes module 344, and an account manager 346. Payment processing module 342 processes payments for transactions in the e-marketplace 306. Settlement & disputes module 344 processes disputes between buyers and sellers, buyers and payment entities, or sellers and payment entities. Account manager 346 processes information related to users, such as form of payment, shipping address, and preferences. Payment application 308 processes credit cards or other methods of payment, and settlement, and handles risk management.

Procurement application 302 may include On-demand or On-premise enterprise applications. These applications provide a buying experience to the user and implement a procurement process to perform enterprise buying. Procurement application 302 comprises a shopping user interface (UI) 312, a contracted catalog content module 314, a requisitioning module 316, and a processing process module 318.

Shopping user interface (UI) 312 provides the user with a user interface to provide item information, order information, and other information for the user to search and make a spot buy. Contracted catalog content module 314 processes content from contracted catalog 218.

Procurement requisitioning module 316 processes requisitions from users that request purchase of items, returns, and the like. Requisitioning module 314 may process the requisitions described below in conjunction with FIG. 5.

Procurement process module 318 processes all procurement activity in the procurement application 302. The procurement activity may include the processes described below in conjunction with FIGS. 4-7.

Business network 304 provides process extension to one or more procurement applications 302 for performing business commerce with suppliers. For ease of discussion, only one procurement application is described below.

Business network 304 comprises an orders & invoices module 322, a process extensions module 324, a seller integration module 326, and a collaboration module 328. Orders & invoices module 322 processes order, purchase orders, invoices, requisitions, and returns. Process extensions module 324 provides process extension to one or more procurement applications 302 for performing business commerce with suppliers.

Seller integration module 326 processes information, such as stock information, item details and the like, from sellers and provides the information to procurement application 302. Collaboration module 328 processes communication between procurement agent 502 and supplies or vendors to supply a non-catalog item.

Procurement application 302 provides a unified buying experience across items from contracted catalog content and public catalog from the e-marketplace 306. In some embodiments, public procurement and contracted procurement are processed by procurement process 318 in procurement application 302.

In response to search request from a user, procurement application 302 sends search requests 350 for items, item details, inventory or stock out status, shipping information, seller profile, and the like. Procurement application 302 sends purchase orders 352-1 to business network 304, which in response thereto, sends purchase orders 352-2 to marketplace 306. Business network 304 may integrate procurement applications of different entities. In some embodiments, business network sends purchase orders 352-2 to the e-marketplace 306 using commerce extensible markup language (cXML).

Order processing 338 in the e-marketplace 306 handles payment processing via payment application 308 that may include a checkout process 354. Checkout process 354 may be for a guest or a registered user. The e-marketplace 306 provides an order confirmation (OC) 356-1 to business network 304, which in response thereto, provides an order confirmation (OC) 356-2 to procurement application 302. The e-marketplace 306 provides an advance ship notice (ASN) 358-1 to business network 304, which in response thereto, provides an advance ship notice (ASN) 358-2 to procurement application 302. For order cancellation, procurement application 306 provides a cancel order request 360-1 to business network 304, which in response thereto, provides a cancel order request 360-2 to the e-marketplace 306. The cancellation of an order may be per the flow described below in conjunction with FIG. 7.

In an example setup, a buyer sets up a buyer account in the e-marketplace 306. In some embodiments, this setup is done manually. A buyer may set up a buyer account in the payment processing 308, for example, if the buyer is not using a credit card directly for the purchase. An accounting department may setup an accounting setup in procurement application 302. Rules for spot buys may be setup by the enterprise operating the business network 304 or the procurement application 302.

FIG. 4 illustrates a data flow diagram for shopping process 400 according to some embodiments. In various embodiments, shopping includes searching, browsing, and filtering.

A user 402 provides a search request 404 to procurement application 302 for a search for spot buy connect. (The searches of FIG. 4 may be the searches 350 described above.) In response to the search request 404, procurement application 302 sends a search request 406 to e-marketplace 306 that executes, for example, a first API (API-1) for the search. The e-marketplace 306 provides the search results with filter 408 that is generated by the first API to procurement application 302. Procurement application 302 provides a search results page 410 to user 402.

In various embodiments, the first API (API-1) provides free text capability for searches. In some embodiments, the search is restricted to catalog items from quality suppliers. Examples of criteria include top rated supplier, plus some inventory criterion (e.g., available to buy now items only instead of auction items). The first API is a search API that may support pagination via parameters such as “start” and “size”.

In some embodiments, the search may include additional filtering based on business rules. In one embodiment, the business rules include exclusion from display any items from a set of categories. In one embodiment, the business rules include not showing any items from a set of suppliers. In one embodiment, procurement application 302 provides a default shipping address of user 402 to e-marketplace 306.

The search result may include any or all of an identifier, name or title, short description, image, price or lead time of the item. The search result may include any or all of seller name, a seller identifier, seller rating, and offer details (e.g., free shipping). The search result may include total search result count. The search result may include filtering options, such as color with options, size with options, manufactures with names, etc.

User 402 provides a search request 412 that filters the results of the search of e-marketplace 306 to procurement application 302 for a search based on the filtered results. In response to the search request 412, procurement application 302 sends a search request 414 to e-marketplace 306 that executes, for example, a second API (API-2) for the search. The e-marketplace 306 provides the search results with filter 418 that is generated by the second API to procurement application 302. Procurement application 302 provides a search results page 416 to user 402.

In various embodiments, the second API (API-2) is the same as the first API API-1 (Search) and further includes filtering. The second API may support filtering results further based on user selection. For example, user 402 may request to be shown only yellow colored items.

User 402 provides a view item details request 420 to procurement application 302. In response to the view item details request 420, procurement application 302 provides a fetch item details request 422 to e-marketplace 306 that executes, for example, a third API (API-3), to fetch the details of the requested item. The e-marketplace 306 provides the item details 424 to procurement application 302, which in response thereto, provides an items details page 426 to user 402.

In various embodiments, the third API (API-3) fetches item details from public catalog 332 (see FIG. 3). The third API may be called in other instances where a user 402 or a procurement application 302 requests item details. In some embodiments, the call is based on item identifier. In some embodiments, the third API (API-3) receives the default shipping address of user 402 for shipping rate calculation.

In some embodiments, the e-marketplace 306 provides items details that include item identifier, item name, a description (e.g., full or partial description), images, price, shipping price, taxes, and other details as shown on an item details page 426 of the e-marketplace 306. In some embodiments, the e-marketplace 306 provides items details that include return policy details with information to print return label as needed, configuration options (e.g., color or, size) that are used to buy the item, and seller metrics (e.g., ratings). In some embodiments, the e-marketplace 306 returns seller details that may include seller identifier, name, address, email, phone, and the like. This additional information supports instances when where the user decides to add the item to the cart for shopping.

User 402 provides a view seller details request 428 to procurement application 302, and in response thereto, procurement application 302 provides a fetch seller details request 430 to e-marketplace 306 that executes, for example, a fourth API (API-4), to fetch the details of the seller. The e-marketplace 306 provides a seller profile 432 to procurement application 302, which in response thereto, provides a seller profile page 434 to user 402.

In various embodiments, the fourth API (API-4) fetches seller details from e-marketplace 306. The fourth API may be called in other instances where a user 402 or a procurement application 302 requests item details. In some embodiments, the call is based on seller identifier. In various embodiments, the seller details may include a seller identifier, seller name, and seller metrics. The search results may include items to showcase. Further, certain categories can be restricted (e.g., exclude adult content from search results if a user searches for certain words or phrases.

FIG. 5 illustrates a data flow diagram for requisitioning process 500 according to some embodiments. The requisitioning process 500 includes adding one or more items to the cart/requisition and submitting the requisition for approval. Approval can be configured to be auto-approved or configured to have a professional buyer (in this example, a procurement or purchasing agent 502) as the final approver depending on commodity, amount, etc. For ease of illustration, requisitioning process 500 is described with a procurement agent 502, and that the procurement agent 502 has the last approval in the approval flow. The procurement approval may be automated with rules for approval and learning to adapt to new items. For ease of illustration, requisitioning process 500 is described for a single item purchase, but may be performed with multiple items purchase with a different user interface and multiple requests and results of those described.

In various embodiments, the requisitioning process 500 is performed after procurement application 302 provides item details page 426 (see FIG. 4) to user 402, and the user 402 has configured the item (e.g., selected color, size, and the like).

User 402 provides an item to cart or requisition 506 to procurement application 302, and in response thereto, procurement application 302 provides a check stock request 508 (or a check stock out request) to the e-marketplace 306 that executes, for example, a fifth API (API-5), to determine whether the requested item is in stock. The e-marketplace 306 provides a result indication 510 to procurement application 302, which in response thereto, provides a requisition page 512 to user 402.

In various embodiments, the fifth API (API-5) checks whether the requested item in the cart or requisition is in stock from e-marketplace 306. The fifth API also may be used to update pricing information. The fifth API receives one or more items to check (e.g., referenced by item identifier), the configuration of each item, and offers or discounts that are associated with the item when the item is added to the cart or requisition, and shipping address. The result indication may include an updated item pricing and availability information.

User 402 provides requisition for approval request 514 to procurement application 302, and in response thereto, procurement application 302 provides a check stock request 516 (or a check stock out request) to e-marketplace 306 that executes, for example, the fifth API (API-5), to determine whether the requisitioned item is in stock. The e-marketplace 306 provides a result indication 518 to procurement application 302, which in response thereto, provides a confirmation page 520 to user 402.

At this stage, procurement agent 502 reviews the requisition and determines whether to approve the requisition. Procurement agent 502 provides an access requisition for approval request 522 to procurement application 302, and in response thereto, procurement application 302 provides a check stock request 524 (or a check stock out request) to e-marketplace 306 that executes, for example, the fifth API (API-5), to determine whether the requisitioned item is in stock. The e-marketplace 306 provides a result indication 526 to procurement application 302, which in response thereto, provides a requisition page 528 to procurement agent 502. Procurement agent 502 provides an approval indication 530 to procurement application 302, and in response thereto, procurement application 302 provides a check stock request 532 (or a check stock out request) to e-marketplace 306 that executes, for example, the fifth API (API-5), to determine whether the requisitioned item is in stock. The e-marketplace 306 provides a result indication 534 to procurement application 302. At this stage, the requisition has been approved. Procurement application 302 queues 536 the requisition for ordering. Upon completion of the ordering (see FIG. 6), procurement application 302 provides a confirmation page 538 to procurement agent 502. The confirmation page 538 may be the order confirmation 356 (see FIG. 3).

In a system with a human procurement agent 502, the approval of the requisition is asynchronous. Thus, these follow-up stock checks are performed. In a system with an automated approval, these follow-up stock checks may be eliminated

FIG. 6 illustrates a data flow diagram for order processing process 600 according to some embodiments. After the requisition is approved in the requisition process 500, the order-processing process 600 is initiated.

Procurement application 302 provides a purchase order 602 to business network 304, which in response thereto, provides an acknowledgment (OK) 604 to procurement application 302. Business network 304 creates and configures 606 a seller account. Upon completion of the creation and configuration of the seller account, the e-marketplace 306 provides a purchase order 608 to e-marketplace 306 that executes, for example, a sixth API (API-6), to request the order. The e-marketplace 306 performs a checkout process 610, and provides an acknowledgment (OK) 612 to business network 304. Also, e-marketplace 306 processes 614 the order, and upon completion, provides an order confirmation 616 that is generated, for example, by a seventh API (API-7). In response to the order confirmation 616, business network 304 provides an acknowledgment (OK) 618 to e-marketplace 306. The e-marketplace 306 processes 620 a received shipping completion notification, and provides an advance shipping notice 622 to business network 304, using, for example, an eighth API (API-8). In response to the advance shipping notice 622, business network 304 provides an acknowledgment (OK) 624 to the e-marketplace 306, and provides an advance shipping notice 626 (which may be generated by the eighth API) to procurement application 302, which in response thereto, provides an acknowledgment (OK) 628 to business network 304. The advance shipping notices 622 and 626 may be the advance shipping notice 358 (see FIG. 3).

The sixth API (API-6) is an order request, such as a purchase order (PO) that business network 304 routes to e-marketplace 306. In some embodiments, the sixth API (API-6) uses an “OrderRequest” in cXML. In various embodiments, an order request document includes the seller that the order is for. In some embodiments, it is always one seller. The order request document may further include buyer information (e.g., name or shipping address), payment information (e.g., credit card or payment processing 308), one or more items (e.g., including item identifier, quantity, price, offer details, and the like), and credentials to perform a security check.

The seventh API (API-7) is an order confirmation that e-marketplace 306 generates to confirm an order in response to the completion of payment processing. In some embodiments, the seventh API (API-7) uses an “OrderConfirmation” in cXML. In some embodiments, e-marketplace 306 does not send confirmation directly to the user 402. The order confirmation may include items that have been confirmed.

The eighth API (API-8) is an advance shipping notice that the e-marketplace 306 and business network 304 generates to provide the buyer information about the shipping. In some embodiments, the eighth API (API-8) uses an “AdvancedShipNotice” in cXML. In some embodiments, e-marketplace 306 gives higher preference to sellers who provide this information. In some embodiments, e-marketplace 306 does not send the advance ship notice directly to the buyer. In some embodiments, the advance shipping notice includes shipping information and tracking numbers.

FIG. 7 illustrates a data flow diagram for return order processing process 700 according to some embodiments. Return orders, if allowed by the suppliers, may follow the return order processing process 700. In some embodiments, return order processing process 700 starts the return process from the user interface of e-marketplace 306. In some embodiments, casual users are not exposed to the user interface because these users do not have access to the buyer's account on e-marketplace 306.

User 402 searches for an order for an item to return by sending a find order request 702 to procurement application 302, which in response thereto, provides a fetch return details request 704 to e-marketplace 306 by executing, for example, a ninth API (API-9), to fetch the return details. The e-marketplace 306 provides a result 706 to procurement application 302, by executing, for example, the ninth API (API-9). In response to the result 706, procurement application 302 provides return details 708 to user 402. User 402 provides a start return process 710 to procurement application 302 if user 402 decides to return the item. In response to the start return process 710, procurement application 302 creates a return To Do 712 for procurement agent 502. (This example has a human procurement agent 502.) Procurement application 302 also provides a confirmation page 714 to user 402. Procurement agent 502 may process the return from a return User Interface. Procurement agent 502 provides a fill order return form 716 to e-marketplace 306, which in response thereto, sends procurement agent 502 a confirmation page 718. Procurement agent 502 provides a delete order request 720 to procurement application 302, by executing, for example, a tenth API (API-10), to delete the order. Procurement application 302 provides a confirmation page 722 to procurement agent 502 and provides a delete order request 724 to procurement application 302, by executing, for example, the tenth API (API-10), to delete the order. In response thereto, business network 304 provides an acknowledgment (OK) 726 to procurement application 302 and provides a delete order request 728 to e-marketplace 306, by executing, for example, the tenth API (API-10), to delete the order. In response thereto, e-marketplace 306 provides an acknowledgment (OK) 730 to business network 304.

The ninth API (API-8) is a fetch return details request that procurement application 302 and business network 304 generate to fetch return details for each item in the order.

The tenth API (API-10) is a delete order request that procurement agent 502, procurement application 302 and, business network 304 generate to cancel the order process in response to the delete order request. In some embodiments, the tenth API (API-10) uses a “Delete Order Request” in cXML.

FIG. 8 illustrates a process flow diagram 800 for procurement according to some embodiments. At 802, a procurement request for an item is received. At 804, procurement application 302 determines whether the item is in a contracted catalog. If, at 804, the item is in the contract catalog, procurement application 302 processes, at 806, the procurement request per a first set of procurement rules.

On the other hand, if, at 804, the item is not in the contract catalog, procurement application 302 processes the procurement request per a second set of procurement rules for spot buy items. At 810, tracking module 212 tracks the procurement requests for items not in the contract catalog, and, at 812, analyzes the tracked procurement requests. At 814, tracking module 212 adds a tracked item to the contracted catalog based on the tracked procurement requests meeting a first set of criteria.

At 816, tracking module 212 determines categories of items based on the tracked procurement request, and, at 818, adds a tracked item to the contracted catalog based on the tracked procurement requests meeting criteria.

FIG. 9 illustrates an exemplary computer system 900 according to some embodiments. A computer system 910 includes a bus 905 or other communication mechanism for communicating information, and a processor 901 coupled with bus 905 for processing information. Computer system 910 also includes a memory 902 coupled to bus 905 for storing information and instructions to be executed by processor 901, including information and instructions for performing the techniques described above, for example. This memory may also be used for storing variables or other intermediate information during execution of instructions to be executed by processor 901. Possible implementations of this memory may be, but are not limited to, random access memory (RAM), read only memory (ROM), or both. A storage device 903 is also provided for storing information and instructions. Common forms of storage devices include, for example, a hard drive, a magnetic disk, an optical disk, a CD-ROM, a DVD, a flash memory, a USB memory card, or any other medium from which a computer can read. Storage device 903 may include source code, binary code, or software files for performing the techniques above, for example. Storage device and memory are both examples of computer readable mediums.

Computer system 910 may be coupled via bus 905 to a display 912, such as a cathode ray tube (CRT) or liquid crystal display (LCD), for displaying information to a computer user. An input device 911 such as a keyboard and/or mouse is coupled to bus 905 for communicating information and command selections from the user to processor 901. The combination of these components allows the user to communicate with the system. In some systems, bus 905 may be divided into multiple specialized buses.

Computer system 910 also includes a network interface 904 coupled with bus 905. Network interface 904 may provide two-way data communication between computer system 910 and the local network 920. The network interface 904 may be a digital subscriber line (DSL) or a modem to provide data communication connection over a telephone line, for example. Another example of the network interface is a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links are another example. In any such implementation, network interface 904 sends and receives electrical, electromagnetic, or optical signals that carry digital data streams representing various types of information.

Computer system 910 can send and receive information, including messages or other interface actions, through the network interface 904 across a local network 920, an Intranet, or the Internet 930. For a local network, computer system 910 may communicate with a plurality of other computer machines, such as server 915. Accordingly, computer system 910 and server computer systems represented by server 915 may form a cloud computing network, which may be programmed with processes described herein. In the Internet example, software components or services may reside on multiple different computer systems 910 or servers 931-1235 across the network. The processes described above may be implemented on one or more servers, for example. A server 931 may transmit actions or messages from one component, through Internet 930, local network 920, and network interface 904 to a component on computer system 910. The software components and processes described above may be implemented on any computer system and send and/or receive information across a network, for example.

The above description illustrates various embodiments of the present invention along with examples of how aspects of the present invention may be implemented. The above examples and embodiments should not be deemed to be the only embodiments, and are presented to illustrate the flexibility and advantages of the present invention as defined by the following claims. Based on the above disclosure and the following claims, other arrangements, embodiments, implementations and equivalents will be evident to those skilled in the art and may be employed without departing from the spirit and scope of the invention as defined by the claims.

Claims

1. A method comprising:

receiving a procurement request for an item;

determining whether the item is in a contracted catalog;

processing the procurement request per a first set of procurement rules if the item is in the contract catalog; and

processing the procurement request per a second set of procurement rules if the item is not in the contract catalog.

2. The method of claim 1 wherein the second set of procurement rules include procurement rules that are in the first set of procurement rules.

3. The method of claim 1 further comprising tracking the procurement requests for items not in the contract catalog.

4. The method of claim 3 further comprising:

analyzing the tracked procurement requests; and

adding a tracked item to the contracted catalog based on the tracked procurement requests meeting a first set of criteria.

5. The method of claim 3 further comprising:

analyzing the tracked procurement requests;

determining categories of items based on the tracked procurement request; and

adding a tracked item to the contracted catalog based on the tracked procurement requests meeting criteria.

6. The method of claim 3 further comprising:

analyzing the tracked procurement requests; and

adding a tracked item to the contracted catalog based on the tracked procurement requests meeting a first set of criteria.

7. The method of claim 3 further comprising:

analyzing the tracked procurement requests;

receiving a search query for a spot buy item; and

adjusting the search results based on the analyzed tracked procurement requests.

8. A non-transitory computer-readable storage medium containing instructions, that when executed, control a computer system to be configured for:

receiving a procurement request for an item;

determining whether the item is in a contracted catalog;

processing the procurement request per a first set of procurement rules if the item is in the contract catalog; and

processing the procurement request per a second set of procurement rules if the item is not in the contract catalog.

9. The non-transitory computer-readable storage medium of claim 8 wherein the computer system is configured for tracking the procurement requests for items not in the contract catalog.

10. The non-transitory computer-readable storage medium of claim 9 wherein the computer system is configured for:

analyzing the tracked procurement requests; and

adding a tracked item to the contracted catalog based on the tracked procurement requests meeting a first set of criteria.

11. The non-transitory computer-readable storage medium of claim 9 wherein the computer system is configured for:

analyzing the tracked procurement requests;

determining categories of items based on the tracked procurement request; and

adding a tracked item to the contracted catalog based on the tracked procurement requests meeting criteria.

12. The non-transitory computer-readable storage medium of claim 9 wherein the computer system is configured for:

analyzing the tracked procurement requests; and

adding a tracked item to the contracted catalog based on the tracked procurement requests meeting a first set of criteria.

13. The non-transitory computer-readable storage medium of claim 9 wherein the computer system is configured for:

analyzing the tracked procurement requests;

receiving a search query for a spot buy item; and

adjusting the search results based on the analyzed tracked procurement requests.

14. A computer implemented system, comprising:

one or more computer processors; and

a non-transitory computer-readable storage medium comprising instructions, that when executed, control the one or more computer processors to be configured for: receiving a procurement request for an item; determining whether the item is in a contracted catalog; processing the procurement request per a first set of procurement rules if the item is in the contract catalog; and processing the procurement request per a second set of procurement rules if the item is not in the contract.

15. The computer implemented system of claim 14 wherein the second set of procurement rules include procurement rules that are in the first set of procurement rules.

16. The computer implemented system of claim 14 wherein the one or more computer processors are configured for tracking the procurement requests for items not in the contract catalog.

17. The computer implemented system of claim 15 wherein the one or more computer processors are configured for:

analyzing the tracked procurement requests; and

adding a tracked item to the contracted catalog based on the tracked procurement requests meeting a first set of criteria.

18. The computer implemented system of claim 15 wherein the one or more computer processors are configured for:

analyzing the tracked procurement requests;

determining categories of items based on the tracked procurement request; and

adding a tracked item to the contracted catalog based on the tracked procurement requests meeting criteria.

19. The computer implemented system of claim 15 wherein the one or more computer processors are configured for:

analyzing the tracked procurement requests; and

adding a tracked item to the contracted catalog based on the tracked procurement requests meeting a first set of criteria.

20. The computer implemented system of claim 15 wherein the one or more computer processors are configured for:

analyzing the tracked procurement requests;

receiving a search query for a spot buy item; and

adjusting the search results based on the analyzed tracked procurement requests.