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

Abstract

(57) [Summary] An execution server (16) for managing ATP data in a distributed supply chain planning environment receives an ATP request (30) from one of a plurality of clients (12). The ATP request (30) includes a plurality of request line-items. Each request line-item corresponds to one desired product. Thereafter, the execution server (16) creates one or more component ATP requests (32) based on the request line-item and communicates the component ATP requests (32) to at least one of the plurality of local execution managers (14). In response, the execution server (16) receives a component estimate (34) from the local execution manager (14). Each component quote corresponds to one component ATP request (32), each containing product validity information for the corresponding desired product. The execution server (16) creates an estimate (36) including product validity information for all desired products in accordance with the component estimate (34), and transmits the estimate (36) to the client (12).

Description

DETAILED DESCRIPTION OF THE INVENTION

TECHNICAL FIELD The present invention generally relates to supply chain planning (supply chain planning:
In the field of supply chain planning, and more particularly, to systems and methods for managing order execution in a distributed supply chain planning environment.

BACKGROUND OF THE INVENTION Large and complex supply chains are typically managed by multiple planning organizations. Each organization supports one or more planning engines that are appropriate for its needs. For example, one organization may have a supply chain planner (SC
P) engines, other organizations may support factory planner (FP) engines, and other organizations may support yet another type of planning engine.
As a result, demand and supply reconciliation, product allocation, order contracting and execution tasks are expected to be managed using various logically or geographically distributed planning engines. This presents a number of difficulties for customers and suppliers as well.

[0003] Lack of detailed perspective on extended supply chain operations,
Often, companies cannot estimate the exact delivery date and cannot meet customer orders. Even with a good view, a lack of coordination between front-end and back-end business objectives can lead to a critical market that runs out of capacity, lowers product margins, or provides worse service than less important market channels Channels come out and lead to other non-optimal commitments. Also, once the delivery date and other contracts are determined, it is necessary to monitor the contracts throughout the manufacturing and logistics execution processes to determine unexpected changes in supply and demand. Thus, a distributed supply chain planning environment requires a single, consistent interface to customers for order contract execution. Failure to provide such capabilities negatively impacts order acquisition rates, delivery performance, and management costs, order processing, and other activities associated with inventory.

[0004] Despite many attempts in recent years, none have successfully devised an effective solution for managing order fulfillment tasks across a network of computers in a distributed supply chain planning environment. Some companies have developed acceptable front-end or "customer-focused" solutions, while others have invested a great deal of energy in achieving suitable back-end supply chain optimization solutions. The successful integration of end and back-end solutions to intelligently manage order fulfillment tasks in this environment has not been successful. As a result, for example, companies routinely over-
With a mix of successes, they are losing money trying to execute the promises they have made. To compete effectively in a growing global Internet-based economy, companies must create, execute and execute their contracts accurately and consistently with their business objectives. Must be able to do it.

Further, in such multi-company efforts, it is often not economically or at least politically feasible to completely move the system during the supply chain. Thus, in order to deploy solution systems on a daily basis in most situations, the ability to adapt existing systems so that their capabilities can be expanded and more sophisticated alternatives can be subsequently introduced. Must have. The solution system can eventually co-exist commercially, with such existing or alternative systems. Conventional techniques for order contract and execution management cannot meet these needs.

SUMMARY OF THE INVENTION According to the present invention, inconveniences and problems associated with supply chain planning and order execution in a distributed network environment have been substantially reduced or eliminated. According to one embodiment of the present invention, a contract valid (available-to-
A system for managing available-to-promise data includes a client interface and an ATP server interface. The execution server is
A first ATP request is received using a client interface. The first ATP request includes a plurality of request line items (line-items), each corresponding to one desired product. The execution server generates one or more component ATP requests based on the request line-item and communicates the component ATP requests to at least one of the plurality of ATP servers using an ATP server interface. The execution server receives a plurality of component estimates from the ATP server using the ATP server interface. Each component quote corresponds to one component ATP request and includes product availability information for one or more corresponding desired products. The execution server generates an estimate determined according to the product validity information provided by the product estimate, and transmits the estimate via the client interface.

According to another embodiment of the present invention, a local execution manager (LFM) has an associated ATP server and functions within a distributed supply chain planning environment that includes other LFMs. LFM includes an execution server and an ATP server interface. The LFM receives one or more component ATP requests from the execution server. Each component ATP request is a special ATP for one desired product
Request line-corresponds to the item. The LFM determines each request line-item using the associated ATP server and generates a component quote for each request line-item according to the corresponding ATP response. The component quote includes product validity information for the corresponding desired product. LFM
Then communicates the component estimate to the execution server for integration with other component estimates from one or more other LFMs.

[0008] The present invention provides important technical advantages. The execution server and LFM of the present invention can simultaneously execute order contracts for complex multiple line-item ATP requests from a potentially large number of clients, according to specific users, customers, suppliers and other business constraints. And it can be managed intelligently. The advantages of the present invention become particularly apparent when the ATP servers are geographically distributed from one another and from execution servers, for example in the Internet. Further, if such ATP servers are at different common boundaries, the execution server establishes a basis for order contract execution capabilities. The present invention also provides clients with ATP product distribution, material availability, or capacity availability in ATP and related planning engines around the world, trusting and affecting ATP requests, quote confirmations, and contract acceptances. Provides a single interface. This provides the client with a highly desirable view of the extended supply chain operation.

The present invention minimizes the required transmission between the execution server and the LFM, maximizes bandwidth and minimizes latency. This allows interactive systems (eg, multiple-
Its use on Internet websites that provide online customers with immediate quotes for the delivery of items is supported, and other applications that would otherwise not be possible are supported. The present invention contemplates the implementation of smart and flexible computations within the execution server, LFM or, where appropriate, the ATP server, by devising the LFM interface to convey a rich response that can include many options at the same time, This is partially achieved. This matching LFM interface is provided while supporting various ATP servers.
It includes the adaptation of existing ATP servers and similar systems that were not originally designed to support the extended features, operations, and architecture achieved by the present invention.

[0010] Further, the system architecture of the present invention contemplates that different environments need to be varied when certain calculations occur to optimize performance appropriately for particular applications. For example, some applications may require systems with very high throughput, but can tolerate longer latencies, while other applications require very short hourly May be able to withstand lower throughput. On the other hand, some applications may need to support a very large number of products, while other applications may need to support a large network of suppliers for each product, and others The application may require a large merchant network. The present invention provides sufficient flexibility to support such diverse requirements. Other technical advantages will be readily apparent to one skilled in the art from the following figures, descriptions, and claims.

For a more complete understanding of the present invention, and other features and advantages of the present invention, the following description is provided in connection with the accompanying drawings.

DETAILED DESCRIPTION OF THE INVENTION FIG. 1 illustrates an exemplary system 10 for executing a deal in a distributed supply chain planning environment. The system 10 includes a suitable corporate resource plan (E
RP) one or more clients 12 representing a system and sales force automation (SFA)
Systems, order management systems (OMS) and other suitable systems. Each client 12 may be associated with one or more customers, users, or other entities. In particular embodiments, client 12 may include a sales and customer service oriented application that requires increasing or replacing existing order fulfillment capabilities. Client 12 is an application
It communicates with and interacts with the execution server 16 using a specific integration layer (not explicitly shown). The integration layer includes an application programming interface (API) running on the client 12, the execution server 16, or both the client 12 and the execution server 16, an object request broker (ORB).
), Or other suitable software interface. Network 18 connects client 12 to execution server 16. The network may be a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN), a global network such as the Internet, or any other suitable network or collection of networks.

[0013] The contract-valid (ATP) servers 14 each support or are coupled to a planning engine that can provide a product validity response to component ATP requests, particularly of the component quote type. . One or more planning engines coupled with the ATP server 13 may also provide pricing and other additional capabilities as appropriate. A local execution manager (LFM) 22 located on each ATP server 14 or otherwise connected to each ATP server 14 manages the interaction between the ATP server 14 and the execution server 16. In one embodiment, the LFM 22 is a "thin" engine whose primary responsibilities within the system 10 are: component request, component quote, component quote confirmation, component contract
This means that the information is transmitted from the ATP server to the TP server 14, and the state of the order execution can be monitored. The ATP server 14 provides services to the execution server 16 via an application-specific integration layer (not explicitly shown). This integration layer may include an API, ORB, or other suitable software interface running on the ATP server 14, the execution server 16, or both the ATP server 14 and the execution server 16. Execution server 16 is ATP server 14
May be a global network, such as a LAN, MAN, WAN, Internet, or any other suitable network, or a collection of networks integrated with or separate from network 18.

In one embodiment, each LFM 22 provides the same interface and functionality to the execution server 16, but may be designed to work with different ATP servers. Many of the ATP servers 14 may be older ATP systems, execution systems, or ERP systems that may be used to calculate component estimates, but more comprehensive distribution, such as the environment associated with the system 10. It is not designed to work with the execution server 16 in a network environment. Other ATP servers 14 may not even have the ability to provide ATP estimates; rather, they may simply store or support the information needed to calculate ATP estimates. it can. In still other cases, the ATP server 14 may be designed to work with the execution server 16, in which case an integrated LFM 22 that directly supports the LFM interface of the execution server 16 may be provided.

In each of these cases, the LFM 22 is responsible for accurately calculating the formed component quote or component contract, handling the resulting acceptance, and actually securing the corresponding material or capacity. The LFM 22 may have little translation of the information communicated between the LFM interface of the execution server 16 and the associated ATP server 14, but will have to translate it. In other situations, the ATP server is not designed to function as part of a larger system, in which case LFM 22 may need to perform substantial calculations or other operations on the information. The LFM 22 performs some of the ATP functions when interacting with systems that are not designed for ATP, or when interacting with slower systems that need to be avoided if system activity is possible. There may even be things you have to do. The present invention provides a variety of flexibility in LFM22 and makes translation easier to distribute.
(Different ATs that are computationally large and separated from more complex execution servers 16
P server variations).

Generally, client 12 submits an ATP request to an execution server. Each request includes one or more line-items belonging to a particular product, which may be ATP at one or more distributed ATP servers 14. The execution server 16 mediates component ATP requests corresponding to these line-items to the appropriate LFM 22 using the LFM interface and network 20. Each LFM 22 that receives a component ATP request now has an associated ATP
The server 14 is used to perform the necessary calculations and record the required reservations or changes. The LFM 22 sends the obtained component quote to the execution server 16 which appropriately operates the component quote and requests a unified general quote in response to the original corresponding ATP request to the client 12
To provide.

The client 12 may generate a quote confirmation that accepts the quote, in whole or in part, which the execution server 16 appropriately manipulates to provide the LFM.
22 is sent as a component estimate confirmation. Each confirmation corresponds to one special component ATP request. The LFM 22 cooperates with the associated ATP server 14 to consume the supply and generate a component contract for the contract between the customer and the supplier for the requested product. The execution server 16 uses the LF
Based on the component contract received from the M22 and the ATP server 14, a unified contract is provided to the client 12 according to the corresponding ATP. Client 12 may generate an acceptance that approves the contract, in whole or in part, and then sends the acceptance to the execution server. The execution server 16 sends a component acceptance to the LFM 22, and the LFM 22 responds to the execution server 16 with the component acceptance confirmation. Once the execution server 16 sends a unified acceptance confirmation to the client 12, the order contract execution cycle is completed based on the component acceptance confirmation received from the LFM 22. The operation of system 10 is fully described below.

The client 12, execution server 16, LFM 22, and ATP server 14 may each operate on one or more computers or other suitable processing devices at one or more locations. Each such computer may include an input device,
The input device may be a suitable keypad, touch screen, microphone, or other device that receives information. The output device conveys suitable information, including digital or analog data, visual information, and audio information. The input and output devices may support a suitable fixed or removable storage medium, such as a magnetic computer diskette, CD-ROM, or other medium that receives information from and provides information to a computer. In some cases, one or more processors and associated volatile or non-volatile storage execute instructions and manipulate information according to the operations of the associated client 12, ATP server 14, LFM 22, or execution server 16. Client 12, execution server 16, LFM
22 and ATP server 14 may be embodied, integrated with each other, or separated from each other in computer software, in computer hardware, or in an appropriate combination of software and hardware. . To support high availability or other performance requirements, system 10 may incorporate redundant clients 12, execution servers 16, LFMs 22, and ATP servers 14 according to special needs.

In one embodiment, for each of the LFMs 22 in the system 10, the execution server 16 determines the LFM name, suitable descriptive information for the LFM 22, an Internet Protocol (IP) or other network address for the LFM 22, LF
The identity of the designated backup LFM 22 if M22 fails, and other suitable information may be maintained. The execution server 16 performs sourcing (sour
Acing) ATP group and layer information may be maintained for the purpose. The ATP server group may, for example, model a supplier group, a pricing group, or a geographic location. Since the execution server 16 may operate according to group and supplier-based selections, as described in more detail below, it may be desirable to associate one or more suppliers with an applicable ATP server group. Absent. By way of example, if the client 12 or associated user specifies a preferred supplier, a preferred group, or both, then the execution server 16 may generate a component ATP request based on these selections and the supplier-group mapping. Assign to LFM22. The execution server 16 provides, for each ATP server group, a group name, descriptive information suitable for the group part, a list of parent groups and child groups for the group, a list of LFMs 22 in the group, and an active list associated with the group. A list of suppliers and other suitable information may be maintained. Sourcing choices may be defined at any level within the ATP server group hierarchy.

A product may represent anything that a user associated with client 12 may request, and may be tangible (eg, a computer) or intangible (eg, a service). . Products are associated with items, each of which can be associated with multiple products. This allows modeling different price points, lead times, suppliers, locations, or other suitable characteristics for the same item. Further, multiple items can be associated with the same product. This allows, for example, modeling of multiple suppliers of the same product. In one embodiment, the execution server 16 cancels the order for each product by product name, product description, default unit of measure (UOM), default lot size or sizes, client 12 or the associated user. The type of attribute for the product, such as a cancellation window, a customer-ranked, substitute-supplied, or other list, style, size and color of the substitute or substitute for that product, or other May maintain appropriate product information. The execution server 16 also maintains information about attributes, such as attribute type, description, value range, UOM, special attributes within one attribute, and other suitable attribute information, independent of any special product. You may.

The execution server 16 includes a sales channel (customer) and a parent between the sales channels.
Children or other hierarchical relationships may be maintained. Execution server 16 may use these for order contracts and other suitable purposes, as described in more detail below. In one embodiment, the rules for each sales channel maintained by the execution server 16 include (1) name, (2) description, (3) category, (4) parent, (
(6) a ranked or other list of groups that execution server 16 can use in determining product sourcing; (7) products that customers may have or order; (8) ) A ranked or other list of groups for a given product, (9) a ranked or other list of suppliers for each product, (10) a general, or given product, Or accepting substitutes, (11) a ranked or other list of substitutes or substitutes for each product, (12) the customer accepting alternative sourcing groups, generally or for a given product. (13) target or mandatory price limits or price ranges for each product; (14) general or Do you prefer only enough shipments, (15) generally, or for a given product, the customer prefers to cancel some of the unfulfilled requests rather than owning them as spares, (16) generally, Alternatively, for a given product, the customer selects only on-time shipment, so early or late contracts are rejected, or (17) a delivery window outside which late or early shipments are not allowed; The requested lot size or multiple for the product, the quote is rounded based on this value, and (19) request line-item shortage, logically related request line-item shortage in proportion To do so, including, but not limited to, what the customer generally prefers, and combinations thereof.

In general, distribution information may be maintained at any level of one sales channel or another, and may be as deep as necessary. The execution server 16 may process the request line-item via an alternative group or supplier if the original group or supplier cannot process the request. Within the preferred group, the supplier selection is fulfilled, if defined. The list of substitutes or substitutes should generally not be limited, so if an acceptable quote response is not obtained from the preferred supplier, the execution server 16 will be Product distribution or material or volume availability may be sought. For requests that do not explicitly dismiss the replacement or substitute and that do not identify a substitute that the customer prefers, the supplier may respond with a substitute or substitute of its own choice.

The execution server 16 may maintain information about suppliers and parent-child or other hierarchical relationships between suppliers, and the execution server 16 may, as described in more detail below,
It may be used for order contracts and other suitable purposes. In one embodiment, the provisions for suppliers maintained at the execution server 16 include (1) name,
(2) description, (3) category, (4) parent, (5) child, (6) product provided by the supplier (7) group related to the supplier, (8) ranking of the group for a given product Or other lists, (9) ranked or other lists of preferred customers for each product, (10) minimum and maximum quantities for orders,
(11) a constraint on the order quantity for which the execution server 16 cannot reduce the estimate without affecting the validity of the estimate; (12) a cancellation limit; and (13) a cancellation window outside which the order cannot be canceled. And suitable combinations thereof, but are not limited thereto.

The execution server 16 uses the business constraints described above. The execution server may pre-store this constraint, accept it in an ATP request from client 12, or both, specify the request line-item to a special LFM 22, or Component estimates and component contract responses from LFMs 22 that do not satisfy the constraints may be eliminated. For example, if the supplier provides multiple alternative responses, or responses from alternative groups, execution server 16 may reject non-compliant or unacceptable responses. If none of the options match, execution server 1
6 may reject all of the responses. The presence of a list of alternatives or alternative groups does not imply that they will be used. In one embodiment,
The client 12 or associated user may selectively ignore some or all of these business restrictions when generating ATP requests, quote confirmations, and contract acceptances according to special needs.

In one embodiment, the execution server 16 supports one or more seller tiers of products, and each LFM 22 supports the same seller tier, but the execution server 1
6 also has a subset of the products supported by it. The LFM 22 calculates a component quote or a component contract for the corresponding product based on the distribution among the seller hierarchies. These capabilities are described in Kenedy et al., Filed June 16, 1995, entitled "Systems and Methods for Managing Available-to-Promises." Entitled, co-pending U.S. patent application Ser. No. 08 / 491,167, and Kennedy.
y) et al., filed Feb. 18, 1997, entitled "Systems and Methods for Managing ATP," co-pending US patent application Ser. No. 08 / 802,434.
No. Both of which are cited and referenced herein.
Eventually, the system 10 assigns the product distribution to the LFM2 for one product by product basis.
2 provides the ability to distribute to the ATP server 14 associated with it. This allows space and time scalability in systems with many products.
) Are obtained.

