The present invention generally relates the field of data processing and to computerized systems and methods for automatically assigning an incoming quantity of goods in response to an event. More particularly, and without limitation, the invention relates to systems and methods for using a predetermined criteria to assign an incoming quantity of goods to a subset of sales orders.
Supply chain management software systems, such SAP's Supply Chain Management (SAP SCM) system, currently exist in the industry. Such supply chain management systems may include a plurality of applications for implementing the management of the supply chain. SAP's Advanced Planning and Optimization (SAP APO) and Extended Warehouse Management (EWM) are examples of these applications. A core interface (CIF) may connect SAP SCM with online transaction processing systems (OLTP), such as SAP Customer Relations Management (SAP CRM) and Enterprise Resource Planning (ERP). Also, the core interface may connect the OLTP to the SAP APO. In supply chain management, when a product is available to be promised to a customer, it is “available to promise” (ATP). Supply chain management systems including available to promise (ATP) functionality currently exist in the industry. Supply Chain Management applications, such as SAP APO may include ATP functionality. Such systems include software for determining whether a product is available to promise. This determination may include performing an availability check when a customer calls to place an order.
In conventional supply chain management systems like SAP SCM, events that may improve the availability situation of a given material cannot be evaluated to trigger functions or processes in order to optimize business opportunities. Such events include, for example, changes in stock, new planned supply or drop of demand. Triggered functions may include distribution of any additional surplus close in time to the occurring event. In conventional systems, a realignment of the availability situation, in response to an event, is only possible by mass availability check runs initiated at predefined points in time, for example, manually or periodically scheduled as a background job. The resulting time delay with respect to the monitoring effort leads to significant business impact since supply which would be available is not assigned directly to highly prioritized demands or demands that were put in at an earlier time. Thus, the business performance is compromised.
It is desirable to address one-or more problems, such as the problems identified above, in conventional systems. In particular, it is desirable to improve the business performance aspects of the application availability check to ensure that available stock-can be assigned to sales orders more quickly. Thus, it is further desirable to increase the speed with which aspects of the availability check can be carried out.
In view of the foregoing, systems and methods are disclosed herein for overcoming one or more of the above-mentioned problems. In accordance with embodiments of the invention, systems and methods may be provided for automatically assigning an incoming quantity of goods in response to an event. More specifically, embodiments of the invention include systems and methods for using a predetermined criteria to assign an incoming quantity of goods to a subset of sales orders.
In accordance with an embodiment of the invention, a system is provided for automatically assigning an incoming quantity of goods in response to an event. The system comprises an inbound interface for interfacing with a plurality of data storage devices in at least one of which the incoming quantity of goods are stored as data and a plurality of sales orders to be confirmed are stored; an execution memory operable to hold a software system, and a processor for coupling to the inbound interface and the execution memory, the processor being operable to execute the software system such that the software system operates: to select a subset of sales orders from the plurality of sales to be confirmed according to one or more predetermined criteria and to assign to the subset of sales orders the incoming quantity of goods.
In conventional systems, a realignment of the availability situation after changes in stock, planned supply, or demand change is only possible by mass availability check runs initiated at predetermined points in time, for example, after supply planning. In accordance with an aspect of the present invention, using event driven quantity assignment, it is possible to assign in real time, document changes as events which immediately trigger the fulfilment of certain demands, for example, high priority sales orders, and /or trigger deployment processes.
According to another embodiment of the present invention, a method is provided for automatically assigning an incoming quantity of goods in response to an event. The method comprises the steps of interfacing with a plurality of data storage devices in at least one of which the incoming quantity of goods are stored as data and a plurality of sales orders to be confirmed are stored, holding a software system in an executable memory, and coupling the inbound interface to the execution memory, executing the software system such that the software system operates to select a subset of sales orders from the plurality of sales to be confirmed according to one or more predetermined criteria and to assign to the subset of sales orders the incoming quantity of goods.
According to an embodiment of the present invention, a user terminal may be provided that includes means operable with systems and methods consistent with the invention, such as those previously described.
Embodiments of the present invention further relate to a computer readable storage medium that stores a program which, when run on a computer, controls the computer to perform systems and methods consistent with the present invention, such as those previously described.
Additional objects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. The objects and advantages of the invention will be realized and attained by means of the elements and combinations particularly pointed out in the appended claims.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.
The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate various embodiments and aspects of the present invention. In the drawings:
The following detailed description refers to the accompanying drawings. Wherever possible, the same reference numbers are used in the drawings and the following description to refer to the same or similar parts. While several exemplary embodiments and features of the invention are described herein, modifications, adaptations and other implementations are possible, without departing from the spirit and scope of the invention. For example, substitutions, additions or modifications may be made to the components illustrated in the drawings, and the exemplary methods described herein may be modified by substituting, reordering, or adding steps to the disclosed methods. Accordingly, the following detailed description does not limit the invention. Instead, the proper scope of the invention is defined by the appended claims.
As previously described, SAP CRM and ERP are both examples of an OLTP system. SAP CRM or ERP may be used for daily online transaction processing, where sales orders may be entered. SAP APO is a logistic planning system that may be a component of SAP SCM. ATP may also be a component of SAP APO. A core interface CIF may connect the OLTP to the SAP APO and may provide functions to transfer the business data between the two types of systems. The ATP component may execute an availability check when a customer enquires about placing an order. To determine whether the product is available to promise, the availability check may take into account existing stock as well as the quantities of future incoming or outgoing orders that should be delivered by the date of the order. In illustrating a possible benefit, consider the following example. If a quantity (of stock or an incoming order) is promised to a first customer, a second customer may not be able to access their reserved quantity. If there is not enough quantity to honor a complete order as requested by the second customer, the order can either be confirmed at a later date, stay unconfirmed, or may be partially confirmed. However, if the product is available to promise, the order can be confirmed. Rules based availability (RBA) checks can be used to automatically or manually optimize the decision making process between alternative product items using predefined rules. In a sales order, RBA can cause the creation of a main item with several sub-items reflecting alternatives on a product/location level. For example, if a customer orders a yellow car, the rule may specify that he may be given a red car instead. Similarly, if the order cannot be confirmed from stock in a first manufacturing location, the rule may specify that the order is honored from stock in a second manufacturing location. In this way, global ATP may be provided to allow a switch between locations. Further, in a situation where there are several orders which cannot all be confirmed, those order which cannot be confirmed may become back orders. Back orders are sales documents whose order items cannot be completely confirmed as requested due to lack of availability or material shortages. Orders, including back orders, also may be assigned a priority rating such as a high priority order and a low priority order. If a high priority order cannot be confirmed immediately, it may become a back order. Back order processing (BOP) is a technical vehicle for dealing with back orders. BOP may be a tool of the ATP component, for example in SAP APO. Using BOP, an available quantity of one or more products may be reallocated using a quantity of selected requirements. BOP may be carried out as interactive BOP or batch BOP.
Thus, a situation may arise where there may be a plurality of backorders and an event (such as incoming goods or a cancelled order) may occur such that an incoming quantity may become available. In accordance with an embodiment of the current invention, the event may trigger a redistribution of the incoming quantity. This may be achieved using event driven quantity assignment services, wherein one or more activities, for example, changes in stock, are defined with respect to an event, as shown and described with respect to the example of
In particular, according to embodiments of the invention, event driven global available to promise services in a supply chain management system, for example, SAP SCM, may be exploited by offering techniques to release quantities to prioritized order requirements. Positive changes of ATP quantity may be registered in corresponding SAP SCM inbound interfaces. Inbound interfaces may include interfaces for stock changes, interfaces for purchase orders, and interfaces for sales orders. Using event driven global available to promise services in SAP SCM, it is possible to assign now individually defined document changes communicated to SAP SCM from an external OLTP as events which may immediately trigger the fulfillment of highly prioritized demands and/or the deployment process (e.g., for spare parts planning). Depending on the activities, for example, changes in stock data, changes in purchase order documents, changes in sales documents and back order processing, and the individually definable selection criteria, according to an embodiment of the invention, the quantity may be distributed according to the range of selected order items that have to be confirmed and their sort sequence. The order due lists deliver the information for selection and sort. If all waiting order items (backorders) are confirmed, the still available quantity may be deployed to other facilities.
Event driven global available to promise, in accordance with an embodiment of the invention, can provide a trigger via the workflow event “Quantity release to order due lists”. The confirmation process may be based on the standard mass availability check (backorder processing), but may instead use order due lists to reduce the number of selected items and accelerate the process. A parameter set finally determines if and how event driven quantity assignment will be executed. The quantity that is being distributed can also be protected by changing its category, which makes it invisible to the standard ATP check, as described and shown in
In the case where the invention can be applied in back order processing, a processor, such as a back order kernel 3, carries out the back order processing which may include carrying out an availability check including RBA. At first the process may decide which items of the back order are to be checked and in what sequence. In order to do this a filter may be defined. The filter may have a filter type which defines what criteria are used to select the items to be processed. Criteria are, for example, customer type, product/location, item type (for example, sales order). The filter also may have a filter variant which defines which values of defined criteria meet the conditions of the filter. The order items may be stored in the OLTP system. They may also be stored in SAP APO. The filtering may select items corresponding to the particular filter to the particular data base. For example, the filter type may define a parameter—customer type. The filter variant may define the parameter value—customer type—very important or medium. In this way, the filter may be defined. This filter may select only items having a very important and medium important customer. In one embodiment, the filter can be designed to define back orders.
In another embodiment, event driven quantity assignment (EDQA) back order processing including global ATP may be used as an internal tool. If several orders cannot be confirmed and a quantity is received that the system can assign, back order processing may begin. For example, if a sales order is cancelled, the released quantity can be reassigned. Such a quantity assignment is called EDQA. In addition, for an event to be the cancellation of an order, it may include incoming stock and a changed order.
EDQA and ROC use order due lists (ODL) which are described in more detail below. Order due lists may use a filter to select orders. The ODL filtering may be used if the order is saved. At the time that the order item is saved, all filters of order due lists may be scanned. If an ODL is activated, it is being filled by the system via inbound interface with corresponding OLTP documents.
In addition to those drawbacks mentioned above, in conventional back order processing systems, the system typically has to search for back ordered items. To do this, conventional systems filter the whole database to find the affected items. Consistent with an aspect of the present invention, ODLs may provide an index function, and may allow affected items to be stored immediately after being saved. In this way, affected items can be retrieved faster than in conventional systems.
The ODL may be an additional data base element with a restricted number of fields, which may perform the function of an index. It may be assigned to a process, for example, EDQA, and may perform a pre-selection. The function performed may be that of a sorter. The ODL pre-selection can be edited manually. The pre-selection may be at least one of edited, deleted or overruled. The ODLs can be used as a reference for searching items under consideration of its priority. The order types of the handled items, the criteria to filter, and to sort them can be freely configured. Filter and sorter may be defined independent from the ODL. Selection can be aborted after the number of necessary items is reached. The selection from the ODL may obey the corresponding sort profile.
The ODL may have a type which may define the nature of items that can be contained in the ODL. For example, the types “Obtain Confirmation (RCV)”, “Lose Confirmation (SPL)”, and “Free Work List (WLS)” are supported. The filter assigned to the ODL may comprise a filter type and a filter variant. The filter type may define the criteria and the variant may contain the values of the criteria to select the items. Several variants can be defined for each filter type. The sorter assigned to the ODL may contain the criteria for sorting the items. Database objects and source code may be generated out of the settings of an ODL. An ODL may comprise a database table with a specific database index and specific source code for table access. The generated database table may depend on the criteria that is used to calculate the item priority (sorter). The generated source code for selection from the ODL can be used, for example, by any SAP SCM application.
The ODLs of the type “Free Work List” may be defined without specifying a filter. The assignment of the sorter may be optional. They may be filled manually and can be used like a notepad for order items. Items can be added to this ODL in the display of the explanation component of the availability check, in the display of the backorder processing (BOP) result, or in the display of the worklist. The situations where items can be added to work list ODLs are not restricted. These work list ODLs can be used as a work list of BOP.
In conventional systems, the complete selection of affected items from several database tables and LiveCache was necessary. Sorting the items was only possible after filtering them from the database. No sort/filter based reference was available. In contrast, in accordance with embodiments of the present invention, it is possible to let the customizable filter work before storing the data in a reference table. Further, a quick item search by creating a customized database object is also possible. It is possible to allow creation of ODLs only if it is needed.
ODLs can be used at any place where pre-selected lists of orders or order items are necessary (e.g. out of performance reasons). ODLs can be used, for example, in SAP SCM during event driven quantity assignment (EDQA) and also in back order processing as a reference to items that should be confirmed, during reassignment of quantity confirmations (ROC) as a reference to items that can lose their confirmations and during backorder processing as a work list. Using ODLs, a list of items fulfilling the criteria of the filter may be selected. The ODL may provide an index in the database table, so that all data in the table can be accessed. For example, a sales order may be stored in LiveCache or 10 database tables where there are between 500 to 800 fields. ODLs may be linked to the databases where the order ID may be used as a key. Accessing the database using a key is fast, since the index may be used to pre-select very quickly. The index may be defined by customizing based on the sorter definition. In this way, the system finds all items associated with the order for BOP.
With further reference to the example of
Order due lists are herein described in further detail with reference to the exemplary embodiments of
The ODL builder data basis may comprise the following object groups: structure for definition of fields valid for all filter types and sort profiles, database tables for filter definition and generation of corresponding program code statements, database tables for sort profile definition and generation of corresponding program code statements and database table for assigning of filter/sort to ODL tables and generation/activation of the tables.
The ODL definition further includes a filter variant definition according to an embodiment of the current invention. Having chosen a filter type 32, a filter variant 40 that is valid for the filter type can be chosen. The variant may be predefined, i.e. already created and maintained. Further, the filter variant can be maintained. It is also possible to create a filter variant. The filter variant may include the filter conditions according to the filter type parameters. The filter variant 40 and the filter type 32 may build together the actual filter 32, 40. Further, a sort profile 34 can be chosen from one of the predetermined, maintained sort profiles. Within the maintenance view screen it is also possible to change ODL description, delete ODLs, generate ODLs, drop and refresh code, activate ODLs 44, activate and fill tables 46, and deactivate ODLs. As mentioned, the filter type definition and the sort profile definition can be customized. Based on the sort profile 34, a database table with appropriate database index may be generated by clicking on the generate icon 42. Based on the chosen filter 32 and program code template, a program name 50, for example, XYZ, and program code for filling the table by the ODL agent 14 may be generated. Based on the chosen sort profile 34 and program code template, a program name 50 and program code for selection from the table by EDQA may be generated. Once generated, the status 48 of the ODL may become GENERATED 52. It is noted that the ODL table, although generated, does not contain any entries at this point. Activation of a table by clicking on the activate icon 44 may immediately enable filling it by necessary and eligible index data. The function activate and fill 46 can be used for filling the table with index data of possibly already existing backorder items, which may be eligible for the table. The table (filter/sort) can be valid for greater than or equal to 1 trigger events 1. Reassigning a filter/sort may make ODL organization necessary, for example, if it is decided to use a different filter but the existing data does not meet the conditions of reorganizing. Below the ODL definition 30, a screen shot shows an example of a filter variant. The filter parameters ‘product’ and ‘source location’ are chosen and can be maintained.
The function “Range” may be standard functionality in the user interface of SAP. It means that the user can for example add a list of product names and/or a range of all products between “A” and “CCCC” and/or a pattern of a product name, for example, all products whose name starts with “A”.
The user may have two possibilities to use the chain together with the selection via the product. The basis for this functionality is always the list of products specified in the range “product”. In the following it is referred to as “specified products”.
If the indicator “consider substitutes” 130 is set, automatically all other products related to the specified one may be added to the range of products in the filter. This enhancement of the filter range may be done at any execution of the filter. The list may be based on the current information in the replacement change, but it cannot be influenced by the user.
If instead, the button “add substitutions” 132 is pressed, the actual content of the replacement chain may be read and added to the range “product” that can be seen in the screen. This is done if the user defines the filter variant. The-range may contain the actual active situation and will not reflect automatically any changes done in the future in the rules. To get an update, the filter variant of the replacement may be changed. This can be done with minimal manual effort. If the range is enhanced by the content of the related replacement chains, the user can modify the list of products. He can add or delete entries out of the list.
It is to be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design alternatives without departing from the scope of the appended claims. For example, the computational aspects described here can be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. Where appropriate, aspects of these systems and techniques can be implemented in a computer program product tangibly embodied in a machine-readable storage device for execution by a programmable processor, and method steps can be performed by a programmable processor executing a program of instructions to perform functions by operating on input data and generating output. The mere fact that certain measures are recited in mutually different claims does not indicate that a combination of these measures cannot be used to advantage.
Other embodiments of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the invention being indicated by the following claims.
Number | Date | Country | Kind |
---|---|---|---|
05077565.9 | Nov 2005 | EP | regional |