EP1141873A1

EP1141873A1 - Methods and processes for pricing calculation using a computer system

Info

Publication number: EP1141873A1
Application number: EP00980284A
Authority: EP
Inventors: Kambi Ebrahimi; Giuseppe Pillirone; Klaus-Peter Lang
Original assignee: Quark Media House Sarl
Current assignee: Quark Media House Sarl
Priority date: 1999-11-05
Filing date: 2000-11-03
Publication date: 2001-10-10
Also published as: JP2003514306A; WO2001035293A1; AU1756801A; EP1141873A4; CA2359133A1

Abstract

Methods, processes and system for the management and calculation of pricing information of various types of product items and stock keeping units (SKUs) uses a computer system. A pricing system supports a 'real-time' behavior in pricing calculation during on-line transactions based on user defined rules and computation sequences (2). A merchant is able to define a pricing policy related to any applicable variable involved in the business transaction (5) (e.g. customer category, product type, selling season or date). The final price is calculated after a set of pricing steps starting from base prices (6) by applying discounts (7), surcharges (8), taxes and other costs.

Description

METHODS AND PROCESSES FOR PRICING CALCULATION USING A COMPUTER SYSTEM

FIELD OF THE INVENTION

5 The present invention relates to the fields of applications for the management, calculation and displaying of pricing information of various types of product items and stock keeping units (SKUs) using a computer system.

BACKGROUND OF THE INVENTION l o TERMS AND DEFINITIONS

Pricing calculation is a fundamental process for every commercial transaction. The term "price" is used in this document synonymous for the "sales price" and the "purchase price" of a generic product item. The product item is referred to as a stock keeping unit (SKU). It is to be expressly

15 understood that products, product items and SKUs encompass not only physical products but services and other intangibles as well. The methods and processes of this invention are not affected by an additional structure of the SKUs, such as a bill of material or a sales part list unless stated and referred to as structured SKU. Calculation for sales and purchase prices is similarly performed and no 0 specific distinction is required.

PRICING SYSTEMS FOR ELECTRONIC MARKETS AND CALL- CENTERS Traditional applications for determining product pricing are becoming 5 increasingly more complicated in the evolving marketplace. As more and more companies are doing business in online electronic commerce or "eCommerce" as it is commonly called, the traditional processes for determining product pricing are no longer feasible. eCommerce enables rapid change in market conditions that require rapid response to obtain market share. The instant 0 competition in eCommerce requires business models, which can react swiftly in order to obtain customer satisfaction in changing business conditions.

Presently, eCommerce transactions need to allow customers to obtain instantaneous pricing for desired products in various configurations, volumes and scenarios. Traditionally, the pricing of products for various customers and various scenarios have occurred in a manual process handled either by a customer call center or by a sales representative. This process is time- consuming and laborious process. A particular product may have different pricing depending on the particular customer, category of customer (i.e., end- user, dealer, distributor, VAR, etc.), shipping location and other conditions.

Also, different prices may need to be calculated for a particular customer based on various conditions such as quantities, shipping destinations, payment terms, etc.

One traditional pricing process includes "Back-Office" commercial transactions and commercial retail transactions, which allow the merchant to decide on the discounts, or surcharges to be applied during a specific transaction. Either the merchant has direct contact with the customer/vendor or the back-office clerk is able to follow, document and process manually given rules of pricing. This process is laborious and creates opportunities for mistakes to occur during the manual process. Also, the given rules of pricing must be manually created, updated, maintained and applied for each transaction.

Call-Center applications, which have been previously created for order capture and processing, have to minimize average call times and error rates. These can be done through a customer service representative who keys in entries based on the customer order. These applications still typically require an intermediary to process the order and apply pricing discounts and surcharges.

Front-Office applications have also been developed for eCommerce and other types of transactions. In typical eCommerce transactions, the customer interacts directly with the merchants software system. This interaction can occur through global networks, local networks, directly-linked systems, or other online systems including the Internet, intranets, extranets, portals and the like. All functions are automatically executed by a software system that applies predefined prices, price rules and pricing tables with limited dimensions for each sale or purchase. Front Office or eCommerce applications for commercial transactions require highly automated and customizable pricing systems. These applications must be able to adapt to changing business conditions and business models. METHODOLOGY REQUIREMENTS FOR A PREFERRED PRICING SYSTEM

The increase in automation for eCommerce and Front-Office application transactions necessitate that a pricing system provide greater flexibility in defining various different rules for automation. This flexibility is represented in the merchants' need to create and dynamically modify a product price e.g., according to such variables as the category of a customer or for an individual customer, the type and category of an SKU or for an individual SKU. Those variables have to be defined and combined together for the creation of a pricing rule, independent of a particular commercial transaction. For purposes of the present invention, a "pricing rule" is a single step, such as a defined base price, a discount, or a surcharge that is applied for calculating final price of a product item for a particular customer.

Automation is achieved if the pricing rule can be defined and customized to the need of the merchant. Although commonly used, a term like customer category does not have an exact definition. Therefore a preferred pricing system should use variables such as customer category, which are defined by the merchant with a variable definition system. The preferred pricing system must be able to integrate with the variable definition system. The combination of several different variables, such as customer category, country and currency, is necessary to automate where more than two dimensions are required. The prior pricing systems are unable to provide such multi-dimensional variable automation.

The prior pricing systems utilized classes of static predefined pricing rules such as a generic base price for a particular SKU. The preferred pricing system also needs to be able to provide a second class of pricing rules that allow price computations to be performed according to different variables that are instantiated at runtime during a transaction step of a commercial transaction. These variables include such conditions as the selling or purchase date/time, country of destination, taxes, currency, custom duties and other circumstances in the transaction. These variables, while instantiated at the time of the transaction, are based on static pre-defined rules.

The eCommerce customer expects a real-time and dynamic behavior of the pricing system. The present invention provides creation of pricing rules by the pricing system at runtime to allow a merchant to configure dynamic pricing for eCommerce transactions. An example of a dynamic pricing system allows the merchant to calculate a price, which is computed by using such variables as the return consignment rate or the inventory stock level of a particular SKU or a currency exchange rate at the given time of the commercial transaction.

Consequently the pricing system of the present invention creates dynamic rules, which are computed at a given time of the transaction in opposite to a static variable definition or a variable, which is simply instantiated from the particular commercial transaction. Current pricing systems do not provide such capabilities.

A preferred pricing system will allow a merchant the ability to associate different type of SKUs or categories of customers to specific pricing rules. The preferred pricing system provides the merchant with the possibility to add new pricing variables, or conditions, which can influence the final price of a product. Pricing rules can be applied permanently or temporarily depending to discount seasons, customer categories, selected SKUs, SKU availability, etc. Current pricing systems fail in satisfying these requirements and specifically they fail in providing software flexibility and ease of customization. A preferred pricing system for the eCommerce and Front-Office applications is an effective and efficient solution when it provides a merchant with:

Flexible pricing rules definition with variables Real-time pricing rule creation and application with variables Dynamic pricing rule definition with variables

Graphical user interface for the customization by the end-user, including a pricing simulator to verify designed pricing rules

Feature-set (discounts, surcharges, taxes, price lists, document and line- item level pricing computation sequences and others)

PROCESS REQUIREMENTS FOR PREFERRED PRICING SYSTEM Computation of the price, discount and surcharge are performed in multiple steps. Discounts can be applied only over parts of the base price (e.g. discounts can be applied only over base prices and not over delivery costs, taxes, etc.) and surcharges can be added after or before the discounts calculations. Shipping costs, import duties and other fees are similarly applied. Prices may be calculated either as percentages or as fixed amounts. A pricing system has to manage different results from calculation even over partial amounts. A structured SKU composed of different items can have different surcharges such as import duties or freight cost. A pricing system must be able to manage item price calculation of a structured SKU. The final price of the

SKU includes the sum of all surcharges and discounts, even though the pricing system must manage each surcharge and discount separately.

The process of defining pricing rules gains importance with the variety and complexity of pricing rules. The price rule definition process has to satisfy the role of an end-user. Access to available variables for definition and online simulation of the defined pricing rules are as important as the simplistic creation of price lists for distribution.

There is presently a need for applications that can efficiently and easily manage and calculate pricing information and which can be easily customized according to users' requirements.

CURRENT PRICING SYSTEMS