The execution server 16 may support one or more layers of related or generic products, as described in US patent application Ser. No. 08 / 802,434. LFM 22 may support one or more subsets of the same tier and may calculate component estimates or component contracts based on their allocation to products within the sub-class. This provides further technical advantages in applications where the product is associated with a hierarchy.

The one or more execution servers 16 may cooperate, independently, or otherwise
It may work with the same set of FMs 22. Each such LFM 22 may receive a component ATP request and a component estimate confirmation from multiple execution servers 16 and may send a component estimate or component contract to multiple execution servers 16. This provides many technical advantages, such as the ability to scale systems that handle more clients or more ATP requests 30. In addition, this capability allows execution servers 16 to be distributed geographically or organizationally according to special needs.

Each execution server 16 may enforce different business constraints depending on the set of clients 12 that each execution server 16 supports. Each execution server 16 may operate with a different set of LFMs 22, where each LFM 22 is
6 may belong to one or more sets of LFMs. Each execution server 16 also has
It may support its own supply or distribution for the above products. This adds a number of technical advantages, including considerable flexibility in setting up a distributed ATP system with execution servers 16 tuned and optimized to support various clients 12. In addition, these options facilitate the configuration of local distribution of product supply at the execution server 16, reduce latency for requests for common products, and increase throughput.

Each execution server 16 may have the ability to operate as the LFM 22. In one embodiment, each execution server 16 is at least enough ATP server 14 to support a separate LFM 22. In either situation, the first execution server 1
6 and the corresponding LFM 22, and the associated ATP server 14, the second system 16 and the corresponding LFM 22,
Like the ATP server 14 in the second system including its associated ATP server 14, it is possible to form a hierarchy of LFMs 22. In this way, a hierarchy of the LFM 22 and the ATP server 14 having an appropriate width and depth can be formed according to special needs. The present invention contemplates a suitable relationship between one or more LFMs 22 and one or more execution servers 16.

[0030] Such a hierarchical organization facilitates many additional system designs and provides many additional technical advantages. For example, each LFM in such a hierarchy
22 may be assigned one or more products to handle, in which case the products are part of a related or comprehensive product hierarchy. In that case, the LFM 22
Component ATP request 32 is converted to a special LF for its comprehensive product
By sending it to M22, the effectiveness of the generic name of the assigned product may be calculated, which further provides for parallelization and scalability.

As also described in US patent application Ser. Nos. 08 / 491,167 and 08 / 802,434, execution server 16 may support a hierarchy of one or more sellers of products, Each LFM 22 may correspond to a special one of those sellers. LFM 22 may maintain a distribution of supplies to its associated sellers,
The allocation it contains may be used to calculate all component estimates and possible component contracts. The execution server 16 accepts these component quotes or component contracts, as if the ATP requests 30 were quoted and contracted by a single system with all of the distributions, and combines them for each product. As a result, the system 10 can distribute the product distribution to the LFM 22 and the associated ATP server 14 on one merchant on a merchant basis. This provides both spatial and temporal scalability in applications with many merchants, or flexibility in applications where the merchant organizations are geographically or economically separated. Each LFM 22 is
One or more component ATP requests 32 are sent to LFM2 corresponding to the parent seller.
2 may calculate the effectiveness for that parent seller. further,
Multiple LFMs 22 may maintain separate allocations for one particular product, and execution server 16 may distribute the estimation activity across LFMs 22 as needed to obtain a sufficient estimate. Good. These and other features of the system 10 provide advantageous parallelization, scalability, and throughput, as well as a distributed arrangement of merchant systems.

To achieve further scalability, further work decomposition can be performed. In one embodiment, the execution server 16 can operate with an LFM 22 each assigned one or more designated products or corresponding to one or more designated products. Each such LFM 22 in turn uses the ATP server 14, a second execution server 16 backed by a separate LFM 22, which is each allocated a portion of the overall supply allocation for the specified product. be able to. The second execution server 16 can be designed to communicate to its LFM 22, so that the amount of processing located on each of those LFMs 22 is minimized and balanced. Alternatively, the various LFMs 22 may be provided with different horizontal time slices to handle, and thus the component estimates 34 may be decomposed and implemented systematically. This increases latency and optimizes scalability with respect to size and throughput.

In one embodiment, the components of system 10 include a product associated A
When creating, managing, and executing a TP request, "Request-Contract-Accept (
A protocol called "Request-Promise-Accept (RPA)" is used. In general, according to the RPA protocol, a customer requests one or more products, and a supplier provides a contract that matches the request of the customer request as closely as possible. After reviewing the contract provided by the supplier, the customer accepts or rejects the contract. When a customer accepts a contract, the customer and the supplier generally believe that the acceptance has resulted in a binding arrangement. In certain circumstances, the customer does not have the option to revoke acceptance within a certain time due to this commitment. The RPA protocol is I2TEC
RHYTHM supply chain plan from HNOLOGIES, INC (SCP
Developed as a basis for managing demand and supply requests between autonomous planning domains in a distributed supply chain as part of an engine.

FIGS. 2 to 5 show the operation of the system 10 through a series of work flows. These and other described workflows represent interactive scenarios with full use of the enhanced PRA protocol according to the present invention. However, not all possible workflows are interactive, and not all are full uses of the enhanced RPA protocol. For example, but not limited to, large companies often use technology based on Electronic Data Interchange (EDI)
A large number of customer orders can be processed, in which case the ATP request is
In addition, there is an ATP-consumption contract with no interaction with the customer. Those skilled in the art will appreciate that system 10 provides EDI-based workflows and other suitable workflows, and that the present invention encompasses all such workflows and related operations. There will be.

ATP Request Workflow FIG. 2 illustrates an exemplary ATP request workflow. In this process, a plurality of line-item ATP requests 30 are generated by the client 12, and the client 12 submits the ATP requests 30 to the execution server 16, which executes one or more LFMs 22 in the form of the component ATP requests 32.
To the ATP request 30. These LFM22s have associated ATP
It processes the component ATP request 32 in cooperation with the server 14, generates a final component estimate 34, and sends the component estimate 34 to the execution server 14. The execution server 16 processes the component estimate 34 and generates a unified estimate 36, which is sent to the client 12 for review.

Initiating ATP Request [Client] In one embodiment, to initiate ATP request 30, client 12 or an associated user may be required to provide appropriate identification and warranty information. Good. Client 12 includes a user profile,
Default business rules or other constraints may be supported according to the customer profile or other suitable provisions. AT associated with the client 12 by the user
When the P request screen is accessed, the screen is provided with default parameters according to such rules. The user may then adjust some or all of these parameters as needed to create a special ATP request 3
0 needs are satisfied. Such parameters include shipping requirements, product sourcing choices, product substitutes or substitutes, shipping locations, price targets, and other suitable parameters. The user may select from a list of available products, according to product groups or organized in other suitable manners, using a product catalog, search engine, or other. Once the user has selected one or more products, the user can specify the desired amount, desired date, and additional parameters as described above. The user may also logically categorize the request line-item for the purpose of shipping. Client 12 uses ATP
When the request 30 is completely specified, the ATP request submission function is executed, and A
The TP request 30 is sent to the execution server 16.

The ATP request 30 includes a request object, a request line-item object, and a request line-item delivery object.
It may be configured in a level parent-child hierarchy, but any suitable data or message structure may be used within the intended scope of the present invention. For example, ATP
Other three-level structures for request 30 include request objects that include a list of one or more request delivery objects, each including one or more request line-item objects.

Request Attributes In one embodiment, the request object has the following attributes, otherwise it supports the following information, but the combination can be any, and It is not limited. (1) User ID-the user of the client 12 submitting the request; (2) Customer ID-used to determine the business constraints associated with the request; (3) Customer Request ID-
(4) Request ID-assigned by execution server 16 and used for subsequent processing and management activities; (5) Currency-profile shown (6) Sales Channel (Seller)-ATP server 14 provides an allocation function based on a multi-level channel hierarchy, and the seller consumes ATP. (7) Request rank-ATP such as the number of requests for multiple requests for the same product or other ranking, ATP such as allocation of undersupply considering supply issues. The server 14 has different runs of the request in the order planning process (8) Shipment-Shipment location for request; may be defaulted to each request line-Item; (9) Ignore customer constraints-User can execute server 16 Can be ignored, so the response from LFM 22 is unconstrained; (10) total price target-total price for user specified request, execution server 16 evaluates response from LFM 22 (11) Logic selected by default from acceptable alternatives / substitutes, profiled business constraints (yes) / No) parameter, which the user can selectively ignore and the execution server 16 requests this May be used in the process; (12
) Acceptable substitution location-a logical parameter that is defaulted from the profiled business constraints, which the user can selectively ignore and execute server 16
May use this in the processing of the request; (13) Ship Complete-a logical parameter that is defaulted from the profiled business constraints, which the user can selectively ignore and the execution server 16 A component estimate that may be used in the processing of a request and that lacks the request quantity attribute is rejected; (14) Part / Cancel-a logical parameter that defaults from the profiled business constraint, which the user can optionally select. Can be ignored,
The execution server 16 may use this in the processing of the request,
The non-executed part of the request) is deleted or carried over as order balance; (15) On time shipment-logical parameters defaulted from profiled business constraints, accepting early or late component contracts from LFM 22 is acceptable. Depending on whether it is possible, the user can selectively ignore this and the execution server 16 may use it in processing the request;
(16) Lack of Proportion-a logical parameter that is defaulted from the profiled business constraints, which the user can selectively ignore and the execution server 16 may use in processing the request, logically The contract in the associated request line-item is reduced (missing) in proportion to the other missing request line-item; (17) First date requested-first to execution server 16 for quote. (18) the last date requested-if any-the last submitted date request to the execution server 16 for re-estimation; (19) the estimated date-if any (20) the date of acceptance-if any, the client 12 has the last quoted data request Date have accepted the request; (21) rejected date - if any date client 12 has rejected the last complete request; (22
) Contracted date-the date, if any, at which the request was contracted; (23)
Revocation date-the date, if any, at which the request was last revoked; and (24
) Queued Date-The date, if any, at which the request was last queued.

