1. Field of the Invention
This invention relates generally to the field of data processing systems. More particularly, the invention relates to a system and method for synchronizing sales order confirmations with material flow determinations within a supply chain management (“SCM”) system.
2. Description of the Related Art
Certain software applications are designed to comprehend complicated scheduling tasks. For example, as illustrated in
More advanced SCM applications provide functions for intra- and inter-company supply chain planning and for scheduling and monitoring of associated supply chain processes. For example, the assignee of the present application has developed an advanced supply chain management platform known as the Advanced Planner & Optimizer (“APO”) which, as described in Gerhard Knolmayer, et al., SUPPLY CHAIN MANAGEMENT BASED ON SAP SYSTEMS (hereinafter “Knolmayer”), includes different modules for implementing various interrelated SCM functions. As illustrated in
The ability to accurately forecast demand is an important precondition to any production planning schedule. With this goal in mind, the DP module 105 attempts to determine the demand for a product over a specified time period. Current demand planning techniques are largely based on empirical data 100 for a given product such as, e.g., historical demand data stored within an archiving system, data warehouse or other database 120.
SNP and PP/DS both fall into the general category of “advanced planning and scheduling” or “APS” which involves the planning and scheduling of materials and resources within the supply chain. SNP differs from PP/DS in terms of the time horizon used for planning and scheduling. The SNP module 103 is used for tactical (i.e., midterm) planning calculations, whereas the PP/DS module 101 is used for operational (i.e., short-term) planning calculations. For example, a typical planning horizon for SNP may be in the range of 3-6 months whereas a typical planning horizon for PP/DS may be in the range of 1-7 days.
The TP/VS module 104 employs techniques to optimize the delivery of products using different transportation routes and vehicles. It enables manufacturers, retailers, and logistics providers to coordinate transportation resources via the Internet and to synchronize transportation decisions and activities. The transportation planning component of TPNS focuses on medium- to long-term planning whereas the vehicle scheduling component focuses on short-term planning and routing.
The ATP module 102 is responsible for determining whether a product can be promised by a specified delivery date in response to a customer request. If a given product is not in stock, ATP coordinates with other modules such as PP/DS to determine whether the product can be procured from alternate sources and/or manufactured in time to fulfil the customer request.
One problem which exists with current SCM systems is the lack of synchronization between the material resource planning of the PP/DS module 101 and the order confirmations generated by the ATP module 102. Specifically, the confirmation decision provided by the ATP module 102 is based on the current state of production and supply chain planning but the confirmation does not force a corresponding material flow determination in the multi-stage PP/DS production and supply chain planning. Thus, the sales order confirmation and the material flow determination may ultimately differ. Consequently, problems to deliver the sales orders as confirmed can occur.
Accordingly, what is needed is an SCM system which provides for improved synchronization between the ATP confirmation decision and the corresponding material flow determination.
A computer system and method are described for synchronizing sales order confirmations with material flow determinations in a supply chain management (SCM) environment. For example, a method according to one embodiment of the invention comprises: receiving an indication of a new sales order having associated therewith a desired quantity and a desired delivery date; determining whether the desired quantity can be promised by the desired delivery date based on current receipts; and generating a fixed pegging relationship between the new sales order and receipts identified to satisfy the sales order if the desired quantity can be promised by the desired date.
A better understanding of the present invention can be obtained from the following detailed description in conjunction with the following drawings, in which:
Described below is a system and method for synchronizing sales order confirmations with material flow determinations within a supply chain management (“SCM”) system. Throughout the description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without some of these specific details. For example, although many of the embodiments described herein are based on the APO and/or R/3 architectures developed by the assignee of the present application, the underlying principles of the invention are not limited to any specific SCM architecture. In other instances, well-known structures and devices are shown in block diagram form to avoid obscuring the underlying principles of the present invention.
In one embodiment of the invention, in order to synchronize sales order confirmations and material flow determinations within a multi-sage production and supply chain environment, the material flow determinations are linked directly (e.g., coupled to or integrated into) the sales order confirmations. Before a sales order is created it obviously cannot be considered in planning. At this stage, production is often planned against the demand forecast. At a later point in time, a sales order is entered. During sales order entry, the demand forecast is consumed, an ATP check is performed to determine availability, and the sales order is created. ATP is checked either against receipts (also known as “production orders” or POs) created earlier to cover the forecast or a “capable to promise” (CTP) check is performed. A CTP check is a relatively more advanced check in which the necessary receipts are created dynamically. For example, under a CTP check, it is often not the availability of the sellable product which is checked but rather the availability of the components which comprise the sellable product. Production of the sellable product is subsequently triggered using the components.
In one embodiment of the invention, in response to new sales orders “fixed pegging” relationships are established between the sales orders and allocated receipts. As used herein, “fixed pegging” refers to the matching of specific sales order confirmations with specific receipts. Using the fixed pegging techniques described herein, sales order confirmations and material flow determinations are ensured to be based on the same relationships, thereby improving synchronization between production planning and sales order confirmations. For example, improved visibility of ATP results in production planning allows planners to consider due date constraints set by confirmed sales orders in the multi-stage production and supply chain environment.
In one embodiment, each of the modules illustrated in
In one embodiment of the invention, two PPDS/ATP confirmation types are processed by the synchronization module 200: 1) PPDS/ATP confirmations against available receipts; and 2) PPDS/ATP confirmations against fixed-pegged receipts. Following the description of these embodiments is a description of 3) the creation of fixed pegging relationships during multi-level planning actions.
In the case of PPDS/ATP confirmations against available receipts, existing fixed pegging relationships to the processed sales order are deleted before new fix pegging relationships according to the ATP confirmation are created. System behavior for the creation of fixed pegging relationships within the PPDS/ATP confirmation process will be described using the following examples:
(a) Sales Order Creation
Referring to
(b) Sales Order Quantity Increase
In the example shown in
(c) Sales Order Quantity Decrease
In the example shown in
(d) Sales Order Date Shift Forward
In the example shown in
(e) Sales Order Date Shift Backward
In the example shown in
(f) Sales Order with Several Scheduling Lines
A single order may have multiple scheduling lines. In the example shown in
With respect to PPDS/ATP confirmations against fixed-pegged receipts, the existing fixed-pegged relationships to processed sales orders are evaluated as part of the PPDS ATP/CTP confirmation. The existing fixed pegging relationship may restrict the PPDS ATP/CTP confirmation. However, in one embodiment, for newly created receipts within the CTP process, new fixed pegging relationships are created. Based on these principles, one embodiment of the invention will be described using the following examples:
(a) Sales Order Quantity Increase
In the example shown in
(b) Sales Order Quantity Decrease
In the example shown in
(c) Sales Order Date Shift Forward
In the example shown in
(d) Sales Order Date Shift Backward
In the example shown in
(e) Sales Order with Several Scheduling Lines
As mentioned above, a single order may have multiple scheduling lines. In the example shown in
3. Fixed-Pegging Relationships for Multi-Level Planning
As mentioned above, it is often necessary to check component availability directly during order creation within a CTP process. In one embodiment of the invention, to support fixed pegging in a multi-level production environment, fixed pegging creation on a dependent requirement level is implemented. In one embodiment of the invention, three different types of actions may be triggered:
(a) Cover Dependent/Stock Transfer Requirements Immediately with Existing Receipts.
This action demands that for a newly created or changed order, the dependent/stock transfer requirements must be covered by existing receipts. If this is not the case, the order is deleted. If the dependent stock transfer requirements are covered later in time, the order must be scheduled forward in time accordingly. Thus, the order is allowed to be created or changed only when the dependent/stock transfer requirements are covered in time.
(b) Cover Dependent/Stock Transfer Requirements Immediately.
This action demands that for a new created or changed order the dependent/stock transfer requirements must be covered by existing receipts. If this is not the case, creation of new receipts on component level is triggered and the availability check is performed again for the order (in contrast to (a) above). If the dependent/stock transfer requirements are not covered, the order is deleted. If the dependent/stock transfer requirements are covered later in time, the order is scheduled in time accordingly.
(c) Cover Dependent/Stock Transfer Requirements Immediately if Possible.
This action demands that for a newly-created or changed order the dependent/stock transfer requirements are covered by existing receipts, if possible. If the dependent requirement is not covered, creation of new receipts on the component level is triggered and the availability check is performed again for the order. If the dependent/stock transfer requirements are not covered, however, the order is not deleted. If the dependent/stock transfer requirements are covered later in time, the order is not scheduled in time accordingly.
In one embodiment of the invention, for all three techniques described above, an availability check is performed to define material flow on the component level. Thus, in this embodiment of the invention, the creation of fixed pegging relationships can also help to define the material flow, since with existing fixed pegging relationships the determination of availability quantities is much simpler and more stable.
The following different examples will be used to illustrate the requirements for implementing fixed pegging on the component level when an availability check is performed:
(a) Creation of Dependent Requirement
In the example shown in
(b) Increase of Requirement Quantity
In the example shown in
(c) Decrease of Dependent Requirement Quantity
In the example shown in
(d) Forwarded Shift of the Dependent Requirements Date
In the example shown in
(e) Backward Shift of Dependent Requirements Date
In the example shown in
Throughout the description, for the purposes of explanation, numerous specific examples were provided in order to convey an understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without some of these specific details.
It is believed that processes taught by the discussion above can be practiced within various software environments such as, for example, object-oriented and non-object-oriented programming environments, Java based environments (such as a Java 2 Enterprise Edition (J2EE) environment or environments defined by other releases of the Java standard), or other environments (e.g., a .NET environment, a Windows/NT environment each provided by Microsoft Corporation).
Embodiments of the invention may include various steps as set forth above. The steps may be embodied in machine-executable instructions which cause a general-purpose or special-purpose processor to perform certain steps. Alternatively, these steps may be performed by specific hardware components that contain hardwired logic for performing the steps, or by any combination of programmed computer components and custom hardware components.
The present invention may also be downloaded as a computer program which may be transferred from a remote computer (e.g., a server) to a requesting computer (e.g., a client) by way of data signals embodied in a carrier wave or other propagation medium via a communication link (e.g., a modem or network connection).
Throughout the foregoing description, for the purposes of explanation, numerous specific details were set forth in order to provide a thorough understanding of the invention. It will be apparent, however, to one skilled in the art that the invention may be practiced without some of these specific details. For example, although the description above focused on single-activity resources, the same general principles apply to other resources (e.g., multi-activity resources). Accordingly, the scope and spirit of the invention should be judged in terms of the claims which follow.