MXPA01002867A - System and method for managing atp data in a distributed supply chain planning environment - Google Patents

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).

Description

SYSTEM AND METHOD FOR HANDLING DATA AVAILABLE FOR PROMISE IN A CHAIN PLANNING ENVIRONMENT DISTRIBUTED SUPPLY TECHNICAL FIELD OF THE INVENTION This invention relates generally to the field of supply chain planning, and more particularly to a system and to a method for managing the fulfillment of the order and 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 to the needs of the organization. For example, one organization can support a supply chain glider engine (SCP), another can support a factory glider engine (FP), and another can support yet another type of planning engine. As a result of this, the marriage of provision and demand, product endowment and order fulfillment and fulfillment tasks are feasible to be managed using a variety of logically or geographically distributed planning engines. This presents numerous difficulties for customers and suppliers as well.

A lack of detailed visibility in extended supply chain operations often prevents companies from accurately citing dates between and satisfying customer orders in a timely manner. When there is adequate visibility, a lack of integration between the front-end and the back-end business objectives may result in lower margin products using capacity, important market channels receiving service rather than less important market channels, and Other suboptimal commitments. Also, once a delivery date and other commitments have been promised, it is necessary to monitor the commitments through the production and the logistic execution process to determine the effect of unexpected supply and demand changes. Therefore, in a distributed supply chain planning environment, there is a need for a single and consistent interconnection for the client to promise and fulfillment of order. The lack of ability to provide such capacity negatively impacts order picking rates, delivery delivery, and administrative costs associated with inventory, order processing, and other activities.

Despite numerous attempts in recent years, none has been successful in creating an effective solution for the management of promise tasks and order fulfillment through a computer network in a distributed supply chain planning environment. Even though some companies have developed acceptable front-end or "customer centric" solutions, and others have devoted tremendous energy to achieving adequate end-to-end supply chain optimization solutions, none has successfully integrated these front-end and end-of-pipe solutions. rear end pair intelligently handle the tasks of promise and fulfillment of order in this environment. As a result of this, for example, companies routinely promise more and then lose money trying to fill or fulfill the commitments that have been made, usually with mixed success. To compete effectively in the global based internet economy, companies must be able to make more accurate commitments, aligned with the business objectives of the company, and to fulfill these commitments in an efficient and profitable way.

In addition, in such tasks of multiple companies, it is frequent that it is not possible economically or at least politically to completely re-deploy the systems through the supply chain. Therefore, for a solution system to be deployed routinely in most situations it must have the ability to accommodate existing systems so that their capabilities are extended while more sophisticated replacement systems are allowed to be introduced subsequently. The solution system must finally be able to coexist productively with existing or replacement systems. The preferred techniques for managing promise and order compliance are inadequate to meet these needs.

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

According to an embodiment of the present invention, a system for managing data available for promes (ATP) includes a client interconnection and a data server interconnection available for promise. A fulfillment server receives a first request of available pair promise using the interconnection of the client, the first request of available for promise includes the items of line of multiple request each corresponding to a desired product. The compliance server generates one or more requests d available for component promise based on the request line items and communicates requests for available pair promise of component to at least one of the multiple servers available for promise using the interconnection d server available for promise. The fulfillment server receives a plurality of server component appointments from available to promise using the server interconnection available for promise, each component appointment corresponding to a request available for a component promise comprising product availability information for a or more corresponding desired products. The fulfillment server generates a given appointment according to the product availability information provided by the component appointments and communicates the appointment to the client's interconnection.

According to another embodiment of the present invention, a local compliance manager (LFM) has a data server available to promise and operate in a distributed supply chain planning environment including other local compliance managers. The local compliance manager includes the compliance server and the available server interconnections for promise. The local compliance manager receives one or more requests of available for component promise from a compliance server, each available request for component promise corresponds to a request line item available for particular promise for a desired product. The local compliance manager determines a response available to promise for each request line item using the server available for associated promise and generates a component appointment for each request line item according to the response available for corresponding promes . Component citations include product availability information to correspond to desired product. The local compliance manager then communicates the component appointments to the compliance server for consolidation with other component appointments from one or more local compliance administrators.

The present invention provides important technical advantages. The compliance server and the local compliance administrators of the present invention are capable of concurrently and intelligently administering the promise of order fulfillment for available requests for multiple line item promises complex from a very large number of potential customers according to a user, client, specified provider and any other business restrictions. Where the servers available for promise are geographically distributed from one another and the compliance server, through the internet for example, the advantages of the present invention will become particularly evident. In addition, where such servers available for promise lie at different corporate boundaries, the compliance server establishes a foundation for promise capabilities and order fulfillment before not possible. The present invention also provides customers with a unique interconnection for requests for available to promise, the appointment confirmations, and the acceptances of promise that can be relied upon and affect the availability of available product for promise, the availability of material or the availability of capacity in the servers of available for promise and in the associated planning engines around the balloon. This gives customers a desirably very high visibility in extended supply chain operations, among other benefits.

The present invention minimizes the necessary communication between the compliance server and the local compliance management to maximize the bandwidth to minimize the latency, which supports its use in interactive systems (such as the internet network sites that it provides to the clients). online instant quotes pair deliveries of multiple articles) and other applications that otherwise would not be possible. The present invention accomplishes this by providing a flexible intelligent placement of computations within the compliance server, by local compliance administrators or servers, available to promise as appropriate, and also by designing interconnection engineering. of local compliance manager to communicate rich responses that can include numerous options simultaneously. This interconnection of consistent local compliance manager is provided while at the same time supporting a wide variety of servers available for promise, including accommodating the available servers for existing promises and similar systems not originally designed to support the extended features, the operation and the architecture achieved by the present invention.

Furthermore, the architecture of the system of the present invention contemplates that different environments would be required to vary where certain computations occur in order to optimize the operation as is appropriate for the particular application. For example, some applications may be necessary for a system with an estimated high production but may tolerate longer latencies while others may require extremely short latencies but may tolerate less production. On the other hand, some applications may require supporting a large number of products, while others may require supporting huge supplier networks for each product, and still others may require networks of large vendors. The present invention provides adequate flexibility to support such diverse requirements. Other technical advantages will be readily apparent to those skilled in the art of the following figures, description and claims.

BRIEF DESCRIPTION OF THE DRAWINGS In order to provide a more complete understanding of the present invention and of the additional features and advantages thereof, reference is now made to the following description taken in conjunction with the accompanying drawings and which: Figure 1 illustrates an example system for fulfilling commitments within a distributed supply chain planning environment according to the present invention.

Figure 2 illustrates a workflow of available request for example promise according to the present invention.

Figure 3 illustrates a workflow of sample appointment confirmation according to the present invention.

Figure 4 illustrates a sample promise acceptance workflow according to the present invention; and Figure 5 illustrates a sample component promise change workflow according to the present invention.

DETAILED DESCRIPTION OF THE INVENTION Figure 1 illustrates an example system 10 for meeting commitments in a distributed supply chain planning environment. System 10 includes one or more client 12 representing the appropriate enterprise resource planning (ERP) systems, sales force automation (SFA) systems, order management systems (WHO), and any other suitable systems. Each client 1 can be associated with one or more clients, users or other entities. In a particular embodiment, customers 12 may include customer service and sales oriented applications seeking to increase or replace their existing order fulfillment and promise capability. The clients 12 communicate and interact with the compliance server 16 using an application-specific integration layer (not explicitly shown), which may include an application programming interconnection (API), a commercial object request agent (ORB) or other suitable software interconnection operating in the clients 12, the compliance server 16 or in both the clients 12 and the compliance server 16. Network 18 couples clients 12 to compliance server 16 and can 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 appropriate network or network collection.

The servers available for promise (ATP) 1 each support or are associated with a planning engine capable of providing, among other things, product availability responses to requests for available pair promise of component in the form of component appointments . One more planning engines associated with available servers for Promise 14 can also provide the price and other additional capabilities, as appropriate. A local compliance manager (LFM) 22 that is located in or otherwise associated with each available server for Promise 1 handles the interaction between the available par-14 server and the 16-compliance server. In one embodiment, the administrator Local Compliance 22 is a "thin" engine whose primary responsibility within system 10 is to communicate component requests, component appointments, component appointment confirmations, and component promises to and from the available server for promise 14 in an appropriate format, and to monitor your data to the point of order fulfillment. The servers available for promise 14 provide services for the compliance server 16 through a specific application integration layer (not explicitly shown) which may include an application programming interconnection, object request trading agents, or any another suitable software interconnection operating on the servers available for promise 14, on the compliance server 16, or on both the servers available for promise 14 and the compliance server 16. A network 20 couples the fulfillment server 16 to the servers. servers available for promise 14 and can be a local area network, a metropolitan area network, a wide area network, a global network such as the internet or any other network or collections of appropriate networks integrated to separate from the network 18 In one embodiment, the local compliance manager 22 each provides the same interconnection and functionality to the 16 compliance server, but may be designed to work with different servers available for promise. Many of the servers available for promes 14 may be older promise available systems, compliance systems, or enterprise resource planning systems that can be used to compute component appointments, but are not designed to work with the compliance server 16 in an environment of more comprehensive distributed network such as that associated with system 10. Other servers available for promise 14 may not even have the ability to provide quotes from available for promise; rather, they can simply store or support the information required to compute the quotations available for promises. In other cases, the available par-14 servers may be designed to work with the compliance server 16, and as such may have a local compliance manager 22 to directly support the local compliance manager's interconnection of the compliance server 16.

In each of these cases, the Local Compliance Manager 22 is responsible for appropriately computing the component appointments formed or the component promises, managing the resulting acceptances, and ensuring that the corresponding capacity or material is truly confidential. The local compliance manager 22 may have little to do but move the information communicated between the interconnection of the local compliance manager of the compliance server 16 and the available server for associated promise 14. In other situations, where the server of available for promise 14 is not designed to function as part of a larger system, the local compliance manager 22 may require carrying out substantial computation or other manipulation of the information. The local compliance manager 22 may still need to carry out some of the functionality of available to promise if it is interacting with a system that is not designed for the one available to promise., or if it interacts with a slower system where the activity of the system requires the s bypassed when possible. The present invention provided a diverse flexibility in the administrators of local compliant 22 and localizes the transaction to local compliance managers and to deployed ones (keeping the server variations available for various compliance separating from the more complex and computationally heavier compliance server 16).

In general, customers 12 submit requests available for promise to the compliance server 16, the request includes one or more line items that refer specific products that each may be available for promise on one or more servers available for distributed promes 14. Requests for availability to promise the commercial agent component of compliance server 1 correspond to these online articles to the appropriate local compliance administrators 22 using the interconnection d local compliance manager and network 20. Cad local compliance manager 22 receives a request d available for promise of component in turn uses the server d available for associated promise 14 to carry out the necessary compositions and record any necessary reservation changes. The local compliance managers 22 send the resulting component appointments to the fulfillment server 16, which manipulates the appropriate com-component appointments and presents a unified global appointment to the requesting client 12, commensurate with the corresponding original available promise request.

The client 12 can generate a confirmation appointment to fully or partially accept the appointment, which the compliance server 16 handles as appropriate and sends local compliance manager 22 as confirmations d component appointment, each corresponding to a request d available for promise of particular component. E Local Compliance Manager 22, in cooperation with its servers available for associated promise 14, generated promises of component that consume commitments of supply of union of form between the client and the suppliers as soon as the requested products. Compliance server 16 presents a unified promise to customer 12, commensurate with the request for availability for corresponding promise, based on the component promises it receives from local compliance administrators 22 and from the available servers for promise 14. The client 12 can generate an acceptance to fully or partially accept the promise, then sending the acceptance to the compliance server 16. The compliance server 16 sends the compliance acceptances to the local compliance manager 22 and the local compliance manager 22 responds to the server of compliance. compliance 16 with component acceptance confirmations. Once the compliance server 16 has sent a confirmation of unified acceptance to the client 12, based on the component acceptance confirmations received from local compliance manager 22, the promise cycle and order fulfillment is completed. The operation of system 1 is described in more detail below.

The clients 12, the compliance server 16 the local compliance administrators 22, and the servers available for promise 14 can each operate on one or more computers or other suitable processing devices in one or more places. Each computer can include an input device, which can be any suitable keyboard, digital display, microphone, or other device to accept information. An output device can carry the appropriate information, including digital data or analogue visual information, and auditory information. The input device and the output device can support any suitable fixed or removable storage media, such as magnetic computer diskettes, CD-ROMs, or other means for receiving information and providing information to the computer. One or more processors and the volatile or non-volatile memory executing instructions and manipulate the information according to the operation of the associated client 12, of the available server for promise 14, of the local compliance manager 22 or of the compliance server 16 com It may be the case. The clients 12, the compliance server 16, the local compliance manager 22 and the servers available for promise 14 may be involved in a computer software, in a computer device or in any appropriate combination of software and apparatus and may be integrated or separated one from the others. To support high availability or other operational requirements, system 10 can incorporate redundant clients 12, compliance servers 16, local compliance administrators 22 and servers available for promise 14, according to particular needs.

In one embodiment, for each of the local compliance managers 22 in the system 10, the compliance server 16 can maintain a local compliance manager name, the appropriate descriptive information for the local compliance manager 22, an internet protocol (IP) or other network address for the local compliance manager 22, the identity of the backup local compliance manager designated 22 in the event that the local compliance manager 22 fails, and any other appropriate information. The compliance server 16 can keep the server group available for promise and the hierarchical information for source purposes. Server groups available for promise can model, for example, provider groups, price groups, or geographic locations. Since the fulfillment server 16 can operate according to both the supplier and group source preference, as described in more detail below, it may be desirable to relate one or more providers with any available promising par-server groups. . As an example, the client 12 or an associated user can specify a preferred provider, a preferred group or both, in which case the fulfillment server 1 addresses the requests for available to promise of component the appropriate local compliance administrators 22 based on these preferences and provider group mappings. The compliance server 16 can maintain, for each group server of available to promise, a group name suitable descriptive information for the group, a group padr for the group, a list of children groups, a list of local compliance administrators 22 in the group, with the list of active providers associated with the group and any other appropriate information. Font preferences can be defined at any level within the server group hierarchy of available for promise.

A product can represent anything that a user associated with a client 12 can request and can be tangible (for example, a computer) or non-tangible (for example, a service). The products are related to the articles, each of which may be related to multiple products. This allows the modeling of different points of price, front times, suppliers, locations, or other suitable characteristics for the same item. In addition, multiple items may be related to the same product. This allows, for example, the multiple supplier modeling of the same product. In an embodiment, the fulfillment server 16 can maintain, for each product, a product name, a product description, a unit of measure of failure (UOM), a lot size of failure or multiple, a cancellation window in which the customer 12 or an associated user can cancel an order, a qualified customer, a qualified supplier, or another list of alternates or substituents for the product, related and defined products to the supplier, 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. The compliance server 16 may also maintain information about the attributes, separate from any other particular product, such as the type of attribute, the description, the value range, the unit of fault measurement, the particular attributes within a type of attribute, and any other appropriate attribute information.