Further, the execution server 16 sends the ATP request 30
It may support a request status field to be updated at predetermined milestones during the lifetime of the request. As such, (1) "failed request"-a request submitted for initial quote or re-quote, but one or more request lines-item does not satisfy the request; (2) "Pending Estimates"
-The request submitted for the initial quote or re-quote, but the resulting quote is still being processed; (3) "Failed quote"-the execution server 16 requests the profiled business (4) "Accept pending"-The execution server 16 has processed the quote and sent it to the client 12, but the client 12 is still responding; (5) "Unaccepted Acceptance"-A quote confirmation has not been received from client 112 by the date and time specified in the Accept attribute, so the quote is essentially invalid; (6)
"Rejected"-The execution server 16 processed the rejection and sent it to the LFM 22; (7)
"Pending Contract"-Execution server 16 has processed the quote confirmation and sent it to LRM 22 and is currently monitoring the component contract response from LFM 22; (8
) "Contracted"-the execution server 16 has accepted the component contract and sent the resulting contract to the client 12; (9) "Failed contract"-the execution server 16 still has the component contract from the LFM 22 Not received and sent non-performance notification to client 12; (10) "Cancel Reservation"-The execution server 16 processes the cancellation, sends it to the LFM 22, and monitors the acknowledgment from the LFM 22; (11) "Cancel"-The execution server 16 sends the necessary cancellation confirmation to the LFM2.
2 and received confirmation to client 12; (12) "Queue"
-Execution server 16 processes request queue commands and monitors requests for re-quotes, but is not limited to such.

Request Line-Item Attributes In one embodiment, a request line-item is an object that has the following attributes, or otherwise supports the following information: Their combination may be any, and is not particularly limited. (1) Request I
D: request line-link item to request; (2) request line-item ID-assigned by execution server 16; (3) shipping-request line-default shipping address for item, which is defaulted from request and user Can be selectively ignored and defaulted to request line-item delivery; (4) Accept-date and time the user must accept the quote; (5) Contract-Execution server 16 (6) Product ID-Request Line-Requested Product for Item; (7) Product UOM-Basic Unit of Measurement (UOM) for Requested Product; (8) Request Volume-Request The amount or range of quantity of the finished product, It must be equivalent to the combined delivery quantity if multiple request line-item deliveries are specified; (9) Request date-the product was required to arrive at the customer's destination Date or date range,
The user may ignore any request line-item delivery for that request line-item, if any; (10) category / attribute-category / attribute combination for requested product; (11) line- Item Grouping-combine multiple request lines-items as logical groupings for delivery coordination, which may represent an array, a tying package of products, a set of items that must be shipped together, or otherwise (12) line-item price target-request-request line-user specified target price for item, execution server may consider this when evaluating ATP server response. ,
If not, this may be indicated in the resulting quote; (13) Preferred product / supplier-defaulted from profiled business constraints, user can selectively ignore this and execute The server 16 uses this during request line-item sourcing; (14) acceptable substitutes / substitutes-defaulted from the profiled business constraints, the user can selectively ignore this; The execution server 16 may use this to process the request line-item; (15) the preferred alternative / substitute-default from the profiled business constraints, the user may selectively ignore this This allows you to choose a valid replacement or substitute for the requested product, Server 16 and the supplier can cooperate; (16)
Mandatory-request-line-whether the item is mandatory with respect to others in the grouping, so if the amount of mandatory items is insufficient, the estimate may fail; (17 ) Lot size / multiple-defaulted from basic product specification, user may selectively ignore this and execution server 16 may use this to process request line-item; Therefore, the ATP server response amount is rounded accordingly; (18) Shipment completed-
Defaulted from the profiled business constraints, the user may selectively ignore this and the execution server 16 may use this to process the request line-item; (19) Part / Cancel -Defaulted from the profiled business constraints, the user may selectively ignore this, and the execution server 16 may use this to process the request line-item, and thus execute completely If not, it may be deleted; (20) On time shipment-defaulted from profiled business constraints, user may selectively ignore this and execution server 16 processes request line-item May be used to reject late or early contracts; LFM response status-execution server 16 2, after monitoring the component ATP request, and when all component estimates are received, the execution server 16 may start the evaluation estimation; (22) LFM start event state-maintained by the execution server 16; So, if a planned event affects supply, LFM will notice this,
Notify the execution server 16, so that the execution server 16 reevaluates the status of the profiled business request or request and informs the user of the change in the request status; Updated at predetermined milestones in the life cycle of the item.

Request Line-Item Delivery Attributes In one embodiment, a request line-item delivery is an object that has the following attributes or otherwise supports the following information:
The combination may be any, and is not limited. (1) Request line-Item ID-Request line-Request delivery for item delivery-
Link to item; (2) request line-item delivery ID-assigned at execution server 16; (3) ship-to-request line-default ship-to address for item delivery, default from request line-item, user (4) Requested quantity-the quantity or range of quantities requested, must be the same as the line-item request quantity; (5) Request date-product is requested line-item Date or date range required to reach the customer ship-to location for delivery; (6) category / attribute-request-line-category / attribute combination for item delivery; For multiple request lines-item distribution If there is, it may be selectively ignore it.

Processing ATP Requests [Executing Server] Each line-item associated with an ATP request 30 may be executed from a logically or geographically separate ATP server 14. In this workflow,
The basic task of the execution server 16 is to decompose the ATP request 30 into individual request lines-items and convert the resulting component ATP requests 32
It mediates the distributed network of the ATP server 14 using the network 20 and the LFM 22, evaluates the component estimate 34 received from the LFM 22, and sends a unified estimate 36 to the client 12 using the network 18. Once multiple deliveries have been identified for a given request line-item, execution server 16 generates a separate component ATP request 32 for each delivery. Some or all of the component ATP requests 32 may be pre-sourced to a special LFM 22 according to customer business constraints or supplier-selection sourcing rules. Alternatively, the sourcing choice may not be specified, so that multiple LFMs 22 have an opportunity to provide an estimated response. In one embodiment, execution server 16 breaks down and encapsulates customers and other suitable business constraints into component ATP requests 32 before sending them to LFM 22.

For each product, the supplier may specify minimum and maximum order quantity requirements. 1
In one embodiment, once the parameters of such a request have been identified, execution server 16 first evaluates whether each request line-item satisfies such a request. If none of the request line-items match the particular request, a failure response is generated and sent over the network 18 to the requesting client 12. In this case, the execution server 16 sends the ATP request 3
The status of 0 or the failure component ATP request 32 is updated to “failure request”.

The execution server 16 may be designed to specify sourcing for each request line-item according to the supplier or location. Execution server 16 may then specifically direct component ATP request 32 to special LFM 22. Since the user may ignore the profiled default constraint, the execution server 16 first evaluates the request line-item and request line-item delivery details, and then checks for alternate supplier and location sourcing attributes, Determine if a replacement is acceptable for ATP request 30. If no replacement is allowed, the basic relationships specified in ATP request 30 will be respected. If other sourcing is allowed, the user, customer or other alternative sourcing choices will prevail. If no such sourcing selection is specified, execution server 16 may check for a supplier default selection. If the specified selection does not exist for the supplier, the component ATP request 32 may be considered “not specified” for the target LFM 22. In this case, a plurality of LFMs 22 may appropriately respond to the component ATP request.

The execution server 16 may attempt to define alternative or substitute selections for the ATP request 30. The execution server 16 may include the substitute product information in the component ATP request 32. The execution server 16 first evaluates the request line-item and request line-item delivery details, and then checks the ATP request 30 because the user may ignore the selectively profiled default constraint, Determine if a substitute or substitute is acceptable. If not allowed, the basic relationships specified in the ATP request 30 will be respected. If a substitute or substitute product is acceptable, the user, customer or other suitable substitute or substitute choice will prevail. If no such selection is specified, execution server 16 may perform a confirmation of the supplier default selection. If the specified selection does not exist for the supplier, the component ATP request 32 may be considered "unspecified" for the replacement and the substitute. In this case, LFM 22 may respond to a component ATP request having multiple product options.

The execution server 16 has a component ATP with embedded business constraints.
Request 32 is generated. The execution server 16 uses the request line-item and request line-item delivery details to specify the attributes of the component ATP request 32 because the user may ignore the default constraints profiled by the interaction. In one embodiment, the following constraints are defined. The combination may be any suitable and is not limited: request quantity, shipment completed, part / cancellation, on time shipment, acceptable substitutes / substitutes, preferred substitutes / substitutes, Lot size / multiple and consumption front / back boundary. Execution server 16 may also indicate that component ATP request 32 should be further restricted in some manner according to the profiled business constraints. Once the component ATP request 32 is generated, the execution server 16 sends the component ATP request 32 to one or more LFMs 22 for processing using the network 20. The execution server 16 may also update the state of the ATP request 30 or, if possible, the component ATP request 32 to "pending estimate".

In one embodiment, execution server 16 includes a series of components AT
Compute or otherwise generate a P request 32 and send it to one special LFM 22 associated with the first component ATP request 32 in the sequence. The target LFM 22 accepts the sequence and processes the component ATP request 32 specifically targeting it, and then passes the resulting component quote or component contract together with the remaining component ATP requests 32 in the sequence to the next. To the LFM 22 targeted by the component ATP request 32. Next, the LFM 22 accepts the sequence, processes the component ATP request 32 specifically targeting it, and translates the resulting component quote or component contract, along with the remaining component ATP requests 32 in the sequence, The next component ATP request 32 passes to the targeted LFM 22.
Each such LFM 22 may calculate its component quotes or component contracts, so that they may apply any suitable business constraints with respect to the component quotes or component contracts created by other previous LFMs 22 in the sequence. To be satisfied. Execution server 16 receives the resulting component quote or sequence of component contracts from the last such LFM 22 and generates a combined quote or contract corresponding to ATP request 20 from client 12.

Component ATP Request Attributes In one embodiment, the component ATP request 32 is an object that has some or all attributes of a request line-item and a request line-item delivery object. The execution server 16 embeds the business constraint in a component request related to the function of the LFM 22. The component request may have the following attributes, or otherwise support the following information: The combination may be any suitable one, and is not limited. (1) Component request ID
-Assigned at the execution server 16 when it generates a component request; (2) LFM ID-target LFM2 for component request
2. If the sourcing relationship is not specified or guided by the execution server, it may remain unspecified, in which case any LFM 22 is free to respond to the component request if it can satisfy the request; (3) Execution server ID-a network address or other identifier for execution server 16 that is valid in an environment with multiple execution servers 16; (4) sales channel (seller) for component requests; (5) for parent request. Request rank; (6) request line-item ID-component request is linked to request line-item; (7) request line-item delivery ID; (8) target LFM 22 with product ID-1 or higher and possible correspondence ATP1 to do May correspond to a known product ID in; (9) Product UOM-
One or more target LFMs 22 and possibly corresponding product UOMs used in the corresponding ATP server 14; (10) request volume; (11) request date; (12) category / attribute; (13) (14) partial / cancelled; (15) on-time shipment; (16) lot size / multiple; (17) acceptable substitute / substitute; (18) preferred substitute / substitute; 19) Consumption Forward / Backward Boundary-Defines the delivery window that the customer wants to acknowledge, thereby
The ATP server 14 may search for an effective amount and control how far forward or backward from the request date.

Further, the component request object may support a request status field that the execution server 16 updates at predetermined milestones in the life cycle of the component request, such as: However, it is not limited thereto. (1) "Pending Estimate"-the component request has been submitted for the first estimate or for re-estimate, but the resulting estimate has not been processed; (2) "Failure Estimate"-execution server 16 Determined that the component quote could not meet the request for the component request; (3) "pending quote confirmation"-the execution server 16 processed the quote and transmitted it to the client 12, but still Not Responding (4); “Unaccepted Confirmation” —Acknowledgment not received from client 12 by the date and time specified in the Accepted Attribute, so the quote is essentially meaningless and invalid (5) "Rejected"-execution server 16 processed the rejection and sent it to LFM 22; (6) Pending agreement "- execution server 16 processes the estimate confirmation, LFM it as a component confirmation
22 to monitor the contract response; (7) "Contract"-the execution server 16 has received the required component contract and sent the resulting contract to the client 12;
(8) "Failure contract"-The execution server 16 has not received the necessary component contract, and has sent the obtained failure notification to the client 12; (9) "Hold cancellation"-
The execution server 16 processes the cancellation, sends it to the LFM 22, and monitors the acknowledgment; (10) "cancel"-the execution server 16 receives the component cancellation confirmation from the LFM 22, and sends the cancellation confirmation to the client 12. Was.