Available pricing solutions, such as the SAP R/3 (SD/Pricing), the Oracle Applications, Siebel, Vantive, Clarify and Baan systems, adopt static pricing conditions to calculate product prices. Final prices are normally pre-calculated and the flexibility is limited. Customization of the pricing conditions requires in-depth knowledge and understanding of low level implementation details such as table and field names, or communication structures. In some cases, the specification of consistency checks and constraints in pricing calculation may require some programming skills, such as, for example for the SAP R/3 system, the knowledge of the SAP programming language ABAP/4. These prior systems require extensive databases to store the pricing information and customer lists in static conditions. These systems thus are relatively laborious in retrieving the individual information for each product and customer as well as the time in updating each individual pricing and customer information.

In the typical pricing solutions, product prices are usually calculated by calculating material cost and base price and applying available discounts on it. Whereas sophisticated conditions can be defined to calculate material cost, those systems do not provide arbitrary variables and a process for an end-user to configure the pricing conditions. The logical explanation is the focus on manufacturing of existing ERP systems. The pricing conditions are supposed to derive from material cost and are static with limited flexibility. The processes of definition are designed and mostly sufficient for Back-Office operations where multiple users with different roles fulfill a task. An end-user role and process, which give easy and effective control over dynamic pricing aspects of the eCommerce software system, is not supported.

Another pricing system is disclosed in U.S. Patent No. 5,878,400, issued to Trilogy Development Group. This system uses an hierarchical organizational group and a hierarchical product group. Each level of each of the groups within a hierarchy are assigned a characteristic of that level. A price adjustment for a particular purchasing organization is determined by retrieving the price adjustment for that organization as well as the price adjustments for other organizational groups that are above that particular purchasing group in the hierarchy of that organizational group. Likewise, the price adjustment for a particular product is determined by retrieving the price adjustment for that product as well as the price adjustments for other product groups that are above the particular product in the hierarchy for that product group. These price adjustments are sorted and applied sequentially in accordance with static pricing criteria.

DEFICIENCIES OF CURRENT PRICING SYSTEMS

Available pricing systems for eCommerce fail to provide a merchant with a system able to evaluate several variables during each transaction for the final price calculation. They fail to support modification of existing pricing rules without an in-depth knowledge of the low-level implementation details of the system applied. These systems are unable to provide dynamic modification of a pricing calculation. They do not provide flexible pricing rules definition or user defined variables for pricing rules. They do not provide real time pricing calculations or simulations. They do not provide graphical user interfaces for user customization of the pricing rules, pricing sequences and pricing data. They do not provide a pricing simulator to verify designed pricing rules. These systems cannot be used for purchasing or cost accounting uses. They do not provide other desired features of a preferred pricing system. There presently is a need for such a preferred pricing system that dynamically manages product pricing in an efficient and easy to use manner and that is easily customizable to the user's needs.

SUMMARY OF THE INVENTION

The present invention accomplishes these needs and others by providing a system apparatus, methods and processes for a pricing system supporting sophisticated pricing rules and easy customization mechanisms. The present invention allows a pricing system to support a "real-time" behavior during on- line transactions, based on user-defined rules and computation sequences. A merchant can easily define a pricing policy related to any applicable variable involved in the business transaction (e.g. customer category, product type, selling season or date, etc). The final price is calculated after a set of pricing steps starting from base prices and applying discounts, surcharges, taxes and other costs. These pricing steps can include not only static conditions but dynamic conditions as well.

Processes and methods supported by the present invention are based on pricing rules. Pricing rules represent the basic components used for the calculation of prices and costs. Pricing rules correspond to various types of base prices, discounts and surcharges. A pricing rule is defined in terms of type of product, time, quantity, category of customer, etc. These are called the "attributes" of the pricing rule. Each pricing rule has associated activation expression fields, or activation fields, used to "activate" the pricing rule only when required. An activation expression field is a pricing rule attribute that shall be evaluated to check if the pricing rule is to be applied or not in a specific price calculation. Only "active" pricing rules are applicable to calculate a price in a specific transaction. For example, pricing rules with activation expression fields referring to a time period are applied over a base price only during the time period specified for that rule. Attributes of each pricing rule as defined within the present invention provide the merchant the ability to describe different pricing computation sequences composed by base prices, discounts and surcharges. Base prices are the standard prices that are specified for a product. Base prices are the starting point for every price calculation. A discount is any amount that shall be subtracted from the base price. Discounts can be specified for special seasons, category of customers, products, etc. Surcharges are all additional costs that shall be added at the discounted base price, including shipping costs, import duties, and any other additional sum. Other categories can be defined, which can be subtracted or added to the base prices, such as, for example, taxes. Taxes over sales can be managed in the present invention both as a special type of surcharges and as a separate pricing rule type.

Supported value types for pricing rules include "fixed amount" and "percentage". For example a discount can be defined as a percentage of the base price. "Scale based" pricing information, e.g. different prices related to different quantities of products sold or purchased, can be easily represented via "fixed amount" pricing rules. Activation expression fields express the dependencies of pricing rules, denoting when the pricing rules shall be applied. The present invention includes predefined activation expression fields, but new ones can be created, when a new dependency must be described. The pricing definition starts with the identification of all the necessary pricing rules to be considered in a pricing calculation, each having at least one activation expression field. For each rule, a corresponding pricing data set must be created, to specify the amount (fixed or percentage) to apply when the activation expression fields of the pricing rule are satisfied. Pricing data are instances of pricing rules defining a specific transaction. Pricing computation sequences are then defined, to describe the sequence of steps that the price calculation requires. Pricing computation sequences, or pricing sequences, are the sequences of all steps to be applied for the calculation of the final price for a product item or SKU. Pricing rules compose pricing computation sequences. Starting from the base price, several discounts and surcharges can be applied according to related activation expression fields, even over partial amount. The application of several pricing rules over a base price consists in a pricing computation sequence. The final price is the result of the execution of all the "active" pricing rules included within a pricing computation sequence.

In the present system, all value instances or "pricing data" for each pricing rule are stored within pricing tables, which compose the system pricing database. Instances in the pricing table can be displayed to the user in pricing grids. Instances stored in pricing tables can be extracted by selecting the related attributes (e.g. name of the customer, product type, price amount, etc.). The lists of pricing data displayed in the pricing grids are called price lists. Each product item, pricing rule and pricing sequence can be displayed, added, modified and deleted by means of a graphical user interface supporting customization of each component. Users can directly and easily complete customization of each pricing component. The present invention provides the user with a set of flexible pricing processes for adding, modifying, deleting and displaying each pricing element. A merchant can easily change each pricing element included in the pricing system. These and other features are set forth in the detailed description of a preferred embodiment of this invention and in the related drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 is the general schema of the method applied in the present invention for calculating pricing information. Figure 2 is the display pricing grid. Figure 3 is the dialog window used to define a set of activation expression fields for a pricing rule.

Figure 4 is the dialog showing a pricing computation sequence. Figure 5 is the dialog used to add existing pricing rules in a pricing computation sequence. Figure 6 is the dialog used to create new pricing rules to be added within a pricing computation sequence.

Figure 7 is the dialog to add new groups of pricing rules. Figure 8 illustrates the dialog window used to display a pricing table. Figure 9 is the price list selection screen. Figure 10 is the properties dialog for a price list.

Figure 1 1 depicts the default values for pricing data. Figure 12 is the process flow for creating pricing rales. Figure 13 is the process flow for creating pricing computation sequences. Figure 14 is the process flow for the line item pricing calculation. Figure 15 is the process flow for a document pricing calculation.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT

SYSTEM OVERVIEW

The present invention includes a software system, methods and processes for the calculation, managing and displaying of pricing information related to product items or stock keeping units (SKUs). It is to be expressly understood that product items or SKUs include not only physical products but services and other intangible items as well. Described processes and techniques can be applied in several systems where pricing information and calculation are required, such as electronic commerce solutions, back-office/front-office applications and ERP systems in general.

It is to be expressly understood that the exemplary description that is discussed herein is for descriptive purposes only and is not meant to limit the scope of the inventive concept. Other implementations of the inventive concept are considered to be within the scope of the appended claims.

