System and method for managing ATP data in a distributed supply chain planning environment

Abstract

A fulfillment server (16) for managing ATP data in a distributed supply chain planning environment receives an ATP request (30) from one of multiple clients (12). The ATP request (30) includes multiple request line-items that each correspond to a desired product. The fulfillment server (16) then generates one or more component ATP requests (32) based on the request line-items and communicates component ATP requests (32) to at least one of multiple local fulfillment managers (14). In response, the fulfillment server (16) receives component quotations (34) from the local fulfillment managers (14), each corresponding to a component ATP request (32) and each including product availability information for the corresponding desired product. The fulfillment server (16) generates a quotation (36) that includes product availability information for all desired products, according to the component quotations (34), and communicates the quotation (36) to the client (12).

Claims

1. A system for automatically managing available-to-promise (ATP) data, comprising:

a client interface operable to facilitate communication between a centralized fulfillment server and a plurality of client systems;

an ATP server interface operable to facilitate communication between the centralized fulfillment server and a plurality of ATP servers; and

the centralized fulfillment server, the centralized fulfillment server allowing the plurality of client systems to submit ATP requests for quotation without first identifying or directly communicating with any of the plurality of ATP servers that are to be used in generating quotations corresponding to the ATP requests, the centralized fulfillment server operable to:

receive a first ATP request from a first one of the plurality of client systems using the client interface, the first ATP request comprising a plurality of request line-items each corresponding to a desired product;

automatically select a first plurality of ATP servers from among the plurality of ATP servers according to the request line-items within the first ATP request;

generate a plurality of component ATP requests based on the request line-items contained in the first ATP request;

communicate the plurality of component ATP requests to the selected first plurality of the ATP servers using the ATP server interface, one or more component ATP requests being communicated to each ATP server in the selected first plurality of ATP servers;

receive a plurality of component quotations from the selected first plurality of ATP servers using the ATP server interface, each component quotation corresponding to a component ATP request and comprising product availability information for one or more desired products corresponding to the component ATP request;

generate a quotation determined according to the product availability information provided by the plurality of component quotations received from the selected first plurality of ATP servers; and

communicate the quotation to the first one of the plurality of client systems using the client interface.

2. The system of claim 1, wherein the first ATP request specifies one or more business constraints and the centralized fulfillment server is further operable to evaluate the component quotations according to the business constraints in generating the quotation.

3. The system of claim 2, wherein at least some of the business constraints are based on a customer profile.

4. The system of claim 1, wherein the centralized fulfillment server is further operable to evaluate the component quotations according to supplier-specified business constraints in generating the quotation.

5. The system of claim 1, wherein each of the plurality of ATP servers is associated with a local fulfillment manager (LFM) that manages processing of component ATP requests at a planning engine associated with the ATP server.

6. The system of claim 1, wherein the centralized fulfillment server receives the first ATP request from the first one of the plurality of client systems and, concurrent with the first ATP request, receives a second ATP request from a second one of the plurality of client systems.

7. The system of claim 1, wherein the centralized fulfillment server is further operable to communicate at least one component ATP request to a target ATP server of the selected first plurality of ATP servers based on one or more business constraints within the first ATP request.

8. The system of claim 1, wherein the centralized fulfillment server allows the plurality of client systems to submit quotation confirmations for promising without directly communicating with any of the plurality of ATP servers that are to be used in generating promises corresponding to the quotation confirmations, the centralized fulfillment server further operable to:

using the client interface, receive a quotation confirmation comprising acceptances of at least some of the quotation line-items within the quotation, each of the quotation line-items corresponding to a particular accepted product;

automatically select one or more second ATP servers from among the selected first plurality of ATP servers according to the acceptances of quotation line-items within the quotation confirmation;

generate a component quotation confirmation for each accepted quotation line-item;

communicate component quotation confirmations to the one or more selected second ATP servers using the ATP server interface;

receive a plurality of component promises from the one or more selected second ATP servers using the ATP server interface, each corresponding to a component quotation confirmation and each representing a commitment of product availability for corresponding accepted products;

generate a promise comprising commitments of product availability for accepted products according to the component promises; and

communicate the promise to the first one of the plurality of client systems using the client interface.

9. The system of claim 8, wherein the centralized fulfillment server is further operable to evaluate the component promises according to business constraints profiled for a customer in generating the promise.

10. The system of claim 8, wherein the centralized fulfillment server is further operable to receive a promise acceptance from the first one of the plurality of client systems using the client interface and to communicate the promise acceptance to the one or more selected second ATP servers for fulfillment of the ATP request.

11. A centralized fulfillment server for operation in a distributed supply chain planning environment, operable to:

allow a plurality of client systems to submit available-to-promise (ATP) requests for quotation without first identifying or directly communicating with any of a plurality of local fulfillment managers (LFMs) that are to be used in generating quotations corresponding to the ATP requests;

receive at least one ATP request from a first one of the plurality of client systems, the ATP request comprising a plurality of request line-items each corresponding to a desired product;

automatically select a first plurality of LFMs from among the plurality of LFMs according to the request line-items within the first ATP request;

generate a plurality of component ATP requests based on the request line-items contained in the ATP request, each generated component ATP request corresponding to a request line-item;

communicate the plurality of component ATP requests to the selected first plurality of LFMs for quotation, one or more component ATP requests being communicated to each of the selected first plurality of LFMs, each selected first LFM being associated with a planning engine;

receive a plurality of component quotations from the selected first plurality of LFMs, each component quotation corresponding to a component ATP request and comprising product availability information for one or more desired products corresponding to the component ATP request;

generate a quotation determined according to the product availability information provided by the plurality of component quotations received from the selected first plurality of LFMs; and

communicate the quotation to the first one of the plurality of client systems.

12. The centralized fulfillment server of claim 11, wherein each of the plurality of ATP requests specifies one or more business constraints and the centralized fulfillment server is further operable to generate the plurality of component ATP requests according to the business constraints.

13. The centralized fulfillment server of claim 12, wherein at least some of the business constraints are based on a customer profile.

14. The centralized fulfillment server of claim 11, further operable to communicate at least one component ATP request to a target one of the selected first plurality of LFMs based on one or more business constraints within the ATP request.

15. The centralized fulfillment server of claim 11, further operable to:

receive a plurality of component promises from at least one of the selected first plurality of LFMs, each of the component promises corresponding to a component ATP request and representing a commitment of product availability for the corresponding desired product;

generate a promise comprising commitments of product availability for all the desired products according to the component promises; and

communicate the promise to the first one of the plurality of client systems.

16. The centralized fulfillment server of claim 15, further operable to evaluate component promises according to business constraints profiled for a customer in generating the promise.

17. A local fulfillment manager (LFM) having an associated available-to-promise (ATP) server and operating in a distributed supply chain planning environment including other LFMs, comprising:

a fulfillment server interface operable to facilitate communication between the LFM and a centralized fulfillment server, the centralized fulfillment server allowing a plurality of client systems to submit ATP requests for quotation without first identifying or directly communicating with any of the LFMs or associated ATP servers that are to be used in generating quotations corresponding to the ATP requests; and

an ATP server interface operable to facilitate communication between the LFM and the associated ATP server;

the LFM operable to receive one or more component ATP requests from the centralized fulfillment server, each component ATP request corresponding to a particular ATP request line-item for a desired product within an ATP request submitted by one of the plurality of client systems to the centralized fulfillment server for quotation, the LFM further operable to determine an ATP response for each ATP request line-item using the associated ATP server and generate a component quotation for each ATP request line-item according to the corresponding ATP response, each component quotation comprising product availability information for the desired product associated with the corresponding component ATP request, the LFM further operable to communicate each component quotation to the centralized fulfillment server for consolidation with one or more other component quotations from one or more other LFMs such that a quotation comprising the consolidated component quotations is returned to the one of the plurality of client systems without the one of the plurality of client systems first identifying or directly communicating with any of the LFMs from which the component quotations were communicated.

18. The LFM of claim 17, wherein each component ATP request specifies one or more business constraints and the LFM is further operable to evaluate the ATP response according to the business constraints in generating the component quotations.

19. The LFM of claim 18, wherein at least some of the business constraints are based on a customer profile.

20. The LFM of claim 17, wherein the LFM is further operable to generate the component quotations according to supplier-specified business constraints.

21. The LFM of claim 17, wherein the LFM manages processing of the component ATP requests at an associated planning engine, the LFM being operable to compute a portion of the ATP response according to information obtained from the ATP server, the portion depending on the capabilities of the ATP server and its associated planning engine.

22. The LFM of claim 17, further operable to:

receive from the centralized fulfillment server a component quotation confirmation for each component quotation accepted at the one of the plurality of client systems as a quotation line-item, the centralized fulfillment server allowing the one of the plurality of client systems to submit a quotation confirmation for promising without directly communicating with any of a plurality of LFMs or associated ATP servers that are to be used in generating a promise corresponding to the quotation confirmation;

determine a promise response for each accepted quotation line-item using the associated ATP server;

generate a component promise for each accepted quotation line-item, representing a commitment of product availability for the corresponding accepted product; and

