Patent Application
20070027891
In general commercial relationships, large organizations often set limits on the purchasing power of individual units within the organization. For example, a retailer may indicate to a consumer products manufacturer that its retail stores may not order certain goods from the manufacturer. Alternatively, the retailer may specify that its retail stores may only order certain goods. Sometimes the retailer may specify that any order that does not meet these specifications may not be accepted.
Consumer products manufacturers may use automated ordering systems to support their efforts. These ordering systems check newly received orders from purchasers to determine if the associated order items are allowed or prohibited. For each purchaser (e.g., retailer) or purchasing organization (e.g., retail organization), the ordering system may include “listings,” a data set that specifies the requirements all orders must meet—either by inclusion or by exclusion of specified products.
The ordering systems can be quite complex. SAP AG, for example, provides automated ordering functionality in both its ERP Sales and Distribution application (hereinafter “SD application”) and its CRM Enterprise and Mobile Client application (hereinafter “EMC application”). Each application, therefore, includes an independent listing rule set that defines, for each purchaser, requirements that the orders must meet. The listing rule sets of each application have unique formats and unique search algorithms.
For example, in SAP's SD application, the listing rule set is formatted into flat records (i.e., unitary data structures with no linkages to other data structures), so that the listing data may be directly accessed by a search in one step without further evaluation. Accordingly, every listing record is defined for only one product. Thus, if multiple products are listed for a particular purchaser, then multiple listing records are defined for the purchaser—one for each product. Additionally, any standard data element in the SD application which is pre-configured at the development level, and moreover any custom data element which is defined by the user at the application level, can be used to create such listing records (e.g., classifications such as customer sales group or sales district, customer region or country, product group, product brand). By this, listings can be flexibly created according to a customer's needs. As used herein, data elements pertain to logical units of data, whereas fields pertain to actual storage units and data items pertain to individual instances of data elements.
On the other hand, in SAP's EMC application, the listing rule set is formatted into non-flat, or relational, records so that it is possible to associate various products with various purchasers within one associated data set. Under this format, multiple products and purchasers are referenced at the same level by a header element. However, not only is this format not fitting for quick searches for allowed/prohibited products for a particular purchaser, it also only allows a pre-configured standard set of attributes to be used for defining listings, such as product, product category, product catalog, business partner, business partner hierarchy, and target group.
Accordingly, there is a need in the art for a system and method that integrates the benefits of different existing types of listing rule sets so that a consistent and efficient listing functionality may be provided over a complete system landscape.
The present invention addresses the current drawbacks in listing check functionality by implementing a data model that combines the flexibility and efficiency of a flat record model with the product bundling ability of a relational model, as illustrated in
For identifying classifications of any product associated with the listing, the other data structure may similarly include one (140) or more data elements that are pre-configured at the development level in addition to one (150) or more data elements that are defined by the application user at the application level. This other data structure may also include one (160) or more data elements identifying listing conditions for the associated product. Of course, in other embodiments the user-defined data elements and/or the listing condition data elements may reside only in one of the data structures.
If, on the other hand, the search returns one or more valid records (step 420), then for each identified record the order engine (230) follows the link (130) to search the product list contained in a different record (step 430). If no valid records are found (step 440), the order engine (230) allows the item to be purchased (step 450) because no valid listing exists identifying the item as excluded. If, on the other hand, the search returns a valid record (step 440), then the order engine (230) prohibits the purchase of the item because the item has been specifically identified as excluded (460).
If, on the other hand, the search returns one or more valid records (step 520), then for each identified record the order engine (230) follows the link (130) to search the product list contained in a different record (step 530). If no valid records are found (step 540), the order engine (230) prohibits the item from being purchased (step 550) because a valid listing of specifically allowable items exists in which the item was absent. If, on the other hand, the search returns a valid record (step 540), then the order engine (230) allows the purchase of the item because the item has been specifically identified as allowable (560).
Input device 620 may include a keyboard, mouse, pen-operated touch screen or monitor, voice-recognition device, or any other device that provides input. Output device 630 may include a monitor, printer, disk drive, speakers, or any other device that provides output.
Storage 640 may include volatile and nonvolatile data storage, including one or more electrical, magnetic or optical memories such as a RAM, cache, hard drive, CD-ROM drive, tape drive or removable storage disk. Communication device 660 may include a modem, network interface card, or any other device capable of transmitting and receiving signals over a network. The components of the computing device may be connected in any manner, such as via electrical bus or wirelessly.
Software 650, which may be stored in storage 640 and executed by processor 610, may include, for example, the application programming that embodies the functionality of the present invention (e.g., as embodied in order engine 230). Software 650 may include a combination of enterprise servers such as an application server and a database server.
Communication network 205 may include any type of interconnected communication system, which may implement any communications protocol, which may be secured by any security protocol. The corresponding network links may include telephone lines, DSL, cable networks, T1 or T3 lines, wireless network connections, or any other arrangement that implements the transmission and reception of network signals.
The computing device may implement any operating system, such as Windows or UNIX. Software 650 may be written in any programming language, such as ABAP, C, C++, Java or Visual Basic. In various embodiments, application software embodying the functionality of the present invention may be deployed on a standalone machine, in a client/server arrangement or through a Web browser as a Web-based application or Web service, for example.
Several embodiments of the invention are specifically illustrated and/or described herein. However, it will be appreciated that modifications and variations of the invention are covered by the above teachings and within the purview of the appended claims without departing from the spirit and intended scope of the invention. For example, software modules that implement the present invention such as order engine 230 may comprise several discrete modules that together still provide the same functionality, data specified in listing rule set 240 may be spread over several databases and/or systems, and the flow diagrams of