Within the present invention, the term "pricing" is used to mean any specific action or combinations of specific actions related to the calculation of the purchase and sale price for a product. Pricing includes, for example, application of discounts, tax calculation and determination of surcharges. Pricing is further used to identify when a specific calculation or "rule" (e.g. concerning a special discount, etc.) shall be applied and to which category of customers or individual customer. Each of these issues can be easily and automatically performed by the present invention. One objective of the present invention is to allow a merchant to define pricing rules without being forced to follow any system pre-defined schema. The present invention provides real-time calculation of pricing information, including determination of the "best price" for the customer and for the merchant and the "final price" for a product in a specific transaction. The dynamic management of pricing calculations in an effective and efficient manner can optimize the marginal return for a company and increase its sale revenue and/or profits. The present invention can reduce delays and efforts in calculation of a product price, its modification and any application of discounts and surcharges. Pricing information is handled by the present invention by the following pricing processes: a) Processes for creating, modifying or deleting pricing rules and pricing data; b) Processes for defining pricing computation sequences used to create and apply pricing rules; c) Processes for creating and applying pricing information including simulation of pricing computation sequences; d) Processes used to display a pricing item and the result of the price calculation after discounts and surcharges.

PRICING PROCESSES

Pricing processes adopted in the present invention consist of software structures used to estimate pricing items. A pricing item is any data related to a product or SKU price including: a price value, a discount percentage, a surcharge amount, etc. They are applied to create pricing for a product or SKU both during selling or purchasing, but can also be applied for accounting purposes. Pricing processes are applied within the present invention for performing several actions to create prices. During sales order entry, the system automatically determines pricing for a sales order by taking into account all the relevant information: the base price for a particular customer, whether special discounts or surcharges can be applied, and if the customer is liable for freight charges, and sales taxes. Likewise, if a merchant or other user is using the present invention for purchasing, the system can take information from various sources, such as the vendor and purchasing organization, and then calculate pricing for a specific purchase order. Furthermore, when the invention is used for cost accounting, pricing can be used to calculate the costs of an internal order.

Pricing processes are composed by three main elements: (1) pricing rules, (2) pricing computation sequences, and (3) pricing data, as depicted in Fig. 1. "Pricing computation sequences" 2 are used to perform price calculation, where "pricing rules" 1 represent base prices, discounts, surcharges or subtotals composing a pricing computation sequence. "Pricing data" 3 are pricing items (e.g. a price value, a discount percentage, a surcharge amount, etc.) which are stored in the pricing database. Pricing data, along with attributes such as customer categories, time of year, shipping destinations, etc, are used to compose pricing rales.

A pricing calculation always starts with a pricing request (FIG. 1). A pricing request 4 is a request for a pricing calculation. A pricing request comes from a customer or from the merchant or can be automatically generated by the pricing system when a price shall be calculated, e.g. to display a line item price in a pricing document 5. The pricing document is any document requiring a price calculation (e.g. a purchase order, a sale order, etc.). A pricing document can include several line items, each of them requiring a sub-calculation. The pricing request can refer to a specific product, an SKU or any single pricing line item, such as each single discount or tax calculation. When a pricing request is established, specific pricing rules 1 for that item are called. Pricing rules include base prices 6, discounts 7, surcharges 8 and attributes applicable on that item. Each pricing rule has an associated activation expression field 9. Activation expression fields are used to select pricing rules required in a pricing calculation. Pricing rules are applied to calculate the price for the line item according to pre-defined pricing computation sequences 2. The pricing computation sequences are used to calculate the line item and document price by applying the pricing rules specified for that item and the related values of the pricing rules stored in the pricing data. In a preferred embodiment of the present invention, the pricing computation sequence consists in selecting the base price and by applying discounts and surcharges on it. A pricing rule is evaluated in the pricing computation sequence only if the associated activation expression fields are satisfied (e.g. if the time period when the pricing computation sequence is started is the same as specified in the activation expression field).

The result of the pricing computation sequence is the price for a single line item 11 or the final price of the pricing document.

PRICING DATA

The pricing data are inputted by the user through the use of a graphical user interface, such as the pricing grid shown in FIG. 2. For example, menu item "pricing" is selected on the dialog box shown in FIG. 2 which then displays the Pricing Grid 12. A base price for a product item is defined using the pricing grid (FIG. 2). In the pricing grid 12, users can add information concerning a SKU item, including the item code 13, the item name 14, the country code and the price for the country 15. To create a new item, users can select the "New item price" command in the main menu and a new empty row is created in the pricing grid. Each section of the grid can be edited. For example, the user can define which columns to be displayed in the pricing grid. Discounts and surcharges can also be defined or edited in a similar manner by selecting the appropriate menu item in the dialog box shown in FIG. 2.

PRICING RULES

The main goal of a "pricing rule" is the definition of a calculation step for a pricing computation sequence. This is required, for example, when a sales department wants to determine the net value of a specific sales order, that is the final price after all discounts, freight charges and cash discounts. Another example occurs when the purchasing department wants to know the effective final price of a purchase order. Yet another example is when the cost accounting department wants to know the final manufacturing cost of an internal order, corresponding to the final cost after all the basic costs and overhead costs are taken into account. Examples of pricing rales of a preferred embodiment of the present invention include:

A merchant offers its customers a discount whenever they buy certain quantities of one of the company's products. The company defines a pricing rule for item discounts. The pricing rule specifies, for example, that the discount is dependent on quantity. - A merchant sells their products in multiple countries and wants to have different prices for the different countries. The company defines a pricing rule for these country-related prices. The pricing rule specifies that the price is dependent on the country.

A merchant offers a discount when certain combinations of products are purchased in order to move slow inventory. The merchant defines a pricing rule that specifies the combinations of products, quantities of the products and the discount to be applied.

Each pricing rule is composed by a set of attributes denoting a specific business transaction. For example, when a particular customer orders a certain quantity of a product on a certain date, the final price that the customer gets depends on some variable factors, such as "customer", "product", "ordered quantity" and "date". In order to specify a final cost, the system shall provide the functionality of defining pricing rales depending on any business circumstances taking place in a commercial transaction.

Pricing rules can be defined for each possible pricing type to be considered: base prices, discounts, surcharges, taxes, etc. Discounts and surcharges can be either fixed monetary amounts, or percentage amounts. Discounts always express positive amounts to be subtracted from the base price. Surcharges always express positive amounts, such as shipping costs, to be added. All instances of these pricing categories are stored as pricing data.

Each pricing rule has an associated set of fields or attributes that the system uses to identify pricing data and define business circumstances. Attributes associated to a pricing rule identify all properties of that pricing rule. Examples of pricing rule attributes are the pricing rule types (e.g., if a pricing rule is a "base price", a "discount" or a "surcharge") and the calculation type (e.g., if the discount or the surcharge shall be calculated as a "fixed amount" or a "percentage") or the "price value" itself. New attributes such as "manually changeable" can be assigned to pricing rules. To identify when a given pricing rule is relevant, a set of "pricing fields", or "activation expression fields", is attached to each rule. These fields are a subset of the pricing attributes. The activation expression fields describe the variable factors upon which the application of a pricing element is based given a specific business transaction. These fields may refer to any attribute of the pricing rule, such as time, customer type, quantity, etc. The activation expression fields compose the activation expression.

The present invention supports the definition of separate pricing rules for computing the value of both single sales document line items and for the computation of sales document's total value. The determination of the value of a specific item or of a document's total value is similarly performed by the application of pricing rules. The application of pricing rules depends on the activation expression fields defined for a specific pricing rule.

The values for each rule are contained in "pricing data", that are instances of pricing rules. A set of pricing data composes price lists that can be displayed to the user. Pricing data may exist for some values of the activation expression fields but not necessarily for all. For example, if the prices of some products must be defined in a price list by country, a rule type whose activation expression field is "country/product" can be defined, and pricing data must be created for each country and product that must be in that price list. Each pricing data gives the amount of the field for one particular instance of the variable factors (for example, for a specific product in a specific country). This instance is identified by the value of the activation expression field. A validity period may be defined for each pricing data, so that pricing data is used only for the specified time. For example, a company can define prices of its products by country, and discounts that are applied for some specific qualified customers only in some specific seasons. To do that, two pricing rules are defined: one of type "base price" having the "country" and the "product item" as activation expression fields, and one of type "discount" having the "customer category" and "validity date" as activation expression fields. The pricing computation sequence will contain the sequence: start with "price", then apply "discount". Pricing data for the "price" rule will be created for each product in each country; records for "discount" will be created for the customer deserving the discount (and not for any other customer), and each record will give the amount of the discount for one specific customer. The validity date of the pricing data controls the time interval when the discount has to be applied.