communicate the component promises to the centralized fulfillment server for consolidation with component promises from one or more other LFMs such that a promise comprising the consolidated component promises is returned to the one of the plurality of client systems without the one of the plurality of client systems directly communicating with any of the plurality of LFMs from which the component promises were communicated.

23. The LFM of claim 22, further operable to evaluate the promise responses according to business constraints profiled for a customer in generating the component promise.

24. The LFM of claim 17, wherein the component ATP requests correspond to individual items and the LFMs are operable to compute component quotations that include information and rules regarding how the centralized fulfillment server may mutate those component quotations.

25. The LFM of claim 17, wherein the component ATP requests correspond to individual items and the LFMs are operable to compute component promises that include information and rules regarding how the centralized fulfillment server may mutate those component promises.

26. The LFM of claim 17, wherein the LFM is further operable to:

receive a sequence of component ATP requests from the centralized fulfillment server, one or more first component ATP requests in the sequence targeted to the LFM;

process the first component ATP requests targeted for the LFM to compute one or more resulting component quotations;

pass the resulting component quotations, along with remaining component ATP requests in the sequence, to a second LFM targeted by one or more second component ATP requests in the sequence.

27. The LFM of claim 17, wherein the LFM is operable to:

support a seller hierarchy also supported by the centralized fulfillment server;

support a subset of products supported by the centralized fulfillment server; and

compute component quotations or component promises on a per product basis based upon allocations throughout the seller hierarchy for the subset of products.

28. The LFM of claim 17, wherein the LFM is operable to:

support a subset of products in a hierarchy of related products supported by the centralized fulfillment server; and

compute component quotations or component promises based upon allocations for the subset of products throughout the hierarchy.

29. The LFM of claim 28, wherein the LFM is further operable to compute availability of generics of a product by sending component ATP requests to a second LFM that corresponds to the generic products.

30. The LFM of claim 17, wherein the LFM corresponds to a seller within a seller hierarchy supported by the centralized fulfillment server and is operable to:

hold allocations of supply for the corresponding seller;

compute all component quotations or component promises possible with the allocations it contains; and

send the component quotations or component promises to the centralized fulfillment server for combination, for each product, as if the ATP request had been quoted or promised by a single system having all the allocations.

31. The LFM of claim 30, wherein the LFM is further operable to compute availability of a corresponding parent seller by sending component ATP requests to a second LFM corresponding to the parent seller.

32. The LFM of claim 17, wherein the LFM is operable to accept component ATP requests from multiple centralized fulfillment servers and communicate component quotations or component promises to multiple centralized fulfillment servers.

33. The LFM of claim 17, wherein the LFM is operable to support a subset of a product hierarchy and compute component quotations or component promises based on allocations to products in the hierarchy.

34. A system for automatically managing available-to-promise (ATP) data, comprising:

a client interface operable to facilitate communication between a centralized fulfillment server and a plurality of client systems;

a local fulfillment manager (LFM) interface operable to facilitate communication between the centralized fulfillment server and a plurality of LFMs; and

the centralized fulfillment server, the centralized fulfillment server allowing the plurality of client systems to submit ATP requests for quotation without first identifying or directly communicating with any of the plurality of LFMs that are to be used in generating quotations corresponding to the ATP requests, the centralized fulfillment server operable to:

receive a first ATP request from a first one of the plurality of client systems using the client interface, the first ATP request comprising a plurality of request line-items each corresponding to a desired product;

automatically select a first plurality of LFMs from among the plurality of LFMs according to the request line-items within the first ATP request;

generate a plurality of component ATP requests based on the request line-items contained in the first ATP request;

communicate the plurality of component ATP requests to the selected first plurality of LFMs using the LFM interface, one or more component ATP requests being communicated to each LFM in the selected first plurality of LFMs;

receive a plurality of component quotations from the selected first plurality of LFMs through the LFM interface, each component quotation corresponding to a component ATP request and comprising product availability information for one or more desired products corresponding to the component ATP request;

generate a quotation determined according to the product availability information provided by the plurality of component quotations received from the selected first plurality of LFMs; and

communicate the quotation to the first one of the plurality of client systems using the client interface.

35. The system of claim 34, wherein the centralized fulfillment server computes the component ATP requests for individual items and the component quotations received from the selected first plurality of LFMs include information and rules regarding how the centralized fulfillment server may mutate those component quotations, the centralized fulfillment server further operable to mutate the component quotations according to the information and rules such that the component quotations together satisfy one or more business constraints.

36. The system of claim 34, wherein the centralized fulfillment server computes the component ATP requests for individual items and is operable to receive component promises from the at least one of the selected first plurality of LFMs that include information and rules about how the centralized fulfillment server may mutate those component promises, the centralized fulfillment server operable to mutate the component promises according to the information and rules such that the component promises together satisfy one or more business constraints, the centralized fulfillment server further operable to communicate the mutated component promises back to the at least one of the selected first plurality of LFMs such that the at least one of the selected first plurality of LFMs may adjust reservations of supply.

37. The system of claim 34, wherein the centralized fulfillment server is operable to:

compute component ATP requests that include all items supplied through the selected first plurality of LFMs and all business constraints on the first ATP request that apply to the items of the component ATP requests;

receive from each of the selected first plurality of LFMs component quotations fulfilling the business constraints; and

combine resulting multi-item component quotations to generate the quotation corresponding to the first ATP request.

38. The system of claim 34, wherein the centralized fulfillment server is operable to:

compute component ATP requests that include all items supplied through the selected first plurality of LFMs and all business constraints on the first ATP request that apply to the items of the component ATP requests;

receive from each of the selected first plurality of LFMs component promises fulfilling the business constraints; and

combine resulting multi-item component promises to generate a single promise corresponding to the first ATP request.

39. The system of claim 34, wherein:

at least some of the selected first plurality of LFMs hold separate allocations for the same product; and

the centralized fulfillment server is further operable to distribute quoting activity across multiple of the selected first plurality of LFMs to obtain component quotations for the product.

40. The system of claim 34, wherein the centralized fulfillment server is also operable as an LFM.

41. A method for automatically managing available-to-promise (ATP) data using a centralized fulfillment server, comprising:

using the centralized fulfillment server to allow a plurality of client systems to submit ATP requests for quotation without first identifying or directly communicating with any of a plurality of ATP servers that are to be used in generating quotations corresponding to the ATP requests;

receiving a first ATP request from a first one of the plurality of client systems using a client interface, the first ATP request comprising a plurality of request line-items each corresponding to a desired product;

automatically selecting a first plurality of ATP servers from among the plurality of ATP servers according to the request line-items within the first ATP request;

generating a plurality of component ATP requests according to the request line-items contained in the first ATP request;

communicating the plurality of component ATP requests to the selected first plurality of the ATP servers using an ATP server interface, one or more component ATP requests being communicated to each ATP server in the selected first plurality of ATP servers;

receiving a plurality of component quotations from the selected first plurality of ATP servers using the ATP server interface, each component quotation corresponding to a component ATP request and comprising product availability information for one or more desired products corresponding to the component ATP request;

generating a quotation in accordance with the product availability information provided by the plurality of component quotations received from the selected first plurality of ATP servers; and

communicating the quotation to the first one of the plurality of client systems using the client interface.

42. The method of claim 41, further comprising evaluating the component quotations according to one or more business constraints in generating the quotation, wherein the first ATP request specifies the business constraints.

43. The method of claim 42, wherein at least some business constraints are based on a customer profile.

44. The method of claim 41, further comprising evaluating the component quotations according to at least one supplier-specified business constraint in generating the quotation.

45. The method of claim 41, wherein each of the plurality of ATP servers is associated with a local fulfillment manager (LFM) operable to manage processing of a component ATP request at a planning engine associated with the ATP server.

46. The method of claim 41, further comprising receiving, concurrent with the first ATP request, a second ATP request.

47. The method of claim 41, wherein at least one component ATP request is communicated to a target ATP server of the selected first plurality of ATP servers based on one or more business constraints within the first ATP request.

48. The method of claim 41, further comprising:

using the centralized fulfillment server to allow the plurality of client systems to submit quotation confirmations for promising without directly communicating with any of the plurality of ATP servers that are to be used in generating promises corresponding to the quotation confirmations

receiving a quotation confirmation comprising acceptances of at least some line-items within the quotation, each of the quotation line-items corresponding to a particular accepted product;

automatically selecting one or more second ATP servers from among the selected first plurality of ATP servers according to the acceptances of quotation line-items within the quotation confirmation;

generating a component quotation confirmation for each accepted quotation line-item;

communicating component quotation confirmations to the one or more selected second ATP servers through the ATP server interface;

receiving a plurality of component promises from the one or more selected second ATP servers using the ATP server interface, each corresponding to a component quotation confirmation and each representing a commitment of product availability for corresponding accepted products;

generating a promise comprising commitments of product availability for the accepted products according to the component promises; and

communicating the promise to the first one of the plurality of client systems.

49. The method of claim 48, further comprising evaluating the component promises according to business constraints profiled for a customer in generating the promise.

50. The method of claim 48, further comprising:

receiving a promise acceptance; and