Compliance server 16 can maintain sales channels (clients) and parent-child relationships or other surgical relationships between sales channels, which compliance server 16 can use for order prompting and other suitable purposes, as discuss more completely below. In an incorporation, the definitions for each sales channel maintained in the compliance server 16 include, in any combination and without limitation: (1) the name, (2) the description, (3) the category, (4) the father, (5) ) children, (6) qualification or other list of groups that the compliance server 16 can use to determine the source of the product, (7) products that the client has or can order, (8) qualified or another list of groups for a given product, (9) qualified or another list of suppliers for each product, (10) inform if the customer accepts alternate products or substitutes generally or for a given product, (11) qualified or another list of substitutes or alternates for each product , (12) the information on whether the client accepts groups of alternate sources generally or for a given product, (13) a mandatory or target price limit or a price range for each product, (14) information on whether the client prefers only complete shipments eo for a given product, (15) if the client prefers that the unfulfilled parts of the requests be canceled rather than taken as a delay generally or for a given product, (16) information on whether the client prefers only shipments of one usually or for a given product so that early or late promises are rejected, (17) delivery window out of which a late or early shipment is not acceptable, (18) a required or multiple lot size for a product given so that citations are rounded based on this value, and information on whether the client generally prefers that if the line-item of petitions is shortened that then logically the associated request line items are proportionally shortened.

In general, location information can be maintained at any level of a sales channel or other hierarchy and can be as deep as necessary. The compliance server 16 can process the line items of request through groups or alternate suppliers if a group or primary provider is unable to service a request. Within a preferred group, the provider's preferences are met and those are defined. The alternate alternate lists should not be generally restrictive, so that if an acceptable citation response is not available from a preferred provider, the compliance server 16 may locate materials or product endowments or availability capabilities of other potential suppliers. For requests that do not explicitly disable alternates or substitutes, and that do not specify alternates preferred by the client, the provider may be able to respond with its own selection of alternates or substitutes.

The compliance server 16 may maintain the information in relation to the providers and the parent-child relationships or other hierarchical relationships between the provider whose compliance server 16 may be used for the promise of order and other suitable purposes, as fully discussed above. down. In an embodiment, the definitions for the providers maintained in the compliance server 1 may include, in any suitable combination, if limitation: (1) name, (2) description, (3) category, (4) parent, (5) children, (6) the products provided by the provider, (7) the products associated with the supplier, (8) the qualification or other list of preferred customers for a given product, (9) the alternates or substitutes acceptable for a given product, (10) the minimum and maximum quantities for the orders , (11) the order quantity restriction by not allowing the compliance server 16 to reduce the number of appointments without affecting the validity of the appointment, (12) cancellation of restrictions, and (13) cancellation window out of which the Orders can not be canceled.

The compliance server 16 uses the business restrictions described above which it may have previously stored, and may receive within the available requests for the promise of the clients 12 or both, to source request line items for compliance administration local 22 or to filter any component citation and component promise responses from the local compliance manager that does not satisfy these restrictions. For example, if a provider provides multiple alternate responses, or replies from alternate groups, the compliance server 16 can filter the responses that are not met or the responses from unacceptable groups. If none of the alternatives complies, the compliance server 16 may reject the response at all. The existence of a list of alternates or alternate groups does not mean that they will be used. In an embodiment, the client 12 or an associated user may selectively waive some or all of the business restrictions when requests for available for promises, appointment confirmations and promises of promise are generated, according to particular needs.

In one embodiment, the compliance server 16 supports a hierarchy of one or more product vendors and each local compliance manager 22 maintains the same vendor hierarchy but with a subset of the products supported by the compliance server 16. The administrator of local compliance 22 computes component quotations or component promises based on endowments through the vendor hierarchy for the corresponding products. These capabilities are described in the co-pending application of the United States of America number 08 / 491,167 filed on June 16, 1995 by Kennedy and others, for a "System and Method of Handling Available for Promise (ATP)", and the application of the United States of America co-pending number 08 / 802.43 filed on February 18, 1997 by Kennedy and others, for a "System and Method for Managing a Promise Available" of which are incorporated herein by reference. As a result, the system 10 provides the product distribution capability to the local compliance manager 2 and the servers available to promise 14 on a product-by-product basis, thereby gaining space and time scaling in systems with large D products numbers.

The compliance server 16 can support one or more hierarchies of related or generic products, as described in United States Patent Application No. 08 / 802,434. The local compliance manager 22 can support one or more subgames of the same hierarchies and can compute component quotations or component promises based on the endowments to the products in this sub-hierarchy. This provides additional technical advantages and applications where the products are related by the guidelines.

One or more compliance servers 16 can work cooperatively, independently, or otherwise with the same set of local compliance manager 22. Each of such local compliance managers 2 can accept requests for availability for component promise and confirmations of component appointment from multiple compliance server 16 and can send component appointments or component promise to multiple compliance servers 16 This offers numerous technical advantages, including the ability to scale the system to handle large numbers of customer or large numbers of clients. In addition, this capacity allows the organized geographical distribution of the compliance servers 16 according to the particular needs.

Each compliance server 16 can enforce different business constraints, depending on the set of clients 12 that each compliance server supports 16. Each compliance server 16 can work with different local compliance manager games 22, and where each compliance manager Local 22 can belong to one or more of the local compliance manager games that correspond to the compliance server 16. Each compliance server 16 can also support its own locations or supplies for one or more of the products. This offers numerous additional technical advantages, including significant flexibility in placing the systems available for distributed promise with compliant 16 fulfillment servers optimized to support a variety of clients 12. In addition, these options facilitate the placement of the local endowments. product supply and compliance servers 16 to reduce latency increase production for common product requests.

Each compliance server 16 may have the ability to operate as a local compliance manager 22. In one embodiment, each compliance server 16 at least one server will be available to promise 14 to support a separate local compliance manager 22. any situation, it is possible to form a hierarchy of local compliance administrators 22 by using a first system, including a first compliance server 16, which corresponds to local compliance administrators 22 a. its servers available to promise partners 14, since the server available for promise 14 within a second system that includes a second compliance server 16, corresponds to the local compliance administrators 22 and to the servers available for associated promise. In this way, a hierarchy of local compliance managers 22 and available data servers 14 of an appropriate width and depth can be formed according to particular needs. The present invention contemplates any suitable relationship between one or more local compliance administrators 22 and one more compliance servers 16.

Such a hierarchical organization facilitates numerous additional system designs and offers numerous additional technical advantages. For example, each local compliance manager 22 in such a hierarchy can be assigned the management of one more product, where the products are part of a hierarchy of related or generic products. In this case, the local compliance administrators 22 can compute the availability of the generics of a product assigned by sending the requests of available for the promise of component 32 to the local local compliance administrators 2 that correspond to the generic products, providing a additional escalation and parallelization.

Also, the compliance server 16 described in patent applications Nos. 08 / 491,167 and 08 / 802,434 can support a hierarchy of one or more vendors of products and each local compliance manager 22 can correspond to a particular one of its vendors. The local compliance manager 22 can retain supply provisions for its associated vendor and compute all component quotations and possible component promises with the provisions it contains. The compliance server 16 receives these component citations or component promises and combines them for each product as if the request available for promise 30 had been cited or promised by a single system having all endowments. As a result, the system 10 provides the ability to distribute product endowments to local compliance managers 22 and to the partners available to promise partners on a vendor-to-seller basis, thereby earning both space and time scaling in the applications. with larger numbers of vendors or gaining flexibility in applications where the vendor organizations are geographically or economically separated. Each local compliance manager 22 can compute the availability for their parent vendor by sending one or more available requests to promise components 32 to the local compliance manager 22 which corresponds to the parent vendor. In addition, multiple local compliance administrators 22 may retain separate endowments for a particular product and a compliance server 16 may distribute the appointment activity through such local compliance managers 22 as necessary to obtain the appropriate quotas. These and other features of the system 10 provide or otherwise allow advantageous parallelization, escalation, production as well as a distributed positioning of the vendor systems.

To achieve even an additional escalation, additional breaks can be made. In one embodiment, a first compliance server 16 can work with local compliance managers 22 that each is assigned or otherwise correspond to one or more of the designated products. Each local compliance manager 22 can in turn use a server available for promise 1 which is a second compliance server 16 backed by separate local 22 compliance managers that have each been assigned to a portion of the global supply envelope for a designated product. The second compliance server 16 can be designed to communicate to its local compliance managers 22 to minimize the burden of processing placed on each of these local compliance managers 22. Alternatively, the various local compliance managers 22 may have different Horizon slices to handle, and component 34 quotas can be broken and staggered accordingly. This can increase latency to optimize scalability with respect to size and production.

In one embodiment, the components of the system 10 use a protocol referred to as "request-promise-acceptance" (RPA) to create, manage and fill available requests for promise in relation to the products. In general, according to the request-promise-acceptance protocol, a client requests one or more products and a supplier offers a promise that satisfies the requirements of the client's request as closely as possible. With the review of the supplier's offered commitment, the client either accepts or rejects the promise. If the client accepts the promise, both the client and the supplier generally consider this acceptance as forming a binding agreement. In certain situations, a customer can not freely cancel an acceptance within a specified time interval due to their commitment. The request-promise-acceptance protocol was developed as the basis for managing the supply and demand requests between autonomous planning domains of a distributed supply chain as part of the supply chain-planning engine (SCP) RHYTHM of 12 TECHNOLOGIES , INC.

Figures 2 to 5 illustrate the operation of system 10 through a series of workflows. These other workflows described involve an interactive scenario with the full use of the extended request-promise-acceptance protocol according to the present invention. However, not all possible workflows are interactive and not all result in the full use of the extended request-promise-acceptance protocol. For example only and not by way of limitation, large companies can frequently process the volume of their customer orders using techniques based on electronic data exchange (EDI) in which a request for availability for promise results in a consumer promise of availability to promise without additional customer interaction. Those skilled in the art will appreciate that the system 10 accommodates the electronic data exchange base and other suitable work flows and that the present invention is intended to encompass all those work flows and associated operations.

Petition Workflow Available for Promise Figure 2 illustrates a workflow of request available for promise in which a request d available for online article promise 30 is created in client 12, said client 12 submits a request for availability for promise 30 to a server of compliance 16 and the availability request for promise of 16 compliance server agents against one or more local compliance administrators 22 in the form of a request for availability for component 32 pledge. This local compliance administrators 22 process the availability requests for component promise 32 and comparison with the availability servers for associated promes 14, generates the resulting component citations 34, send the component citations 34 to the compliance server 16. Compliance server 16 processes the component appointments 3 and generates a unified appointment 36 which is sent to client 1 for review.

Initiate Request for Promise [Client] In one embodiment, to initiate a request d available for promise 30, the client 12 or an associated user may require the provision of appropriate identification and security information. The customer 12 can support the business rules of noncompliance or other restrictions according to the user profile, a customer profile, or other suitable definitions. When the user accesses a screen of available request to promise with the client 12, the screen can be populated by different parameters of non-compliance according to such definitions. The user may then optionally adjust all or some of these parameters to suit the needs of the availability request for particular promise 30. Such parameters may include the shipping requirements, the preferences with respect to the product source, the substitutions or alternate of product, and location for shipment, price objectives and any other appropriate parameters. The user can select from a table of available products, organized according to a product group or to another suitable form, using a product catalog, a search engine or otherwise. Once the user selects one or more products, the user can satisfy the desired quantities, the desired due dates, and any additional parameters such as those discussed above. The user can also logically group the items online request for the purpose of sending programming. The client 12 executes an availability request submission function for promes when the availability request for promise 30 e is fully specified, by sending a request for availability to promise 30 to the fulfillment server 16.

The availability request for promise 30 can 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, even when any suitable data or message structure may be used without departing from the intended scope of the present invention. As an example, an alternate third level structure for the availability request for promise 30 may include a request object containing a list of one or more request delivery objects, each containing one or more line item objects of petition.

Attributes of the Request In one embodiment, the request object has the following attributes or otherwise supports the following information, in any combination and without limitation: (1) user-user identification of client 12 submits the request; (2) customer-used identification to determine the business restrictions relevant to the request; (3) Customer identification request-assigned to customer 12 and used primarily for tracking purposes; (4) request identification-assigned to a compliance server 16 and used for subsequent processing and administrative activities; (5) currency-the preferred currency for the request, possibly unfulfilled by outlined business restrictions; (6) channel d sales (salesperson) - sales channel for the request, useful e where availability servers for promise 14 provide the location of functionality based on a multi-level channel hierarchy and the vendor determines the channel from which consume availability for promise; (7) numerical-request range or other request rank in relation to other requests for the same product, useful as a classification criterion in which the servers available for promise 14 provide functionality in relation to the different ranges of requests within of the order scheduling process, such as when a scarce supply is allocated in light of supply problems; (8) shipment to shipment location for the application, which may be violated for each item of the application line; (9) overcoming customer constraints-allows the user to avoid the business restriction processing functionality of the compliance server 16 so that responses from the local compliance manager 22 are not restricted; (10) objective of the total price-target price of the total price specified by the user for the request, which the compliance server 16 can consider to evaluate the responses of the local compliance administrators 22 and, if they are not satisfied, it can indicate a resulting appointment; (11) alternating / substitutes allowed logical parameter (yes / no) included in the profiled business restrictions, that the user may be able to selectively exceed and that the compliance server 16 may use the processing of the request; (12) acceptable alternating location-unfulfilled logical parameter of the profiled business restrictions, that the user may be able to selectively exceed and that the compliance server 16 may use and process the request; (13) Complete logical and unfulfilled sending-parameter of profiled business constraints, which the user may be able to selectively overcome and which the fulfillment server 16 can use to process a request to make component appointments close to the requested quantity. attributed are rejected; (14) partial / cancel-unmatched logical parameter of profiled business constraints, which the user may be able to selectively overcome and which the compliance server 16 may use to process the request so that late promises (unfulfilled portions of the request) are either discarded or carried as delay; (15) timely delivery-unfulfilled logical parameter of business or profile restrictions, which the user may be able to selectively overcome and which the compliance server can use to process a request according to whether it is acceptable to receive early component promises or late of local compliance administrators 22; (16) provides short-parameter unfulfilled of the outlined business constraints, which the user may be able to selectively overcome and that the compliance server 16 may use and process the request so that the promises between the request line items associates are logically reduced (shortened) in proportion to another line item of the cut request; (17) initial date requested-the first requested date submitted to compliance server 16 for the appointment; (18) last requested date-last date request submitted to the compliance server 16 to re-cite if there is one; (19) cited date-last cited request date, if any; (20) accepted date-request accepted to the last client of date 12 if there is any; (21) date rejected, client date 12 last rejected request total if there is one; (22) promised date-last promised application date if there is one; (23) canceled date-canceled request date if any; and (24) date in queue-date in the last request queue if there is one.