The present invention supports multiple price, discount and surcharge rules. Each rule contains an activation expression composed by activation expression fields. The activation expression of a pricing rule is a Boolean expression that is build up of one or more comparison operations that finally evaluate to TRUE or FALSE. If the activation expression is evaluated during runtime as TRUE, the pricing rule will become part of the pricing computation sequence that performs the real price calculation. Besides the activation expression, a rule also has a set of other attributes that describe the action that should be taken when the activation expression evaluates to TRUE.

In the present invention, an activation expression for a pricing rule is a set of attributes provided by the system. The set of attributes available in the system includes: 1. Customer; 2. Product Item;

3. Sales document;

4. Contract;

5. Relations defined for objects ( 1 ), (2), (3) and (4); 6. Characteristic attributes defined for objects (1), (2), (3) and (4);

7. Customer history values (for example total amount ordered in the year).

Other attributes can be added. Each attribute of a pricing rule can be specified as activation expression field of that pricing rule. For example a special discount can be activated only if the customer has already bought a certain quantity of products from that merchant, etc. The activation expression is a Boolean expression that shall be evaluated to determine whether a pricing rule should be applied or not. This Boolean expression can use business objects and their attributes in order to make rules dependent on their state. Activation expression fields are defined as the items of the activation expression that refer to the attributes of the business objects, describing the criteria when the pricing rule is applicable. All activation expression fields of a pricing rule need to be specified in the pricing data to evaluate the activation expression. Within the present invention, a generic pricing rule is defined by using the following fields within the system database: ID This ID is the internal ID of the pricing rule. It is not showed to the user. The system will ensure the uniqueness of this attribute.

External ID This ID is shown to and can be set by the user. The system only checks the uniqueness and rejects the changes if necessary. The system also provides the possibility to generate this ID automatically. Description A multilingual description of the pricing rules like e.g.

"Base Price dependent on Customer Category" or "Season Discount". Activation Expression Activation Expressions are Boolean expressions used for evaluating the related pricing rules in order to find the relevant pricing data for the calculation. Rule Type Rule Type is one of the following flag: (1) Price, (2)

Discount, and (3) Surcharge. Computation Type Computation Type can be Fixed or Percentage.

Rules can be "always active", when they are applied independently of any runtime value. Pricing rules may further depend on multiple sales document line items (for example to detect items of the same item group in different lines of an order). Users can associate activation expression fields to pricing rules using the dialog depicted in FIG. 3. A list of attributes 16 is listed in the left side of the dialog. Each attribute can be added 17 as activation expression field 18 for a pricing rule. The following base pricing rules are included in the present system (other pricing rules can be defined by the merchant) using the above dialog: - Standard price (activation expression field: item id);

Price by catalog (activation expression fields: catalog number and item id);