communicating the promise acceptance to the one or more selected second ATP servers for fulfillment of the ATP request.

51. A method for managing available-to-promise (ATP) data at a centralized fulfillment server within a distributed supply chain planning environment, comprising:

using the centralized fulfillment server to allow a plurality of client systems to submit ATP requests for quotation without first identifying or directly communicating with any of a plurality of local fulfillment managers (LFMs) that are to be used in generating quotations corresponding to the ATP requests;

receiving at least one ATP request from a first one of the plurality of client systems, the ATP request comprising a plurality of request line-items each corresponding to a desired product;

automatically selecting a first plurality of LFMs from among the plurality of LFMs according to the request line-items within the first ATP request;

generating a plurality of component ATP requests based on the request line-items contained in the ATP request, each generated component ATP request corresponding to a request line-item; and

communicating the plurality of component ATP requests to the selected first plurality of LFMs for quotation, one or more component ATP requests being communicated to each of the selected first plurality of LFMs, each selected first LFM associated with a planning engine;

receiving a plurality of component quotations from the selected first plurality of LFMs, each component quotation corresponding to a component ATP request and comprising product availability information for one or more desired products corresponding to the component ATP request;

generate a quotation determined according to the product availability information provided by the plurality of component quotations received from the selected first plurality of LFMs; and

communicate the quotation to the first one of the plurality of client systems.

52. The method of claim 51, further comprising:

communicating at least one component ATP request to a target one of the selected first plurality of LFMs based on one or more business constraints within the ATP request, the business constraints being based on a customer profile; and

evaluating the component quotations according to the business constraints in generating the quotation.

53. The method of claim 51, further comprising:

receiving a plurality of component promises from at least one of the selected first plurality of LFMs, each corresponding to a component ATP request and representing a commitment of product availability for the corresponding desired product;

generating a promise comprising commitments of product availability for the desired products according to the component promises; and

communicating the promise to the first one of the plurality of client systems.

54. A method operating at a local fulfillment manager (LFM) for managing available-to-promise (ATP) data, comprising:

receiving one or more component ATP requests from a centralized fulfillment server using a fulfillment server interface operable to facilitate communication between the LFM and the centralized fulfillment server, the centralized fulfillment server allowing a plurality of client systems to submit ATP requests for quotation without first identifying or directly communicating with any of a plurality of LFMs or associated ATP servers that are to be used in generating quotations corresponding to the ATP requests, each component ATP request corresponding to a particular ATP request line-item for a desired product within an ATP request submitted by one of the plurality of client systems to the centralized fulfillment server for quotation;

computing an ATP response for each ATP request line-item using an associated ATP server;

generating a component quotation for each ATP request line-item according to the corresponding ATP response, each component quotation comprising product availability information for the desired product associated with the corresponding component ATP request; and

sending each component quotation to the centralized fulfillment server for combination with one or more other component quotations from one or more other LFMs such that a quotation comprising the combined component quotations is returned to the one of the plurality of client systems without the one of the plurality of client systems first identifying or directly communicating with any of the plurality of LFMs from which the component quotations were communicated.

55. The method of claim 54, further comprising assessing the ATP response according to one or more business constraints specified in the ATP request to generate the component quotations.

56. The method of claim 55, wherein at least some business constraints are based on a customer profile.

57. The method of claim 54, further comprising generating the component quotations according to supplier-specified business constraints.

58. The method of claim 54, further comprising computing a portion of the ATP response according to information obtained from the associated ATP server, the LFM managing processing of the component ATP requests at the associated planning engine, the portion depending on the capabilities of the ATP server and its associated planning engine.

59. The method of claim 54, further comprising:

receiving, from the centralized fulfillment server, a component quotation confirmation for each component quotation accepted at the one of the plurality of client systems as a quotation line-item, the centralized fulfillment server allowing the one of the plurality of client systems to submit a quotation confirmation for promising without directly communicating with any of a plurality of LFMs or associated ATP servers that are to be used in generating a promise corresponding to the quotation confirmation;

determining a promise response for each accepted quotation line-item using the associated ATP server;

generating a component promise for each of the accepted quotation line-items, representing a commitment of product availability for the accepted products; and

sending the component promises to the centralized fulfillment server for combination with component promises from one or more other LFMs such that a promise comprising the combined component promises is returned to the one of the plurality of client systems without the one of the plurality of client systems directly communicating with any of the plurality of LFMs from which the component promises were communicated.

60. The method of claim 59, further comprising evaluating the promise responses according to business constraints profiled for a customer in generating the component promise.

61. The method of claim 54, wherein component ATP requests correspond to individual items, and further comprising computing component quotations including information and rules regarding how the centralized fulfillment server may mutate the component quotations.

62. The method of claim 54, wherein component ATP requests correspond to individual items, and further comprising computing component promises including information and rules regarding how the centralized fulfillment server may mutate the component promises.

63. The method of claim 54, further comprising:

receiving a sequence of component ATP requests from the centralized fulfillment server, one or more first component ATP requests in the sequence targeted to the LFM;

processing the first component ATP requests targeted for the LFM to compute one or more resulting component quotations;

passing the resulting component quotations, along with one or more remaining component ATP requests in the sequence, to a second LFM targeted by one or more second component ATP requests in the sequence.

64. The method of claim 54, further comprising:

supporting a seller hierarchy also supported by the centralized fulfillment server;

supporting a subset of products supported by the centralized fulfillment server; and

computing component quotations or component promises on a per product basis based upon allocations throughout the seller hierarchy for the subset of products.

65. The method of claim 54, further comprising:

supporting a subset of products in a hierarchy of related products supported by the centralized fulfillment server; and

computing component quotations or component promises based on allocations for the subset of products throughout the hierarchy.

66. The method of claim 54, further comprising computing availability of generics of a product by sending one or more component ATP requests to a second LFM that corresponds to the generic products.

67. The method of claim 54, wherein the LFM corresponds to a seller within a seller hierarchy supported by the centralized fulfillment server, and further comprising:

holding allocations of supply at the LFM for the corresponding seller;

computing all component quotations or component promises possible with the allocations the LFM contains; and

sending the component quotations or component promises to the centralized fulfillment server for combination, for each product, as if the ATP request had been quoted or promised by a single system having all the allocations.

68. The method of claim 67, further comprising computing availability of a corresponding parent seller by sending component ATP requests to a second LFM that corresponds to the parent seller.

69. The method of claim 54, further comprising:

accepting component ATP requests from multiple centralized fulfillment servers; and

sending component quotations or component promises to multiple centralized fulfillment servers.

70. The method of claim 54, further comprising:

supporting at the LFM a subset of a product hierarchy; and

computing component quotations or component promises at the LFM based on allocations to products in the hierarchy.

71. A method for automatically managing available-to-promise (ATP) data using a centralized fulfillment server, comprising:

using the centralized fulfillment server to allow a plurality of client systems to submit ATP requests for quotation without first identifying or directly communicating with any of a plurality of local fulfillment managers (LFMs) that are to be used in generating quotations corresponding to the ATP requests;

receiving a first ATP request from a first one of the plurality of client systems using a client interface, the first ATP request comprising a plurality of request line-items each corresponding to a desired product;

automatically selecting a first plurality of LFMs from among the plurality of LFMs according to the request line-items contained in the first ATP request;

generating a plurality of component ATP requests based on the plurality of request line-items contained in the first ATP request;

communicating the plurality of component ATP requests to the selected first plurality of LFMs using an LFM interface, one or more component ATP requests being communicated to each LFM in the selected first plurality of LFMs;

receiving a plurality of component quotations from the selected first plurality of LFMs through the LFM interface, each component quotation corresponding to a component ATP request and comprising product availability information for one or more desired products corresponding to the component ATP request;

generating a quotation according to the product availability information provided by the plurality of component quotations received from the selected first plurality of LFMs; and

communicating the quotation to the first one of the plurality of client systems using the client interface.

72. The method of claim 71, further comprising:

computing the component ATP requests for individual items, the component quotations received from the selected first plurality of LFMs including information and rules regarding how to mutate the component quotations; and

mutating the component quotations according to the information and rules such that the component quotations together satisfy one or more business constraints.

73. The method of claim 71, further comprising:

computing the component ATP requests for individual items, wherein component promises received from the selected first plurality of LFMs include information and rules concerning how to mutate the component promises;

mutating the component promises according to the information and rules, such that the component promises together satisfy one or more business constraints; and

communicating the mutated component promises back to the at least one of the selected first plurality of LFMs, such that the at least one of the selected first plurality of LFMs may adjust reservations of supply.

74. The method of claim 71, further comprising:

computing component ATP requests that include all items supplied through the selected first plurality of LFMs and all business constraints on the first ATP request that apply to the items of the component ATP requests;

receiving from each of the selected first plurality of LFMs component quotations fulfilling the business constraints; and

combining resulting multi-item component quotations to generate the quotation corresponding to the first ATP request.

75. The method of claim 71, further comprising:

computing component ATP requests that include all items supplied through the selected first plurality of LFMs and all business constraints on the first ATP request that apply to the items of the component ATP requests;

receiving from each of the selected first plurality of LFMs component promises fulfilling the business constraints; and