Processing of Component ATP Request [LFM] The component ATP request 32 from the execution server 16
22 are accepted. As mentioned above, LFM 22 generally comprises A
During the life of the TP request 30, it is responsible for managing the component ATP requests 32 and for communicating between the execution server 16 and the associated ATP server 14.
In one embodiment, LFM 22 estimates the associated ATP 14;
Relating to contract, acceptance, shipping and archiving operations. If a particular sourcing choice exists, the component ATP request 32 may include this information, so that the LFM 22 may identify and process the component ATP request 32 accordingly. Without a particular sourcing choice, LFM 22 may identify the relevant component ATP request 32 based on the user, customer or product. In one particular ATP server location, the LFM 22 has a component AT
It accepts the P request 32 and generates a quote request to the ATP server 14 using command syntax appropriate for the particular associated planning engine. As part of this processing, the LFM 22 sends the component ATP request 32
Assess the business constraints contained within and act accordingly.

The planning engine may vary with respect to the requirements of this interface. For example,
The FP engine does not typically maintain ATP where the request transaction consumes the allocated product availability. Each component request is planned for an indication of finished goods inventory, available material or capacity, and other suitable factors that determine product effectiveness. From a shipping time adjustment and lot sizing perspective, there may be little correlation to control the output structure of the resulting estimated response. In this state, LFM 22 may submit the quote request as a planned transaction and evaluate the quote response according to the business constraints contained within component ATP request 32. If the response from the ATP server 14 does not satisfy these requests, the LFM 22 identifies this and sends a failure notification to the execution server 16.

For example, if the shipment completion attribute in the component ATP request 32 requires a complete match of the request and the estimate response from the ATP server 14 is less than the request amount attribute, the LFM 22 determines that the component estimate 34 Indicates failure and provides appropriate descriptive failure annotations. This state of the art rating may be important. This is because, depending on the planning engine, the ATP server response may be multidimensional (providing multiple options).
Providing a response assessment at the LFM level, rather than at the execution server level, causes failure conditions to be identified and summarized before the component quote 34 back to the execution server 16, thereby reducing the overall network load. .

As an example of a multidimensional ATP server response, consider a predetermined request line item (eg, 100 wheels on May 8). In response, 60 wheels were available for $ 22 on May 8 and / or 30 wheels for $ 16 on May 10 and / or 100 wheels for $ 16 on May 12. Let it be possible. These are multiple options for line-item quotes. System 10 may allow for the incorporation of rules and scope. For example, on May 10, 30 wheels, 5
Acquisition of the remaining 70 wheels on May 12 may be limited if the option for $ 16 on May 12 includes a conflicting amount limit.

As yet another example, consider a three line-item request (eg, on May 8, 100 wheels, 25 simple axles, 25 complex axles will be proportionately delivered). Individual line-item quotes can be calculated with multiple options, as described above, and combined in a suitable manner. For example, a simple axle is available on May 9 for 15 units and on May 11 for 25 units for $ 10. The complex axle will be available on May 8 for 10 units, May 10 for 25 units for $ 25. Ignoring the proportional business constraints included in the request, delivery of the product that fulfills the order will take place for several days, from May 8 to May 12, as appropriate. However, proportional business constraints mandate that line-items be delivered only in quantities proportional to how they are requested. This is because, for example, if the axle is not delivered, the delivered wheels are useless. From the above, the following exemplary multidimensional estimates are obtained.
This estimate includes multiple line-item estimates and is subject to exemplary proportional business constraints.

May 9-Wheels 40, axle 10 each for $ (22 ^* 40 + 10 ^* 10 + 25 ^* 10) May 10-Wheels 28, axle 7 each, May 16 for (16 ^* 28 + 10 ^* 7 + 25 ^* 7) $ 10 -Each wheel 60 and each axle 15 (16 ^* 30 + 22 ^* 30 + 10 ^* 15 +
For $ 25 ^* 15) May 11-Wheel 88, axle 22 each, (16 ^* 30 + 22 ^* 58 + 10 ^* 22 +
25 ^* 22) $ 12 May-100 wheels, 25 axles each, (16 ^* 100 + 10 ^* 25 + 25 ^* 2)
5) In dollars

In one embodiment, system 10 supports many different business constraints. Some of these business constraints may require one or more extra fields to be specified. To model this, the business constraint field can be an extended selector, as described in US Pat. Nos. 5,764,543 and 5,930,156. Both of these patents are cited and referenced herein. Additional extension fields may be activated when the corresponding extension value is inserted in the extension selector field. For example, but not by way of limitation, a maximum variability constraint may be specified on the ATP request 30 and additional fields may be added to the request model called max variance percentage. This allows the client 12 or the associated user to specify an acceptable amount of variation from the requested amount. The field may not be present and may not occupy memory space unless a maximum variation constraint is specified. The system 10 can provide such a model of scalability, or the ability to be used with respect to some or all of the business constraints described herein, and can have significant advantages over flat modeling techniques or other conventional modeling techniques. Flexibility and significant technical advantages are provided.

Within the system 10, various LFMs 22 can calculate various partial quotes or contracts, for example, that do not include supply availability details. When this occurs, the execution server 16 may be tasked with using the partial quote information to create a combined contract. Even worse, because the LFM 22 may be returned by a subordinate ATP server that cannot provide adequately rich ATP information, the execution server 16 handles various sophistication of component estimates or component contracts, and , May need to form the best quote or contract for ATP request 30 as a whole. To perform this task correctly, some business constraints may be required to guide the interpretation of the various component estimates or component contracts, or to change the various component estimates or component contracts appropriately.
Due to the extensibility in the model representing the LFM 22, different constraints can change the component quote or component contract being modeled. The present invention considers extensibility with respect to the suitable business constraints described herein.

When the ATP server 14 is associated with a SCP engine, as opposed to an FP engine state, there is usually a significant indication with respect to distribution and, for example, order timing and lot sizing constraints. As a result, the LFM 22 can communicate these restrictions from the component ATP request 32 to the ATP server 14. In particular, with respect to the SCP engine, LFM 22 may need to make a distinction between quote and contract workflow. This is because the first quote request to ATP server 14 may be only a query that does not consume the allocated product or the available material or capacity. The obtained estimated response is A
It is sent back from the TP server 14 to the LFM 22. However, in an EDI-based switch, a quote request to the ATP server 14 is actually
May be a TP-consumption contract.

The LFM 22 evaluates the estimated response from the ATP server 14 according to the business constraints contained in the initial component ATP request 32. The processing request for this evaluation depends on the advancement of the planning engine associated with the ATP server 14. With the SCP engine, this estimated response can include business constraints, thus limiting the processing reliability of the LFM 22. However, in the case of an FP engine, the LFM 22 may need to rigorously evaluate the quote response before the component quote 34 is generated. ATP server 14 may be able to return one or more quote responses. Each of them must be evaluated for applicable business constraints.

After evaluating the quote response from the ATP server 14, the LFM 22 calculates a component quote 34 that includes product validity information and determines how the execution server 16 can change the component quote 34. I do. LF
M22 sends the component estimate 34 back to the execution server 16. If the multiple quote responses are deemed valid according to the constraint, LFM 22 generates multiple component quotes 34 and sends them back to execution server 16. If the component ATP request 32 fails to obtain a valid component quote 34, the LFM can send an annotated failure notification to the execution server 16. Such a failure notification may include, for example, "insufficient product quantity" or "cannot meet shipping and lot sizing requirements." As described below, the execution server 16 changes the component estimate 34 according to the provided information and rules. Therefore, the components 34 are both executed server 1
Satisfy the business constraints applied at 6 or asserted with the ATP request 30.