Price by country (activation expression fields: customer's country and item id); - Customer discount (activation expression field: customer number);

Sales taxes (activation expression fields: merchant's country, customer's country and item id);

Base surcharges (activation expression field: item quantity).

Several processes are applied within the system to manage pricing rules by a graphical interface. Some of them allow the user to perform the following actions:

Processes to create new pricing rules;

Processes to display and modify existing pricing rules;

Processes to discontinue pricing rules. The process to create pricing rules is presented in Fig. 12. The following functions are applied to define a pricing rule:

Select a name for the pricing rule. A pricing rule is identified by a name selected by the user.

Select the type of the pricing rule. The pricing rule can be a base price, a discount, a surcharge or a tax. The user can add other pricing rule types.

Select attributes of the pricing rule as activation expression fields. To make a pricing rule active, users shall select activation expression fields to be applied in a pricing rule among those available in the system. Pricing attributes can be "time", "country", "customer category", etc. Select pricing rule list. When a pricing rule schema is created users shall select the pricing list to add all details related to the pricing rule (e.g. country codes, customer categories, etc.).

Add values and amounts for the activation expression fields. For each pricing rule users can create pricing data including information to be used in specific transactions. For example, if a pricing rule with "product" and

"country" as activation expression fields is created, users can add pricing information according to different countries. Each single information, e.g. the price of the "product" for "country"=US, the price of the "product" for "country"=DE, is stored in the database as a pricing data.

Pricing rules can only be modified before pricing data are entered in the price lists. Discontinuing a pricing rale causes all the associated price lists to be discontinued. Price lists and pricing data are displayed together in the pricing grid.

PRICING COMPUTATION SEQUENCES

The pricing computation sequences identify the pricing rules (prices, discounts, and surcharges) that must be applied to calculate the final value of an item. For example, the sequence may be a base price to which a chain of discounts is applied, and then some surcharges are charged on the resulting amount. Each step of a pricing computation sequence is composed by a "pricing rule". A pricing computation sequence, or pricing sequence, can be considered as a list of pricing rales and groups of pricing rules, defined in a particular sequence. Pricing computation sequences describe the way in which several pricing rales shall be combined to determine the final price of an item in a business transaction. A pricing computation sequence enables the system to determine which particular set of pricing rules, and in which sequence, shall be apply in given circumstances. An example of pricing computation sequence is when a merchant wants to define a procedure that determines how prices, discounts, and surcharges appear in sales orders and invoices. In a typical situation, the first pricing rule in the sequence determines the base price. Following rules determine the applicable discounts. Finally, there are rules that determine freight costs and other possible surcharges. Since some pricing rules are related to a specific value (e.g. pricing rales with "percentage" as Computation Type), the pricing computation sequence shall receive the base value for computing the pricing rules. This base value is specified by assigning to the relative step a reference to a previous step of the pricing computation sequence, assuming that a "current subtotal" is defined at each step of the sequence. As for pricing rules, pricing computation sequence can be defined for a single line item or for the whole pricing document.

Within the present invention, pricing computation sequences have three main computation stages. A sample of pricing computation sequence is depicted in Fig. 4. The first stage of the sequence 19 determines the base price 20. The second stage applies discounts 21. The third stage applies surcharges 22. Each stage consists of a group of pricing rules of the same type (price, discount or surcharge), and can have subgroups inside. At the document level sequence, the base price determination stage 20 consists of the sum of the line item values of an order document. The surcharge stage 22 can be executed before the discount stage 21, but the price determination stage 20 must always be executed first. The system supports multiple pricing computation sequences, both for line item and for document, meaning that each item type and order type can be bound to a different pricing computation sequence. A computation step within the context of pricing computation sequences is the smallest executable unit of the price calculation, similar to a command in a batch programming language. The sets of available price calculation "commands" are the pricing rules. Therefore a step is a reference to the pricing rule that should be executed. But in opposite to a command in a programming language, the pricing rule contains not only the command to execute, it also includes the circumstances when to be executed, i.e. the activation expression fields.

A group in a pricing computation sequence is a collection of steps that logically belong together. Every group and step in a pricing computation sequence has a calculation basis, which is a reference to the interim result of the price calculation process that corresponds to the basis for the current computation. When users do not specify a calculation basis, the result of the last computation step is applied as the input for the next step. But users can also define a step or a group of the pricing computation sequence as calculation basis and then the result of this step or group will be the input for the next computation step.

The order of steps in a pricing computation sequence is important for the result. Each step in a pricing computation sequence is linked to other steps by a group of operands: AND, XOR, MIN, MAX. These operands are defined on group level and affect all steps defined with the group. These operands are defined as follows:

AND All steps within the group will be evaluated and executed.

XOR All steps within the group will be evaluated but only the first step that becomes active will be executed.

MIN All steps within the group will be evaluated and executed, but they all use the same calculation basis, namely the calculation basis of the group they belong to. Only the lowest result will become the calculation basis for the next computation step. MAX All steps within the group will be evaluated and executed, but they all use the same calculation basis, namely the calculation basis of the group they belong to. Only the highest result will become the calculation basis for the next computation step. Pricing computation sequences can be managed by the present invention by means of the following processes:

Processes to create new pricing computation sequences (possibly as copy of existing pricing computation sequences);

Processes to modify existing pricing computation sequences (sequence of the steps, add/remove steps, modify attributes of the steps, triggering item- or document-type);

Processes to discontinue pricing computation sequences; Processes to display pricing computation sequences. When pricing computation sequences are modified, old versions and their range of validity are stored in the system, in order to allow a view on pricing computation sequences from different points in time. Details of the changes can be displayed, and particularly when the pricing computation sequence was changed, what was changed and who changed it. The change history can be displayed as well. All previous versions of pricing computation sequences can be archived or deleted. The application of a pricing computation sequence depends on the date of the sales document being priced. When applicable, it is possible to decide whether the latest version of a pricing computation sequence or a relevant discontinued version must be applied. A step in the pricing computation sequence can specify that one rule out of a group of rules must be applied. The selection within the group depends on a selection criteria (minimum, maximum, first applicable, etc.). The system allows the definition of what action must be taken during price determination when a step of the pricing sequence is undefined (i.e. no pricing data is found for the rale of the step, or group of rales). Possible actions are "no action", when a step is "optional" or "raise error" when a step is "mandatory".

During sales or purchase order entry (or in any other case when the pricing needs to be carried out) the system determines, according to the order

(or transaction) type, which pricing computation sequence must be applied. For each step in the sequence, the system selects all the active pricing rules among those having the activation expression fields that match the corresponding values in the fields of the order (or other sales document being priced). The pricing data of the active pricing rule is used as the value for that step. In this way, at each step of the pricing computation sequence, a subtotal is defined, as the value of the computation up to that step. The application of all the steps gives the final price for the pricing computation sequence. When a rule is defined as "manually changeable", the amount can be modified during order processing. The manual value is applied to the order line only, but it does not affect the value of the pricing data stored in the pricing database. To create a pricing computation sequence within the system, the following processes are applied:

Select the "new pricing computation sequence" command in the main menu. This selection display a dialog, where the sequence can be added (FIG. 4); - Select the "Add rule" button 23. This selection opens the Add Rule dialog

(FIG. 5). In the Add Rule dialog, a user can select to add an existing pricing rule, that is those pricing rules available in the system, or to add a new pricing rule. Existing pricing rules are divided in three categories: "Prices" 24, "Discounts" 25 and "Surcharges" 26. Other user-defined categories can be included when required.

Add an existing pricing rule. An existing pricing rule is included in the pricing computation sequence by selecting the pricing rule in the Add Rule dialog and by confirming the selection. A new pricing rale is defined by selecting the Create New tab 27 in the Add Rule dialog.

Create and add a new pricing rule. To create a new pricing rale, users shall select the Create New tab in the Add Rule dialog. In the "Create

New" tab (FIG. 6) users shall define the name of the new pricing rule 28, the type of the new pricing rale 29, i.e. if it is a price, a discount or a surcharge, and the attributes 30 that activate the pricing rule. By confirming it, the new pricing rule is added in the pricing computation sequence and in the list of the existing pricing rales.

In a pricing computation sequence, groups can be defined as a step that involves more than one pricing rule. Groups are added by selecting the pricing rules involved and by clicking on the Add Group button in the main dialog

(FIG. 4). The Add Group dialog (FIG. 7) is used to identify the rule to be applied over the selected pricing rules 31, if a result from the group is mandatory 32 and the action to be taken when an error is encountered 33. For each step a pricing rule shall be selected among existing ones, or a new pricing rule shall be created.

Within the present invention, users can define several pricing computation sequences. A pricing computation sequence can be defined accordingly to the transaction type (for example if it is a sales order, and which type of order) and from some master data (for example, if the customer belongs to a special category). A set of pricing computation sequences is built in the default system. These built-in pricing computation sequences implement the price determination strategies that are supposed to be used most commonly among different companies. The simplest item pricing computation sequence calculates the value of the sales document line as the standard price of the item in the line.

The simplest document pricing computation sequence computes the sales document value as the sum of the values of the lines in a document, e.g. a purchase order. The process applied for line item pricing calculation is presented in Fig.

14. The process for the calculation of a pricing document is presented in Fig.

15. The process for the calculation of a pricing document performs a pricing calculation over each line item. When it gets a subtotal for all the line items, further document-level discounts or surcharges (e.g. delivery costs) can be applied for the calculation of the final document price. The processes for the line item pricing calculation can be described as follows:

Select the pricing computation sequence. The sequence to be applied into a specific transaction is selected according to information included in the line item. The pricing computation sequence is required to calculate the value of a single line item available in a pricing document. Compute each step in the pricing computation sequence (single pricing rule). If a step is a single pricing rule, the activation expression fields of the pricing rale are checked and, if satisfied, the pricing rule is instantiated by collecting details from the pricing database. The result is then added to the previous and passed to the following step as subtotal. Compute each step in the pricing computation sequence (group of pricing rules). If a step is a group of pricing rules, each pricing rules is calculated as for single steps, then all steps are elaborated according to the definition of the group (minimum, maximum, first applicable, etc.). The result is then added to the previous step and passed to the following one as subtotal.

Each computed step is checked if defined as mandatory or not. If a check is mandatory, but no result is available, the pricing computation sequence is terminated. Otherwise the next step is calculated.

When all steps are calculated, the result of the computation is assigned to the pricing document as the result of the line item.

Each line item is then calculated according to the previous steps, until the computation of all the line items available in the pricing document. For accounting, it can be needed to have document-level discounts applied at a line item level. Re-computing each line item price after having reached the document final value can do this. The document final discounts and surcharges are so allocated over line items according to user's selection. In FIG. 4 a sample description of a line item pricing computation sequence is presented. PRICING DATA AND PRICE LISTS

Pricing data are used to store all specific pricing values that users enter into the system. For example, in pricing, when users enter the price for a product or a special discount for a special customer, the system creates individual pricing data. Pricing data are used to store price values. Pricing data are instances of pricing rules. Given a specific transaction, only a single pricing data can satisfy it. A consistency check in the pricing database is executed every time a new pricing data is added. Pricing data are displayed in pricing tables (Fig. 8). A pricing table 34 defines the combination of fields 35 that identifies an individual pricing data 36. Every pricing rule has exactly one pricing table where all pricing data defined for that pricing rule are stored.

An example of a Pricing Table can be used to define prices according to customer categories. The present invention allows the creating of specific pricing table based on customer categories. This table may include the following fields: Customer_Category, Product ltem, Price Value and Validity_Period. The first two fields of the table identify the activation expression fields used to make the pricing rule available in a pricing computation sequence. "Price_Value" contains the price applied to a specific customer category. The "Validity_Period" field fixes a period - if required - when the customer-based price can be applied.

A "price list" is a subset of the pricing data of a specific pricing table. The subset is defined by the filter condition of the price list. The filter condition identifies the criteria used to select pricing data in a price list. A price list without a filter condition contains all records of a pricing table. Price lists are used for simplifying the creation or modification of pricing data. They enable a centralized definition of the validity range, the default values, and a set of layout settings for the system interface. An example of price lists can be as follows: a merchant defines a pricing rule for country dependent sales prices. The pricing table of this rule contains all pricing data for all countries. When changing prices, you just want to see the prices for one country, so you create a price list that filters all records for that country. For example a US price list that contains only sales prices for the US. In order to simplify the price maintenance, you also define the default value 'US' for the country field. So when someone adds a new price to this price list, the system automatically sets the correct country. The price list type is inherited by the pricing rale the list depends on. Therefore we have just the same price list types like pricing rule types, namely prices, discounts, and surcharges. Each price list further includes a view of price values, custom-id, product-id, purchase date, quantity for each single purchase of a given product item.

The process for creating a new price list is based on pricing rules. After the determination of the pricing rule, the other properties of the price list will be set (e.g. validity, default values, and filter conditions). When the creation of a new price list is finished, the pricing data can be entered. The process applied to create a price list is the following:

Select a pricing rule as basis for the new price list: normally this process gets the pricing rule for the new price list as input from the calling process. However, the based-on pricing rule can be changed during the process execution time.

Modify the activation expression fields: This function allows changing the activation expression fields during process execution time. So the operator is not restricted on existing pricing rules. He can also create new pricing rules during the creation of a price list. The component has to check, whether a pricing rule with the same activation expression fields already exists and reuse this rule instead of creating a new one. The modification of the activation expression fields can be done in two ways. One is changing the activation expression fields with the expression builder (FIG. 3). The other way is, adding, changing or removing columns to the price list.

Create new empty price list for the specified rule: then the based-on pricing rule is specified, either it's a new rule or an existing, the new price list can be created. - Define properties of the new price list: these are mainly the name, the description and the validity range of the price list.

Define the default values for the pricing data: When creating a new pricing data, any field of that record can have its own default value. And their default values can be different for every price list. For example, let us consider having a pricing rule dependent on item number and customer country. For this pricing rale we have two price lists defined. One is "Prices for US" the other is "Prices for Germany". In the US price list, the country has the default value US and in the Germany price list, the default value of country is DE.

Define the filter conditions: Without a filter condition, a price list will show all pricing data of the based on pricing rule. But most often, multiple price lists that base on the same pricing rule but contain a different set of records are required. To display an available price list, the "Display Price Lists and Pricing data" process is applied. This process fetches the data from the price list component and all pricing data that belong to the price list and displays them in a grid. The process applied to display a price list is the following:

Load all price list headers and fill the price list selection control: this function fetches name and activation expression fields of all price lists stored in the system.

Load properties of the price list to be displayed: Load the data about structure, validity, based on pricing rule, default settings, and filter conditions of the current price list. - Build query based on the pricing rule and filter conditions: Take the information about the structure of the pricing data and the filter conditions and create a query command out of it. The structure of the pricing data can be derived from the pricing rale on which the price list is based on. Execute query and fetch the pricing data: Executes the newly generated query and fetches pricing data, which are the result of the query.

Setup the display of the grid based on the metadata of the price list: The information about the columns of the grid and their labels are taken from the structure of the pricing data. This information can be derived from the pricing rule on which the current price list is based on. - Check if there are user preferences available for the current price list.

Some grid settings are controlled by user preferences, like e.g. the sequence of the columns, the display width of the columns, the size of the grid, the column to be displayed or to hide, etc. Load and apply the user preferences for the settings of the current price list: when there are user preferences available, than this function loads these preferences and adapts the grid display.

These and other features in the descriptive embodiment set forth above are considered within the inventions as claimed. The above descriptive embodiments were set forth for explanatory purposes and are not meant to unduly limit the claimed inventions. Other embodiments and variations of the inventive concept are considered to be within the claimed inventions.

AN EXAMPLE OF APPLICATION OF PRICING RULES AND PRICING COMPUTATION SEQUENCES

To explain the preferred embodiment of the present invention, a simple example of its implementation for a generic company is presented. To implement this type of pricing with the proposed pricing schema, four pricing rules would be needed: two for products (full products and upgrades), and two for discounts (upgrades quantity and payment terms). Price lists can be accessed by country, customer group, product classification (full products and upgrades must be distinguished) and product number. In the case of the price list for upgrades, also the product being upgraded is part of the access key, since the price depends on that. The example lists part of the key values and records that a real system would store. To define the scale-based values, three scale-tables are created. Two different scales are applied to different customer groups in the full products price list. Another scale is for upgrade discounts. The pricing rules available in the example refer to different pricing policy.

Each pricing rule includes a list of keys, or activation expression fields, that shall be evaluated during the pricing evaluation.

Within the system database, instances are available for each key. These instances describe the product items available for each customer. SP40, for example, denotes a generic software product, version 4.0 and HP is a generic hardware product.

Each product item has associated a price amount in the database. For example, the Upgrade from SP30 to SP40 (Access ID KD2001 1) costs 65 DEM.

Scales and Scale Details define discounts for item quantity. The amount for each item is calculated according to the ordered quantity.

A pricing computation sequence is defined as a set of steps to be taken in order to calculate the final price. Not all steps shall be calculated, according to the pricing computation sequence.

Now, let us suppose that an order is posted for a German customer belonging to customer group "GR02". The order is of a type having pricing computation sequence Ql, and "Advanced" payment is specified. The order line items are the following:

The pricing computation sequence will work in the following way for each order line item. Line nr 1

In Step 10, no matching was found since the request was an upgrading. The pricing computation sequence is so continuing with the other steps in the group. Step 30 is "mandatory" and it is fulfilled: at least one pricing rule is satisfied in the group. Steps 40 and 50 are both discounts that have Step 30 as basic value. Then the second order line item is evaluated.

Line nr 2

The pricing computation sequence stops in line item 2 since the mandatory step is not fulfilled: no HP product is available for the customer group GR02. The order cannot be completed. The present invention provides a pricing simulator to reproduce a possible runtime situation and check how a pricing computation sequence would determine a price. The simulator asks the user to specify a value for each attribute that can influence the pricing determination in that pricing sequence then runs the computation and shows all intermediate results and subtotals. The pricing simulator can be invoked during editing of the pricing computation sequence.

The main control of the price list component is a grid containing all the pricing data that are defined for the pricing rule on which the current price list is based (FIG. 8). Most of the functions should be reachable by a context menu that pops up when clicking in the grid header. For selecting a price list the UI offers a list screen containing all price lists of the same type, e.g. discounts

(FIG. 9). This screen is also used for displaying the name 37 of the currently selected price list. Every price list has a set of properties that define its structure and behavior. In order to display and change them, the price list component offers an appropriate dialog (FIG.10). Users are able to change the name 38, the validity range 39, the default values 40 and the filter conditions 41. Default values can be changed using he appropriate dialog presented in FIG. 1 1. The Default dialog collects all attributes available in the pricing list, such as the "Country Code" 42, allowing users to select a default value for any new pricing data created for that pricing list. The above description of an example of application of pricing rules, pricing data and pricing computation sequence in the present invention has been presented for the puφoses of illustration and description only. It is not intended to be exhaustive or to limit the invention to the precise form disclosed. This invention is to be limited only by the following claims, which include all such embodiments when viewed in conjunction with the above specification and accompanying drawings.

PREFERRED HARDWARE/SOFTWARE EMBODIMENT

Next, preferred implementation details of the present invention are described. In the preferred embodiment described herein, the present invention is configured as follows: a NT platform with a minimum of 128 MB free RAM, minimum processor speed: Pentium 266, supporting Windows NT 4.x or later.

The above description of a preferred hardware/software embodiment of the present invention has been presented for the puφoses of illustration and description only. It is not intended to be exhaustive or to limit the invention to the precise form disclosed. This invention is to be limited only by the following claims, which include all such embodiments when viewed in conjunction with the above specification and accompanying drawings.

Claims

CLAIMSWhat is claimed is:

1. A method for calculating and managing pricing information related to various types of products, comprising the steps of: providing processes for the calculation of a product price by: providing pricing attributes for the definition of pricing rales; providing pricing rales for the price calculation; selecting activation expression fields among pricing attributes used to activate pricing rules; selecting pricing rules to be applied for the calculation of product prices; applying pricing computation sequences as a composition of active pricing rales to calculate a product price; displaying pricing information in a grid table by listing all pricing attributes selected as activation expression fields; elaborating pricing information in grid tables including the pricing attributes selected as activation expression fields by: adding new pricing items in the price list by including pricing details for each item; modifying existing pricing items in the current price list; deleting existing pricing items in the current price list.

2. The method of claim 1 wherein the step of providing pricing rules for the price calculation, further includes the steps of: describing a product item with pricing attributes including the base price; describing discounts for the price calculation of a product item; describing surcharges for the price calculation of a product item.

3. The method of claim 1 wherein the step of selecting activation expression fields among pricing attributes used to activate pricing rules, further includes the steps of: selecting pricing attributes available in each product item; specifying one or more of the pricing attributes as activation expression fields related to a pricing rale.

4. The method of claim 1 wherein the step of selecting pricing rules to be applied for the calculation of product prices, further includes the steps of: selecting a base price for the calculation; selecting discount rules to be applied to the base price; selecting surcharge rules to be applied to the discounted base price.

5. The method of claim 1 wherein the step of applying pricing computation sequences as a composition of active pricing rules to calculate a product price, further includes the steps of: applying pricing rules to calculate the value of a computation step in the pricing computation sequence; applying groups of pricing rules to calculate the value of a computation step in the pricing computation sequence; applying pricing computation sequences to calculate the total value of a line item in a pricing document; applying pricing computation sequences to calculate the total value of a pricing document and to allocate document level pricing results to each line item.

6. The method of claim 5 wherein the step of applying pricing rules to calculate the value of a computation step in the pricing computation sequence, further includes the step of: selecting available pricing rules to be applied in a pricing computation sequence.

7. The method of claim 5 wherein the step of applying pricing rules to calculate the value of a computation step in the pricing computation sequence, further includes the step of: creating new pricing rules to be applied in a pricing computation sequence.

8. The method of claim 5 wherein the step of applying groups of pricing rules to calculate the value of a computation step in the pricing computation sequence, further includes the step of: relating pricing rules or groups of pricing rules of the pricing computation sequence by a set of Boolean operands.

9. The method of claim 1 wherein the step of displaying pricing information in a grid table by listing all pricing attributes selected as activation expression fields, further includes the steps of: applying a filter condition to the pricing details included in the price list; displaying the subset of the pricing data of a specific pricing table which satisfies the applied filter condition.

10. The method of claim 1 wherein the step of adding new pricing items in the price list by including pricing details for each item, further includes the steps of: add a new empty pricing item in the selected grid where the item has to be listed; specifying all pricing details related to the new pricing item.

11. The method of claim 1 wherein the step of modifying existing pricing items in the current price list, further includes the steps of: selecting an attribute of a pricing item to be modified in the current price list; replacing the selected attribute of the pricing item with a new one.

12. The method of claim 1 wherein the step of deleting existing pricing items in the current price list, further includes the steps of: selecting a pricing row in the current price list; removing the pricing item from the current price list.

13. A process for calculating pricing data related to various types of product items, comprising processes for: selecting a base price for a product item; selecting discounts applicable according to product, customer and transaction attributes; selecting surcharges specified for the selected product item; applying pricing computation sequences to calculate a product price.

14. The process of claim 13 wherein the step of selecting a base price for a product item, further includes processes for: describing a product item by defining its pricing attributes, including the base price; selecting a price value as the base price of the selected product item.

15. The process of claim 13 wherein the step of selecting discounts applicable according to product, customer and transaction attributes, further includes processes for: selecting discount rules from existing pricing rules to be applied in a pricing computation sequence.

16. The process of claim 13 wherein the step of selecting discounts applicable according to product, customer and transaction attributes, further includes processes for: creating new discount rules to be applied in a pricing computation sequence.

17. The process of claim 16 wherein the step of creating new discount rules to be applied in a pricing computation sequence, further includes processes for: specifying the name of the new discount rule; selecting the pricing rule as discount rule; associating the activation expression fields to the discount rule.

18. The process of claim 13 wherein the step of selecting surcharge specified for the selected product item, further includes processes for: selecting surcharge rules from existing pricing rales to be applied in a pricing computation sequence.

19. The process of claim 13 wherein the step of selecting surcharge specified for the selected product item, further includes processes for: creating new surcharge rales to be applied in a pricing computation sequence.

20. The process of claim 19 wherein the step of creating new surcharge rules to be applied in a pricing computation sequence, further includes processes for: specifying the name of the new surcharge rale; selecting the pricing rule as surcharge rule; associating the activation expression fields to the surcharge rule.

21. The process of claim 13 wherein the step of applying pricing computation sequences to calculate a product price, further includes processes for: defining a pricing computation sequence as a composition of pricing rules.

22. The process of claim 13 wherein the step of applying pricing computation sequences to calculate a product price, further includes processes for: applying pricing computation sequences to calculate the value of a line item in a pricing document.

23. The process of claim 13 wherein the step of applying pricing computation sequences to calculate a product price, further includes processes for: applying pricing computation sequences to calculate the value of a pricing document and to allocate document level pricing results to each line item.

24. A computer system for elaborating pricing data related to various types of product items, comprising means for: managing processes for the runtime calculation of the a product price by: editing product item details to be managed on a computer system; selecting activation expression fields among pricing attributes used to activate pricing rules; defining pricing rules to be applied for the calculation of item prices; executing pricing computation sequences as composition of pricing rules to calculate an item price; displaying pricing details in an grid table by showing all pricing attributes selected as activation expression fields; elaborating pricing items in grids including the pricing attributes selected as activation expression fields by: inserting new pricing items in the price lists by including details for each pricing rule; modifying existing pricing items in the price list; deleting existing pricing items in the price list; simulating a runtime situation for checking how a pricing computation sequence determines a price.

25. The system of claim 24 wherein said means for editing product item details to be managed on a computer system, further includes means for: adding a product item with pricing attributes including the base price.

26. The system of claim 24 wherein said means for editing product item details to be managed on a computer system, further includes means for: modifying a product item with pricing attributes including the base price.

27. The system of claim 24 wherein said means for selecting activation expression fields among pricing attributes used to activate pricing rules, further includes means for: displaying pricing attributes available in each product item; selecting one or more of the pricing attributes as activation expression fields related to a pricing rule.

28. The system of claim 24 wherein said means for defining pricing rules to be applied for the calculation of item prices, further includes means for: displaying a dialog window for defining pricing rules to be applied for the calculation of final prices; selecting a base price for the calculation; selecting discount rules to be applied to the base price; selecting surcharge rales to be applied to the discounted base price.

29. The system of claim 24 wherein said means for executing pricing computation sequences as composition of pricing rales to calculate an item price, further includes means for: applying pricing rules to calculate the value of a computation step in the pricing computation sequence; applying groups of pricing rules to calculate the value of a computation step in the pricing computation sequence; modifying and discontinuing pricing computation sequence by: modifying pricing rules applied to calculate the value of a computation step in the pricing computation sequence; storing in the system database all previous versions of the modified pricing computation sequences; applying pricing computation sequences to calculate the value of a line item in a pricing document; applying pricing computation sequences to calculate the value of a pricing document and to allocate document level pricing results to each line item.

30. The means of claim 29 wherein said means for applying pricing rules to calculate the value of a computation step in the pricing computation sequence, further includes means for: displaying a list of available pricing rules in the computer system; selecting available pricing rules to be applied in a pricing computation sequence.

31. The means of claim 29 wherein said means for applying pricing rules to calculate the value of a computation step in the pricing computation sequence, further includes means for: displaying a dialog window for the definition of all properties of new pricing rales to be applied for the calculation of final prices; creating new pricing rules to be applied in a pricing computation sequence;

32. The means of claim 29 wherein said means for applying groups of pricing rules to calculate the value of a computation step in the pricing computation sequence, further includes means for: relating each pricing rule or group of pricing rules of the pricing computation sequence by a set of Boolean operands.

33. The system of claim 24 wherein the step of displaying pricing details in a grid table by showing all pricing attributes selected as activation expression fields, further includes means for: applying a filter condition to the pricing items included in the price list; displaying the subset of the pricing data of a specific pricing table which satisfies the applied filter condition.

34. The system of claim 24 wherein said means for inserting new pricing items in the price lists by including details for each pricing rule, further includes means for: adding a new empty pricing item in the selected grid where the item has to be listed; editing all pricing details related to the new pricing item.

35. The system of claim 24 wherein said means for modifying existing pricing items in the price list, further includes means for: selecting the item attribute to be changed; editing a new attribute in the pricing item.

36. The system of claim 24 wherein said means for deleting existing pricing items in the price list, further includes means for: selecting a pricing row in the current price list; removing the pricing item from the current price list.

37. The system of claim 24 wherein said means for simulating a runtime situation for checking how a pricing computation sequence determines a price, further includes means for: specifying a value for each attribute that can influence the pricing determination in the pricing computation sequence; executing the pricing computation sequence using the specified values for each attribute; displaying all intermediate results and subtotals of the execution of the pricing computation sequence.

38. A process for calculating pricing of transactions in a system having a storage device, a processing unit and a display device, said process comprising: inputting pricing data into said storage device; said pricing data including pricing information; discount information and surcharge information; inputting pricing rules into said storage device; said pricing rales including at least one attribute denoting a specific business transaction and at least one activation expression field; said at least one attribute includes information that identifies said pricing data applicable to a particular business transaction; said activation expression field include information describing the factors that determine whether the pricing rule is to be applied to a particular transaction; inputting computation sequences into said storage device; said computation sequences determine the sequence of said pricing rules to be applied to calculate pricing for a particular transaction; processing said computation sequences with said processing unit to determine the results of a particular transaction; and displaying the results of the processed computation sequences for a particular transaction.

39. The process of claim 38 wherein said process further comprises: calculating a total result for a transaction.

40. The process of claim 38 wherein said process further comprises: calculating pricing of individual items within a total result for a business transactions.

41. The process of claim 38 wherein said activation expression field includes: variable factors describing whether said pricing data in said pricing rule is to be applied to a particular transaction.

42. The process of claim 38 wherein said at least one pricing rule includes: multiple pricing rules.

43. The process of claim 38 wherein said at least one pricing rale includes: at least one attribute describing the type of the rule as one of a property relating to pricing information, discount information and surcharge information.

44. The process of claim 38 wherein said at least one pricing rule includes: at least one attribute describing the calculation to be based on one of a fixed amount of the price and on a percentage of the price.

45. The process of claim 38 wherein said computation sequence includes: a first stage determining the base price for the calculation of pricing for a particular transaction; a second stage determining one or more discounts to be applied for a particular transaction; and a third stage determining one or more surcharges to be applied for a particular transaction.

46. The process of claim 38 wherein said pricing data includes: said pricing data stored in pricing tables; and said pricing tables include one of said pricing tables for each of said at least one pricing rules.

47. The process of claim 46 wherein said pricing data further includes: applying filter conditions to a specific one of said pricing tables for creating a subset of said specific pricing table of pricing data which satisfies said filter condition.

48. The process of claim 38 wherein said step of inputting pricing data includes: allowing a user to define factors relating to said pricing data.

49. The process of claim 48 wherein said step of allowing a user to define factors relating to said pricing data includes: displaying a grid table displayed on said display device; displaying said pricing data listed in said grid table; and displaying said attributes for said pricing rule applicable to said pricing data listed in said grid table.

50. The process of claim 38 wherein said step of inputting pricing rules includes: allowing a user to define factors relating to said pricing rules.

51. The process of claim 50 wherein said step of inputting pricing rules includes: a dialog window for defining said pricing rules displayed on said display device; selecting a base price for a particular transaction from said dialog window; selecting discount rules to be applied to said selected base price for a particular transaction on said dialog window; and selecting surcharge rules to be applied to said selected base price after said selected discount rules have been applied to said selected base price on said dialog window.

52. The process of claim 38 wherein said step of inputting computation sequences includes: allowing a user to define said computation sequences.

53. The process of claim 52 wherein said step of inputting computation sequences further includes: displaying a dialog window on said display device for displaying of said pricing rules in said process; allowing a user to select said pricing rules applicable for a transaction from said dialog window.

54. The process of claim 53 wherein said step of inputting computation sequences further includes: displaying on said dialog window all properties for defining new pricing rules available on said process; and allowing a user to define new pricing rules by selecting applicable properties from said dialog window.

55. The process of claim 38 wherein said process further comprises: allowing a user to modify said pricing data.

56. The process of claim 38 wherein said process further comprises: allowing a user to modify said pricing rules.

57. The process of claim 38 wherein said process further comprises: allowing a user to modify said computation sequences.

58. The process of claim 38 wherein said process further comprises: allowing a user to define variables for said activation expression fields.

59. The process of claim 38 wherein said process further comprises: simulating a runtime transaction for verifying a pricing computation sequence on a transaction.

60. The process of claim 59 wherein said step of simulating a runtime transaction includes: specifying a value for each attribute of each pricing rule in a particular computation sequence; executing the computation sequence using specified values; displaying the intermediate results of said computation sequence; and displaying the final results of said computations sequence.

61. The process of claim 38 wherein said transaction includes: a transaction determining the pricing of a product for a customer.

62. The process of claim 38 wherein said transaction includes: a transaction determining the purchase price of products from a vendor.

63. The process of claim 38 wherein said transaction includes: a transaction determining the cost of a product for internal cost- accounting puφoses.

64. A system for calculating pricing of transactions, said system comprising: means for storing data; means for inputting pricing data into said means for storing data; said pricing data including pricing information; discount information and surcharge information; means for inputting pricing rules into said means for storing data; said pricing rules including at least one attribute denoting a specific business transaction and at least one activation expression field; said at least one attribute includes information that identifies said pricing data applicable to a particular business transaction; said activation expression field include information describing the factors that determine whether the pricing rule is to be applied to a particular transaction; means for inputting computation sequences into said means for storing data; said computation sequences determine the sequence of said pricing rales to be applied to calculate pricing for a particular transaction; means for processing said computation sequences to determine the results of a particular transaction; and means for displaying the results of the processed computation sequences for a particular transaction.

65. The system of claim 64 wherein said system further comprises: means for calculating a total result for a transaction.

66. The system of claim 64 wherein said system further comprises: means for calculating pricing of individual items within a total result for a business transactions.

67. The system of claim 64 wherein said activation expression field includes: variable factors describing whether said pricing data in said pricing rule is to be applied to a particular transaction.

68. The system of claim 64 wherein said at least one pricing rule includes: multiple pricing rules.

69. The system of claim 64 wherein said at least one pricing rule includes: at least one attribute describing the type of the rule as one of a property relating to pricing information, discount information and surcharge information.

70. The system of claim 64 wherein said at least one pricing rule includes: at least one attribute describing the calculation to be based on one of a fixed amount of the price and on a percentage of the price.

71. The system of claim 64 wherein said computation sequence includes: a first stage determining the base price for the calculation of pricing for a particular transaction; a second stage determining one or more discounts to be applied for a particular transaction; and a third stage determining one or more surcharges to be applied for a particular transaction.

72. The system of claim 64 wherein said pricing data includes: said pricing data stored in pricing tables; and said pricing tables include one of said pricing tables for each of said at least one pricing rules.

73. The system of claim 9 wherein said pricing data further includes: means for applying filter conditions to a specific one of said pricing tables for creating a subset of said specific pricing table of pricing data which satisfies said filter condition.

74. The system of claim 64 wherein said means for inputting pricing data includes: means for allowing a user to define factors relating to said pricing data.

75. The system of claim 74 wherein said means for allowing a user to define factors relating to said pricing data includes: means for displaying information; a grid table displayed on said means for displaying information; said pricing data listed in said grid table; and said attributes for said pricing rule applicable to said pricing data listed in said grid table.

76. The system of claim 64 wherein said means for inputting pricing rules includes: means for allowing a user to define factors relating to said pricing rules.

77. The system of claim 64 wherein said means for inputting pricing rules includes: means for displaying information; a dialog window for defining said pricing rules displayed on said means for displaying information; means on said dialog window for selecting a base price for a particular transaction; means on said dialog window for selecting discount rules to be applied to said selected base price for a particular transaction; means on said dialog window for selecting surcharge rules to be applied to said selected base price after said selected discount rules have been applied to said selected base price.

78. The system of claim 64 wherein said means for inputting computation sequences includes: means for allowing a user to define said computation sequences.

79. The system of claim 78 wherein said means for inputting computation sequences further includes: means for displaying information; a dialog window displayed on said means for displaying information for displaying of said pricing rules in said system; means on said dialog window for allowing a user to select said pricing rules applicable for a transaction.

80. The system of claim 79 wherein said means for inputting computation sequences further includes: means on said dialog window for displaying all properties for defining new pricing rules available on said system; and means on said dialog window for allowing a user to define new pricing rules by selecting applicable properties.

81. The system of claim 64 wherein said system further comprises: means for allowing a user to modify said pricing data.

82. The system of claim 64 wherein said system further comprises: means for allowing a user to modify said pricing rules.

83. The system of claim 64 wherein said system further comprises: means for allowing a user to modify said computation sequences.

84. The system of claim 64 wherein said system further comprises: means for allowing a user to define variables for said activation expression fields.

85. The system of claim 64 wherein said system further comprises: means for simulating a runtime transaction for verifying a pricing computation sequence on a transaction.

86. The system of claim 85 wherein said means for simulating a runtime transaction includes: means for specifying a value for each attribute of each pricing rule in a particular computation sequence; means for executing the computation sequence using specified values; means for displaying the intermediate results of said computation sequence; and means for displaying the final results of said computations sequence.

87. The system of claim 64 wherein said transaction includes: a transaction determining the pricing of a product for a customer.

88. The system of claim 64 wherein said transaction includes: a transaction determining the purchase price of products from a vendor.

89. The system of claim 64 wherein said transaction includes: a transaction determining the cost of a product for internal cost- accounting puφoses.