In addition, the request object can support a request status field that the compliance server 16 updates at certain times during the life of the request d available for promise 30, including but not limited to (1) "failed request" -request submitted for initial appointment or re-appointment, but one or more items of the application line do not meet the requirements; (2) "pending appointment" -specified submitted for initial appointment or re-appointment, but that results in the appointment still to be processed; (3) "failed appointment" - fulfillment server 16 determines the failed appointment to satisfy the business restrictions outlined for the request; (4) "pending acceptance" -compliance server 16 processed the appointment and sent it to client 12, but client 12 still does not respond; (5) "acceptance not received" -confirmation of appointment n received from client 12 by the date and time specified in the acceptance attribute, so that the appointment is essentially null; (6) "rejected" - the compliance server 16 processed a rejection and sent it to the local compliance manager 22; (7) "pending promise" - the fulfillment server 16 processed the appointment confirmation, sent it to the local fulfillment manager 22 and is now monitoring the promise response of the component from the local compliance managers 22; (8) "promised" -compliance servers 1 received component promises sent the resulting promes to customer 12; (9) "failed promise" - the fulfillment server 16 has not yet received the promises of component d of local compliance managers 22 and has sent both a failure notification to client 12; (10) "canceled pending" - compliance server 16 processed a cancellation, sent it to local compliance administrators 22, and is monitored for confirmation of responses from local compliance administrators 22; (11) "canceled" - compliance server 16 received the required cancellation confirmations from local compliance administrators 22 and sent confirmation to client 12; and (12) "queue" -e compliance server 16 processed a request queue command and is monitoring the request to re-quote it.

Attributes of Article-Line of Petition In one embodiment, the request line item is an object that has the following attributes or that otherwise supports the following information, in any combination and without limitation: (1) request identification links the line item request to the request; (2) line of request-identification of article-assigned to a server of compliance 16; (3) sent-to in compliance with shipping address for line item request, which and in breach of the request, the user may be able to selectively exceed and is unfulfilled for delivery of the online item of request; (4) accept by-date and time by which the user must accept the appointment; (5) promise by-date by which the compliance server 16 must respond with promise; (6) product identification - application product for the request line item; (7) unit of measure of product-primary unit of measurement (UOM) for the requested product; (8) request amount-quantity or quantity range of product requested, which must combine equal quantities of deliveries and deliveries of multiple request line item are defined; (9) request date-date or rang of product date is required to arrive at a place of shipment to the customer, which the user can surpass if there are multiple deliveries of item of line of request for item d line of request; (10) category-attribute-combinations d category / attribute for the requested product; (11) item-line grouping-refers to multiple request line items such as the logical grouping for delivery coordination, where grouping can represent the configuration, a package of products in bundle, the set of items must be sent together or any other suitable grouping; (12) line item price target-the price of the user's specified goal for the request line item, which the compliance server can consider when evaluating server responses from available to promise and if they are not satisfied, can indicate in the resulting quote; (13) preferred product-provider-breached of profiled business restrictions, which the user may be able to selectively overcome and which the compliance server 16 uses when searching for the source of the request line item; (14) alternating / substitutes allowed-following the outlined business constraints, which the user may be able to selectively overcome and which the compliance server 16 may use to process the request line item; (15) alternates / preferred substitutes-breached business profile restrictions that the user may be able to selectively exceed and which may allow the compliance server 16 and the supplier to cooperate in selecting the substitutes or alternates available for the requested product (16 ) mandatory - whether the request line item is mandatory in relation to others in its grouping so that insufficient quantities of the mandatory item may result in a failed appointment; (17) batch / multiple size breached of the basic product definition that the user may be able to selectively overcome and that the fulfillment server 16 may use to process the request line item so that the response quantities of the served of available for promise are rounded accordingly; (18) full-unfulfilled shipment of profiled business restrictions, which the user may be able to selectively overcome and that the compliance server 16 may use and process the request line item; (19) Partial / canceled breach of business decisions outlined that the user may be able to selectively overcome and that the compliance server 16 may use in processing the request line item so that it can be discarded unless fully complied with; (20) on-time delivery-unfulfilled of the profiled business restrictions, which the user may be able to selectively overcome and which the fulfillment server 16 may use to process the request line item to reject the late or early promises; (21) local compliance manager response status-compliance server 16 monitors after the request agent component of available to promise local compliance managers 22, so that when all component sites have been received the Compliance server 16 can begin to evaluate the appointment; (22) event status initiated by local compliance manager-maintained in compliance server 16, so that if a planning event affects the provision, the local compliance manager 22 notices this in form to the compliance server 16 so that the compliance server 16 may re-evaluate the status of the request in relation to the outlined business restrictions and notify the user of any change in the request status; and (23) online article status request-updated at certain times in the life cycle of the request line item.

Petition Line Article Delivery Attributes In one embodiment, the delivery of the request line item is an object that has the following attributes or otherwise supports the following information, in any suitable combination and without limitation: (1) item line identification of request-link the delivery of the request line item to the request line item; (2) delivery of identification-line request article assigned to compliance server 16; (3) I sent a non-submission to the address for the delivery of the request line item, which is breached of the request line item and the user can selectively exceed; (4) amount of request-quantity or range of quantity of product requested, which must be equal to the quantity of request of article of line of request; (5) date of request-date or product of date range is required to arrive at the shipping location to the customer for the delivery of the request line item, which the user must be able to overcome if there are multiple deliveries of request line item for a request line item; and (6) attribute / category-category / attribute combinations for the delivery of the request line item, which the user may be able to selectively overcome if there are multiple item line deliveries of request for a request line item dice.

Application Process for Promise Available [Compliance Server] Each of the line items associated with the request for availability for promise 30 can be fulfilled from a server available to promise different logically or geographically 14. In this workflow, the primary tasks of the compliance server 16 are to decompose the request from available to promise 30 in individual request line items, requests for available to promise component resulting from agent 32 against the distributed r of servers available for promise 14 using network 20 and local compliance administrators 22, evaluate appointments from component 34 received from the local compliance administrators 22, send a unified appointment 36 to the client 12 using the network 18. If multiple deliveries have been specified for a given request line item, the fulfillment server 16 creates a separate request component available for promise 32 for each delivery. Some or all of the components of the requests available for promise may be pre-allocated for a local 22 compliant administrator according to client's business preferences, user preference preferences, or preferred source rules. In the alternative, source preferences can not be specified so that local compliance administrators 22 have an opportunity to provide appointment responses. In one embodiment, the compliance server 16 decomposes and encapsulates the client and other appropriate business constraints in the component of the available requests for promise 32 before sending them to the local compliance administrators.

For each product, a supplier can specify minimum and maximum order quantity requirements. In the case of incorporation, if the parameters of such requirements are specified, the compliance server 16 evaluates at the beginning of each request online article satisfies such requirements. If any of the online items request does not meet the specified requirements, a failure response is generated and sent to the requesting client 1 using the network 18. In this case, the fulfillment server 1 updates the status of the available request for promise 3 and possibly of the requests of available for promise d failed component 32 to "failed request".

The compliance server 16 may attempt to define the source for each item in the request line according to the provider or the location. Compliance server 16 can then specifically target the requests for available for component 32 promise for particular local compliance administrators 22. Due to the fact that the user may have exceeded the profiled non-compliance restrictions, the first 16 compliance server evaluates the online request article and the request line item delivery details, then verifies the alternate provider and the location of source attributes to determine if the alternates are allowed for the availability request. for promise 30. If alternates are not allowed, then the primary relationship specified in the request for available par-promise 30 will be honored. If the alternate source is allowed then the user, client or other alternate source preferences take precedence. If such source preferences have been specified, the compliance server 16 can verify the existence of any supplier default preferences. If there are no preferences specified for the provider either, the requests for availability for component 32 promise may be marked "unspecified" in relation to objective 22 local compliance manager. In this case, multiple local compliance managers may be allowed to provide service and respond to requests for available to promise component 32 as appropriate.

The compliance server 16 may attempt to define alternate or substitution preferences for the request for data available for the promise 30. The compliance server 16 may include the alter product information in the data requests available for component promise. 32. Since the user may have selectively exceeded the profiled breach constraints, the compliance server 16 first evaluates the item details on the online request and delivery of the request online article then verifies the available request to promise 30 to determine if they are substitutions or alternates are allowed If they are not allowed, then the primary relationship specified in the request for available to promise 30 is honored. If alternate or substitute products are allowed then the user, the customer, or other alternative substitution preferences take precedence. If such preferences are not specified, the compliance server 16 may verify with respect to any provider failure preference. S the specified preferences do not exist for the supplier either, the requests of available for promise of component 32 can be marked as "unspecified" in alternate relation and substitutions. In this case, local compliance managers 22 can respond to requests d available for component 32 promise with multiple product options.

The compliance server 16 generates the requests for available for component 32 promise with embedded business constraints. Since the user can have interactively exceeded the profiled breach restrictions, the compliance server 16 uses the item details on the request and delivery line of the request line item to define the attributes of the request available for the component's promise. 32. In an embodiment, the following restrictions are defined in any appropriate combination and without limitation: amount of request, complete submission, partial / canceling, timely shipment, alternates / substitutes allowed, alternates / preferred substitutes, size / batch multiples, and front / back consumption limits.

The compliance server 16 may also indicate that the request for availability for the component 32 promise is also restricted in some way according to the outlined business restrictions. Once the request for available for promise of components 32 has been generated, compliance server 16 sends the availability requests for promise of component 32 to one or more local compliance administrators 22 to provide service using the network 20. compliance server 16 You can also update the status of the available request for promise 30 and possibly l requests for available for component 32 promise "pending appointment".

In one embodiment, the compliant server 16 computes or otherwise generates a sequence of requests available for component 32 promise that it sends to the particular local compliance manager 22 associated with a first available request for the promise of component 3 in the sequence . The target local compliance manager 22 accepts the sequence, processes the request d available for the specified component 32 promise of objectiv for it, and then passes the resulting component quotations the component promises, together with the availability requests for component promise remaining 32 in sequence, to local compliance manager 22 for the next request available for component promise 32 At the time, that local compliance manager 22 accepted the sequence, processes the available requests for component 32 promes specifically of objective for this one and pass the resulting component quotations to the component promises along with any requests of available to promise the remaining component 32 in the sequence, the target compliance manager 22 for the next request available for the promise of component 32. Each local compliance administrator 22 can compute their component appointments or their component promises so that they satisfy all the appropriate business constraints. in relation to component citations or component promises made by another local compliance manager 22 earlier in the sequence. The compliance server 16 receives the sequence d of component or component promises resulting from the last such local compliance manager 22 generates a combined appointment or promise corresponding to the request available for promise 20 of the client 12.