Component Estimation Attributes In one embodiment, each component estimate is an object that has the following attributes or supports the following information: The combination may be any, and is not limited. (1) Component estimation ID-LF
Assigned when the component quote is created in M22; (2) component request ID; (3) execution server ID; (4) product ID-specified in the component request since the replacement or substitute has already been specified. (5) Since the product UOM-ATP server 14 is responding in a UOM different from the requested one, it does not need to correspond to the one specified in the component request. Good; (6) Contract quantity-quantity of product for component estimated delivery; (7) Contract date-date when product delivery was contracted by ATP server 14, this is the shipment from the manufacturing or distribution location rather than the customer delivery date. (8) Contract lot; (9) Contract attribute-component estimate List of combination of category / attributes for; (10
) Contract type-response type, updated by LFM 22 (eg, "as requested", "substitute / substitute", "option"); (11) unit price-ATP server 14
(12) Estimation status-updated by LFM 22, indicating whether the quote failed or succeeded; (13) Reason for failure-brief description of why the quote failed (e.g., LFM 22 evaluates, updates, and sends it to execution server 16.

Process of Component Estimation [Execution Server] Once the execution server 16 processes the component ATP request 32 and
When sent to the FM 22, the execution server 16 obtains the component ATP estimate 3
4 is monitored for completion. In one embodiment, when each component ATP request 32 receives at least one component quote 34 or failure notification, quote 36 may be considered complete. The supplier may respond to the component ATP request 32 with a number of acceptable ATP options. The execution server 16 uses these component quotes 34 to create a multi-dimensional (eg, variable with respect to product options, lead times and prices) quotes 36 and sends them to the client 12. Once the component quotes 34 have all been received and the quotes 36 have been completed, the execution server 16 evaluates the entire quote 36 according to the business constraints specified in the original ATP request 30. As a result, the execution server 16 determines whether the request for the ATP request 30 has been satisfied and removes the non-conforming supplier response from the unified quote 36 to be submitted to the client 12. In one embodiment, the execution server 16 changes the component estimates according to the information and rules provided, so that both the component estimates 34 are applied at the execution server 16 or the ATP request 3
Satisfy business constraints asserted with 0. Since some of the clients 12 cannot handle the multidimensional estimation 36, the execution server 1
The 6 client interface may also provide more restrictive use of quote information according to special needs.

In general, the execution server 16 follows the evaluation of the quote 36 for customer and supplier business constraints and attempts to provide a “best fit” response to the client 12. For example, the on-time shipping attribute for ATP request 30 specifies that shipping must be received on time, and one or more component quotes 3
4 is unsatisfactory in some respects, the execution server 16 sets the failure status as ATP
It may be assigned to the request 30. The execution server 16 may simply pass the failure status annotation received from the LFM 22 to the client 12. Alternatively or additionally, execution server 16 may assign its own failure evaluation annotation. For example, the LFM 22 may create a valid component quote 34, while the execution server 16 may determine the failure of the overall quote 36 based on quoted pricing decisions that do not meet business constraints for the customer. If a particular request line-item gives more than one component quote 34, each component quote 34 must be evaluated for the specified constraints. All valid component quotes 34 for the request line-item are communicated to client 12 in the form of quotes 36 using network 18.

If the ATP server response is satisfactory in one or more points (based on product, lead time, and / or price), execution server 16 creates a quote 36 to communicate to client 12. Before doing so, additional functions may be performed. For example, client 12 may request calculation of price, tax, fare, or delivery schedule. Depending on the implementation, this may be achieved using special routines, or may include the incorporation of one or more background planning processes that rely on, for example, a transportation and logistics planning package. Use of such a "back-up" process may be delayed as necessary until the client 12 confirms all or some of the quotes 36.

In one embodiment, execution server 16 provides a pricing engine component that operates according to customer needs. For example, if the execution server 16 is implemented with a packaged ERP system, the customer may prefer that pricing be managed within the ERP system boundaries. In one embodiment, when the execution server 16 manages pricing, each component quote 34 is priced first in a list, after which general discounts are pre-specified for line, request, or volume-level. Applied on a program basis. A plurality of discounts can be applied to a given ATP request 30. Pricing and discount programs may be specified according to customer, customer location, supplier, agreement, product group, product, or other suitable parameter or set of parameters.

The multi-dimensional response capabilities of the execution server 16 may provide special problems with the pricing function. That is, if more than one option is provided to a user for one particular request line-item, it may be difficult for execution server 16 to evaluate the order as a whole for discounting purposes. If there are multiple component quotes 34 for one particular component ATP request 32, the pricing for ATP request 30 cannot generally be expressed as a simple gross amount with a discount. Instead, the ATP request price will be in the range with minimum and maximum limits and will not be finalized until the ATP request option is confirmed. At that point, the pricing is recalculated and provided to the user upon contract confirmation.

The execution server 16 estimates 3 for the specified constraint of the ATP request 30.
6 has been completed and it is determined that estimate 36 meets these requirements,
The execution server 16 sends the estimate 36 to the client 12, and the examination and the estimate confirmation are performed. If the requesting client 12 is no longer active, the quote 36 may be saved until later queried. Estimate 36
Is modeled on the original ATP request 30 structure. However, estimate 36 may be more complex than ATP request 30 in some cases. Because it may include multiple responses to each request line-item and request line-item delivery.

Estimate Attributes In one embodiment, an estimate is an object that has the following attributes or supports the following information: The combination may be any, and is not limited. (1) Estimate ID-assigned by the execution server 16 and may be the same as the request ID; (2) request ID; (3) maximum total price (
(Base currency)-the maximum total price of the quote calculated by the execution server 16 in the base currency, representing the upper limit of the price estimate; (4) the minimum total price (base currency)-the estimate of the quote calculated by the execution server 16 in the base currency. (5) Maximum total price (customer currency)-the execution server 16 in the customer's preferred currency.
(6) Minimum total price (customer currency)-the minimum total price of the quote calculated by the execution server 16 in the currency preferred by the customer, the lower limit of the price estimate. (7) Estimation Status—Executing server 16 updates during the lifetime of the estimate (eg, “Failed Estimate”, “Pending Accepted”, “Accepted”, “Rejected”, “Accepted Not Accepted” (8) Accepted date-date and time, if any, of the quote confirmation processed; (9) Rejected date-if any, date and time the quote was rejected.

Estimate Line-Item Attributes In one embodiment, an estimate line-item is an object that has the following attributes or supports the following information: The combination may be any, and is not limited. (1) line-item ID-has multiple quote responses per request line-item, assigned by execution server 16; (2) quote ID-link quote to quote line-item; (3) product ID-source Request line-the product specified in the item may not correspond directly, as a substitute or substitute may be cited instead; (4) Product UOM-original May not correspond to the UOM specified in the request line-item of the ATP server 14 because the ATP server 14 may have responded with a UOM different from the requested one; (5) the proposed quantity -The quote line-the quantity associated with the item; (6) the proposed date-the date on which the quantity is available. The implementation may represent a shipping date or a harmonized customer delivery date provided by the ATP server 14; (7) Proposed lot-quote line-lot identifier for item; (8) proposed lot identifier Attribute-estimate line-list of category / attribute combinations for item; (9) quote type-response type (
Eg "as requested", "substitute / substitute", "optional");
(10) Proposed unit price (base currency)-quote line expressed in base currency of execution server 16-unit price associated with item; (11) proposed total price (base currency)-base currency of execution server 16 (12) Proposed unit price (customer currency)-quote line expressed in customer selected currency-unit price for item; (13) Proposed total price (Customer passing)-quote line expressed in customer selected currency-total price calculated for item; (14) quote line-item state-logical parameter, request updated by execution server 16 based on corresponding component quote state Line—Indicates whether the item succeeded or failed to obtain an acceptable quote; (15) Reason for failure— Brief Description of reasons for over; (16) estimates the line -
Item Accepted Status-Quote Line-Indicates whether the item has been accepted or rejected, and is used by execution server 16 to create a component quote confirmation transaction to LFM 22.

In one embodiment, the quote line-item delivery is an object that has the following attributes or supports the following information: The combination may be any, and is not limited. (1) Estimation line-item delivery ID-assigned by the execution server 16 and have multiple estimation responses for each request line-item delivery; (2) estimation line-item ID; (3) proposed quantity; (4) ) Proposed lot; (5) Proposed attributes.

Estimation Check Workflow FIG. 3 is a diagram illustrating an exemplary estimate confirmation workflow in which the client 12 estimates based on an estimate 36 and possibly input from the associated user. Create confirmation 40. The client 12 sends a quote confirmation 40 to the execution server 16 where it is decomposed and evaluated. The execution server 16 sends the obtained component estimate confirmation 42 to the LFM 22 using the network 20 and
The FM 22 cooperates with the associated ATP server to process the component quote confirmation 42, and the LFM 22 creates a component contract 44 accordingly. Thereafter, the LFM 22 sends the component contract 44 back to the execution server 16. The execution server 16 processes the component contract 44, creates a single unified contract 46,
The contract 46 is sent to the client 12 for review and confirmation.

Create Quote Confirmation [Client] Once the quote 36 has been accepted, the client 12 or associated user reviews and optionally accepts or rejects one or more quote line-items, or the entire quote 36. Is also good. Depending on the capabilities of the ATP server 14 and business constraints on the ATP request 30, one or more reasonable options may be enabled for any request line-item. The client 12 or associated user may then select from a number of options before accepting the quote 36 in whole or in part. Once this process is completed, the client 12 sends the quote confirmation 40, which includes all acceptances and rejections, to the execution server 16 for processing. It is the quote confirmation 40 rather than the quote 36 that forms the basis of the resulting contract 46 because the quote confirmation 40 can only accept a subset of the quote 36. Client 12 estimates 36
Considers that it is unacceptable, client 12 may queue ATP request 30 for later resubmission. Default constraints specify the duration and frequency of resubmitting (reestimating) requests according to special needs.

In one embodiment, estimate confirmation 40 is an object that has the following attributes or supports the following information: The combination may be any, and is not limited. (1) Estimate ID; (2) Estimate Line-Item ID; (3) Estimate Line-Item Status-Estimate Line-indicate whether the item has been accepted, rejected, canceled or queued; A component estimate confirmation 42 for use by the execution server 16 and submitted to the LFM 22 is created.

Estimation Confirmation Process [Execution Server] The estimate 36 is a statement in which product validity is not combined. Once the client 12 accepts the quote 36 in whole or in part, the execution server 16 determines the quote confirmation obtained in the distributed network of the LFM 22 in the form of a component quote confirmation 42 and at each appropriate ATP server location The allocated supply is consumed. In one embodiment, ATP requests 30 are distributed, immutable objects that are monitored and maintained at respective fill locations (LFMs 22). Thus, until the ATP request 30 is executed or canceled, the component ATP request 32 remains as part of the distributed order backlog intelligently managed by the execution server 16.

In one embodiment, execution server 16 may include a complete or partial acceptance, rejection, re-quotation, change, cancellation, inquiry and other appropriate user response from client 12 or an associated user. Various responses can be processed. Once the quote line-item has been accepted, it must be confirmed at the LFM 22. Because the LFM 22 generally has a corresponding component estimate 34
This is because the supply reservation is not made based on. However, the line-item has failed due to a shortage of reserved supplies, and execution server 16 will need to notify LFM 22 and may take any appropriate action. In one embodiment, execution server 16 may request LFM 22 to provide component contract 44 along with component quote 34, but the expected date of acceptance is relatively short. Execution server 16 may then accept component contract 44 upon receiving the quote confirmation from client 12. The execution server 16 has one special AT
The task is imposed using the P request 30 and the associated scheduled date of acceptance from the LFM 22 as appropriate. The resulting expected date of acceptance should generally give the execution server 16 time to calculate the quote 36 (or contract 46) and may preferably include some padding. Since most of the responses from LFM 22 may not reflect the date that the product is actually delivered to the customer, but instead may be a statement of the supplier shipping schedule, execution server 16 Ability to derive a customer delivery date for an item order
If possible, it may be provided as a post-processing step provided as necessary for the contract action.

As explained above, the quote confirmation 40 may be an object that decrements the status of each quote line-item, such as accepted, rejected, canceled or queued. Good. The execution server 16 indicates the status for the corresponding component quote 34, removes the acceptance from rejection on a line-item basis, and creates a component quote confirmation 42 for submission to the LFM 22. The execution server 16 updates the original component ATP request 32 to “holding contract”. In one embodiment, the component estimate confirmation 42 is an object having the following attributes or supporting the following information. The combination may be any, and is not limited. (2) LFMID; (3) Component Estimation Status—Indicates whether the component estimation has been accepted, rejected, or canceled.

Component Estimation Confirmation Process [LFM] The LFM 22 receives the component estimation confirmation 42 and creates a contract request to the ATP server 14 using a command syntax appropriate for the relevant planning engine. This transaction is similar to the original component request transaction, except that it requires a re-stock distribution or a firm commitment of valid material or capacity from the ATP server 14. The confirm transaction must also confirm the fill corresponding to the desired component quote 34, so that if the original component ATP request 32 receives more than one component quote, the LFM 22 allows the user to know at the client 12 You must confirm the specific quote response. At this point, the ATP server 14 responds with a firm contract and the appropriate allocated product or available material or capacity is consumed. In some cases, it may be appropriate to create an acceptance in this regard. The LFM 22 may delete the rejected component estimate 34 based on the reject command or other information received from the client 12.

The LFM 22 calculates a component contract 44 that includes information and rules on how the execution server 16 can change the component contract 44. When a contract response is received from the ATP server 14, the LFM 22 evaluates the response and verifies that it is consistent with the component estimate confirmation 42. This is because the contract response may be different from the original component quote 34. This may occur, for example, when a planned change has changed the product effectiveness at some point, or when other component estimate confirmations 42 have resulted in product allocations being consumed in the meantime. When this happens, LFM
Looks at this condition and evaluates whether the contract response still satisfies the business constraints specified in component ATP request 32. If so, the LFM 22 sends the component contract 4 according to the contract response from the ATP server 14.
Create 4. If multiple contract responses are considered valid according to the constraints, LF
M22 creates a plurality of component contracts 44 and sends them back to the execution server 16. If the component contract 44 differs from the original component quote 34 in some way, this may be indicated in the component contract 44. If the component contract 44 no longer conforms to the business constraints specified in the component ATP request 32, the LFM 22 may generate an annotated or other suitable failure notification to communicate to the execution server 16. Good. Exemplary annotations include "insufficient product volume" or "cannot meet shipping and lot sizing requirements."

In one embodiment, the component contract 44 is an object that has the following attributes or supports the following information: The combination may be any, and is not limited. (1) Component contract ID-LFM2
2 is assigned when creating the component contract and may be the same as the component quote ID; (2) execution server ID; (3) acceptance-acceptance must be accepted or corresponding contract reservation released. (4) Component Contract Status-Indicates whether the component contract was successful or failed; (5)
2.) Reason for failure-a brief description of the reason for the failed contract, if any.

Process of Component Contract [Execution Server] Once the execution server 16 processes the component estimate confirmation 42, the LF
When sent to M22, the completion of the resulting component contract 44 is monitored. In one embodiment, contract 46 is deemed completed when each of the original component quote confirmations received one or more component contracts 44 or failure notifications. Execution server 16 may also monitor contracts with attributes that specify the length of time that execution server 16 should wait for component contract 44 from LFM 22. When this constraint is reached before all component contracts 44 have been accepted, and thus the quote confirmation 40 has essentially ended, the execution server 16 may create an appropriate failure notification and send it to the client 12. In formulating the contract 46, the execution server 16 may consider any of the acceptance attributes for the component contract 44 and specify the acceptance attribute for the contract 46 accordingly.

In one embodiment, once the component contract 44 expires, the execution server 16 and the appropriate LFM 22 release a subscription for supply. Execution server 16
Provides a more precise date of acceptance than LFM 22, execution server 16 may need to send an indication of release to LFM 22. Similarly, if the contract 46 fails or is rejected, the execution server 16 notifies the LFM 22 and
22 can release a suitable supply reservation.

The execution server 16 receives the component contract 44 from the LFM 22 and
Is completed, the execution server 16 evaluates all contracts 44 according to the business constraints specified in the original ATP request 30 and again evaluates the success of all responses. This is done again during the contract creation phase. This is because one or more component contracts 44 may be different from the original component quote 34. If any component contract differs from the original component quote 34, the pricing may need to be recalculated during the contract creation phase. Further, if there are multiple component quotes 34 for one particular component ATP request 32, it may be necessary to calculate a confirmed final price. In one embodiment, all component contracts 44 must be reasonable to reach a successful contract 46.

In one embodiment, the execution server 16 may change or otherwise process the component contract 44 according to the information and rules provided, so that both the component contracts 44 Applied in or ATP
Satisfy the business constraints asserted with request 30. In addition to sending the contract 44 to the client 12, the execution server 16 may send the changed component contract 44 back to the original LFM 22, so that the LFM 22 can adjust its supply reservation appropriately.

The execution server 16 assigns a failure status to the contract 46 if the total response no longer satisfies the request of the ATP request 30 due to a change in product validity in the interval between the quote 36 and the contract 46 or for other reasons. The explanatory information may be annotated before sending the contract 46 to the client 12. Execution server 16 may simply communicate the failure status received from LFM 22. Alternatively or additionally, the execution server 16 may assign its own annotation. For example, LFM 22 may have created an acceptable component contract 44,
Execution server 16 may determine that contract 46 as a whole fails based on contract pricing not meeting specified business constraints for the customer.

The execution server 16 may include a delivery coordination engine component, depending on customer requirements. Without this capability, execution server 16 would return the optimal shipping date from an individual manufacturing or dispensing location rather than returning the delivery date to the customer. May be achieved using a relatively simple table navigation technique. More successful implementations may include the use of advanced planning engines for transportation and logistic optimization. In this scenario, it appears that the delivery adjustment may be calculated in multiple phases. For example, the standard lead-time approach based on tables,
It may be used in the initial contract creation phase to derive a provisional delivery date. When considering multiple delivery requests, a second phase of batch-oriented processing may be desirable to evaluate the overall backlog of requests, as transportation plan optimization is generally the most effective. As a result of such second phase processing, individual ATP requests 30
May be adjusted to reflect the optimized total delivery plan.

When the execution server 16 completes the evaluation of the contract 46, properly calculates the pricing and delivery, and considers that the pre-response is still satisfactory, the execution server 16 determines that the contract 46 (all valid (Including the component contract 44) to the client 12 for confirmation. The structure of the contract 46 models the structure of the original quote 36, but may be simpler than the corresponding part of the quote. Because the estimate 36 may be multidimensional, the contract 46 is discrete. If the requesting client 12 is no longer active, the contract 46 can be queried at a later point.

Contract Attributes In one embodiment, contract 44 is an object that has the following attributes or supports the following information: The combination may be any, and is not limited. (1) Contract ID-assigned at the execution server 16 and may be the same as the quote ID; (2) Total price (base currency)-total price of the contract calculated at the execution server 16 in base currency; (3 ) Total Price (Customer Pass)-Total price of the contract calculated in the execution server 16 in the currency selected by the customer; (4) Total Tax (
(Base currency)-the total tax associated with the request calculated at the execution server 16 in the base currency; (5) total tax (customer currency)-the total tax associated with the request calculated at the execution server 16 in the currency selected by the customer. (6) Confirmed date-date and time the contract was processed; (7) Scheduled acceptance-may indicate the expiration date of the contract, by which date the acceptance must arrive, or some Alternatively, all relevant contract appointments must be released; (8) date canceled-date and time, if any, contract was canceled; (8) ship date-if any, the contract is executed. Date and time.

Contract Line-Item Attributes In one embodiment, a contract line-item is an object that has the following attributes or supports the following information: The combination may be any, and is not limited. (1) Contract line-item ID-Estimated line item ID assigned by execution server 16 may be the same as the item ID;
2) Product ID for contracted product; (3) Product UO for contracted product
M; (4) Contracted line-contracted quantity for item; (5) Contracted shipping date-date the contracted quantity is available to ship, representing the shipping date provided by ATP server 14; 6) Customer Delivery Date-the date the contracted quantity reaches the designated customer ship-to location, which may be calculated and updated using the transportation plan and logistic engine; (7) contracted lot; (8) Contracted attributes; (
9) Contract Type-Contract Line-Type of response to item (eg, "as requested", "Substitute / Substitute", "Option"); (10) Contracted Unit Price (Base Currency)-Execution Server Unit price in base currency; (11) Contracted total price (base currency)-total price calculated in execution server base currency; (12) Contracted unit price (customer currency)-unit price in currency selected by customer (13) Total price contracted (customer currency)-total price calculated in the currency selected by the customer; (14) contract line-item status-request line, which the execution server 16 updates according to the corresponding component contract status. -Indicate whether the item succeeded or failed to obtain an acceptable contract response; (15) Scheduled Acceptance-Contract Line-Indicate Expiration Date for Item Good it must reach the acceptance to date, or related contract reservation might be released; (16) failure reason; (17
) Ship Date / Time; (17) Date Canceled. In one embodiment, a contract line item delivery is an object that has the following attributes or supports the following information: The combination may be any, and is not limited. (1) Contract line-item delivery ID-assigned by execution server 16 and possibly quote line-item delivery ID
(2) Contracted quantity; (3) Contracted shipping date; (4) Customer delivery date; (4) Contracted lot; (6) Contracted attribute.

Contract Acceptance Workflow FIG. 4 illustrates an exemplary contract acceptance workflow in which the client 12 accepts the contract 46 and possibly accepts 5 according to input from the associated user.
Create 0. The client 12 sends an acceptance 50 to the execution server 16 where it is decomposed and evaluated. The execution server 16 then executes the obtained component acceptance 52
To the LFM 22 using the network 20, and the LFM 22
4 processes the component acceptance 52 and the LFM 22 creates a component acceptance confirmation 54 as appropriate. The LFM 22 sends a component acknowledgment 54 back to the execution server 16 where it is processed and a final acknowledgment 56 is sent to the client 12 using the network 18 to complete the cycle.

Although this workflow describes an interactive contract acceptance scenario, the present invention typically contemplates non-interactive acceptance processes such as those associated with EDI-based workflows. In some cases, it may be appropriate to perform a parallel process of confirming the quote and accepting the contract. However, product effectiveness is estimated 40 and accepted 5
Since there is a possibility of changing in the interval between 0, it is appropriate to make the interactive processing of estimation confirmation and contract acceptance separate. In this case, the user can reject the contract 46, if necessary, if the contract 46 no longer reflects the quote 36.
This type of scenario may be specific to an ATP server environment based on SCP. Those skilled in the art will recognize that system 10 has an EDI-based workflow and other suitable workflows, and that the present invention includes all such workflows.

Acceptance Creation [Client] Once the client 12 or an associated user has evaluated the contract 46 received from the execution server 16, the client 12 or user may accept the contract 46 in whole or in part. The client 12 creates a formal acknowledgment 50 corresponding to the original ATP request 30 and sends it to the execution server 16 for processing.

Acceptance Attributes In one embodiment, acceptance 50 is an object that has the following attributes or supports the following information: The combination may be any, and is not limited. (1) Accepted ID-assigned by the execution server 16 and may be the same as the quote ID and contract ID; (2) total price (base currency); (3) total price (
(4) gross tax (base currency); (5) gross tax (customer currency); (6) date of acceptance-date and time when acceptance was processed; (7) date of cancellation-if any. (8) Ship Date-the date and time when the acceptance was performed.

In one embodiment, an acceptance line-item is an object that has the following attributes or supports the following information: The combination may be any, and is not limited. (1) acceptance line-item ID-assigned by the execution server 16 and may be the same as the quote line-item ID and contract line-item ID; (2) product ID; (3) product UOM; (4) acceptance line-
(5) contracted shipping date; (6) customer delivery date;
(7) accepted lot-accepted line-identifier associated with item; (8) accepted attribute-accepted other house-list of category / attribute combinations associated with item;
(9) Accepted Type-Accepted Line-Type of Response for Item (eg, "as requested", "Substitute / Substitute", "Option"); (10) Accepted Unit Price (Base Currency)-Execution Acceptance line in server base currency-unit price for the item,
Probably calculated in the contract phase; (11) Total price accepted (base currency)
-Accept line, expressed in the execution server base currency-Calculated total price for the item, possibly calculated in the contract phase; (12) Accepted unit price (customer currency)-expressed in the currency selected by the customer Acceptance line-Unit price for item, possibly calculated in contract phase; (13) Total price accepted (customer currency)-Acceptance line expressed in customer selected currency-Total price calculated for item,
Probably calculated in the contract phase; (14) Acceptance line-item status-a logical parameter that the execution server 16 updates based on the corresponding component contract status, request line-whether the item succeeded in obtaining proper acceptance or (15) Reason for failure-a brief description of the reason for the failed acceptance, if any; (16) Ship date-if any, acceptance line-date and time the item was shipped; (18) ) Date Canceled-Accept Line, if any-Date and time the item was canceled.

In one embodiment, the acceptance line-item delivery is an object that has the following attributes or supports the following information: The combination may be any, and is not limited. (1) Accepted line-Item delivery ID-Assigned by execution server 16 and may be the same as estimated delivery line-Item ID; (2) Accepted line-Accepted quantity for item delivery; (3) Contracted (4) Customer delivery date; (5) Contracted lot-acceptance line-Lot identifier associated with item delivery; (6) Contracted attribute-acceptance line-Category / attribute combination for item delivery. List.

Processing Acceptance [Execution Server] In one embodiment, the acceptance 50 is accepted, rejected, revoked,
Or an object that specifies the status of each of the contract line-items, such as being queued. The execution server 16 indicates the status for the corresponding component contract 44, removes the acceptance from rejection on a line-item basis, creates a component acceptance 52, and submits it to the LFM 22. Execution server 16 may also update component ATP request 32 as appropriate.

Processing of Component Acceptance [LFM] Upon receiving the component acceptance from the execution server 16, the LFM 22 creates and executes an acceptance transaction with a syntax appropriate for the planning engine associated with the ATP server 14. This transaction is the same as the original component quote confirmation 42, except that it creates a formal acceptance for an existing contract 46. The LFM 22 records an acknowledgment from the ATP 14 and sends a corresponding component acceptance acknowledgment 54 back to the execution server 16 using the network 18.

Processing of Component Acceptance Confirmation [Execution Server] Once the execution server 16 processes the component acceptance 52 and sends it to the LFM 22, the completion of the obtained component acceptance confirmation 54 is monitored. In one embodiment, acknowledgment 56 is considered completed when each of component acknowledgments 52 has received one or more component acknowledgments 54. When the execution server 16 receives all the component acceptance confirmations 54 and the acceptance confirmation 56 is completed, the execution server 1
6 sends a final acknowledgment including all valid component acknowledgments 54 to client 12 using network 18.

Workflow for Changing ATP Request In this workflow, the client 12 searches for an active ATP request 30, changes some or all of the ATP request 30, and sends the ATP request 30 to the execution server 16. Resubmit. Execution server 16
Then mediates the modified ATP request 30 throughout the LFM 22 distributed network and manages non-conforming responses. For example, the client 12 has an AT
The order may be re-quoted, in whole or in part, in an attempt to improve the contract volume or delivery date associated with the P-request 30. The client 12 may also search for an active ATP request and then cancel the ATP request 30. In this case, the execution server 16 sends this cancellation to the ATP request 3
0 must be transmitted to each of the LFMs 22 that handle a part of the zero. In one embodiment, the revocation effectively removes the ATP request 30 at each location where data persists, including the appropriate LFM 22 and execution server 16.

Initiating ATP Request Change [Client] Once the ATP request 30 has been displayed on the client 12 by a query, the user can enter the “edit request” mode. In this mode, the user can make any suitable changes to the request, e.g., add or remove request line-items, change the amount and date of the request, or adjust the associated business constraints. . The client 12 or user then resubmits the modified ATP request 30 or queues the modified request 30 for future resubmission. In one embodiment, once the ATP request 30 has been fully executed, no changes may be made. When the ATP request 30 is partially executed, only the request line-item still pending can be changed.

Processing ATP Request Change [Execution Server] The execution server 16 evaluates the resubmitted ATP request 30 and checks any part of the request structure (eg, request, request line-item, or request line-item delivery). ) To determine if any changes were made. A
For the changed part of the TP request 30, the execution server 16 modifies the existing component ATP request 32 accordingly. This may include any sourcing, substitutes or substitutes, or other choices, and reevaluation of identified business constraints. Modifications may also include the use of individual request line-items. Once the execution server 16 completes these modifications, the resulting component ATP request 32 is sent out again on the network 20 for processing by the LFM 22. Each component ATP request 32
May be appropriately set to “pending quote” or “pending cancel”.