combining resulting multi-item component promises to generate a single promise corresponding to the first ATP request.

76. The method of claim 71, wherein at least some of the selected first plurality of LFMs hold separate allocations for the same product, and further comprising distributing quoting activity across multiple of the selected first plurality of LFMs to obtain component quotations for the product.

Description

TECHNICAL FIELD OF THE INVENTION

This invention relates generally to the field of supply chain planning, and more particularly to a system and method for managing order fulfillment in a distributed supply chain planning environment.

BACKGROUND OF THE INVENTION

Large and complex supply chains are typically managed by multiple planning organizations, each supporting one or more planning engines appropriate for the needs of the organization. For example, one organization might support a supply chain planner (SCP) engine, another might support a factory planner (FP) engine, and another might support yet another type of planning engine. As a result, matching of supply and demand, product allocation, and order promising and fulfillment tasks are likely to be managed using a variety of logically or geographically distributed planning engines. This presents numerous difficulties for customers and suppliers alike.

A lack of detailed visibility into extended supply chain operations often prevents companies from quoting accurate delivery dates and meeting customer orders in a timely manner. Even when there is adequate visibility, a lack of integration between front-end and back-end business objectives may result in lower margin products using up capacity, important market channels receiving worse service than less important market channels, and other sub-optimal commitments. Also, once delivery date and other commitments have been made, it is necessary to monitor the commitments throughout the production and logistics execution process to determine the effect of unexpected supply and demand changes. Accordingly, in a distributed supply chain planning environment, there exists a need for a single and consistent interface to the customer for order promising and fulfillment. The inability to provide such a capability negatively impacts order capture rates, delivery performance, and administrative costs associated with inventory, order processing, and other activities.

Despite numerous attempts in recent years, none have succeeded in creating an effective solution to manage order promising and fulfillment tasks across a network of computers in a distributed supply chain planning environment. While some companies have developed acceptable front-end or "customer-centric" solutions, and others have devoted tremendous energy to achieving suitable back-end supply chain optimization solutions, none have successfully integrated these front-end and back-end solutions to intelligently manage order promising and fulfillment tasks in this environment. As a result, for example, companies routinely over-promise and then lose money attempting to fulfill the commitments they have made, usually with mixed success. To compete effectively in the growing global Internet-based economy, companies must be able to make accurate commitments, aligned with business objectives of the company, and to fulfill their commitments in an efficient and profitable manner.

Furthermore, in such multi-enterprise endeavors, it is often economically or at least politically infeasible to completely re-deploy systems throughout the supply chain. Thus, for a solution system to be routinely deployable in most situations, it must have the ability to accommodate existing systems such that their capabilities are extended while allowing more sophisticated replacement systems to be subsequently introduced. The solution system must ultimately be able to productively co-exist with such existing or replacement systems. Previous techniques for the management of order promising and fulfillment are inadequate to meet these needs.

SUMMARY OF THE INVENTION

According to the present invention, disadvantages and problems associated with supply chain planning and order fulfillment within a distributed network environment have been substantially reduced or eliminated.

According to one embodiment of the present invention, a system for managing available-to-promise (ATP) data includes a client interface and an ATP server interface. A fulfillment server receives a first ATP request using the client interface, the first ATP request including multiple request line-items each corresponding to a desired product. The fulfillment server generates one or more component ATP requests based on the request line-items and communicates the component ATP requests to at least one of multiple ATP servers using the ATP server interface. The fulfillment server receives a plurality of component quotations from the ATP servers using the ATP server interface, each component quotation corresponding to a component ATP request and comprising product availability information for one or more corresponding desired products. The fulfillment server generates a quotation determined according to the product availability information provided by the component quotations and communicates the quotation through the client interface.

According to another embodiment of the present invention, a local fulfillment manager (LFM) has an associated ATP server and operates in a distributed supply chain planning environment including other LFMs. The LFM includes fulfillment server and ATP server interfaces. The LFM receives one or more component ATP requests from a fulfillment server, each component ATP request corresponding to a particular ATP request line-item for a desired product. The LFM determines an ATP response for each request line-item using the associated ATP server and generates a component quotation for each request line-item according to the corresponding ATP response. The component quotations include product availability information for corresponding desired products. The LFM then communicates the component quotations to the fulfillment server for consolidation with other component quotations from one or more other LFMs.

The present invention provides important technical advantages. The fulfillment server and LFMs of the present invention are capable of concurrently and intelligently managing order promising and fulfillment for complex multiple line-item ATP requests from a potentially very large number of clients according to specified user, customer, supplier, and any other business constraints. Where the ATP servers are geographically distributed from one another and the fulfillment server, across the Internet for example, the advantages of the present invention become particularly apparent. Further, where such ATP servers lie in different corporate boundaries, fulfillment server establishes a foundation for order promising and fulfillment capabilities not before possible. The present invention also provides clients a single interface for ATP requests, quotation confirmations, and promise acceptances that may rely on and affect ATP product allocation, material availability, or capacity availability at ATP servers and associated planning engines around the globe. This gives clients highly desirable visibility into extended supply chain operations, among other benefits.

The present invention minimizes the communications necessary between the fulfillment server and the LFMs to maximize bandwidth and minimize latency, which supports its usage in interactive systems (such as Internet web sites that provide online customers instant quotations for multi-item deliveries) and other applications that would not otherwise be possible. The present invention accomplishes this in part by providing clever and flexible placement of computations within the fulfillment server, LFMs, or ATP servers as appropriate, and also by engineering the LFM interface to communicate rich responses that can include numerous options simultaneously. This consistent LFM interface is provided while at the same time supporting a wide variety of ATP servers, including accommodation of existing ATP servers and similar systems not originally designed to support the extended features, operation, and architecture achieved by the present invention.

Moreover, the system architecture of the present invention contemplates that different environments would need to vary where certain computations occur in order to optimize performance as appropriate for the particular application. For example, some applications may need a system with extremely high throughput but can tolerate longer latencies, whereas others may require extremely short latencies but can tolerate less throughput. On the other side, some applications may need to support a huge number of products, while others may need to support huge networks of suppliers for each product, and still others may need large seller networks. The present invention provides adequate flexibility to support such diverse requirements. Other technical advantages will be readily apparent to those skilled in the art from the following figures, description, and claims.

BRIEF DESCRIPTION OF THE DRAWINGS

To provide a more complete understanding of the present invention and further features and advantages thereof, reference is now made to the following description taken in conjunction with the accompanying drawings, in which:

FIG. 1 illustrates an exemplary system for fulfilling commitments within a distributed supply chain planning environment according to the present invention;

FIG. 2 illustrates an exemplary ATP request workflow according to the present invention;

FIG. 3 illustrates an exemplary quotation confirmation workflow according to the present invention;

FIG. 4 illustrates an exemplary promise acceptance workflow according to the present invention; and

FIG. 5 illustrates an exemplary component promise changes workflow according to the present invention.

DETAILED DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an exemplary system 10 for fulfilling commitments in a distributed supply chain planning environment. System 10 includes one or more clients 12 representing appropriate Enterprise Resource Planning (ERP) systems, Sales Force Automation (SFA) systems, Order Management Systems (OMS), and any other suitable systems. Each client 12 may be associated with one or more customers, users, or other entities. In a particular embodiment, clients 12 may include sales and customer service oriented applications seeking to augment or replace their existing order promising and fulfillment capability. Clients 12 communicate and interact with fulfillment server 16 using an application-specific integration layer (not explicitly shown), which may include an application programming interface (API), an object request broker (ORB), or another suitable software interface operating at clients 12, fulfillment server 16, or both clients 12 and fulfillment server 16. Network 18 couples clients 12 to fulfillment server 16 and may be a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN), a global network such as the Internet, or any other suitable network or collection of networks.

Available-to-promise (ATP) servers 14 each support or are associated with a planning engine able to provide, among other things, product availability responses to component ATP requests in the form of component quotations. One or more planning engines associated with ATP servers 14 may also provide pricing and other additional capabilities, as appropriate. A local fulfillment manager (LFM) 22 that is located at or otherwise associated with each ATP server 14 manages the interaction between ATP server 14 and fulfillment server 16. In one embodiment, LFM 22 is a "thin" engine whose primary responsibility within system 10 is to communicate component requests, component quotations, component quotation confirmations, and component promises to and from ATP server 14 in a suitable format, and to monitor their status to the point of order fulfillment. ATP servers 14 provide services to fulfillment server 16 through an application-specific integration layer (not explicitly shown), which may include an API, ORB, or any other suitable software interface operating at ATP servers 14, fulfillment server 16, or both ATP servers 14 and fulfillment server 16. A network 20 coupling fulfillment server 16 to ATP servers 14 and may be a LAN, a MAN, a WAN, a global network such as the Internet, or any other appropriate network or collection of networks integral to or separate from network 18.