Request Attributes Available for Component Pledge In an embodiment, the request for available for component promise 32 is an object that has some or all of the attributes of the online article objects of request and article on-line delivery of the request. The compliance server 16 embeds the business constraints in the component request that are relevant to the functions of the local compliance managers 22. The component request may have the following attributes may otherwise support the following information, and any combination adequate and without limitation: (1 component request identification-assigned to a compliance service 16 when it creates the component request (2) local compliance manager identification - the local compliance manager 22 has as objective the request for component that can remain unspecified and where the source relationship is not specified or hosted in the compliance server 16 and in any case any local compliance manager 22 is free to respond to the component request if it can satisfy the requirements; 3) identification of compliance server -direction of network or other identifier for the server d compliance 16, useful in the environment that has multiple servers of compliance 16; (4) sales channel (seller) for the component request; (5) petition rank for the parent petition; (6) online item identification of request-link component request to online article request; (7) identification of online article submission of petition; (8) product identification-may correspond to the product identification known by one or more local compliance managers 22 of the target and possibly by the servers available for corresponding promise 14; (9) product measurement unit-may correspond to the unit of measure of product used in one or more local compliance managers of objective 22 possibly in the servers available for corresponding promes 14; (10) amount of petition; (11) date of petition; (12) category / attributes; (13) full shipment; (14 partial / cancel; (15) on-time shipment; (16) batch / multiple size; (17) alternates / substitutes allowed; (18) preferred alternates / substitutes; and (19) front / back consumption limit / define each window to the client who is willing to accept, who can control how far or back from the date of request the servers available for promise 14 will search in relation to available quantities.

In addition, the object of the component request can support a request status field that the compliance server 16 updates at certain times in the vid cycle of the component request, including but not limited to (1) the "pending appointment" -competition of a component that has been submitted for an initial appointment or for re-appointment, but the resulting appointment is not processed; (2) "failed appointment" -compliance server 16 determines the failed component appointment to satisfy the requirements for the component request; (3) "conformation of pending appointment" - the fulfillment server 16 has processed the appointment and transmitted it to the client 12 who still has to answer; (4) "confirmation not received" -the confirmation not received from the client 12 by the date and time specified in the acceptance attribute, so that the cit is essentially null; (5) "rejected" - the fulfillment server 16 has processed the rejection and sent it to the local compliance administrators 22; (6) "promes pending" - the fulfillment server 16 has processed the appointment confirmation, sent it to the local compliance administrators 22 as component confirmations, and is monitoring the promise responses; (7) "promised" -the fulfillment service 16 received the required component promises and sent the resulting promise to the client 12; (8) "failed promes" -compliance server 16 has not received the required component promises and has sent the resulting failure notification to client 12; (9) "cancellation pending" - compliance server 16 has processed a cancellation, sent it to local compliance administrators 22 and is monitoring confirmation responses; and (10) "canceled" - the compliance server 16 received the component cancellation confirmations from the local compliance administrators 22 and sent a cancellation confirmation to the client 12.

Available Request for Promise of Process Component [Local Compliance Administrator] The availability requests for component 32 promise of compliance server 16 are received in each of the appropriate local compliance managers 22. As discussed above, a local compliance manager 22 is generally responsible for managing the requests for available to promise. of component 32 and d to communicate them between the compliance server 16 and the promise server for associated compliance 14 over the life of the request for availability for promise 30. In an incorporation, the local compliance manager is involved in the appointment the promise, the acceptance, dispatch and in-file operations for the server available for associated promise 14 If specified source preferences exist, the requests for component 32 promise may include this information so that local compliance administrators 22 can identify and process the requests d available to promise of component 32 accordingly. If n there are specified source references, the local compliance managers 22 may be able to identify the available requests for relevant component 3 promises based on the user, the client or the product. At a server location available for particular promise, local compliance manager 22 receives the request d available for component 32 promise and generates an appointment request on the available server for promise 14 using the appropriate order syntax for the engine of associated private planning. As part of this processing, the local compliance manager 22 evaluates the business constraints encapsulated in the available request to promise component 32 and acts accordingly.

The planning engines may vary in relation to the requirements of this interconnection. As an example, the factory glider motors typically keep the data available for the promise of which the request transactions will consume the allocated product availability. Each component request is planned against an inventory representation of finished items, materials or available capacity, and other appropriate factors to determine the availability of the product. There may be a functionality to control the output structure of the resulting citation response from the point of view of shipping time and batch size. In this situation, the local compliance manager 22 can submit the appointment request as a planning transaction and value the appointment response according to the business decisions encapsulated in the available request for the promise of component 32. If the answer of the The server available for promise 14 does not meet these requirements, the local compliance manager 22 identifies this and sends a failure notification to the compliance server 16.

For example, if the complete submission attribute within the available request for component 32 promise requires that the request be fully satisfied, and the server appointment response available for promise 14 is less than the quantity attribute requested, then the local compliance manager 22 may indicate the citation of component 34 as having failed and provide an appropriate descriptive failure annotation. This line-frent evaluation can be important since, depending on the planning engine, the response of the server from available to promise can be multidimensional (offering multiple options). Providing the response valuation at the local compliance manager level rather than at the compliance server level allows the failure conditions to be identified and allows them to be resumed before the component 34 appointments are sent back to the compliance server. 16, thereby reducing the overall network load.

As an example of a server response available for multidimensional promise, consider a given request line item (for example, the wheels on May 8) for which the answer may be that 60 wheels are available on May 8 for 22 dollars, and / or 30 wheels on May 10 for $ 16 and / or 100 wheels for May 12 for $ 1. These are multiple options for online article appointment. The system 10 can allow the incorporation of rules and ranges. For example, the ability to take 30 rolls on May 10 and the remaining 70 wheels on May 12 may be restricted and the option for $ 16 on May 12 included a quantity restriction inconsistent with this.

As a further example, consider 3 online article requests (for example 100 wheels, 25 simple axes 25 complex axes delivered proportionally on May 8) Online article citations can be computed as indicated above with multiple options, then combined in a proper way. For example, the sample axis may be available on May 9, 15 units and May 11 25 units for $ 1. The complex axes may be available on May 8, 10 units and May 10, 25 units and May 10, 2 units, for 25 dollars. Ignoring the business restriction of proportionality including the request, and the delivery of product satisfying the order may occur for several days, May 8 to May 12, as appropriate. A business restriction of proportionality, however, can mandate that online items are only delivered in proportional quantities as they were ordered, since for example it can not do any good to deliver the wheels if the axles have not been delivered. The result indicated above in the following multi-dimensional example citation that includes citations of multiple online articles obeys a business constraint of proportionality for example. May 9 - 40 wheels, 10 of each axis, for $ (22 * 4 + 10 * 10 + 25 * 10) May 10 - 28 wheels, 7 of each axle, for $ (16 * 28 10 * 7 * 25 * 7) May 10 - 60 wheels, 15 of each axle, for $ (16 * 3 + 22 * 30 + 10 * 15 + 25 * 15) May 11 - 88 wheels, 22 of each axis, for $ (16 * 3 + 22 * 58 + 10 * 22 + 25 * 22) May 12 - 100 wheels, 25 of each axis, for $ (16 * 10 + 10 * 25 + 25 * 25) In one embodiment, system 10 supports many different business constraints, some of which may require one or more extra fields that have to be specified. To model this, the business restriction field may be an extension selector, as described in United States of America Patents Nos. 5,764.54 and 5,930,156, both of which are incorporated by reference herein. Additional extension fields can be made operational when the corresponding extension value is inserted into the extension selector field. For example only and not by way of limitation, a maximum variance restriction can be specified with the request of available pair promise 30 and an additional field can be added to the request model called Max_variation_percentage that allows the client 12 or a user associated with the specify the quantity d variation of a requested quantity that will be tolerated. That field may not exist and may not take any memory space when the maximum variation constraint is not specified. The system 10 may allow such an extensible model or capacity to be used with respect to any or all of the business constraints described herein, providing significant flexibility and an important technical advantage over flat techniques or other prior modeling techniques.

Within system 10, several local compliance administrators 22 can compute a variety of partial or partial-promise appointments, for example, that do not contain details of supply availability. When this occurs, the compliance server 16 may be assigned the task of ting a combined promise using the partial citation information. Worst, since local compliance managers 22 can be backed by servers available for lower promise 14 unable to provide the available information for adequate rich promise, the compliance server 16 may need to deal with a varied sophistication of component citations or of promises of component and even form the best promises or possible appointments for the request of available for promise 30 as a whole. Completion of this task properly may require any number of business restrictions to prompt the interpretation of the various component appointments or the various component promises or to mutate the various component appointments or the various component promises as appropriate. The extension within the models representing compliance administrators d promise 22 allow different constraints to be modeled for mutant component appointments or component dues. The present invention contemplates extension co with respect to any suitable business restrictions described herein.

In contrast to the situation of the factory glider engine, where the available par-promise server 14 is associated with a supply chain glider engine there is usually a significant representation and relationship to the endowments as well as for example in relation to the Restrictions on lot size or order time. As a result, the local compliance manager 22 is able to pass these restrictions from the available request to promise 32 to the available server to promise 14. In particular with respect to the supply chain glider engines, the compliance manager Local 22 may need to distinguish between appointment and promise workflows since the initial appointment request for the server available for promise 14 may be just a question that does not consume any assigned product or available material or capacity. The resulting citation responses are sent to the available server to promise 14 back to the local compliance manager 22. In the EDI base exchanges, however, an appointment request to the server available for promise 14 may currently result in a consumer promise of available for promise.

The local compliance manager 22 devalues the quote response from the available server to promise 14 according to the business constraints encapsulated in the available request for original component promise 32. Again, the processing requirements of this evaluation will depend on the sophistication of the planning engine associated with the server available for promise 14. With a supply chain glider engine, this appointment response can encompass business constraints so that the responsibility of local compliance manager processing 22 It is limited. In the case of a factory glider engine, however, the local compliance manager 22 may require that the appointment response be evaluated closely before a component 34 appointment is generated. The server available for promise 14 may be capable to return one or more appointment responses, each of which may be evaluated in relation to the applicable business restrictions.

After evaluating the appointment responses of the servers available for promise 14, the local compliance manager 22 computes a component 34 appointment that includes product availability information and regul as the compliance server 16 can mutate the component appointment 34. Local compliance manager 22 sent component appointment 34 back to fulfillment server 16. If multiple valid appointment responses are required according to the restrictions, the local compliance manager 22 generates and sends multiple appointments for component 34 d return to the compliance server 16. If the request d available for the promise of component 32 fails to give an appointment for valid component 34, the local compliance manager 2 may send a notice of failure noted to the compliance server 16. Such notifications of failure may include, for example, "insufficient product quantities" OR "unable to satishipment delivery or batch size requirements. " As described below, the compliance server 16 mutates the citations of component 34, according to the information and rules that they provide, so that together the component citations 34 satithe business restrictions applied in the compliance server 16. or established together with the request for availability to promise 30.

COMPONENT APPOINTMENT ATTRIBUTES In an embodiment, each component appointment is an object with the following attributes or supports the following information, in any appropriate combination and if limitation: (1) component citation identification-assigned local compliance manager 22 when it creates the cit cit component; (2) identification of component appointment; (3 identification of compliance server; (4) product identification- may not directly correspond to the product specified in the component request since an alternate or a substitute may have been specified; (5) unit of measurement may not correspond to a specific component request since the server available for promise 14 may have responded in a unit of measure different from the requested one; (6 promise amount- the quantity of product for delivery d component appointment; (7) promise date - the product delivery date is promised to be sent by a data server available for promise 14 which represents the shipment from the distribution or manufacturing location rather than the customary delivery date; (8) promise lot ( 9) pledge attribute - list of category / attribute combinations for the component citation: (10) type of pledge - type of response, l which the local compliance manager 2 2 updates (eg "as requested", "alternate / substitution" "suction") (11) unit axis - unit price for product on coin basis of server available for promise 14; (12) state appointment- the local compliance manager 22 updates indicating whether the appointment failed or succeeded; and (13) reason for the failure- brief description of the reason for failed appointment (for example insufficient supply availability, business restrictions that can not be met, that the local compliance manager 22 evaluates, updates and sends to the compliance server. 16 Appointments of the process component [compliance server].

Once the 16-hr compliance server processed and sent the available requests to promise component 32 to the local compliance managers, the compliance server 16 monitors that the resulting component appointments are completed. 3 may be considered complete when each request for availability of component 32 has received at least one component cit 34 or a failure notification. Providers can respond to requests for available to promise component 32 with multiple options available for acceptable promes. The compliance server 16 uses the citations of component 34 to generate and send to the client 12 a multidimensional cit (variable on the product suctions, lead time and price for eg); when the d component 34 appointments have been received and the appointment 36 is complete, the compliance service 16 evaluates the global appointment 36 according to the business constraints specified in the request d available for the originating promise 30. As a result of this, the compliance server 16 determines whether the requirements for the request for available for promise 30 s have filled and filtered any supplier responses n conforming the unified appointment 36 to be presented to the client 12. In an embodiment, the compliance server 1 modifies the citations of component 34, according to the information and the rules they provide, so that together the citation of component 34 satisfies the business restrictions applied to the fulfillment server 16 or established together with the request of available for promise 30. Due to that some 12 clients may not be able to handle a multi-dimensional appointment 36, the interconnection of the client Compliance Code 16 can also provide more descriptive use of appointment information according to particular needs.

In general, the compliance server 16 attempted to provide a "best fit" response to the client 12, according to his assessment of appointment 36 against the business restrictions of the client and the provider. If, for example, the delivery attribute in time for the request d available for promise 30 specifies that the shipment must be received on time, and one or more quotations of component 34 are somehow insufficient, the compliance server 16 can assign a status of failure to the request of available par pledge 30 in its entirety.

The compliance server 16 can simply pass along the client 12 the fail status annotations received from the local compliance managers 22. On or in addition to this, the compliance server 16 can itself assign the annotations. of failure evaluation. For example, while the local compliance administrators 22 may have generated valid component citations 34, the compliance server 16 may determine a failure of the global cit 36 based on the appointment price and not filling the business restrictions for the client . If a particular request line item gives multiple component citations 34, each component appointment 34 must be evaluated in relation to the specified restrictions. All citations of valid components 34 for the online request article are transmitted to the client 12 in the form of an appointment 36 using the network of 18.

If the server's response of available for satisfactory promise in one or more ways (based on the products, delivery times, prices, singularly or in any combination) then the compliance server 16 can carry out additional functions before generating the appointment 36 for communication to the customer 12. For example, customer 12 may require the calculation of the price, taxes, shipping cost or delivery schedule. Depending on the implementation, this may be accomplished using specialized routines or may involve the incorporation of one or more background planning processes that rely on, for example, transportation and logistics planning packages. The use of such "auxiliary processes" may be optionally delayed until the client 12 confirms a whole part of the appointment 36.

In one embodiment, the compliance server 16 provides an evaluation engine component that operates according to the client's needs. For example, when the compliance server 16 is implemented in conjunction with the packaged enterprise resource planning system, the client may prefer that the price evaluation be handled within the limits of the enterprise resource planning system. if a compliance server 16 handles the price evaluation, each component appointment 34 is the first price evaluated in the list and then the prevailing discounts are applied based on the pre-specified line, the request or the volume-level programs. Multiple discounts may be applicable to a request for available par promise given 30. The price evaluation and discount programs may be specified according to the customer, the customer's location, the supplier, the agreement, the product group, the product or to any other suitable parameter parameter parameter.

The multidimensional responsiveness of the compliance server 16 may present a special problem in relation to the price evaluation functionality. That is, more than one option is presented to the user for a particular request line item, it may be difficult for compliance server 16 to evaluate the order as a whole for discount purpose. Where there are multiple component citations 34 for an available request for component 32 promise, the price evaluation for the request d available for promise 30 can not generally be represented as a total simple sum with the discount. Instead of this, the price of the request for availability for promise becomes a range with minimum and maximum limits and is not finalized until the request for availability for promise is confirmed. At that point, the price evaluation is recalculated and presented to the user with the promise of confirmation.

When the compliance server 16 has supplemented the evaluation appointment 36 in relation to the specified restrictions of the available request for promise 30, and the appointment 36 has been determined to satisfy these requirements, the compliance server 16 sends the appointment 36 to the client 12 for the review and confirmation of the appointment. If the requesting client 12 is no longer active, the appointment 36 can be stored until it can be requested at a later time. The structure of citation 36 models that of the available request for originating promise 30. Citation 36, however, can be potentially more complex than the request d available for compliance 30 since it can contain multiple responses for each article online of request delivery of request line item.

APPOINTMENT OF ATTRIBUTES In an embodiment, the citation is an object that has the following attributes or otherwise supports the following information, in any appropriate combination and if limitation: (1) citation identification-assigned to the compliance server 16 and may be the same as Identification of the request; (2) identification of application; (3) maximum total price (based on currency) - maximum total quote price calculated on compliance server 16 on the coin basis representing the higher citation price union; (4) minimum total price (base currency) - minimum total price of cit calculated on compliance server 16 in the base currency representing the lowest price quotation limit; (5) maximum total price (customer's currency) - maximum total price of cit calculated on compliance server 16 in the client's preferred moned; (6) minimum total price (client currency) - minimum total price of the quote calculated in compliance service 16 in the customer's preferred currency; (7) appointment-compliance server status 16 updates during the life of the appointment (eg "missed appointment", "pending acceptance", "accepted", "rejected", "acceptance not received"); (8) accepted date-confirmation of date and time was processed, if any; and (9) date rejected-date and appointment time was rejected if any.

APPOINTMENT LINE ITEM ATTRIBUTES In one embodiment, the cit line item is an object that has the following attributes or otherwise supports the following information in any combination and without limitation: (1) line item ID assigned to compliance server 16, accommodating responses multiple appointments per request line item; (2) identification of appointment-citation of links for the article-appointment line; (3) product identification, may not correspond directly to the product specified in the originating request line item since a substitute proxy may instead be cited; (4) product measurement unit-may not correspond to the unit of measurement specified in the originating request line item since the server available for promise 14 may have responded in a different unit of measure than requested; (5) quantity offered-the amount associated with the appointment line item; (6) date offered-date in which the amount will be available, which may represent the date sent by the server available for promise 14 or a coordinated customer delivery date, depending on the implementation; (7) batch offered-batch identifier for quote line item; (8) attributes offered-list d category / attribute combinations for line item d appointment; (9) type of citation-type of response (for example "as requested", "alternate / substitute" "option"); (10) offered unit price (base currency) - unit price associated with the item line item expressed in the base currency of compliance server 16; (11) total price offered (moned base) - associated computed total price for the item-line of appointment expressed in base currency of compliance server 16 (12) unit price offered (client's currency) -price d unit for item-line of quotation expressed in the client's preferred currency; (13) total price offered (customer's currency) total price computed for the cit line item expressed in the customer's preferred currency; (14) state-line appointment-server updates d 16 logical parameter compliance based on the state c corresponding component appointment and indicating whether the request line item has been successful or has failed to obtain an acceptable quotation; (15) reason for failure-brief description of the reason for the failure of the appointment; and (16) citation line item acceptance status-indicates whether the citation line item was accepted or rejected and that compliance server 16 uses par to generate component citation confirmation transactions for local compliance administrators 22 .

In one embodiment, the delivery of item of appointment line is an object having the following attributes that otherwise supports the following information, and any suitable information and without limitation: (1 appointment-item line assignment identification-assigned) in compliance server 16 and obtains multiple cit responses per line item delivery; (2) identification of appointment line item; (3) quantity offered; (4) date offered; (5) lot offered; (6) attributes offered.

APPLICATION CONFIRMATION WORK FLOW Figure 3 illustrates a sample appointment confirmation workflow in which the client 12 generated an appointment confirmation based on the appointment 36 and possibly, the entry to from an associated user. The client 12 sends the appointment confirmation 40 to the fulfillment server 16, where it is decomposed and evaluated. The fulfillment server 16 sends the resulting component citation confirmations 42 to the local compliance managers 2 using the network 20, the local compliance managers 2 process the citation confirmations of component 42 and cooperation with the available servers for associated promes 14 and local compliance managers 22 general pledges of component 44 accordingly. The local compliance administrators 22 then send the promises of component 44 back to the fulfillment server 16. The fulfillment server 16 processes the promises of component 44, generates a single unified promise 46 and sends promise 46 to customer 12 for review and confirmation.

Generate Appointment Confirmation [Client] When appointment 36 is received, the customer 12 or associated user reviews and can selectively accept or reject one or more appointments or individual appointment line items 36 as a whole. Depending on the capabilities of the servers available for promise 14 and the business restrictions in relation to the request available for promise 30, one or more valid options may be available for any requested online article. The client 12 or an associated user can then select from the multiple options before accepting appointment 36 in whole or in part. Once this process has been completed, the client 12 sends the appointment confirmation 40, including all acceptances and rejections, to the fulfillment server 16 for processing. Because appointment confirmation 40 can accept only a subset of appointments 36, this is appointment confirmation 40 rather than appointment 36 which will form the basis of the resulting promise 46. If client 12 considers appointment 36 unacceptable, client 12 can queue the available request to promise 30 for a later resubmission. Compliance constraints specify the period and frequency of requests rescissions (re-appointments) according to particular needs.

In an embodiment, appointment confirmation 4 is an object having the following attributes or otherwise supporting the following information, in any combination and without limitation: (1) appointment identification; (2 line identification-appointment item; (3) appointment line item status-indicates whether an appointment line item was accepted, rejected, canceled, or queued, used in the fulfillment server 16 to generate the confirmations d appointment of component 42 to be submitted to local compliance administrators 22.

APPOINTMENT CONFIRMATION PROCESS [COMPLIANCE SERVER] Appointment 33 is a non-mandatory declaration of product availability. Once the client 12 accepts the appointment 36 in whole or in part, the fulfillment server 16 requires the confirmation of the resulting appointment 40 through the redistribution of the local compliance administrators 22 and the form of the appointment confirmations. of component 42, allocated supply of consumption to each server place d available for appropriate promise. In an incorporation, the request for availability for promise 30 is a distributed and persistent object that is monitored and maintained in each of the respective commitment places (local compliance administrators 22). Therefore, until the request for available par promise 30 is either complemented or canceled, the requests d available for the promise of component 32 remain as a part of a distributed order delay that it intelligently manages the compliance server 16.

In one embodiment, the compliance server 16 is capable of processing a variety of responses from the client 12 or an associated user, including partial full acceptance, rejection, re-citing, changes, cancellations, questions, and any other appropriate user responses. If an appointment line item is accepted, it must be confirmed by local compliance managers 22 as those local compliance managers 22 will generally not have made supply reservations based on the corresponding component appointment 34. As a result of the lack of reserved supply, however, the line item may fail so that compliance server 16 requires that local compliance managers 22 be notified so that they can take action if appropriate. At incorporation, the compliance server 16 may request local compliance administrators 22 to provide component 44 promises together with the 34 component appointments, but with an acceptance by relatively short date. The compliance server 16 can then accept the promises of component 44 when it receives the confirmation d citation 40 from the client 12. The compliance server 16 is assigned the task with appropriately combining the acceptance dates by local compliance administrators 2 associated with a request for availability to promise part 30. The date of acceptance by result should generally allow the compliance server 16 time to compute the appointment 36 (or the promise 46) and preferably, may include some cushioning. Since most responses from local compliance managers 22 may reflect the dates when the products will actually be delivered to the customer, but instead may be statements from the provider's submission programs, the compliance server 1 may Provide the ability to derive the dates of delivery to the customer for an order of multiple items, possibly as an optional post processing step to the action d promise.

As discussed above, the confirmation of cit 40 may be an object that specifies the status of the appointment line item as accepted, rejected, canceled, or queued. Compliance server 16 indicates the status of the corresponding component appointments among 4, filters acceptance of rejections on an article-line basis, generates appointment confirmations of component 42 for submission to local compliance administrators 22. The Compliance server 16 updates the status of the availability request to promise the originating component 32 to a "pending pending". In a citation confirmation of incorporation component, 42 is an object having the following attributes or otherwise supporting the following information, in any suitable combination and without limitation; (1) Component appointment identification; (2) identification of local compliance manager; and (3) component appointment status- indicates the component appointment was accepted, rejected or canceled.

COMPONENT APPOINTMENT CONFIRMATION PROCESS [ADMINISTRATE OF LOCAL COMPLIANCE] The local compliance manager 22 receives an appointment confirmation from component 42 and generates a promise request to the available server for promise 14 using the appropriate command syntax for the associated planning engine. This transaction is similar to the original component request transaction, except that it seeks a firm commitment from the available server to promise 14 of the product location or available materials or capabilities. The confirmation transaction must also confirm the corresponding commitment for the desired component appointment 34 so that if the original component promise availability request 32 receives multiple component appointments 34, the local compliance manager 22 must confirm the appointment response. specific to the user specified in the client 12. At this point, the server of available pair promise 14 responds with a firm promise, consuming the appropriate assigned products or available materials or capacity. In some cases, it may also be appropriate to create acceptance at this point. The local compliance manager 22 can eliminate the rejected component citations 34 based on the rejection commands any other information received from the client 12. The local compliance manager 22 computes a promise of component 44 which includes the information and the rules of how the Compliance server 16 can mutate the promise of component 44. When the promise response is received from the available server to promise 14, the local compliance manager 22 evaluates the response to ensure that it is consistent with the component appointment confirmation 42, since it is possible that the promise response is different from the original component appointment 34. This may occur, for example, where a change in planning has somehow altered product availability or when another appointment confirmation component 42 has resulted in the product endowment being consumed in the meantime. When this occurs, the local compliance manager 22 notices this condition and evaluates whether the promise response still satisfies the business constraints specified in the available request for component 32 promise. If this is the case, the local compliance manager 22 generates a promise of component 44 according to the promise response of the server available for promise 14 If the multiple promise responses are considered valid according to the restrictions, the local compliance manager 22 generates and sends multiple component promises 44 return to compliance server 16. If the promise of component 44 differs in any way from the original component quote 34, it can be noted in the promise of component 44. If the promise of component 44 no longer conforms to the specified business constraints In the request d available for the promise of component 32, the local compliance manager 22 can generate An annotated failure notification or other appropriate for communication to the fulfillment server 16. Sample annotations may include "insufficient product quantities" or "unable to satisfy lot size or shipment delivery requirements".

In an embodiment, the promise of component 4 is an object that has the following attributes or that otherwise supports the following information, in any appropriate combination and without limitations: (1) identification of component-assigned promise when the compliance manager local 22 creates the component promise and can be identical to the component appointment identification; (2) identification of compliance server; (3) accepted by may indicate an expiration date for the promise component for which an acceptance must be received or the corresponding pledge reserves may be released; (4) component promise status-indicate whether the promise component has been successful or has failed; and (5) reason for failure- the description of the reason because the promise has failed if any.

Component Promise Process [Compliance Server] Once the compliance server 16 has processed the component 42 appointment confirmations and sent them to the local compliance manager 22, it monitors that the resulting component promises 44 are completed. In an embodiment, the 46 promise is considered complete when each of the originating component citation confirmations 42 has received one or more promises of component 44 or failure notifications. The compliance server 16 can also monitor the promise by specifying the attribute the length of time that the compliance server 16 should wait for the 44 promises from the local compliance administrators 22. When this restriction is reached before all the promises of component 44 have been received, so that appointment confirmation 40 has essentially expired, the compliance server 16 can generate an appropriate failure notification and send it to client 12. In the formulation of promise 46, the server Compliance 16 can take into consideration any attributes of accepting po for a promise of component 44 and specifically an attribute of accepting for for promise 46 accordingly.

In one embodiment, once the promise of component 44 expires, the compliance server 16 and the appropriate local compliance administrators 22 release the supply reservations. Where the compliance server 1 provided an accept data by is more stringent than those of the local compliance administrators 22, the compliance server 16 may not require sending an indication of the release back to the local fulfillment administrators 22. In Similarly, if the promise 46 fails to reject you, the compliance server 16 will notify local compliance administrators 22 so that local compliance administrators 22 can release the appropriate supply reserves.

When the compliance server 16 receives the promises of component 44 of the local compliance administrators 22 and the promise 44 is completed, the compliance server 16 evaluates the overall promise 44 according to the business constraints specified in the available request for original promise 30 to again evaluate the success of the global response. This is done again during the promise generation phase because it is possible that one or more components of promises 44 may be different from the original component citations 34. The price evaluation may also be necessary to be recalculated during The promise generation phase if any promises of component 44 are different from the original component citations 34. In addition, if there were multiple citations of component 34 for an available request for a particular component 32 promise, it may be necessary to calculate a confirmed price. final. In an incorporation, all the promises of component 44 must be valid to achieve a successful promise 46 In one embodiment, the compliance server 16 can mutate or otherwise manipulate the promises of component 44, according to the information and rules that this provides, so that together the promises of component 4 satisfy the business restrictions applied to the server 16 or successful fulfillment together with the request for availability for promise 30. In addition to sending the promise 44 to client 12, the compliance server 16 can send the mutated component promises 44 back to the originating local compliance administrators 22 so that said local compliance managers 22 can adjust their supply reserves appropriately.

If the overall response no longer satisfies the requirements of the available request for promise 30 due to changes in product availability in the interval between appointment 36 and promise 46 or for any other reason, compliance server 16 may assign a state fails to promise 46 and write it down with descriptive information before sending the promise 46 to the client 12. The compliance server 16 may simply pass along the failure status annotations received from the local compliance manager 22. Instead of or in addition, the compliance server 16 can assign an own annotation. For example, even though the local compliance manager 2 may have generated an acceptable component promise 44, the compliance server 16 may determine that the overall promise 4 fails based on the price of the promise that n satisfies the business constraints specified by e customer.

The compliance server 16 may include a delivery coordination engine component, depending on the client's requirements. Without this capability, the compliance service 16 will return the optimal shipping dates from the respective manufacturing and distribution locations rather than returning the delivery date to the customer. The delivery coordination can be achieved using a relatively simple tabl-driven technique that links standard front products, places and time. More sophisticated implementations may involve the use of advanced planning engines for transport optimization and logistics. In this scenario, it is feasible that the delivery coordination can be calculated in multiple phases. For example, a standard table-based forward time approach can be used in the initial generation phase to derive a preliminary delivery date. Because transport planning optimization is generally more effective when multiple delivery requirements are considered, a second phase of a load-oriented processing may be desirable to evaluate the complete request delay. As a result of such second-stage processing, the delivery dates correspond to the requests available for individual promes 30 can be adjusted to reflect an optimized global delivery plan.

When the fulfillment server 16 h completed the evaluation promise 46, has calculated the delivery price as appropriate, and the overall response is considered satisfactory, then the fulfillment server 16 sends the promise 46 (including all valid component promises) 44) to customer 12 for confirmation. The structure of promise 46 models that of the originating citation 36, but is potentially simpler than its citation counterpart since citation 36 may have been multidimensional while pledge 46 is discrete. If the requesting client 12 is no longer active, the promise 46 can be requested at a later point.

Promise Attributes In an embodiment, the promise 44 is an object that has the following attributes or supports the following information, in any suitable combination and if limitation: (1) promise identification-assigned to the compliance service 16 and may be identical to the identification c.; (2) total price (currency base) -the total price of the promise calculated on compliance server 16 based on the currency; (3) total price (customer's currency) - total promise d calculated on compliance server 16 in the customer's preferred moned; (4) total tax (currency base) -and total tax associated with the request calculated in compliance service 16 based on the currency; (5) tota tax (client currency) - total tax associated with the request calculated on compliance server 16 in a currency d preferred by the customer; (6) confirmed date-date and time d promise processed; (7) accept by-may indicate a date of expiration for the promise by which an acceptance must be received or some or all of the associated pledge reserves may be released; (8) date canceled-the date and time the promise was canceled, if any; and (8) date of delivery-the date and time promise was completed if there is one.

Online Article Attributes Promise In an embodiment, the article and line promise is an object that has the following attributes or that otherwise supports the following information, in any combination and without limitation: (1) item identification and promise line-assigned on the server of compliance 16 may be identical to the identification of online article d appointment; (2) product identification for the promised product (3) unit of product measurement for the promised product; (4) promised quantity for article-line of promise; (5) date of promised delivery-the promised quantity of dates shall be available to be sent and represents the delivery date given by the service available for promise 14; (6) delivery date the customer promised quantity date will arrive at the designated customer at the shipping location and it will be calculated and updated using the logistics engine and transportation planning; (7) promised lot; (8) promised attributes; (9) type of promise -type d response to online article promise (eg "as requested", "alternate-substitute"); (10) promised unit price (base currency) - unit price in base currency of compliance service; (11) promised total price (base currency) total price computed in the base currency of the fulfillment server; (12) promised unit price (customer's currency)-unit price in the customer's preferred currency; (13) total promised price (customer's currency) -price calculated in the currency preferred by the customer; (14) state of promise online article-compliance server 1 updates according to the corresponding component promise status, indicating whether the request line item succeeded or failed to arrive at an acceptable prompting response; (15) accepted to be able to indicate a date of expiration for the online article promise by which an acceptance must be received or the associated promise reserves may be released; (16) reason for failure; (17) date / time of delivery; and (17) date canceled.

In an embodiment, the article delivery item and delivery line is an object that has the following attributes or that otherwise supports the following information in any appropriate combination and without limitation: (1) Prompt delivery of online item assigned in the compliance server 16 and possibly identical to the online item identification appointment; (2 promise amount; (3) promised delivery date; (4) customer delivery date; (5) promised lot; and (6) ) promised attribute.

Promise Acceptance Workflow Figure 4 illustrates an exemplary promise acceptance workflow in which the client 12 generates an acceptance 50 based on the promise 46 and possibly, an entry from an associated user. The client 12 sends the acceptance 50 to the fulfillment server 16, where it is decomposed and evaluated. The compliance server 16 then sends the resulting component acceptances 52 to the local compliance administrators 22 using the network 20, the local compliance administrators 22 process the acceptances of component 52 in cooperation with the servers available to promise partners 14 and the Local compliance managers 22 generate acceptance confirmations of component 54 as appropriate. The local compliance administrators 22 send the acknowledgment confirmations of component 54 back to the fulfillment server 16, and where these are processed so that the final acceptance confirmation 56 can be sent to the client 12 using the re 18, completing the cycle .

Even though this workflow describes an interactive promise acceptance scenario, the present invention contemplates a non-interactive acceptance process such as that which is typically associated with EDI-based workflows. In some cases, it may be appropriate to carry out the current appointment confirmation and the promise acceptance process. However, it is appropriate to separate the interactive appointment confirmation and the promise acceptance processing, if there is a possibility that the availability of the product may change in the interval between the confirmation of appointment 40 and acceptance 50. In this case, the user may wish to optionally reject the promise 46 if and does not reflect the appointment 36. This type of scenario can be specific for the server environments available for promise based on SCP. Those skilled in the art will appreciate that the system 10 accommodates the EDI base and any other suitable workflow and that the present invention encompasses all these workflows.

General Acceptance [Client] A client 12 or an associated user has the promise 46 evaluated received from the compliance server 16, from client 12 or the user can accept the promise 46 in whole or in part. The client 12 generates a formal acceptance 50 which corresponds to the request available for originant promise 30 and sends it to the fulfillment server 16 for processing.

Acceptance Attributes In one embodiment, the acceptance 50 is an object having the following attributes or otherwise supporting the following information, in any appropriate combination and without limitation: (1) identification of acceptance assigned to the compliance server 16 and may be identical to identification of appointment and identification of promise; (2 total price (base currency), (3) total price (client currency), (4) total tax (base currency), (5) total tax (client currency), (6) date accepted-date and acceptance time processed; (7) date canceled-the date and time of acceptance were canceled if there are any; (8) date sent-the time and date of acceptance were met.

In one embodiment, the acceptance line item is an object that has the following attributes or otherwise supports the following information, in any combination and without limitation: (1) online article-assigned acceptance of the article on the server of compliance 1 and the body must be identical to the identification of article and appointment line and to the identification of online article d promise; (2) product identification; (3) product measurement unit; (4) amount promised for the online article of acceptance; (5) promised delivery date; (6) delivery date to customer; (7) accepted lot - associated lot identifiers with online article acceptance; (8) accepted attributes-list of associated category / attribute combinations acceptance of the online article; (9) type of acceptance-type of response for online article acceptance (for example "as requested", "alternate / substitute", "option"); (10) Accepted unit price (base currency) - unit price for line item acceptance expressed in the base currency of the fulfillment server, feasibly if computed in the phase d promise; (11) accepted total price (base currency) - total price computed for acceptance of the online article expressed in the base currency of the fulfillment server, feasibly d been computed in the promise phase; (12) accepted unit price (client currency) - unit price for the acceptance of online article expressed in the client's preferred currency, very likely to have been computed in the promise phase; (13) accepted total price (customer's currency) -price calculated for the online article of acceptance expressed in the client's preferred currency, feasibly if it has been computed in the promise phase; (14) article status and acceptance line-logical parameter that the fulfillment server 16 updates based on the corresponding component's promise status and which indicates whether the article and application line succeeded or failed to obtain an appropriate acceptance; (15) reason for failure-brief description of the reason for the failed acceptance, if any; (16) date of shipment-date and time of acceptance of the online article that was sent; if there are any; and (18) date canceled-date and time the acceptance of the online article was canceled; if there are any.

In one embodiment, online article acceptance delivery is an object that has the following attributes or otherwise supports the following information, in any suitable combination and without limitation: (1) identification of online article delivery acceptance assigned at the compliance supplier 16 and may be identical to the identification of online article of appointment delivery; (2) acceptance amount for acceptance of online article delivery; (3) promised delivery date; (4) customer delivery date; (5) promised lot - lot identifiers associated with online acceptance item delivery; and (6) promised attribute-list of category / attribute combinations for the online article acceptance delivery.

Acceptance Process [Compliance Server] In an embodiment, acceptance 50 is an object that specifies the status of each line item promised, accepted, rejected, canceled or queued. The compliance server 16 indicates the status of the corresponding component promises 44, filters acceptances and rejections on the online article basis, and then generates the acceptances of component 52 for submission to local compliance administrators 22. The Compliance server 16 can also update the status of available requests to promise component 32 as appropriate.

Component Acceptance Process [Local Compliance Administrator] When the local compliance manager 2 receives the component acceptances from the compliance server 16, it generates and executes a transaction of acceptance in the appropriate syntax to the availability server for promise 14 and to the associated planning engine. This transaction is similar to the originating component citation confirmation 42 except that it creates a formal acceptance for the existing pledge 46. The pledge fulfillment manager 22 records the server confirmation responses available for pledge 14 and sends the confirmations of acceptance of corresponding component 54 back to the compliance server 16 using the network 18.

Confirmation Process of Acceptance of Component [Compliance Server] Once the compliance server 16 has processed and sent the acceptances of component 52 to the local compliance managers 22, it monitors the completion of the resulting component acceptance confirmations 54. In an embodiment, the confirmation of acceptance 56 is considered complete when each of the acceptances of component 52 has received one or more acceptance confirmations of component 54. When the compliance server 16 has received all the confirmation of acceptance of component 54 and acceptance confirmation 5 is complete, the server of compliance 16 sends the final acceptance confirmation 56, including all valid component acceptance confirmations 54 to client 12 using network 18.

Petition Change Workflow d Available for Promise In this workflow, the client 12 asked a request for available for active promise 30, changes all or some of the parts of the request available for promes 30 and resubmits the request for available for promise 3 to the compliance server 16. Compliance server 1 then breaks the available request for promise changed 3 through the distributed network of local compliance administrators 22 and handles any non-conforming response. For example, customer 12 may re-quote the order in whole or in part with the intention of improving the promised quantities or delivery dates associated with the request for available par promise 30. Customer 12 may also question a request for availability for active promise and then cancel the request for availability to promise 30, in which case the fulfillment server 16 must propagate this cancellation to each of the promise fulfillment administrators 22 who handle a part of the request available for promise 30. In an addition, the cancellation effectively suppresses the request for availability to promise 30 in each persistence date, including the appropriate local compliance administrators 22 and the compliance server 16.

Initiate Request Changes for Promise [Client] Once the available request for promes 30 has been displayed to the customer 12 through the question, the user may be able to enter a "avoid request" mode. In this mode, the user is able to change the request and any appropriate way, for example, adding deleting online request items, changing the required quantities and dates, or adjusting the associated business restrictions. The client 12 or the user then re-submits the request for available to promise changed 30 or queue the available request for promes changed to resubmit it in the future (a new appointment d). In an incorporation, if the request for available pair promise 30 has been fully satisfied, the changes can not be made. If the request for availability for promise 30 has been partially satisfied, only the request line items that are still pending can be changed.

Petition Change Process Available for Promise [Compliance Server] The compliance server 16 evaluates the request for availability for re-submitted promise 30 and determines what changes have been made to any part of the request structure (for example the request, the item and line request or a delivery request). online article). For the changed parts of the available request for promise 30, the compliance server 16 reviews the availability requests for existing component 32 promise accordingly. This may involve re-evaluating any source, alternate or substitution or other preferences as well as the specified business restrictions. Changes can also include and add or individual online petition items. Once the compliance server 16 has completed these revisions, the requests for availability for promise of the resulting component 32 are again sent out of the re 20 to serve local compliance administrators. 22. The status of each available request. Promise pair of each component 32 can be put on "pending appointment" or "pending cancellation" as appropriate.

Petition Process Available for Commitment Pledge [Local Compliance Administrator] When the local compliance manager 2 receives the available request for the changed component 32 promise from the compliance server 16, the local compliance manager 22 generates and executes a request transaction in an appropriate syntax for the available server to promise 14 and for the associated planning engine. At this point, the request for available for the promise of changed component 32 is processed to the available server for promes 14 as if it were a new request of available for promise d component 32. Any cancellation of request for availability of component promise can be processed for the service available for promise 14 as a deletion.

The local compliance manager 22 evaluates the available server's response to promise 14 according to the business constraints that are specified in the available request for changed component promise 32. The processing requirements for the local compliance manager 22 in this phase may be identical to those with respect to the new request of available for component 32 pledge. For cancellations, local compliance manager 22 may update the status of any available request for pledge of locally maintained component 32 or citation of component 34 co "canceled". The local compliance manager 22 receives the server component citation response from available for promise 14 and sends the complaint-compliance server complaint 16 responses in the form of a new component appointment 34. The descriptive or other notifications can be created in the manner described above. If necessary, cancellation confirmations are also created and sent to the compliance server 16.

Component Appointment Process [Compliance Server] When the compliance server 16 has processed and sent the available commitment requests to the local compliance managers for change of component 32, it ensures that the resulting component appointments are completed.

In one embodiment, appointment 36 is considered complete when each available request for promissory note of originating change 30 has received one or more component citations 34 failure notifications or cancellation confirmations, as may be the case. The compliance server 16 can update the status of any available par request 30 and the appointment 36 maintained on the fulfillment server 16 based on any cancellation confirmations received from the local compliance administrators 22 Once the component appointment 34 I have received and appointment 36 is considered complete, the fulfillment server 16 re-evaluates the global appointment 36 according to the business restrictions specified in the request d available for the original exchangeable promise 30. The process and identical to that of an appointment 36 for a new request d available for promise 30 The valuation of the price of the cit can be recalculated from the beginning or in another way in light of the confirmed prices existing with the recently cited articles. When the compliance server 16 h evaluated the citations 36 in relation to the request restrictions of available for promise specified, a unified appointment 3 is presented to the client 12. This process is similar to that of a new appointment 36, except that the appointment original 36 and exists and therefore the compliance server 16 only updated parts of the appointment 36 associated with the request for available par exchange promise 30. The failure notifications and the cancellation confirmations can be generated and sent to the client 12 as appropriate . Subsequent user confirmation processing may be accomplished on a network change basis and may reflect the processing described above with respect to promise acceptance and appointment confirmation workflows.

Recording Workflow In an embodiment, the client 12 or an associated user is able to recite an existing available par promise request 30 at any point prior to the satisfaction or cancellation of a total or partial order. This ability does not affect any existing promise, but rather that it simply results in a new appointment. 36. The client 12 or associated user must accept the new appointment 36 to obviate the existing promise 46. Therefore, all processing and essentially the same as that of the request available for initial promise 30 except for the treatment of data objects. The client 12 or an associated user asks the request of available for original promise 30 to initiate this process. Once the request for available for promise 3 has been displayed through the request, the user can then select an appropriate recitation function and client 12 executes the recite command.

Work Request Queue for Promise The compliance server 16 can support the queue of intelligent requests, which can be configured according to a user, a client or other profile, information received from the client 12 or from an associated user, or information received from a system administrator or a function. The request queue parameters can specify the conditions under which the queue will occur, the duration of the queue, and the frequency with which the requests are submitted again. Since any changes through distributed local compliance administrators 22 and servers available for promise 14 may allow a queue request to obtain a satisfactory promise, such changes must be sent to one or more servers of the compliance server. Each compliance server 16 may reconsider its queue requests in light of the changes possibly by initiating an appropriate appointment or a work flow of promise. The queue of requests for promes 30 is more fully described in the patent applications of the United States of America numbers 08 / 491,167 and 08 / 802,434.

Start with the Request for Promise Request [Client] In an embodiment, the client 12 or an associated user may queue a request for available par promise-existing 30 at any point prior to the satisfaction or cancellation of total or partial order. Requests for available to promise in queue 30 are periodically returned to submit for a recitation with the intention of improving the result of the appointment. Similar to the recitation transaction described above, the queue process does not affect any existing promises 46 but simply resulted in a new appointment 36. The client 12 or an associated user can execute a queue function to initiate queue processing. after the unsatisfactory result of a request d available for initial promise 30 or after questioning an available request for existing promise 30. The queuing behavior may be limited according to specified parameters that refer to retest intervals maximum number of trials and the like.

Query Process Request Available for Promise [Compliance Server] The compliance server 16 receives the request queue instruction as a confirmation indicating that all the request line items have been queued. Based on this confirmation, the compliance server 16 updates the status of each line item of the request as "queued". Further processing of the available request for promise 30 is suspended until the queue parameters for such processing have been satisfied.

Based on the retest interval or otherwise the compliance server 16 may periodically return the requests for available for promise of the queued component 32 to the promise compliance administrators 22 for the appointment. At this point, the processing is identical to that of the process recitation workflow discussed above Component Promise Change Workflow Figure 5 illustrates a component promise change workflow according to the present invention. This or a similar workflow can be used to handle the modification of any appropriate existing amount of acceptance, promise, appointment, request or supply. It is common for requests to be available for pledges of delayed component 32 supply support to fluctuate over time. The types of changes are not frequent, but others are common must be handled efficiently. As an example, the planned supply often changes on a regular basis, usually at least weekly, frequently on a daily basis, sometimes even more frequently. In addition, the provisioning of various products or vendors, as described in the co-pending patent applications of the United States of America numbers 08 / 491,167 and 08 / 802,434, typically change at least as frequently. In both cases, all affected elements within the distributed system 10 must be modified and any pending appointments 36 or promises 46 may require adjustment or marking as spoiled.

The impact of the changes in the production plans and programs is likely to spread down to the requests of available for promise of component 32 local compliance managers 22; causing one or more existing commitments to be invalidated. The final result may be that one or more requests for available pa promise 32 is reprogrammed so that afterwards in the horizontal plane it is simply shortened. In one embodiment, the promise fulfillment manager 22 monitors the status of the requests available for the promise of component 32 to identify such events and communicates this in a manner consistent with the compliance server 16. As an example, the server is available as a promise. 14 can "publish" to the local compliance manager 22 the supply changes that affect the requests d available for promise of delayed component 32, and local compliance manager 22 can then notify the compliance server 16 and the compliance server 1 can evaluate the revised component request status act, for example, by notifying the client 12 of the situation and providing one or more options to the client 12. Similarly, changes can be made to the server 16 which are necessary to be sent to the affected local compliance administrators 22 so that they can adjust the reserves of the Supply in accordance form. In addition, each of the workflows described above can support one or more alternate workflows to handle cases in which the data components d available for system promise 10 have been worked which are invalidated due to such changes.

Process of Change of Server of Available for Promise [Administrator of Local Compliance] In one embodiment, the system 10 provides an interconnection protocol between the local compliance administrators 22 and the servers available for the promise pair 14 so that the planning changes affecting the promise characteristics of the availability requests for the promise of component 32 in the associated planning engines are proactively identified within the servers available for promise 14 and sent to local compliance administrators 22 for evaluation. This evaluation process is identical to that of the initial component promise response; that is, the local compliance manager 22 evaluates the promise response of the changed component according to the restrictions specified in the request for available for promissory note 30. The revised promise of the server available for promise 14 may not change the commitment between the client and the provider. Since in an embodiment the promise 46 and the acceptance 50 are different objects, a change to promise 46 does not change acceptance 50, which generally represents the mandatory business commitment between the customer and the supplier. The program and other changes can be negotiated and resolved so that the original commitment can be maintained. However, the mandatory business commitment does not change until the client 12 or an associated user accepts the revised promise 62 and a new acceptance is created 64.

Whether or not the change of plans affects the validity of the promise of component 44, the local compliance manager 22 generates a 60 change planning notice for the change and can also note any of the fault conditions that exist. The change of planning notification 60 is generated in an appropriate format and sent to the compliance server 16 using a network 20. The change of planning notification 60 can prompt the fulfillment server 16 to generate a revised promise 62 and send it to the client 12. Instead of this or in addition to this, the compliance server 16 can evaluate the planning change notification of 60 and generate one or more requests of available for promise of the revised component 66 which are sent to and processed in the administrators of local compliance 22 in essentially the same manner as for the available requests for promise of the changed component 32 described above. The compliance server 16 can act on the change of planning notification 60 in an appropriate manner according to the needs of the clients 12 and of the associated users and clients.

Process of Changes of Local Compliance Manager [Compliance Server] Compliance server 16 monitors and responds to events initiated by the local compliance manager such as component promise changes. The component promise changes within the planning engine associated with the server available for promise 14 may have essentially impacted the integrity of the original promise 46 Therefore, in an incorporation, the fulfillment server 1 reassesses the promise 46 according to the constraints specified in the available request for promises originates 30. For example, depending on the value of the attribute provides short associated with the request of available for promise 30, and compliance server 16 can adjust the promises of the online items of request proportionally and release the shortened endowments of other items on the request line. Failure to do this can leave products tied to the client even when the client will not finally accept those products. The compliance server 16 may treat one or more alternate providers before adjusting or failing the request d available for promise 30, or may simply generate a problem notification suitable for the client 12 or for an associated user to review and resolve.

Compliance server 16 may provide the ability to optionally re-evaluate the price of promise 46 in the case of a change initiated by the local compliance manager, possibly determining if any price calculations are necessary based on the nature of the change. For example, a change in the shipping date for the request for available for promise 30 may not require a re-setting of the price, while a change in the quantity may be that the promised price is invalidated. In addition to or in addition to this, the compliance server 16 can provide the ability to recalculate the delivery dates based on the changes initiated by the promise fulfillment manager, possibly determining if any delivery calculations are necessary based on the nature of the change. For example, a change in the amount for the request available for promise 3 may not require coordination of delivery while a change in the date of shipment may result in invalidity of the promised delivery.

When the compliance server 16 has evaluated any changed component promises 44 in relation to the constraints specified in the available par promising request 30, the fulfillment server 16 generates a revised promes 62 and sends it to the client 12. This processing and identical to promise confirmation processing, except that the original promise 46 already exists and the fulfillment server 16 can only update the parts of the promise 4 associated with the request changes available for promes when generating the revised promise 62. The notifications of fail can be generated as appropriate. In this phase, the client 12 or an associated user may wish to simply live with the changes, generating and sending the acceptance 64 to the fulfillment server 16, or proceeding to a workflow of re-citing, changing or canceling.

Work Request Cancellation Request for Promise Start Cancellation of Request for Availability for Promise [Client] In an embodiment, the client 12 or an associated user may be able to cancel a request for availability to promise at any point in its life cycle unless the provider's business restrictions explicitly exclude it, for example, outside of a specified time interval. As a result of this, the request available for promise 30 may be canceled during the initial generation, during the appointment processing, after acceptance, and even after partial compliance. The cancellation attempt is to make the request for availability permanently inactive. The client 12 or an associated user can question the request for availability to promise 30 to initiate this processing. Once the request for available for promise 30 has been displayed client 12 through the question, the user can select a cancellation function to cause the client to execute the cancellation command.

Cancellation Process of Request for Availability for Promise [Compliance Server] Compliance server 16 receives cancellation of request from client 12 in the form indicating that all items of the request line have been canceled. Compliance server 16 immediately determines if there are any product or supplier restrictions on the cancellation. If this is so, an immediately generated failure notification is sent to the client 12 using the r 18. "After the compliance server 16 determines the validity of the cancellation of the request, peste updates the status of each article online of request to be "canceled." The compliance server 16 then sends the resulting component request cancellations to network 2 for processing at the appropriate local compliance administrators 22.

Process of Request Cancellations of Available for Component Promes [Local Compliance Administrator] When the local compliance manager 2 receives the component request cancellations from the compliance server 16, it generates and executes the cancellation transaction in the appropriate syntax for the server d available for promise 14 and in the associated planning engine. It is more likely a suppression of the request for a promise. When the availability server for promise 14 replies to the local compliance manager 22 with a confirmation of the cancellation, the local compliance manager 22 updates the status of any request available for a locally held component promise, d component appointment and promise of component. The local compliance manager 22 generates a component cancellation confirmation and sends it to the 16 compliance server and the 20 network.

Component Confirmation Process [Compliance Server] When the compliance server 16 has processed and transmitted the component request cancellations to the local compliance administrators 22, it monitors that s complete the resulting component cancellation confirmations. In an addition, a cancellation confirmation is considered complete when each cancellation of the component request has received a confirmation of component cancellation. The fulfillment server 16 may notice the cancellation in any available par request 30, in appointment 36 and in promise 46 maintained in the fulfillment server 16. The final cancellation confirmation is generated and sent to client 12 using the network 18, ending the life cycle of the request for availability of promise.

Workflow of Compliance Confirmations Compliance Notification Process d Component [Local Compliance Administrator] In an incorporation, the system 10 provides an interconnection protocol between the local compliance administrators 22 and the servers available for promise 14 so that the notifications of sending in the associated planning engines are proactively identified in the servers available for promise 14 and the send to local compliance managers 22. Local compliance managers 22 can update the status of the available request for locally held component promise and the promise of component 44 to reflect compliance before sending a resulting component compliance notification to the compliance server 16 using a network 20.

Process Compliance Notifications [Compliance Server] Once the acceptance 50 has been properly processed, the compliance server 16 monitors in relation to the component compliance notifications of the local compliance managers 22. The request for availability for promise 30 is considered fulfilled when each available request for component 32 promise has received a component compliance notification. A unified compliance notification is generated and sent to the requesting client 12 using the network 18. When the available requests for the promise of component 32 have been satisfied, the compliance server 16 may also monitor the corresponding sending confirmations. When the request for availability for promise 30 has been completely sent, its status is updated and the compliance server 16 notifies the requesting client 12. The compliance server 16 can provide filing capabilities for requests for available for promise fulfilled 30, the which may be configurable to allow the client 12 to specify file parameters such as when the requests for availability for promise 30 are to be archived and the number of request history periods to be maintained. The files can be maintained in the compliance service 16, in one or more places associated with the local compliance administrators 22, or in any other place internal or external to the system 10.

Claims (76)

R E I V I N D I C A C I O N S

1. A system for automatically managing the data available for promise (ATP) that includes: a client interconnection; a server interconnection of available pair promise; Y an operable fulfillment server for receiving a first request of available for promise using the interconnection of the client, the first request of available par promise comprises a plurality of online articles of request each corresponding to desired products; generate one or more available par promises based on the request line items; communicating the available requests for a promise of component to at least one of the plurality of available servers for promise using the server interconnection of available for promise; receive a plurality of component quotations from the servers available for pledge using the server interconnection of available for pledge, each component cit corresponds to a request for available pledge of component and comprises information of product availability for one or more corresponding desired products; generate a certain appointment according to the product availability information provided by the component appointments; Y Communicate the appointment using the client's interconnection.

2. The compliance server as claimed in clause 1, characterized in that the request for available for promise specifies one or more business restrictions and the compliance server is also operable to evaluate the component appointments according to the business restrictions to generate the appointment.

3. The system as claimed in clause 2, characterized by at least some of the business restrictions are based on a customer profile.

4. The system as claimed in clause 1, characterized in that the compliance server is also operable to evaluate the component appointments according to the business restrictions specified by the supplier to generate the appointment.

5. The system as claimed in clause 1, characterized in that each available par promise server is associated with a local compliance manager (LFM) that manages the processing of available requests for component promise in an associated planning engine with the server available for promise.

6. The system as claimed in clause 1, characterized in that the compliance server receives the first available request for promise from a first client, and concurrently with the first request available for promise, receives a second request from available to promise of a second client.

7. The system as claimed in clause 1, characterized by the compliance server is further operable to communicate at least one available request for component promise to a server of available for objective promise based on one or more constraints of business within the request of available for promise.

8. The system as claimed in clause 1, characterized in that the compliance server is also operable to: receive an appointment confirmation that includes acceptances of at least some of the items online appointment within the appointment, using the customer interconnection, with one of the appointment line items corresponding to a particular accepted product; generate a component appointment conformation for each accepted appointment line item; communicate component appointment confirmations to the servers available for pledge using the server interconnection available for promise; receive a plurality of component promises from the servers available for promise using the server interconnection of available for promise, each corresponds to a conformation of component appointment and each represents a commitment of product availability for corresponding accepted products; generate commitments that include a promise of product availability for products accepted according to component promises; Y communicate the promise using the interconnection d client.

9. The system as claimed in clause 8, characterized in that the compliance server is also operable to evaluate the promises of component d according to the business restrictions outlined for the client when generating the promise.

10. The system as claimed in clause 8, characterized in that the compliance server is also operable to receive a promise acceptance using the client interconnection and to communicate the acceptance of promise to the available servers for promise for the fulfillment of the request of available for promise.

11. A compliance server for operation in a distributed supply chain planning environment, where: the compliance server is operable to receive at least one request for available to promise (ATP) from a client, the request for available for promise comprises a plurality of online items of request each corresponding to a desired product; the compliance server is operable to generate an available request for component promise for each online request article; Y the compliance server is operable to communicate the available requests for component promise to a plurality of local compliance managers (LFMs) for the appointment, each local compliance manager is associated with a planning engine.

12. The compliance server as claimed in clause 11, characterized in that the request for availability for promise specifies one or more business restrictions and the compliance server is further operable to generate the requests for available for component promise according to business restrictions.

13. The compliance server as claimed in clause 12, characterized in that at least some of the business restrictions are based on a customer profile.

14. The compliance server as claimed in clause 11, characterized in that it is operable to communicate at least one available request for a component promise to a local compliance manager based on one or more business restrictions within the request available for promise.

15. The compliance server as claimed in clause 11, further characterized because it is operable to: receive a plurality of component promises from local compliance managers, each corresponding to a request for availability to promise the component and representing a product availability commitment for the corresponding desired product; generate commitments that include promise of product availability for all desired products according to component promises; Y communicate the promise to the first customer.

16. The compliance server as claimed in clause 15, characterized in that it is also operable to evaluate the promises of the component according to the business restrictions outlined for a client in the generation of the promise.

17. A local compliance manager (LFM) that has a server available for associated promise (ATP) and operates in a distributed supply chain planning environment including other local compliance managers, comprising: a compliance server interconnection; a server interconnection available for prornesaj¬ where the local compliance manager is operable to receive one or more requests of available for component promise from a compliance server, each request of available for component promise corresponds to an online article of request of available for particular promise, the local compliance manager additionally operates to determine a response of available to promise for each request line item using the server available for associated promise and generate a component appointment for each request line item according to the response from available for corresponding promise, component appointments comprise product availability information for the corresponding desired products, the local compliance manager being operable to communicate component appointments to the compliance server for consolidation with other component appointments from one or more from other local compliance managers.

18. The local compliance manager ta and as claimed in clause 17, characterized in that the request for availability for component promise specifies one or more business restrictions and the local compliance manager is also operable to evaluate the response of available for promise of according to business restrictions to generate component citations.

19. The local compliance manager as claimed in clause 18, characterized by at least some of the business restrictions are based on a customer profile.

20. The local compliance manager as claimed in clause 17, characterized in that the local compliance manager is also operable to generate the component appointments according to the business restrictions specified by the provider.

21. The local compliance manager as claimed in clause 17, characterized in that the local compliance manager handles the processing of available requests for component promise in an associated planning engine, the local compliance manager being operable to compute A part of the answer is available to promise according to the information obtained from the available server to promise, the part depends on the capabilities of the server available for promise and its associated planning motorcycle.

22. The local compliance manager ta and as claimed in clause 17, characterized also because it is operable to: receive from the compliance server a component appointment confirmation for each component appointment accepted in a client as an online appointment item; determine a promise response for an online appointment item accepted using the server d available for associated promise; generate a component promise for each accepted online article, representing a commitment of product availability for the corresponding accepted product; Y communicate the component promises to the compliance service for consolidation with the component promises of one or more local compliance managers.

23. The local compliance manager as claimed in clause 22, further characterized in that it is operable to evaluate the promise responses according to the business constraints outlined for a client to generate the component promise.

24. The local compliance manager as claimed in clause 17, characterized in that the requests for available for promise correspond to individual articles and the local compliance managers are operable to compute the component appointments that include information and rules in relation to how the compliance server can change those component appointments.

25. The local compliance manager as claimed in clause 17, characterized in that the requests for availability for component promise correspond to the individual articles and the local compliance managers are operable to compute component promises that include information and rules regarding to how the compliance server can mutate those component promises.

26. The local compliance manager as claimed in clause 17, characterized in that the local compliance manager is also operable to receive a sequence of requests available for promise of component of the compliance server, one or more requests of available to promise component first in the target sequence to the local compliance manager; process the first available requests for a target component promise for the local compliance manager to compute one or more resulting component appointments; pass the resulting component citations, together with the available requests for remaining component promise in the sequence, to a second local compliance manager of objective for one or more requests of available for component promise in the sequence.

27. The local compliance manager as claimed in clause 17, characterized in that the local compliance manager is operable to support a vendor hierarchy also supported by the compliance server; support a subset of products supported by the compliance server; and compute component citations or component promises on a product base based on endowments through the vendor hierarchy for the subset of products.

28. The local compliance manager ta and as claimed in clause 17, characterized in that the local compliance manager is operable to support or sub-play of products in a hierarchy of related products supported by the compliance server; Y compute component quotations or component promises based on endowments of the subset of products through the hierarchy.

29. The local compliance manager as claimed in clause 28, characterized in that the local compliance manager is also operable to compute the availability of generic products by using the available requests for component promise to a second administrator of a product. local compliance corresponding to generic products.

30. The local compliance manager as claimed in clause 17, characterized in that the local compliance manager corresponds to a vendor within a vendor hierarchy supported by the compliance server and that is operable to: support supply provisions for the corresponding vendor; compute all component citations or possible component promises with the envelopes it contains; Y send component appointments or component promises to the compliance server for the combination, for each product as if the request for promes had been quoted or promised by a single system that has all the provisions.

31. The system as claimed in clause 30, characterized in that the local compliance manager is also operable to compute the availability of a corresponding parent vendor by sending the available requests for component promise to a second local compliance manager that corresponds to the parent seller.

32. The local compliance manager as claimed in clause 17, characterized in that the local compliance manager is operable to accept the availability requests for multiple compliance server component promise and communicate the component appointments the component promises to the multiple compliance servers.

33. The local compliance manager ta and as claimed in clause 17, characterized in that the local compliance manager is operable to support a hierarchy of products and compute component quotations or component promises based on product endowments in the hierarchy.

- 34. A system to automatically manage data available for promise (ATP) that includes: a client interconnection; a local compliance manager (LFM) interconnection; Y wherein the compliance server is operable to receive a first request of available for promise (ATP) using the client interconnection, the first available request for promise comprises a plurality of online articles of request each corresponding to a desired product, the compliance server is also operable to: generate one or more requests for available pair promise of component based on the items of line d request; communicate the requests for availability of a component promise to at least one of a plurality of local compliance managers using the local compliance manager interconnection; receive a plurality of component citations from local compliance managers through the local compliance manager interconnection, each component appointment corresponds to a request for component compliance availability and comprises product availability information for one or more products desired ones; generate a certain appointment according to the product availability information provided by the component appointments; Y Communicate the appointment using the client's interconnection.

35. The system as claimed in clause 34, characterized in that the compliance server computes the availability requests for component compliance for individual items and the component citations received from the local compliance administrators include information and rules regarding how the compliance server can mutate those component appointments, the compliance server is also operable to mutate the component appointments according to the information and rules so that the component appointments together satisfy one or more business restrictions.

36. The system as claimed in clause 34, characterized by the compliance server computes the availability requests for component promise for individual items and is operable to receive the component promises of the local compliance managers that include the information and the rules of how the compliance server can mutate those component promises, the compliance server is operable to mutate the component promises according to the information and the rules so that the component promises together satisfy one or more business restrictions , the compliance server is also operable to communicate the component promises mutated back to the local compliance managers so that they can adjust the supply reserves.

37. The system as claimed in clause 34, characterized in that the compliance server is operable to: compute the available requests for component promes that include all items supplied through the associated local compliance managers and all business restrictions on the request d available for promise that applies to the items of the available requests for component promise; to receive citations from each component of local compliance management that meet business restrictions; Y combine the resulting multiple item component citations to generate the quotation corresponding to the request available for promise.

38. The system as claimed in clause 34, characterized in that the compliance server is operable to compute the requests for available for component promise that include all the items supplied through the compliance manager for associated promise and all the constraints of business on the request of available for promise that apply to the articles of the requests of available for promise of component; receive from each component of local compliance manager promises that satisfy business restrictions; Y combine the resulting multi-component component promises to generate a unique promise that corresponds to the request of available for promise.

39. The system as claimed in clause 34, characterized in that: at least some of the local compliance managers retain separate endowments for the same product; Y The compliance server is also operable to distribute the appointment activity through multiple local compliance managers to obtain component appointments for the product.

40. The system as claimed in clause 34, characterized in that the compliance server is also operable as a local compliance manager.

41. A method for automatically managing data available to promise (ATP) comprising: receiving a first request for available par promise comprising a plurality of online articles each request corresponding to a desired product; generate one or more requests of available pair promise of component according to the items of line d request; communicating the availability requests for a component promise to at least a plurality of the available servers for promise using a server interconnection of available for promise; receive a plurality of component citations from the servers available for pledge using the server interconnection available for pledge, each component citation corresponds to a request available for pledge and comprises the availability of product information for one or more corresponding products desired generate an appointment according to the product availability information provided by the component appointments; Y Communicate the appointment.

42. The method as claimed in clause 41, further characterized in that it comprises evaluating the component citations according to one or more business restrictions to generate the appointment where the request for available to promise specifies all the business restrictions.

43. The method as claimed in clause 42, characterized in that at least some business restrictions are based on a customer profile.

44. The method as claimed in clause 41, further characterized by comprising evaluating the component citations according to at least one business restriction specified by the provider to generate the appointment.

45. The method as claimed in clause 41, characterized in that each server available for promise is associated with a local compliance manager (LFM) operable to handle the processing of an available request for component promise in a planning engine associated with the server available for promise.

46. The method as claimed in clause 41, further characterized in that it comprises receiving, concurrently with the first request available for pledge, a second request of available for pledge.

47. The method as claimed in clause 41, characterized in that at least one request d available for component promise is communicated to or local target compliance manager based on one or more business restrictions with the request for availability for promise.

48. The method as claimed in clause 41, further characterized by comprising: receive an appointment confirmation that includes acceptances of at least some online items within the appointment, each of the online appointment items corresponds to a particular accepted product; generate a component appointment confirmation for each accepted appointment line item; communicate the component appointment confirmations to the available servers for promise through the server interconnection of available for promise; receive a plurality of component promises from the servers available for pledge using the server interconnection of available for pledge, each corresponding to a component citation confirmation and each representing a product availability commitment for corresponding accepted products; generate commitments that include a promise of product availability for products accepted according to component promises; Y communicate the promise.

49. The method as claimed in clause 48, further characterized because it comprises the evaluation of the component promises according to the business restrictions outlined by a client when generating the promise.

50. The method as claimed in clause 48, further characterized by comprising: receive an acceptance of promise; Y communicate the acceptance of promise to the servers of available to promise for the fulfillment of the request of available for promise.

51. A method to manage data available for promise (ATP) in a compliance server within a distributed supply chain planning environment, where: receiving at least one request for availability for a promise from a client, the request for availability for a promise comprises a plurality of online articles each request corresponding to a desired product; generate one or more requests of available pair promise of component based on the articles-line of request; Y To communicate the available requests for component promise to a plurality of local compliance managers (LFMs) for appointment, each local compliance manager is associated with a planning engine.

52. The method as claimed in clause 51, further characterized in that it comprises: communicate at least one request of available for component promise to a local compliance manager of objective based on one or more business restrictions within the request of available for promise, the business restrictions being based on a client profile; and evaluate component citations according to the business restrictions to generate the appointment.

53. The method as claimed in clause 51, further characterized by comprising: receive a plurality of component promises from local compliance managers, each corresponding to a request for availability to promise a component and representing a commitment of product availability for the corresponding desired product; generate commitments that include a promise of product availability for the desired products according to the component promises; Y communicate the promise to the client.

54. A method to operate in a local compliance manager (LFM) to manage data available for promise (ATP), which comprises: to receive one or more requests for available for component promise from a compliance server, each request available for component promise corresponds to an online article of request available for promise for a desired product; compute an available response to promise for each online request article using a server available for promise; generate one or more component citations for each of the online request articles according to the response available for corresponding promise, the component citations comprise product availability information for the corresponding desired products; Y send component appointments to the compliance server for combination with other component appointments from one or more of the other local compliance managers.

55. The method as claimed in clause 54, further characterized by comprising evaluating the response of available to promise according to one or more business restrictions specified in the request * of available for promise to generate the component appointments.

56. The method as claimed in clause 55, characterized in that at least some of the business restrictions are based on a customer profile.

57. The method as claimed in clause 54, further characterized in that it comprises generating the component appointments according to business restrictions specified by the provider.

58. The method as claimed in clause 54, further characterized by comprising computing a part of the response available to promise according to the information obtained from the server available for associated promise, from the local compliance manager that handles the processing of the requests available for component promise in the associated planning engine, the part depends on the capabilities of the server available for promise and its associated planning engine.

59. The method as claimed in clause 54, further characterized in that it comprises: receiving from the compliance server, a component appointment confirmation for each component appointment accepted in a client as an appointment line item; determine a promise response for each accepted appointment line item using the available server for associated promise; generate a component promise for each of the accepted appointment line items, representing or commitment to product availability for the accepted products; Y send component promises to the compliance server for combination with the component promises of one or more local compliance managers.

60. The method as claimed in clause 59, further characterized because it comprises evaluating the promise responses according to the business constraints outlined by a client when generating the component promise.

61. The method as claimed in clause 54, characterized in that the requests of available for component promise correspond to the individual articles, and also includes the computing of component citations that include information and rules in relation to how the compliance server can Mutate component appointments.

62. The method as claimed in clause 54, characterized in that the requests for availability for component promise correspond to the individual articles and further comprises the computing of component promises that include information and rules in relation to how the compliance server can mutate the promises d component.

63. The method as claimed in clause 54, further characterized by comprising: receive a sequence of availability requests for component promise from the compliance server, one or more requests for availability of first component promise in the target sequence to the local compliance manager; process the first of the requests available for objective component promise for the local compliance administrator to compute one or more resulting component citations; pass the resulting component citations, together with one or more available requests for component promise remaining in the sequence to a second local compliance manager aiming at one or more requests d available for second component promise in the sequence.

64. The method as claimed in clause 54, further characterized in that it comprises: supporting a vendor hierarchy also supported by the compliance server; support a subset of products supported by the compliance server; Y compute component quotations or component promises on a product basis based on endowments through the vendor hierarchy for the subset of products.

65. The method as claimed in clause 54, further characterized in that it comprises: support a subset of products in a hierarchy of related products in a hierarchy of related products supported by the compliance server; Y compute component quotations or component promises based on endowments for the subset of products through the hierarchy.

66 The method as claimed in clause 54, further characterized in that it comprises computing the availability of a product's generics by sending one or more available requests for a component promise to a second local compliance manager corresponding to the products generic.

67. The method as claimed in clause 54, characterized in that the local compliance manager corresponds to a server within the server hierarchy supported by the fulfillment server and that also comprises: maintain supply provisions in the local compliance manager for the corresponding vendor; compute all component citations or possible component promises with the envelopes that the local compliance manager contains; Y send component appointments or component promises to the compliance server for the combination, for each product, as if the request of the available for promise had been quoted or promised by a single system that has all endowments.

68. The method as claimed in clause 67, further characterized in that it comprises computing the availability of a corresponding parent vendor by sending the requests for component promise available to a second local compliance manager corresponding to the parent vendor.

69. The method as claimed in clause 54, further characterized by comprising: accept requests for available component promes from multiple compliance servers; Y send component appointments or promises d component to the server and multiple compliance.

70. The method as claimed in clause 54, further characterized in that it comprises: support a subset of the product hierarchy in the local compliance manager; Y compute component citations or component promises in the local compliance manager based on the product endowments in the hierarchy.

71. A method for automatically managing the data available to promise (ATP) comprising: receiving the first request for available par promise comprising a plurality of requests for articles and line each corresponding to a desired product; generate one or more requests for availability of a component promise based on the request for articles and line; communicate the requests for availability of a component promise to at least one of a plurality of local compliance managers (LFMs); receiving a plurality of component citations from the local compliance managers each component appointment corresponds to a request available for a component promise and comprises the product availability information for one or more corresponding desired products; generate an appointment according to the product availability information provided by the component appointments; Y Communicate the appointment.

72. The method as claimed in clause 71, further characterized by comprising: computing requests for promes for individual items, component citations received by local compliance managers include information and rules regarding how to mutate appointments of component; Y mutate component citations according to the rules information so that component citations together satisfy one or more business constraints.

73. The method as claimed in clause 71, further characterized in that it comprises: compute the available requests for component pledges for individual items where the component promises received from local compliance managers include information and rules regarding how to mutate component promises; mutate the promises of components according to the information and rules so that the component promises together satisfy one or more business restrictions; Y communicate component promises mutated back to local compliance managers, so that they can adjust supply reservations.

74. The method as claimed in clause 71, further characterized by comprising: compute the available requests for component promes that include all items supplied through the associated local compliance managers and all business restrictions on the request available for pledge that apply to the items of the available requests for promise of component; receive from each of the local compliance administrators the component appointments that satisfy the business restrictions; Y combine the resulting multiple item component citations to generate the appointment corresponding to a request of available for promise.

75. The method as claimed in clause 71, further characterized by comprises: compute the available requests for component pledges that include all the items supplied through the associated local compliance managers and all business restrictions on the available pledge requests that apply to the articles of the pledge requests for pledge of component; receive from each of the local compliance administrators promises of component that comply with business restrictions; Y combine the resulting multiple item component promises to generate a unique promise that corresponds to the request for available for promise.

76. The method as claimed in clause 71, characterized in that at least some of the local compliance managers maintain separate provisions for the same product, and also comprises and distribute an appointment activity through multiple local compliance managers for Obtain component appointments for the product. E S U M E N A compliance server to manage the data available for promise in a distributed supply chain planning environment receives a request available for the promise of one from multiple clients. The request for availability for pledge includes multiple online request items each of which correspond to the desired product. The fulfillment server then generates one or more available requests for component promise based on the request line items and communicates the available requests for component promise to at least one of multiple local compliance managers. In response, the server Compliance receives component citations from the local compliance managers each corresponding to a request for availability of a component promise and each one including product availability information for the corresponding desired product. The compliance server generates an appointment that includes the product availability information for all the desired products according to the component appointments, communicates the appointment to the client.