Processing of Component ATP Request [LFM] The LFM 22 executes the changed component ATP request 32 on the execution server 1
Upon receipt from 6, the LFM 22 creates and executes a request transaction with the appropriate syntax for the planning engine associated with the ATP server 14. At this point, the changed component ATP request 32 is processed by the ATP server 14 as if it were a new component ATP request 32. Any component ATP request cancellation may be treated as a deletion for the ATP server 14.

The LFM 22 evaluates the response from the ATP server 14 according to the business constraints specified in the changed component ATP request 32. The processing request for the LFM 22 at this stage may be the same as that for the new component ATP request 32. Upon revocation, LFM 22 may update the status of locally maintained component ATP request 32 or component quote as "cancelled". LFM 22 receives the component quote response from ATP server 14 and sends a constraint-compliance response to execution server 16 in the form of a new component quote 34. Explanatory or other failure notifications may be generated in the manner described above. If necessary, a cancellation confirmation is also created and sent to the execution server 16.

Processing of Component Estimation [Execution Server] When the execution server 16 processes the changed component ATP request 32 and sends it to the LFM, the execution server 16 monitors completion of the obtained component estimation. In one embodiment, quote 36 is considered complete when each of the original modified component ATP requests 30 receives one or more component quotes, failure notifications, or cancellation confirmations, as appropriate. The execution server 16 may update the statuses of the ATP request 30 and the estimate 36 maintained by the execution server 16 based on any cancellation confirmation received from the LFM 22.

Once the component quote 34 has been accepted and the quote 36 is deemed complete, the execution server 16 re-evaluates the entire quote 36 according to the business constraints specified in the original modified ATP request 30. Processing is a new A
This is the same as the processing of the estimation 36 for the TP request 30. The quoted pricing may be recalculated from the beginning or otherwise using the newly quoted item taking into account the confirmed price. ATP in which the execution server 16 is specified
Evaluating the quote 36 with respect to the request constraints provides a unified quote 36 to the client 12. This process is the same as the process for the new quote 36, except that the original quote 36 already exists and therefore the execution server 16 updates only a portion of the quote associated with the changed ATP request 30. It is. A failure notification and revocation confirmation may be appropriately created and sent to the client 12. Subsequent user confirmation processing may be accomplished on a net change basis, and may reflect the processing described above for the work flow of estimating confirmation and accepting a contract.

Re-Quote Workflow In one embodiment, the client 12 or the associated user may request that all or partial cancellation or execution of the order at any point prior to the execution of the existing AT.
The P request 30 can be re-estimated. This capability does not affect any existing contracts 46, only a new quote. Client 12 or the associated user must accept the new quote and obviate the need for an existing contract 46. In this way, all processing except for the handling of data objects
Substantially the same as for the first ATP request 30. The client 12 or associated user queries the original ATP request 30,
This process is started. Once the ATP request 30 is displayed by the inquiry, the user then selects an appropriate re-estimate function and the client 12
Executes the re-estimate command. Workflow for queuing ATP requests

Execution server 16 may support intelligent queuing of requests. This can be set according to information received from users, customers, other profiles, clients 12 or related users, or information received from a system administrator or function. The request queue parameters may specify the conditions under which queuing occurs, the duration of queuing, and how often the request is resubmitted. Such changes should be sent to one or more execution servers 16 since requests queued due to changes through the distributed LFM 22 and ATP server 14 may get a satisfactory contract. Each execution server 16 can reconsider its queued requests in terms of changes, and possibly begin a contract workflow with a reasonable estimate. The queuing of ATP requests 30 is described in more detail in US patent applications Ser. Nos. 08 / 491,167 and 08 / 802,434.

Initiating ATP Request Queue [Client] In one embodiment, the client 12 or associated user may have an existing ATP at any point prior to cancellation or execution of the entire or partial order.
Request 30 may be queued. Queued ATP requests 30 are submitted periodically to re-estimate to improve the estimation results. As with the re-quote transaction described above, the queuing process does not affect existing contracts 46, but merely results in a new quote 36. The client 12 or associated user may perform the queuing function and initiate queuing after an unsatisfactory result of the first ATP request, or after interrogating an existing ATP request 30. The queuing behavior may be limited by specified parameters regarding the retry interval, maximum number of attempts, etc.

ATP Request Queue Processing [Execution Server] The execution server 16 receives a request queue command as a confirmation that all line-items have been placed in the queue. Based on this confirmation, the execution server 16
Updates the status of each request line-item to "queued". Further, processing of the ATP request 30 stops until the queuing parameters for such processing are met. Based on the specified retry interval or the like, execution server 16 may resubmit component ATP requests 32 queued for estimation to LFM 22 periodically. In this regard,
The processing is the same as the processing in the work flow of the re-estimation processing.

Component Contract Change Workflow FIG. 5 is a diagram showing a workflow of component contract change according to the present invention.
This or a similar workflow may be used to handle changes to suitable existing quantities, acceptances, contracts, estimates, requests or supplies. It is common for component ATP requests 32 reserved as backlogs to support supply to fluctuate over time. Some type changes are rare, while others are common and must be handled efficiently. For example, planned supplies often change regularly, usually at least weekly, often daily, and sometimes more frequently. Further, co-pending US patent applications Ser. Nos. 08 / 491,167 and 08/8.
As described in U.S. Pat. No. 02,434, the distribution of supplies to various products or merchants typically varies at least often. In either case, all affected elements in the distributed system 10 should be informed, and pending quotes 36 or contracts 46 may need to be adjusted or revoked.