In one embodiment, LFMs 22 each provide the same interface and functionality to fulfillment server 16, but may be designed to work with different ATP servers. Many of the ATP servers 14 may be older ATP systems, fulfillment systems, or ERP systems that may be used to compute component quotations, but are not designed to work with fulfillment server 16 in a more comprehensive distributed network environment such as that associated with system 10. Other ATP servers 14 may not even have the ability to provide ATP quotations; rather, they may simply store or support information required to compute the ATP quotations. In still other cases, ATP servers 14 may be designed to work with fulfillment server 16, and as such may have an integrated LFM 22 to directly support the LFM interface of fulfillment server 16.

In each of these cases, LFM 22 is responsible for computing properly formed component quotations or component promises, handling the resulting acceptances, and ensuring that the corresponding material or capacity is indeed reserved. LFM 22 may have to do little but translate information communicated between the LFM interface of fulfillment server 16 and associated ATP server 14. In other situations, where the ATP server 14 is not designed to function as part of a larger system, LFM 22 may need to perform substantial computation or other manipulation of information. LFM 22 may even need to perform some of the ATP functionality if it is interacting with a system that is not designed for ATP, or if interacting with a slower system where the activity of the system needs to be circumvented where possible. The present invention provides for diverse flexibility in LFMs 22 and localizes translation to the more readily deployed LFMs 22 (keeping diverse ATP server variations separated from the computationally heavier and more complex fulfillment server 16).

In general, clients 12 submit ATP requests to fulfillment server 16, each request including one or more line-items pertaining to specific products that each may be ATP at one or more distributed ATP servers 14. Fulfillment server 16 brokers component ATP requests corresponding to these line-items to the appropriate LFMs 22 using the LFM interface and network 20. Each LFM 22 receiving a component ATP request in turn uses associated ATP server 14 to perform necessary computations and record any necessary reservations or changes. LFMs 22 sends resulting component quotations to fulfillment server 16, which manipulates the component quotations as appropriate and presents a unified overall quotation to the requesting client 12, commensurate with the original corresponding ATP request.

Client 12 may generate a quotation confirmation to totally or partially accept the quotation, which fulfillment server 16 manipulates as appropriate and sends to LFMs 22 as component quotation confirmations, each corresponding to a particular component ATP request. LFMs 22, in cooperation with their associated ATP servers 14, generate component promises that consume supply and form binding commitments between the customer and suppliers as to the requested products. Fulfillment server 16 presents a unified promise to client 12, commensurate with the corresponding ATP request, based on the component promises it receives from LFMs 22 and ATP servers 14. Client 12 may generate an acceptance to totally or partially accept the promise, then sending the acceptance to fulfillment server 16. Fulfillment server 16 sends component acceptances to LFMs 22 and LFMs 22 respond to fulfillment server 16 with component acceptance confirmations. Once fulfillment server 16 has sent a unified acceptance confirmation to client 12, based on component acceptance confirmations received from LFMs 22, the order promising and fulfillment cycle is complete. Operation of system 10 is described more fully below.

Clients 12, fulfillment server 16, LFMs 22, and ATP servers 14 may each operate on one or more computers or other suitable processing devices at one or more locations. Each such computer may include an input device, which may be any suitable keypad, touch screen, microphone, or other device to accept information. An output device may convey suitable information, including digital or analog data, visual information, and audio information. The input device and output device may support any suitable fixed or removable storage media, such as magnetic computer diskettes, CD-ROMs, or other media to receive information from and provide information to the computer. One or more processors and an associated volatile or non-volatile memory execute instructions and manipulate information according to the operation of the associated client 12, ATP server 14, LFM 22, or fulfillment server 16, as the case may be. Clients 12, fulfillment server 16, LFMs 22, and ATP servers 14 may be embodied in computer software, in computer hardware, or in any appropriate combination of software and hardware, and may be integral to or separate from one another. To support high availability or other performance requirements, system 10 may incorporate redundant clients 12, fulfillment servers 16, LFMs 22, and ATP servers 14, according to particular needs.

In one embodiment, for each of the LFMs 22 in system 10, fulfillment server 16 may maintain an LFM name, suitable descriptive information for LFM 22, an Internet Protocol (IP) or other network address for LFM 22, the identity of a designated back-up LFM 22 in case LFM 22 fails, and any other suitable information. Fulfillment server 16 may maintain ATP server group and hierarchy information for sourcing purposes. ATP server groups may model, for example, supplier groups, pricing groups, or geographic locations. Since fulfillment server 16 may operate according to both group and supplier sourcing preferences, as described more fully below, it may be desirable to relate one or more suppliers to any applicable ATP server groups. As an example, client 12 or an associated user might specify a preferred supplier, a preferred group, or both, in which case fulfillment server 16 directs component ATP requests to the appropriate LFMs 22 based on these preferences and the supplier-group mappings. Fulfillment server 16 may maintain, for each ATP server group, a group name, suitable descriptive information for the group, a parent group for the group, a list of child groups, a list of LFMs 22 in the group, a list of active suppliers associated with the group, and any other appropriate information. Sourcing preferences may be defined at any level within the ATP server group hierarchy.

A product may represent anything a user associated with client 12 may request, and may be tangible (e.g., a computer) or non-tangible (e.g., a service). Products are related to items, each of which can be related to multiple products. This allows for the modeling of different price points, lead times, suppliers, locations, or any other suitable characteristics for the same item. In addition, multiple items can be related to the same product. This allows, for example, for the modeling of multiple suppliers of the same product. In one embodiment, fulfillment server 16 may maintain, for each product, a product name, a product description, a default unit of measure (UOM), a default lot size or multiple, a cancellation window in which client 12 or an associated user may cancel an order, a customer-ranked, supplier-ranked, or other list of alternates or substitutes for the product, supplier-defined related products, locations for the product, active suppliers for the product, attribute types for the product such as style, size, and color, or any other appropriate product information. Fulfillment server 16 may also maintain information about attributes, separate from any particular product, such as attribute type, description, value range, UOM, particular attributes within an attribute type, and any other suitable attribute information.

Fulfillment server 16 may maintain sales channels (customers) and parent-child or other hierarchical relationships between sales channels, which fulfillment server 16 may use for order promising and other suitable purposes, as discussed more fully below. In one embodiment, definitions for each sales channel maintained at fulfillment server 16 include, in any combination and without limitation: (1) name, (2) description, (3) category, (4) parent, (5) children, (6) ranked or other list of groups fulfillment server 16 may use in determining product sourcing, (7) products customer has or may order, (8) ranked or other list of groups for given product, (9) ranked or other list of suppliers for each product, (10) whether customer accepts alternate or substitute products generally or for given product, (11) ranked or other list of alternate or substitutes for each product, (12) whether customer accepts alternate sourcing groups generally or for given product, (13) target or mandatory price limit or price range for each product, (14) whether the customer prefers only full shipments generally or for given product, (15) whether the customer prefers unfulfilled portions of requests to be canceled rather than carried as backlog generally or for given product, (16) whether the customer prefers only on-time shipments generally or for a given product such that early or late promises are rejected, (17) delivery window outside of which a late or early shipment is not acceptable, (18) required lot size or multiple for given product such that quotations are rounded based on this value, and (19) whether customer generally prefers that if request line-item is shorted then logically associated request line-items are shorted proportionally.

In general, allocation information may be held at any level of a sales channel or other hierarchy and may be as deep as necessary. Fulfillment server 16 may process request line-items through alternate groups or suppliers if a primary group or supplier is unable to service a request. Within a preferred group, supplier preferences are honored if they are defined. Lists of alternates or substitutes should generally not be restrictive, such that if an acceptable quotation response is not available from a preferred supplier, fulfillment server 16 may locate product allocation or materials or capacity availability from other potential suppliers. For requests that do not explicitly disallow alternates or substitutes, and do not specify customer-preferred alternates, the supplier may be able to respond with its own selection of alternates or substitutes.

Fulfillment server 16 may maintain information regarding suppliers and parent-child or other hierarchical relationships between suppliers, which fulfillment server 16 may use for order promising and other suitable purposes, as discussed more fully below. In one embodiment, definitions for suppliers maintained at fulfillment server 16 may include, in any suitable combination, without limitation: (1) name, (2) description, (3) category, (4) parent, (5) children, (6) the products the supplier provides, (7) the groups associated with the supplier, (8) ranked or other list of preferred customers for a given product, (9) acceptable alternates or substitutes for a given product, (10) minimum and maximum quantities for orders, (11) order quantity constraint not allowing fulfillment server 16 to reduce the quotation quantity without affecting validity of quotation, (12) cancellation restrictions, and (13) cancellation window outside of which orders cannot be canceled.

Fulfillment server 16 uses business constraints described above, which it may have previously stored, may receive within ATP requests from clients 12, or both, to source request line-items to particular LFMs 22 or to filter out any component quotation and component promise responses from LFMs 22 that do not satisfy these constraints. For example, if a supplier provides multiple alternative responses, or responses from alternative groups, fulfillment server 16 may filter out non-compliant responses or responses from unacceptable groups. If none of the alternatives comply, fulfillment server 16 may reject the response in whole. The existence of a list of alternates or alternate groups does not mean they will be used. In one embodiment, client 12 or an associated user may selectively override some or all of these business constraints when generating ATP requests, quotation confirmations, and promise acceptances, according to particular needs.

In one embodiment, fulfillment server 16 supports a hierarchy of one or more sellers of products and each LFM 22 supports the same hierarchy of sellers but with a subset of the products supported by fulfillment server 16. LFMs 22 compute component quotations or component promises based on allocations throughout the seller hierarchy for the corresponding products. These capabilities are described in copending U.S. application Ser. No. 08/491,167, filed Jun. 16, 1995 by Kennedy et al. for a "System and Method for Managing Available to Promise (ATP)," and copending U.S. application Ser. No. 08/802,434, filed Feb. 18, 1997 by Kennedy et al. for a "System and Method for Managing ATP," both of which are incorporated by reference herein. As a result, system 10 provides the ability to distribute product allocations to LFMs 22 and associated ATP servers 14 on a product by product basis, thereby gaining both space and time scalability in systems with large numbers of products.

Fulfillment server 16 may support one or more hierarchies of related or generic products, as described in U.S. application Ser. No. 08/802,434. LFMs 22 may support one or more subsets of the same hierarchies and may compute component quotations or component promises based on the allocations to the products in those sub-hierarchies. This provides additional technical advantages in applications where products are related by hierarchies.

One or more fulfillment servers 16 may work cooperatively, independently, or otherwise with the same set of LFMs 22. Each such LFM 22 may accept component ATP requests and component quotation confirmations from multiple fulfillment servers 16 and may send component quotations or component promises to multiple fulfillment servers 16. This offers numerous technical advantages, including the ability to scale the system to handle larger numbers of clients or larger numbers of ATP requests 30. In addition, this capability allows for the geographical or organizational distribution of fulfillment servers 16 according to particular needs.

Each fulfillment server 16 may enforce different business constraints, depending on the set of clients 12 each fulfillment server 16 supports. Each fulfillment server 16 may work with different sets of LFMs 22, where each LFM 22 may belong to one or more of the LFM sets corresponding to fulfillment server 16. Each fulfillment server 16 may also support its own supply or allocations for one or more of products. This offers numerous additional technical advantages, including significant flexibility in setting up distributed ATP systems with fulfillment servers 16 tailored and optimized to support a variety of clients 12. Moreover, these options facilitate setting up local allocations of product supply at fulfillment servers 16 to reduce latency and increase throughput for requests of common products.

Each fulfillment server 16 may have the capability to operate as an LFM 22. In one embodiment, each fulfillment server 16 will at least be an adequate ATP server 14 to support a separate LFM 22. In either situation, it is possible to form a hierarchy of LFMs 22 by using a first system, including a first fulfillment server 16, corresponding LFMs 22, and their associated ATP servers 14, as ATP server 14 within a second system that includes a second fulfillment server 16, corresponding LFMs 22, and the associated ATP servers. In this way, a hierarchy of LFMs 22 and ATP servers 14 of appropriate breadth and depth can be formed according to particular needs. The present invention contemplates any suitable relationship between one or more LFMs 22 and one or more fulfillment servers 16.

Such hierarchical organization facilitates numerous additional system designs and offers numerous additional technical advantages. For example, each LFM 22 in such a hierarchy may be assigned one or more products to handle, where the products are part of a hierarchy of related or generic products. In that case, the LFMs 22 may compute availability of the generics of an assigned product by sending component ATP requests 32 to the particular LFM 22 that corresponds to the generic products, providing further parallelization and scalability.

Also described in U.S. application Ser. Nos. 08/491,167 and 08/802,434, fulfillment server 16 may support a hierarchy of one or more sellers of products and each LFM 22 may correspond to a particular one of those sellers. LFM 22 may hold allocations of supply for its associated seller and compute all component quotations and component promises possible with allocations it contains. Fulfillment server 16 receives these component quotations or component promises and combines them for each product as if ATP request 30 had been quoted or promised by a single system having all of the allocations. As a result, system 10 provides the ability to distribute product allocations to LFMs 22 and associated ATP servers 14 on a seller by seller basis, thereby gaining both space and time scalability in applications with large numbers of sellers or gaining flexibility in applications where seller organizations are geographically or economically separated. Each LFM 22 may compute availability for its parent seller by sending one or more component ATP requests 32 to the LFM 22 corresponding to the parent seller. Furthermore, multiple LFMs 22 may hold separate allocations for a particular product and fulfillment server 16 may distribute quoting activity across such LFMs 22 as needed to obtain adequate quotes. These and other features of system 10 provide or otherwise allow for advantageous parallelization, scalability, throughput, as well as distributed deployment of seller systems.

To achieve even further scalability, further breakdowns can be made. In one embodiment, a first fulfillment server 16 can work with LFMs 22 that each are assigned or otherwise correspond to a one or more designated products. Each such LFM 22 can in turn use an ATP server 14 that is a second fulfillment server 16 backed by separate LFMs 22 that have each been allocated a portion of the overall supply allocation for a designated product. The second fulfillment server 16 can be designed to communicate to its LFMs 22 so as to minimize and balance the processing load placed upon each of those LFMs 22. Alternatively, the various LFMs 22 may be given different time slices of the horizon to handle, and component quotations 34 may be broken down and staged accordingly. This may increase latency to optimize scalability with respect to size and throughput.

In one embodiment, the components of system 10 use a protocol referred to as "Request-Promise-Accept" (RPA) in creating, managing, and fulfilling ATP requests relating to products. In general, according to the RPA protocol, a customer requests one or more products and a supplier offers a promise that meets the requirements of the customer request as closely as possible. Upon reviewing the offered commitment from the supplier, the customer either accepts or rejects the promise. If the customer accepts the promise, both customer and supplier generally consider this acceptance to form a binding agreement. In certain situations, a customer cannot freely cancel an acceptance within a specified time interval because of this commitment. The RPA protocol was developed as the basis for managing supply and demand requests between autonomous planning domains of a distributed supply chain as part of the RHYTHM supply chain planner (SCP) engine from I2 TECHNOLOGIES, INC.

FIGS. 2 through 5 illustrate the operation of system 10 through a series of workflows. These and other described workflows involve an interactive scenario with full use of the extended RPA protocol according to the present invention. However, not all possible workflows are interactive and not all result in full use of the extended RPA protocol. For example only and not by way of limitation, large companies may often process the bulk of their customer orders using Electronic Data Interchange (EDI) based techniques, in which an ATP request results in an ATP-consuming promise without further customer interaction. Those skilled in the art will appreciate that system 10 accommodates EDI-based and other suitable workflows, and that the present invention is intended to encompass all such workflows and associated operations.

ATP Request Workflow

FIG. 2 illustrates an exemplary ATP request workflow in which a multiple line-item ATP request 30 is created at client 12, client 12 submits ATP request 30 to fulfillment server 16, and fulfillment server 16 brokers ATP request 30 against one or more LFMs 22 in the form of component ATP requests 32. These LFMs 22 process component ATP requests 32 in cooperation with associated ATP servers 14, generate resulting component quotations 34, and send the component quotations 34 to fulfillment server 16. Fulfillment server 16 processes the component quotations 34 and generates a unified quotation 36, which is sent to client 12 for review.

Initiate ATP Request [Client]

In one embodiment, to initiate ATP request 30, client 12 or an associated user may be required to provide appropriate identification and security information. Client 12 may support default business rules or other constraints according to a user profile, a customer profile, or other suitable definitions. When the user accesses an ATP request screen associated with client 12, the screen may be populated with default parameters according to such definitions. The user may then optionally adjust some or all of these parameters to suit the needs of the particular ATP request 30. Such parameters may include shipping requirements, preferences with respect to product sourcing, product alternates or substitutions, and ship-to location, price targets, and any other appropriate parameters. The user may select from a table of available products, organized according to product group or in another suitable manner, using a product catalog, search engine, or otherwise. Once the user selects one or more products, the user may specify desired quantities, desired due dates, and any additional parameters such as those discussed above. The user may also logically group request line-items for shipment scheduling purposes. Client 12 executes an ATP request submission function when ATP request 30 is completely specified, sending ATP request 30 to fulfillment server 16.

ATP request 30 may be structured in a three-level parent-child hierarchy that includes a request object, a request line-item object, and a request line-item delivery object, although any suitable data or message structure may be used without departing from the intended scope of the present invention. As an example, an alternative three-level structure for ATP request 30 might include a request object that contains a list of one or more request delivery objects, each containing one or more request line-item objects.

Request Attributes