The effects of changes in manufacturing plans and schedules appear to be propagated downstream to the component ATP request 32 of the LFM 22, invalidating one or more existing contracts. The final result is one or more component ATP requests 3
2 is later rescheduled or simply shortened at the planning horizon. In one embodiment, LFM 22 monitors the status of component ATP request 32 and identifies such events and communicates to execution server 16 accordingly. For example, the ATP server 14 “publishes” the supply change affecting the component ATP request 32 secured as the backlog to the LFM 22.
The LFM 22 may then notify the execution server 16, which evaluates the revised component request status, e.g., notifies the client 12 of the status and provides the client 12 with one or more options, Operate. Similarly, changes made at the execution server 16 are affected by the affected LF
M22 needs to be sent, and the supply reservation may be adjusted accordingly. In addition, each of the above operations may support one or more alternative workflows to handle the case where the ATP data component of the system 10 becomes invalidated by such a change.

Processing ATP Server Changes [LFM] In one embodiment, the system 10 provides an interface protocol between the LFM 22 and the ATP server 14 and thus contracts the component ATP requests 32 in the associated planning engine. Plan changes that affect the characteristics are proactively identified in the ATP server 14 and sent to the LFM 22 for evaluation. This evaluation process is the same as that of the first component contract response; that is, LFM2
2 evaluates the modified component contract response according to the constraints specified in the original ATP request 30. The revised contract from ATP server 14 does not change the contract between the customer and the supplier. In one embodiment, since contract 46 and acceptance 50 are separate objects, a change to contract 46 does not change acceptance 50 and generally represents a binding business commitment between the customer and the supplier. Schedules and other changes may be ignored and the original promise is retained. However,
The binding business agreement remains unchanged until the client 12 or the associated user accepts the revised agreement 62 and a new acceptance 64 is created.

If the plan change attempts to affect the validity of the component contract 44, the LFM
22 may create a plan change notification 60 for the change and may also notify any existing failure conditions. The plan change notice 60 is created in a suitable format and sent to the execution server 16 using the network 20. The execution server 16 may create the revised contract 62 based on the plan change notification 60 and send the revised contract 62 to the client 12. Alternatively or additionally, execution server 16 evaluates the plan change notification and creates one or more revised component ATP requests 66, essentially as for modified component ATP requests 32 as described above. Is the same style,
It may be sent to LFM 22 and processed there. The execution server 16 may appropriately notify the plan change notification 60 according to the needs of customers and users associated with the client 12.
You may work on

LFM Change Processing [Execution Server] The execution server 16 monitors an event started by the LFM, such as a component contract change, and responds to it. A component contract change in the planning engine associated with the ATP server 14 may have essentially affected the integrity of the original contract 46. Therefore, in one embodiment, the execution server 16
Re-evaluate contract 46 according to the constraints specified in request 30. For example, a short proportional associated with the ATP request 30
Depending on the value of the (onal) attribute, the execution server 16 may proportionally adjust all request line-item contracts and release the under-distribution of other request line-items. Failure to do so will leave the product tied to the customer without the customer eventually accepting the product. Execution server 16 may try one or more alternative suppliers before coordinating or abandoning ATP request 30, or may simply create a suitable problem notification and have client 12 or an associated user review and resolve it. Is also good.

The execution server 16 may provide the ability to re-price the contract 46 as needed in the event of a change initiated by the LFM, possibly requiring a pricing calculation based on the nature of the change. Determine whether or not. For example, a change in the shipping date for an ATP request 30 does not require repricing, while a change in volume may invalidate the contracted price. Alternatively or additionally, the execution server 16 may recalculate the delivery date based on the change initiated by the LFM, and possibly determine whether the delivery needs to be calculated based on the nature of the change. For example, if the amount for the ATP request 30 changes, no delivery adjustment is required, but a change in the shipping date may invalidate the contracted delivery.

When the execution server 16 evaluates the changed component contract 44 with respect to the constraint specified in the ATP request 30, it creates a revised contract 62 and sends it to the client 12. This processing is a contract confirmation processing except that the original contract 46 already exists and the execution server 16 only updates a part of the contract 46 related to the ATP request change when creating the revised contract 62. Is the same as Failure notifications may be created appropriately. At this stage, the client 12 or associated user may simply wish to accept this change and create an acceptance 64 and send it to the execution server 64, or proceed with a re-quotation, change, or cancellation workflow.

ATP Request Cancellation Workflow Initiating ATP Request Cancellation [Client] In one embodiment, the client 12 or an associated user sends the ATP request 30 when the supplier business constraint is, for example, outside of the specified time interval. Unless explicitly excluded, the ATP request 30 can be canceled at any point during its life cycle. As a result, the ATP request 30 is being initially created,
It can be canceled during the quote process, after acceptance, and even after some execution. The intention of the cancellation is to make the ATP request 30 permanently inactive.
Client 12 or an associated user queries ATP request 30 to initiate this process. Once the ATP request 30 has been
When displayed on the P client 12, the user selects the cancel function,
The client 12 may execute a cancel command.

ATP Request Cancellation Process [Execution Server] The execution server 16 receives a request cancellation from the client 12 in one type indicating that all request line-items have been canceled. Execution server 1
6 then determines whether there is a product or supplier restriction for revocation. If so, a failure notification is created immediately and sent to the client 12 using the network 18. After determining the validity of the request cancellation, the execution server 16 updates the status of each request line-item to "cancelled".
The execution server 16 then sends the resulting component request cancellation over the network 20 for processing by the appropriate LFM 22.

Processing for Canceling Component ATP Request [LFM] Upon receiving the cancellation of the component request from the execution server 16, the LFM 22 creates and executes a cancellation transaction in a syntax suitable for the ATP server 14 and the related planning engine. When the ATP server 14 responds to the LFM 22 with confirmation of the revocation, the LFM 22
Update the status of TP requests, component quotes, and component contracts. The LFM 22 creates a component cancellation confirmation and sends it to the execution server 16 using the network 20.

Process of Component Confirmation [Execution Server] When the execution server 16 processes the component request cancellation and transmits it to the LFM 22, it monitors the completion of the obtained component cancellation confirmation. In one embodiment, the revocation confirmation is considered complete when each component request revocation receives one component revocation confirmation. The execution server 16 includes the ATP request 30, the estimate 36, and the contract 4 maintained by the execution server 16.
6 may be noted. A final revocation confirmation is created and sent to the client 12 using the network 18, ending the ATP request life cycle.

Executing the Confirmation Workflow Processing Component Execution Notification [LFM] In one embodiment, the system 10 provides an interface protocol between the LFM 22 and the ATP server 14 so that shipping notifications at the associated planning engine are The ATP server 14 proactively identifies it and sends it to the LFM 22. LFM
22 updates the status of the locally maintained component ATP request 32 and component contract 44 and may reflect the execution before the resulting component execution notification is sent to the execution server 16 using the network 20. .

Execution Notification Processing [Execution Server] Once acceptance 50 has been properly processed, execution server 16 monitors component execution notifications from LFM 22. It is considered that the ATP request 30 was executed when each component ATP request 32 received one component execution notification. A unified execution notification is created and sent over the network 18 to the requesting client 12. When the component ATP request 32 is executed, the execution server 16 may also monitor the corresponding shipping confirmation. When the ATP request 30 is completely shipped, its status is updated and the execution server 16 notifies the requesting client 12. The execution server 16 may provide archiving capabilities for executed ATP requests 30, which is configurable so that the client 12 can maintain the ATP requests 30 when they are archived, the number of periods of request history maintained, etc. Archive parameters can be specified. Archive is execution server 1
6, may be maintained at one or more locations associated with the LFM 22, or at other suitable locations within or outside the system 10.

[Brief description of the drawings]

FIG. 1 illustrates an exemplary system for executing a deal in a distributed supply chain planning environment according to the present invention.

FIG. 2 is a diagram showing a work flow of an exemplary ATP request according to the present invention.

FIG. 3 is a diagram showing an exemplary estimation confirmation work flow according to the present invention.

FIG. 4 illustrates an exemplary contract acceptance workflow according to the present invention.

FIG. 5 illustrates an exemplary component contract change according to the present invention.

──────────────────────────────────────────────────続 き Continued on the front page (51) Int.Cl. ⁷ Identification symbol FI Theme coat ゛ (Reference) G05B 19/418 G05B 19/418 Q (81) Designated countries EP (AT, BE, CH, CY, DE, DK) , ES, FI, FR, GB, GR, IE, IT, LU, MC, NL, PT, SE), OA (BF, BJ, CF, CG, CI, CM, GA, GN, GW, ML, MR) , NE, SN, TD, TG), AP (GH, GM, KE, LS, MW, SD, SL, SZ, TZ, UG, ZW), EA (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), AE, AL, AM, AT, AU, AZ, BA, BB, BG, BR, BY, CA, CH, CN, CR, CU, CZ, DE, DK , EE, ES, FI, GB, GD, GE, GH, GM, HR, HU, ID, IL, IN, IS, JP, KE, KG, KP, KR, KZ, LC, LK, LR, LS, LT, LU, LV, MD, MG, MK, MN, MW, MX, NO, NZ, PL, PT, RO, RU, SD, SE, SG, SI, SK, SL, TJ, TM, TR, TT , UA, UG, UZ, VN, YU, ZA, ZW (72) Inventor Herbert V. Joiner London Drive 2448, Plano, Texas 75025 F-term (reference) 3C100 AA01 AA21 BB01 CC07 EE20

Claims (76)