In one embodiment, the request object has the following attributes or otherwise supports the following information, in any suitable combination and without limitation: (1) user ID—user of client 12 submitting the request; (2) customer ID—used to determine business constraints relevant to request; (3) customer request ID—assigned at client 12 and used primarily for tracking purposes; (4) request ID-assigned at fulfillment server 16 and used for subsequent processing and administrative activities; (5) currency—the preferred currency for request, possibly defaulted from profiled business constraints; (6) sales channel (seller)—sales channel for request, useful where ATP servers 14 provide allocation functionality based on a multi-level channel hierarchy and seller determines channel from which to consume ATP; (7) request rank—numeric or other ranking of request relative to other requests for same product, useful as sort criterion where ATP servers 14 provide functionality relative to differential ranking of requests within order scheduling process, such as when allocating scarce supply in light of supply problems; (8) ship-to—ship-to location for request, which may default to each request line-item; (9) override customer constraints—allows user to override business constraint processing functionality of fulfillment server 16 such that the responses from LFMs 22 are not constrained; (10) total price target—user-specified total price target for request, which fulfillment server 16 may consider in evaluating the responses from LFMs 22 and, if not met, may indicate in resulting quotation; (11) alternates/substitutes allowed logical (yes/no) parameter defaulted from profiled business constraints, which user may be able to selectively override and fulfillment server 16 may use in processing request; (12) alternate location acceptable—logical parameter defaulted from the profiled business constraints, which user may be able to selectively override and fulfillment server 16 may use in processing request; (13) ship complete—logical parameter defaulted from profiled business constraints, which the user may be able to selectively override and fulfillment server 16 may use in processing request such that component quotations short of the request quantity attribute are rejected; (14) partial/cancel—logical parameter defaulted from profiled business constraints, which user may be able to selectively override and fulfillment server 16 may use in processing request such that late promises (unfulfilled portions of request) are either dropped or carried as backlog; (15) ship on-time—logical parameter defaulted from profiled business constraints, which the user may be able to selectively override and fulfillment server may use in processing request according to whether it is acceptable to receive early or late component promises from LFMs 22; (16) short proportional logical parameter defaulted from the profiled business constraints, which user may be able to selectively override and fulfillment server 16 may use in processing request such that promises among logically associated request line-items are reduced (shorted) in proportion in to another shorted request line-item; (17) initial date requested—date request first submitted to fulfillment server 16 for quotation; (18) last date requested—date request last submitted to fulfillment server 16 for re-quotation, if any; (19) date quoted—date request last quoted, if any; (20) date accepted—date client 12 last accepted request, if any; (21) date rejected—date client 12 last rejected request in full, if any; (22) date promised—date request last promised, if any; (23) date canceled—date request canceled, if any; and (24) date queued—date request last queued, if any.

In addition, the request object may support a request status field that fulfillment server 16 updates at certain milestones during the life of ATP request 30, including but not limited to: (1) "failed request"—request submitted for initial quotation or re-quote, but one or more request line-items do not meet requirements; (2) "pending quotation"—request submitted for initial quotation or re-quoted, but resulting quotation yet to be processed; (3) "failed quotation"—fulfillment server 16 determined quotation failed to meet profiled business constraints for request; (4) "pending acceptance"—fulfillment server 16 processed quotation and sent it to client 12, but client 12 yet to respond; (5) "acceptance not received"—quotation confirmation not received from client 12 by date and time specified in accept-by attribute, such that quotation essentially null and void; (6) "rejected"—fulfillment server 16 processed a rejection and sent it to LFMs 22; (7) "pending promise" fulfillment server 16 processed quotation confirmation, sent it to LFMs 22, and is now monitoring for component promise responses from LFMs 22; (8) "promised" fulfillment server 16 received component promises and has sent resulting promise to client 12; (9) "failed promise"—fulfillment server 16 has not yet received component promises from LFMs 22 and has thus sent failure notification to client 12; (10) "pending cancellation"—fulfillment server 16 processed a cancellation, sent it to LFMs 22, and is monitoring confirmation responses from LFMs 22; (11) "canceled" fulfillment server 16 received requisite cancellation confirmations from LFMs 22 and sent confirmation to client 12; and (12) "queued"—fulfillment server 16 processed a request queue command and is monitoring the request for re-quotation.

Request Line-Item Attributes

In one embodiment, the request line-item is an object having the following attributes or otherwise supporting the following information, in any combination and without limitation: (1) request ID—links request line-item to request; (2) request line-item ID—assigned at fulfillment server 16; (3) ship-to—default ship-to address for request line-item, which is defaulted from request, user may be able to selectively override, and is defaulted to request line-item delivery; (4) accept by—date and time by which user must accept quotation; (5) promise by—date and time by which fulfillment server 16 must respond with promise; (6) product ID—requested product for the request line-item; (7) product UOM—primary unit of measure (UOM) for the requested product; (8) request quantity—quantity or quantity range of product requested, which must equal combined delivery quantities if multiple request line-item deliveries are defined; (9) request date—date or date range product is required to arrive at customer ship-to location, which user may override if there are multiple request line-item deliveries for the request line-item; (10) category/attribute category/attribute combinations for the requested product; (11) line-item grouping relates multiple request line-items as logical grouping for delivery coordination, where grouping may represent configuration, bundled package of products, set of items that must ship together, or any other suitable grouping; (12) line-item price target—user-specified target price for request line-item, which fulfillment server may consider when evaluating ATP server responses and, if not met, may indicate in the resulting quotation; (13) preferred product/supplier—defaulted from profiled business constraints, which user may be able to selectively override and fulfillment server 16 uses when sourcing request line-item; (14) alternates/substitutes allowed—defaulted from profiled business constraints, which user may be able to selectively override and which fulfillment server 16 may use to process request line-item; (15) preferred alternates/substitutes—defaulted from profiled business constraints, which user may be able to selectively override and which may allow fulfillment server 16 and supplier to cooperate in selecting available alternates or substitutes for requested product; (16) mandatory—whether request line-item is mandatory relative to others in its grouping, such that insufficient quantities of a mandatory item may result in a failed quotation; (17) lot size/multiple—defaulted from basic product definition, which user may be able to selectively override and fulfillment server 16 may use in processing request line-item such that ATP server response quantities are rounded accordingly; (18) ship complete—defaulted from the profiled business constraints, which the user may be able to selectively override and fulfillment server 16 may use in processing request line-item; (19) partial/cancel—defaulted from profiled business constraints, which user may be able to selectively override and fulfillment server 16 may use in processing request line-item such that it may be dropped if not completely fulfilled; (20) ship on-time—defaulted from profiled business constraints, which the user may be able to selectively override and fulfillment server 16 may use in processing the request line-item to reject late or early promises; (21) LFM response status fulfillment server 16 monitors after brokering component ATP request to LFMs 22, such that when all the component quotations have been received fulfillment server 16 may begin evaluating quotation; (22) LFM-initiated event status—maintained at fulfillment server 16, such that if a planning event affects supply, LFM 22 notes this and informs fulfillment server 16 so that fulfillment server 16 may re-evaluate status of request relative to profiled business constraints and notify user of any change in request status; and (23) request line-item status—updated at certain milestones in the life cycle of the request line-item.

Request Line-Item Delivery Attributes

In one embodiment, the request line-item delivery is an object having the following attributes or otherwise supporting the following information, in any suitable combination and without limitation: (1) request line-item ID—links request line-item delivery to request line-item; (2) request line-item delivery ID—assigned at fulfillment server 16; (3) ship-to—default ship-to address for the request line-item delivery, which is defaulted from request line-item and user may selectively override; (4) request quantity—quantity or quantity range of product requested, which must equal request line-item request quantity; (5) request date—date or date range product is required to arrive at the customer ship-to location for the request line-item delivery, which user may be able to override if there are multiple request line-item deliveries for a request line-item; and (6) category/attribute—category—attribute combinations for the request line-item delivery, which the user may be able to selectively override if there are multiple request line-item deliveries for a given request line-item.

Process ATP Request [Fulfillment Server]

Each of the line-items associated with ATP request 30 may be fulfilled from a logically or geographically distinct ATP server 14. In this workflow, the primary tasks of fulfillment server 16 are to decompose ATP request 30 into individual request line-items, broker resulting component ATP requests 32 against the distributed network of ATP servers 14 using network 20 and LFMs 22, evaluate component quotations 34 received from LFMs 22, and send a unified quotation 36 to client 12 using network 18. If multiple deliveries have been specified for a given request line-item, fulfillment server 16 creates a separate component ATP request 32 for each delivery. Some or all component ATP requests 32 may be pre-sourced to particular LFMs 22 according to customer business constraints, user preferences, or supplier-preferred sourcing rules. In the alternative, sourcing preferences may be unspecified, such that multiple LFMs 22 have an opportunity to provide quotation responses. In one embodiment, fulfillment server 16 decomposes and encapsulates customer and other suitable business constraints into component ATP requests 32 before sending them to LFMs 22.

For each product, a supplier may specify minimum and maximum order quantity requirements. In one embodiment, if the parameters of such requirements have been specified, fulfillment server 16 evaluates at the outset whether each request line-item meets such requirements. If any request line-items do not meet specified requirements, a failure response is generated and sent to the requesting client 12 using network 18. In this case, fulfillment server 16 update the status of ATP request 30 and possibly of the failed component ATP requests 32 to "failed request."

Fulfillment server 16 may attempt to define the sourcing for each request line-item according to supplier or location. Fulfillment server 16 may then specifically target the component ATP requests 32 to particular LFMs 22. Because the user may have overridden profiled default constraints, fulfillment server 16 first evaluates the request line-item and request line-item delivery details, then checks the alternate supplier and location sourcing attributes to determine whether alternates are allowed for ATP request 30. If alternates are not allowed, then the primary relationship specified in ATP request 30 will be honored. If alternate sourcing is allowed, then the user, customer, or other alternate sourcing preferences take precedence. If no such sourcing preferences have been specified, fulfillment server 16 may check for the existence of any supplier default preferences. If no specified preferences exist for the supplier either, component ATP requests 32 may be marked "unspecified" relative to the target LFM 22. In this case, multiple LFMs 22 may be allowed to service and respond to component ATP requests 32 as appropriate.