[Claims] 1. A client interface, an ATP server interface, and an execution server, wherein the execution server includes a plurality of request line-items each corresponding to one desired product using the client interface. Receiving a first ATP request, creating one or more component ATP requests based on the request line-item, communicating the component ATP request to at least one of the plurality of ATP servers using an ATP server interface; Receiving from the ATP server a plurality of component quotes each corresponding to one component ATP request and having product validity information for one or more corresponding desired products using the server interface; A contract-available (available-to-available) that is operable to create a single quote determined according to the product validity information provided by the component quote and to communicate the quote using the client interface. -Promise, ATP)
A system for automatically managing data. 2. The method of claim 1, wherein the ATP request specifies one or more business constraints, and wherein the execution server is further operable to evaluate the component estimates according to the business constraints during quote creation. server. 3. The system of claim 2, wherein at least some of the business constraints are based on a customer profile. 4. The system of claim 1, wherein the execution server is further operable to evaluate component quotes according to business constraints specified by the supplier during quote creation. 5. The system of claim 1, wherein each ATP server is associated with a local execution manager (LFM) that manages processing of component ATP requests in a planning engine associated with the ATP server. 6. The system according to claim 1, wherein the execution server receives a first ATP request from a first client, and receives a second request from a second client simultaneously with the first ATP request. . 7. The system of claim 1, wherein the execution server is further operable to communicate at least one component ATP request to a target ATP server based on one or more business constraints in the ATP request. 8. The execution server further comprising: using a client interface, a quote line within the quote each corresponding to one particular accepted product-a quote confirmation including at least some acceptance of the item. , Create a component quote confirmation for each accepted quote line-item, and use the ATP server interface to ATP validate the component quote confirmation
Communicate to the server and use the ATP server interface to receive from the ATP server a plurality of component contracts, each corresponding to a single component quote confirmation and each representing a product effectiveness commitment for the corresponding accepted product. The system of claim 1, wherein the system is operable to create a contract including a product validity commitment for a product accepted according to the component contract, and to communicate the contract using the client interface. 9. The system of claim 8, wherein the execution server is further operable, when creating the contract, to evaluate the component contract according to business constraints profiled for a customer. 10. The execution server further accepts the contract acceptance using a client interface, and executes the ATP request to execute the ATP request.
9. The system of claim 8, operable to communicate to a P server. 11. An execution server for operating in a distributed supply chain planning environment, said execution server valid for at least one contract including a plurality of request line-items each corresponding to one desired product. Na (AT
P) operable to accept a request from one client; wherein the execution server is operable to make one component ATP request for each request line-item; An execution server that is operable to communicate component ATP requests for estimation to a plurality of local execution managers (LFMs), each associated with a planning engine. 12. The execution server of claim 11, wherein the ATP request specifies one or more business constraints and is operable to create a component ATP request according to the business constraints. 13. The execution server of claim 12, wherein at least some of the business constraints are based on a customer profile. 14. The execution server of claim 11, further operable to communicate at least one component ATP request to a target LFM based on one or more business constraints in the ATP request. 15. A method for receiving, from the LFM, a plurality of component contracts each corresponding to one component ATP request and representing a contract of product effectiveness for a corresponding desired product; The execution server of claim 11, operable to create a contract including a contract for product validity for the first product, and to communicate the contract to a first client. 16. The execution server of claim 15, further comprising, when creating the contract, operable to evaluate a component contract according to business constraints profiled for a single customer. 17. A local execution manager having an associated ATP server with an execution server interface and a contract effective (ATP) server interface and operating in a distributed supply chain planning environment including other LFMs. (LFM), wherein the LFM is operable to receive one or more component ATP requests from an execution server, each component ATP request being one special ATP request line-item for one desired product. And the LFM is further operable to determine an ATP response for each request line-item using the associated ATP server and to generate a component estimate for each request line-item according to the corresponding ATP response. The component quote includes product validity information for a corresponding desired product, and the LFM is further operative to communicate the component quote to an execution server for integration with other component quotes from one or more other LFMs. LFM that can do. 18. The component of claim 17, wherein each component ATP request specifies one or more business constraints, and the LFM is further operable to evaluate an ATP response according to the business constraints in creating a component quote. LFM. 19. The LFM of claim 18, wherein at least some of the business constraints are based on a customer profile. 20. The LFM of claim 17, wherein the LFM is further operable to generate a component quote according to a supplier-specific business constraint. 21. The LFM is a component A in an associated planning engine.
Managing the processing of TP requests, wherein the LFM is operative to calculate a part of the ATP response according to information obtained from the ATP server, said part depending on the capabilities of the ATP server and its associated planning engine. Item 18. LFM according to Item 17. 22. Further, a component quote confirmation for each component quote accepted as a quote line-item at the client is received from the execution server, and a contract response to each accepted quote line-item using an associated ATP server. Each acceptance quotation line, which determines the product effectiveness for the corresponding accepted product.
20. The LFM of claim 17, operable to create a component contract for an item and communicate the component contract to an execution server for integration with component contracts from one or more other LFMs. 23. The LFM of claim 22, further comprising, when creating the component contract, operable to evaluate a contract response according to business constraints profiled for a customer. 24. The component ATP request corresponds to an individual item, and the LFM calculates a component quote including information and rules on how the execution server can change their component quotes. 18. The LFM of claim 17, wherein the LFM is operable. 25. The component ATP request corresponds to an individual item, and the LFM computes a component contract that includes information and rules on how the execution server can change those component contracts. 18. The LFM of claim 17, wherein the LFM is operable. 26. The LFM further comprising: receiving from the execution server a series of component ATP requests in which one or more first component ATP requests are targeted to the LFM;
Process a first component ATP request targeting the LFM to calculate one or more resulting component estimates, and combine the obtained component estimates with the remaining component ATP requests in the sequence in the sequence. 18. The LFM of claim 17, operable to pass to the targeted second LFM by one or more second component ATP requests of the LFM. 27. The LFM supports a seller hierarchy also supported by the execution server; supports a subset of products supported by the execution server; and the entire seller hierarchy for a subset of products. 18. The LFM of claim 17, operable to calculate a component quote or component contract for each product based on the distribution over. 28. Supporting a subset of products in a hierarchy of related products supported by the execution server, and calculating a component quote or component contract based on an allocation to a subset of products across the hierarchy. The LFM of claim 17 operable. 29. The LFM is further operable to calculate a generic validity of a product by sending a component ATP request to a second LFM corresponding to the generic product. LFM. 30. The LFM corresponds to a seller in a seller hierarchy supported by the execution server, and the LFM holds a distribution of supplies for the corresponding seller, and is capable of being included in the included distribution. Execution server to calculate all the component quotes or component contracts, and for each product, combine the component quotes or component contracts as if the ATP requests were quoted or contracted by a single system with all the allocations 18. The LFM of claim 17, operable to send to an LFM. 31. The LFM is further operable to calculate a validity of a corresponding parent seller by sending a component ATP request to a second LFM corresponding to the parent seller. LFM as described. 32. The LFM receives a component AT from a plurality of execution servers.
18. The LF of claim 17, operable to accept the P request and communicate a component quote or component contract to multiple execution servers.
M. 33. The LFM of claim 17, wherein the LFM supports a subset of a product hierarchy and is operable to calculate a component quote or component contract based on an allocation to products within the hierarchy. 34. A system comprising: a client interface; and a local execution manager (LFM) interface, wherein the execution server includes a plurality of request line-items, each corresponding to one desired product, using the client interface. Operable to receive a valid (available-to-promise, ATP) request for a first contract, wherein the execution server further creates one or more component ATP requests based on the request line-item. And a component ATP request using the LFM interface
Communicating to at least one of the FMs and receiving a plurality of component quotes from the LFM using the LFM interface, each component response to one component ATP request and having product validity information for one or more corresponding desired products. ATP data, which is operable to create a single quote determined according to the product validity information provided by the component quote and to communicate the quote using the client interface, System for managing. 35. The execution server according to claim 1, wherein each of the items comprises a component A.
Computing a TP request, the component estimates received from the LFM include information and rules on how execution servers can change their component estimates, and the execution server further executes the components according to the information and rules. 35. The system of claim 34, operable to vary the estimates, so that both component estimates meet one or more business constraints. 36. The execution server computes component ATP requests for individual items and accepts from the LFM a component contract including information and rules on how the execution server can modify the component contract. The execution server can operate to modify the component contract according to the information and rules, so that both the component contracts satisfy one or more business constraints, and the execution server is further modified. 35. The system of claim 34, wherein the system is operable to communicate the returned component contract to the LFM so that the LFM can adjust the supply reservation. 37. The execution server comprises: all items provided via an associated LFM, and a component ATP
Calculate a component ATP request that includes all business constraints on the ATP request that apply to the item in the request, receive a component quote from each LFM that fulfills the business constraint, and combine the component quotes of the multiple items obtained. 35. The system of claim 34, operable to generate an estimate corresponding to the ATP request. 38. The execution server according to claim 26, wherein all items supplied via the associated LFM are associated with the component AT
Calculate the component ATP request including all the business constraints on the ATP request applied to the item of the P request, accept the component contract that fulfills the business constraint from each LFM, and combine the obtained component contracts of the multiple items. 35. The system of claim 34, wherein the system is operable to create a single contract corresponding to the ATP request. 39. At least some of the LFMs maintain separate allocations for the same product, and the execution server is further operable to distribute the estimation activity across the plurality of LFMs to obtain a component estimate for the product. 35. The system of claim 34, which is capable. 40. The system of claim 34, wherein said execution server is also operable as an LFM. 41. Receiving a valid ATP request for a first contract, each including a plurality of request line-items corresponding to one desired product; and one or more components according to the request line-item. Creating an ATP request; and transmitting the component request to a plurality of ATP requests using an ATP server interface.
Transmitting to at least one of the TP servers; and receiving a plurality of component quotes from the ATP server using an ATP server interface, each component quote corresponding to one component ATP request and one or more responses. Automatically managing ATP data including: a step of including product validity information for a desired product to be created; a step of creating a quote according to the product validity information provided by the component quote; and a step of transmitting the quote. Way for. 42. The method of claim 41, further comprising evaluating a component estimate according to one or more business constraints identified by the ATP request when creating the estimate. 43. The method of claim 42, wherein at least some business constraints are based on a customer profile. 44. The method of claim 42, further comprising evaluating the component quote in accordance with at least one supplier-specified business constraint when creating the quote. 45. The method of claim 41, wherein each ATP server is associated with a local execution manager (LFM) operable to manage processing of component ATP requests in a planning engine associated with the ATP server. 46. The method of claim 41, further comprising accepting a second ATP request with the first ATP request. 47. The at least one component ATP request comprises: A
The method of claim 41, wherein the method is communicated to the target LFM based on one or more business constraints in the TP request. 48. Receiving a quote confirmation including acceptance of at least some line-items in the quote, each of the quote line-items corresponding to one special accepted product; Creating a component quote confirmation for each accepted quote line-item, communicating the component quote confirmation to the ATP server via the ATP server interface, and each one from the ATP server via the ATP server interface. Receiving a plurality of component contracts corresponding to the component quote confirmation and representing a product validity commitment for the corresponding accepted product, including a product validity promise for the accepted product in accordance with the component contract; Step a The method of claim 41 further comprising the steps of: transferring the contract to create approximately. 49. The method of claim 48, further comprising evaluating a component contract according to business constraints profiled for a customer in creating the contract. 50. The method of claim 48, further comprising: accepting a contract acceptance; and communicating the contract acceptance to an ATP server for performing an ATP request. 51. From a client, at least one contract valid (A) containing a plurality of request line-items, each corresponding to one desired product.
TP) receiving a request, creating one or more component ATP requests based on the request line-item, and estimating the component ATP requests, a plurality of local executions each associated with a planning engine. Communicating to a Manager (LFM). A method for managing ATP data at an execution server in a distributed supply chain planning environment comprising: 52. Communicating at least one component ATP request to a target LFM based on one or more business constraints in the ATP request, wherein the business constraints are based on a customer profile; 53. The method of claim 51, comprising: evaluating component estimates according to business constraints. 53. Further, a plurality of component contracts, each corresponding to one component ATP request and representing a contract of product validity for a corresponding desired product, may be entered into an LFM.
53. The method of claim 51, comprising: receiving from a customer contract, creating a contract including a product validity agreement for a desired product according to a component contract; and communicating the contract to a client. 54. From the execution server, one for each one desired product
Receiving a valid (ATP) request for a contract for one or more components corresponding to one particular ATP request line-item; and using an associated ATP server to set the AT for each request line-item.
Calculating a P response and generating one or more component quotes for each of the request line-items according to the corresponding ATP response, wherein the component quotes include product validity information for a corresponding desired product. Steps; and estimating the component estimates by one or more other local execution managers (L
Sending to the execution server for combining with other component estimates from the FM), and a method operating on the LFM to manage ATP data comprising: 55. The method of claim 54, further comprising evaluating the ATP response according to one or more business constraints identified in the ATP request and creating a component quote. 56. The method of claim 55, wherein at least some business constraints are based on a customer profile. 57. The method of claim 54, further comprising the step of creating a component quote according to business constraints specified for the supplier. 58. Further, according to information obtained from an associated ATP server, A
Calculating a portion of the TP response, wherein the LFM manages the processing of the component ATP request at the associated planning engine, said portion comprising steps dependent on the capabilities of the ATP server and the associated planning engine. Item 55. The method according to Item 54. 59. Furthermore, receiving a component quote confirmation for each component quote accepted as an item from the execution server at the client, and using the associated ATP server to perform each accepted quote line using the associated ATP server. Determining a contract response for the item; creating a component contract for each of the accepted quote line-items representing product effectiveness commitments for the accepted product; 55. The method of claim 54, further comprising: sending to the execution server for combining with the component contract from the LFM of the third party. 60. The method of claim 59, further comprising evaluating a contract response according to business constraints profiled for the customer when creating the component contract. 61. The component ATP request corresponds to an individual item and further comprises the step of calculating a component quote including information and rules on how the execution server can change the component quote. The described method. 62. The component ATP request corresponds to an individual item and further comprises the step of calculating a component contract including information and rules on how the execution server can modify the component contract.
4. The method according to 4. 63. Receiving a series of component ATP requests, wherein one or more first component ATP requests thereof target an LFM, from an execution server, the first component targeting the LFM. Process the ATP request,
Calculating the resulting one or more component estimates; targeting the obtained component estimates along with one or more remaining component ATP requests in the sequence by one or more second component requests in the sequence. 55. The method of claim 54, comprising: passing to a second LFM determined. 64. Supporting a seller hierarchy also supported by the execution server; supporting a subset of products supported by the execution server; and a seller for the subset of products. 55. The method of claim 54, comprising: calculating a component quote or component contract for each product based on distribution across the hierarchy. 65. Supporting a subset of products in a hierarchy of related products supported by the execution server; and estimating a component quote or component contract based on the distribution of the subset of products across the hierarchy. 55. The method of claim 54, comprising: calculating. 66. The method of claim 54, further comprising calculating a generic validity of the product by sending one or more component ATP requests to a second LFM corresponding to the generic product. 67. The LFM corresponds to a seller in a seller hierarchy supported by the execution server, and further comprising: maintaining a distribution of supplies in the LFM for the corresponding seller. Calculating all possible component estimates or component contracts using the allocation; and, for each product, as said ATP requests were estimated or contracted by a single system having all of the allocations, said component estimates or component contracts. 55. The method of claim 54, comprising: sending to the execution server for combining. 68. The method of claim 54, further comprising calculating a validity of the corresponding parent seller by sending a component ATP request to a second LFM corresponding to the parent seller. 69. The method of claim 54, further comprising: accepting a component ATP request from a plurality of execution servers; and sending a component quote or component contract to the plurality of execution servers. 70. The method of claim 54, further comprising: supporting a subset of a product hierarchy; and calculating a component quote or component contract based on an allocation to products in the hierarchy. 71. Receiving (ATP) valid requests for a first contract, each including a plurality of request line-items corresponding to one desired product; and one or more based on the request line-items. Creating a component ATP request; and sending the component ATP request to a plurality of local execution managers (LFs).
M) and receiving a plurality of component quotes from the LFM, each component quote corresponding to one component ATP request and product validity for one or more corresponding desired products. A method for automatically managing ATP data, comprising: a step of including estimate information; a step of creating a quote according to product validity information provided by the component quote; and a step of communicating the quote. 72. Computing a component ATP request for an individual item, wherein the component quote received from the LFM includes information and rules on how to change the component quote; 72. The method of claim 71, comprising: modifying the component estimate according to information and rules, so that the component estimates both satisfy one or more business constraints. 73. Calculating component ATP requests for individual items, the component contract received from the LFM including information and rules on how to change the component contract; Modifying the component contract according to information and rules, so that the component contracts together meet one or more business constraints; and communicating the modified component contract back to the LFM so that the supply reservation is adjusted. 72. The method of claim 71, comprising: 74. Computing a component ATP request that includes all items provided via the associated LFM and any business constraints on the ATP request that apply to the item of the component request; 72. The method of claim 71, comprising: receiving an LFM component quote that enforces business constraints from the LFM; and combining the resulting multiple-item component quote to create a quote corresponding to the ATP request. 75. Computing a component ATP request that includes all items provided via the associated LFM and all business constraints on the ATP request that apply to the item of the component request; 72. The method of claim 71, comprising: receiving an LFM component contract that enforces business constraints from the LFM; and combining the resulting multi-item component contracts to create a single contract corresponding to the ATP request. Method. 76. At least some of the LFMs maintain separate allocations for the same product, and further include the step of distributing estimation activity across multiple LFMs to obtain a component estimate for the product.
The described method.