Fulfillment server 16 may attempt to define alternate or substitution preferences for ATP request 30. Fulfillment server 16 may include alternate product information in component ATP requests 32. Since the user may have selectively overridden profiled default constraints, fulfillment server 16 first evaluates request line-item and request line-item delivery details, then checks ATP request 30 to determine whether alternates or substitutions are allowed. If not allowed, then the primary relationship specified in ATP request 30 are honored. If alternate or substitute products are allowed, then user, customer, or other suitable alternate or substitution preferences take precedence. If no such preferences are specified, fulfillment server 16 may check for any supplier default preferences. If no specified preferences exist for the supplier either, component ATP requests 32 may be marked as "unspecified" relative to alternates and substitutions. In this case, LFMs 22 may respond to component ATP requests 32 with multiple product options.

Fulfillment server 16 generates the component ATP requests 32 with embedded business constraints. Since the user may have interactively overridden profiled default constraints, fulfillment server 16 uses request line-item and request line-item delivery details for defining attributes of component ATP request 32. In one embodiment, the following constraints are defined, in any suitable combination and without limitation: request quantity, ship complete, partial/cancel, ship on-time, alternates/substitutes allowed, preferred alternates/substitutes, lot size/multiples, and consume forward/backward boundaries. Fulfillment server 16 may also indicate that component ATP request 32 is to be further constrained in some manner according to profiled business constraints. Once component ATP requests 32 have been generated, fulfillment server 16 sends the component ATP requests 32 to one or more LFMs 22 for servicing using network 20. Fulfillment server 16 may also update the status of ATP request 30 and possibly component ATP requests 32 to "pending quotation."

In one embodiment, fulfillment server 16 computes or otherwise generates a sequence of component ATP requests 32 that it sends to a particular LFM 22 associated with a first component ATP request 32 in the sequence. The target LFM 22 accepts the sequence, processes the component ATP request 32 specifically targeted to it, and then passes resulting component quotations or component promises, along with remaining component ATP requests 32 in the sequence, to LFM 22 targeted by the next component ATP request 32. In turn, that LFM 22 accepts the sequence, processes the component ATP requests 32 specifically targeted to it, and passes resulting component quotations or component promises, along with any remaining component ATP requests 32 in the sequence, to the LFM 22 targeted by the next component ATP request 32. Each such LFM 22 may compute its component quotations or component promises such that they satisfy all suitable business constraints relative to component quotations or component promises made by other LFMs 22 earlier in the sequence. Fulfillment server 16 receives the sequence of resultant component quotations or component promises from the last such LFM 22 and generates a combined quotation or promise corresponding to the ATP request 20 from client 12.

Component ATP Request Attributes

In one embodiment, component ATP request 32 is an object having some or all attributes of the request line-item and request line-item delivery objects. Fulfillment server 16 embeds business constraints into the component request that are relevant to functions of LFMs 22. The component request may have the following attributes or may otherwise support the following information, in any suitable combination and without limitation: (1) component request ID—assigned at fulfillment server 16 when it creates component request; (2) LFMID—target LFM 22 for component request, which may remain unspecified where sourcing relationship is not specified or derived at fulfillment server 16 and in which case any LFM 22 is free to respond to the component request if it can meet requirements; (3) fulfillment server ID—network address or other identifier for fulfillment server 16, useful in environment having multiple fulfillment servers 16; (4) sales channel (seller) for component request; (5) request rank for parent request; (6) request line-item ID links component request to request line-item; (7) request line-item delivery ID; (8) product ID—may correspond to product ID known to one or more target LFMs 22 and possibly the corresponding ATP servers 14; (9) product UOM—may correspond to product UOM used at one or more target LFMs 22 and possibly the corresponding ATP servers 14; (10) request quantity; (11) request date; (12) category/attributes; (13) ship complete; (14) partial/cancel; (15) ship on-time; (16) lot size/multiples; (17) alternates/substitutes allowed; (18) preferred alternates/substitutes; and (19) consume forward/backward boundaries—defines delivery window the customer is willing to accept, which may control how far forward or backward from the request date ATP servers 14 will search for available quantities.

In addition, the component request object may support a request status field that fulfillment server 16 updates at certain milestones in the life cycle of the component request, including but not limited to: (1) "pending quotation"—component request has been submitted for initial quotation or re-quoted, but resulting quotation not processed; (2) "failed quotation"—fulfillment server 16 determined component quotation failed to meet requirements for the component request; (3) "pending quotation confirmation"—fulfillment server 16 has processed quotation and transmitted it to client 12, which has yet to respond; (4) "confirmation not received" confirmation not received from client 12 by date and time specified in accept-by attribute, such that the quotation is essentially null and void; (5) "rejected" fulfillment server 16 has processed rejection and sent it to LFMs 22; (6) "pending promise"—fulfillment server 16 has processed the quotation confirmation, sent it to the LFMs 22 as component confirmations, and is monitoring promise responses; (7) "promised"—fulfillment server 16 received requisite component promises and sent the resulting promise to client 12; (8) "failed promise"—fulfillment server 16 has not received requisite component promises and has sent resulting failure notification to client 12; (9) "pending cancellation"—fulfillment server 16 processed a cancellation, sent it to LFMs 22, and is monitoring confirmation responses; and (10) "canceled" fulfillment server 16 received component cancellation confirmations from LFMs 22 and sent cancellation confirmation to client 12.

Process Component ATP Requests [LFM]

Component ATP requests 32 from fulfillment server 16 are received at each of the appropriate LFMs 22. As discussed above, an LFM 22 is generally responsible for managing component ATP requests 32 and communicating between fulfillment server 16 and associated ATP server 14 over the life of ATP request 30. In one embodiment, LFM 22 is involved in quotation, promise, acceptance, shipping, and archive operations for associated ATP server 14. If specified sourcing preferences exist, component ATP requests 32 may include this information, such that LFMs 22 may identify and process component ATP requests 32 accordingly. If there are no specified sourcing preferences, LFMs 22 may be capable of identifying relevant component ATP requests 32 based on the user, customer, or product. At a particular ATP server location, LFM 22 receives component ATP request 32 and generates a quotation request to ATP server 14 using the command syntax suitable for the particular associated planning engine. As part of this processing, LFM 22 evaluates the business constraints encapsulated in component ATP request 32 and acts accordingly.

Planning engines may vary relative to the requirements of this interface. As an example, FP engines typically do not maintain ATP from which request transactions will consume allocated product availability. Each component request is planned against a representation of finished goods inventory, available materials or capacity, and other suitable factors to determine product availability. There may be little functionality for controlling the output structure of the resulting quotation response from the standpoint of shipment timing and lot sizing. In this situation, LFM 22 may submit the quotation request as a planning transaction and evaluate the quotation response according to the business constraints encapsulated in component ATP request 32. If the response from ATP server 14 does not meet these requirements, LFM 22 identifies this and sends a failure notification to fulfillment server 16.

For example, if the ship complete attribute within component ATP request 32 requires the request to be met in full, and the quotation response from ATP server 14 was less than the requested quantity attribute, then LFM 22 might indicate the component quotation 34 as having failed and provide an appropriate descriptive failure annotation. This front-line evaluation may be important since, depending on the planning engine, the ATP server response may be multi-dimensional (offering multiple options). Providing response evaluation at the LFM level rather than at the fulfillment server level allows failure conditions to be identified and summarized before component quotations 34 are sent back to fulfillment server 16, thereby reducing overall network load.

As an example of a multi-dimensional ATP server response, consider a given request line item (e.g., 100 wheels on May 8), for which the response might be that 60 wheels are available on May 8 for $22, and/or 30 wheels on May 10 for $16, and/or 100 wheels on May 12 for $16. These are multiple options for the line-item quote. System 10 may allow for the incorporation of rules and ranges. For example, the ability to take 30 wheels on May 10 and the remaining 70 wheels on May 12 may be constrained if the option for $16 on May 12 includes a quantity restriction inconsistent with this.

As a further example, consider a three line-item request (e.g., 100 wheels, 25 simple axles, and 25 complex axles delivered proportionally on May 8). Individual line-item quotes can be computed as above, with multiple options, then combined in some suitable manner. For example, the simple axles might be available on May 9, 15 units, and May 11, 25 units, for $10. The complex axles might be available on May 8, 10 units, and May 10, 25 units, for $25. Ignoring the proportionality business constraint included in the request, delivery of products satisfying the order might occur over several days, May 8 through May 12, as appropriate. A proportionality business constraint, however, might mandate that line-items only be delivered in amounts proportional to how they were requested, since for example it may do no good to be delivered wheels if no axles are delivered. The above might result in the following exemplary multi-dimensional quote that includes multiple line-item quotes and obeys an exemplary proportionality business constraint: