WO2001035293A1 - Methodes et procedes permettant de calculer des prix au moyen d'un systeme informatique - Google Patents

Methodes et procedes permettant de calculer des prix au moyen d'un systeme informatique Download PDF

Info

Publication number
WO2001035293A1
WO2001035293A1 PCT/US2000/030392 US0030392W WO0135293A1 WO 2001035293 A1 WO2001035293 A1 WO 2001035293A1 US 0030392 W US0030392 W US 0030392W WO 0135293 A1 WO0135293 A1 WO 0135293A1
Authority
WO
WIPO (PCT)
Prior art keywords
pricing
rules
computation
price
transaction
Prior art date
Application number
PCT/US2000/030392
Other languages
English (en)
Inventor
Kambi Ebrahimi
Giuseppe Pillirone
Klaus-Peter Lang
Original Assignee
Quark, Inc.
Quark Media House Sarl
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Quark, Inc., Quark Media House Sarl filed Critical Quark, Inc.
Priority to JP2001536956A priority Critical patent/JP2003514306A/ja
Priority to AU17568/01A priority patent/AU1756801A/en
Priority to CA002359133A priority patent/CA2359133A1/fr
Priority to EP00980284A priority patent/EP1141873A4/fr
Publication of WO2001035293A1 publication Critical patent/WO2001035293A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions

Definitions

  • 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.
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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:
  • Graphical user interface for the customization by the end-user, including a pricing simulator to verify designed pricing rules
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • 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 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.
  • 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.
  • 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.
  • Primary 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.
  • Primarycing 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • a rule also has a set of other attributes that describe the action that should be taken when the activation expression evaluates to TRUE.
  • 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;
  • 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.
  • 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.
  • 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)
  • 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);
  • 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);
  • a pricing rule is identified by a name selected by the user.
  • 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.).
  • 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.
  • the pricing computation sequences identify the pricing rules (prices, discounts, and surcharges) that must be applied to calculate the final value of an item.
  • 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.
  • 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.
  • the first pricing rule in the sequence determines the base price.
  • rules determine the applicable discounts.
  • 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.
  • pricing rules pricing computation sequence can be defined for a single line item or for the whole pricing document.
  • 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.
  • 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.
  • 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:
  • Processes to discontinue pricing computation sequences Processes to display pricing computation sequences.
  • 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”.
  • the system determines, according to the order
  • 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.
  • 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.
  • 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.
  • 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 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.
  • New tab 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.
  • 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
  • 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.
  • a pricing rule shall be selected among existing ones, or a new pricing rule shall be created.
  • 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.
  • 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:
  • 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).
  • 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.
  • 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.
  • FIG. 4 a sample description of a line item pricing computation sequence is presented.
  • 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.
  • 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.
  • 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:
  • 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.
  • 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.
  • 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.
  • 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:
  • 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.
  • 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.
  • Each pricing rule includes a list of keys, or activation expression fields, that shall be evaluated during the pricing evaluation.
  • 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.
  • 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.
  • the order line items are the following:
  • 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.
  • 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.
  • 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.

Abstract

L'invention concerne des méthodes, des procédés et un système permettant de gérer et de calculer des informations de prix de différents types d'articles et d'unités de gestion de stock (UGS) utilisant un système informatique. Un système de tarification est compatible avec un comportement 'en temps réel' pour le calcul des prix qui s'effectue pendant des transactions en ligne basées sur des règles et sur des séquences de calcul (2) définies par l'utilisateur. Un commerçant peut définir une politique de fixation des prix liée à toute variable applicable intervenant dans la transaction commerciale (5) (par exemple, catégorie de client, type de produit, saison ou date de vente, etc.). Après une série d'étapes de fixation des prix partant de prix de base (6), on calcule le prix final en appliquant des rabais (7), des suppléments (8), des taxes et d'autres coûts.
PCT/US2000/030392 1999-11-05 2000-11-03 Methodes et procedes permettant de calculer des prix au moyen d'un systeme informatique WO2001035293A1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
JP2001536956A JP2003514306A (ja) 1999-11-05 2000-11-03 コンピュータ・システムを使用したプライシング計算のための方法およびプロセス
AU17568/01A AU1756801A (en) 1999-11-05 2000-11-03 Methods and processes for pricing calculation using a computer system
CA002359133A CA2359133A1 (fr) 1999-11-05 2000-11-03 Methodes et procedes permettant de calculer des prix au moyen d'un systeme informatique
EP00980284A EP1141873A4 (fr) 1999-11-05 2000-11-03 Methodes et procedes permettant de calculer des prix au moyen d'un systeme informatique

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US43540899A 1999-11-05 1999-11-05
US09/435,408 1999-11-05

Publications (1)

Publication Number Publication Date
WO2001035293A1 true WO2001035293A1 (fr) 2001-05-17

Family

ID=23728271

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/030392 WO2001035293A1 (fr) 1999-11-05 2000-11-03 Methodes et procedes permettant de calculer des prix au moyen d'un systeme informatique

Country Status (5)

Country Link
EP (1) EP1141873A4 (fr)
JP (1) JP2003514306A (fr)
AU (1) AU1756801A (fr)
CA (1) CA2359133A1 (fr)
WO (1) WO2001035293A1 (fr)

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10133370A1 (de) * 2001-07-10 2003-01-30 Bayer Ag Computersystem und Verfahren zur automatischen Ermittlung eines Kunden-Preises
JP2009245446A (ja) * 2001-07-12 2009-10-22 Saphran Inc 見積システムおよび方法
US20150066672A1 (en) * 2013-08-30 2015-03-05 Verizon Patent And Licensing Inc. Method and apparatus for providing online content management and e-commerce solution
US20150088697A1 (en) * 2013-09-20 2015-03-26 Target Brands, Inc. Network traffic-based throttling of electronic commerce activity
US9064280B2 (en) 2013-09-20 2015-06-23 Target Brands, Inc. Electronic commerce checkout procedures of a website
US9189605B2 (en) 2005-04-22 2015-11-17 Microsoft Technology Licensing, Llc Protected computing environment
US9224168B2 (en) 2004-11-15 2015-12-29 Microsoft Technology Licensing, Llc Tuning product policy using observed evidence of customer behavior
US9336359B2 (en) 2004-10-18 2016-05-10 Microsoft Technology Licensing, Llc Device certificate individualization
US9363481B2 (en) 2005-04-22 2016-06-07 Microsoft Technology Licensing, Llc Protected media pipeline
US9436804B2 (en) 2005-04-22 2016-09-06 Microsoft Technology Licensing, Llc Establishing a unique session key using a hardware functionality scan
US10229440B2 (en) 2014-06-30 2019-03-12 Sap Se Accelerated price calculation using in-memory technology
US20210241329A1 (en) * 2020-01-31 2021-08-05 Salesforce.Com, Inc. Pluggable Architecture for Performance of Pricing Operations
CN113689170A (zh) * 2021-08-30 2021-11-23 拉扎斯网络科技（上海）有限公司 配送订单的定价处理方法、装置及计算机设备
US11790414B2 (en) 2020-01-31 2023-10-17 Salesforce, Inc. Techniques and architectures for customizable modular line item evaluation

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2371985C (fr) 2002-02-15 2015-12-29 Teranet Enterprises Inc. Methode et systeme d'elaboration de structures de prix de produits et services complexes

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5873069A (en) * 1995-10-13 1999-02-16 American Tv & Appliance Of Madison, Inc. System and method for automatic updating and display of retail prices
US5878400A (en) * 1996-06-17 1999-03-02 Trilogy Development Group, Inc. Method and apparatus for pricing products in multi-level product and organizational groups
US5987425A (en) * 1995-02-28 1999-11-16 United Hardware Distributing Company Variable margin pricing system

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5987425A (en) * 1995-02-28 1999-11-16 United Hardware Distributing Company Variable margin pricing system
US5873069A (en) * 1995-10-13 1999-02-16 American Tv & Appliance Of Madison, Inc. System and method for automatic updating and display of retail prices
US5878400A (en) * 1996-06-17 1999-03-02 Trilogy Development Group, Inc. Method and apparatus for pricing products in multi-level product and organizational groups

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
DATABASE ABI/INFORM [online] "Standard equity classifications lack clear definitions", XP002939124, retrieved from 01369545 accession no. Dialog Database accession no. 00-20532 *
EMPLOYEE BENEFIT PLAN REVIEW, vol. 51, no. 7, January 1997 (1997-01-01), pages 42 - 44, ISSN: 0013-6808 *
See also references of EP1141873A4 *

Cited By (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10133370A1 (de) * 2001-07-10 2003-01-30 Bayer Ag Computersystem und Verfahren zur automatischen Ermittlung eines Kunden-Preises
JP2009245446A (ja) * 2001-07-12 2009-10-22 Saphran Inc 見積システムおよび方法
US9336359B2 (en) 2004-10-18 2016-05-10 Microsoft Technology Licensing, Llc Device certificate individualization
US9224168B2 (en) 2004-11-15 2015-12-29 Microsoft Technology Licensing, Llc Tuning product policy using observed evidence of customer behavior
US9363481B2 (en) 2005-04-22 2016-06-07 Microsoft Technology Licensing, Llc Protected media pipeline
US9436804B2 (en) 2005-04-22 2016-09-06 Microsoft Technology Licensing, Llc Establishing a unique session key using a hardware functionality scan
US9189605B2 (en) 2005-04-22 2015-11-17 Microsoft Technology Licensing, Llc Protected computing environment
US20150066672A1 (en) * 2013-08-30 2015-03-05 Verizon Patent And Licensing Inc. Method and apparatus for providing online content management and e-commerce solution
US9064280B2 (en) 2013-09-20 2015-06-23 Target Brands, Inc. Electronic commerce checkout procedures of a website
US20150088697A1 (en) * 2013-09-20 2015-03-26 Target Brands, Inc. Network traffic-based throttling of electronic commerce activity
US9875500B2 (en) 2013-09-20 2018-01-23 Target Brands, Inc. Network traffic-based throttling of electronic commerce activity
US10373242B2 (en) 2013-09-20 2019-08-06 Target Brands, Inc. Network traffic-based throttling of electronic commerce activity
US10229440B2 (en) 2014-06-30 2019-03-12 Sap Se Accelerated price calculation using in-memory technology
US20210241329A1 (en) * 2020-01-31 2021-08-05 Salesforce.Com, Inc. Pluggable Architecture for Performance of Pricing Operations
US11790414B2 (en) 2020-01-31 2023-10-17 Salesforce, Inc. Techniques and architectures for customizable modular line item evaluation
US11798044B2 (en) * 2020-01-31 2023-10-24 Salesforce, Inc. Pluggable architecture for performance of pricing operations
CN113689170A (zh) * 2021-08-30 2021-11-23 拉扎斯网络科技（上海）有限公司 配送订单的定价处理方法、装置及计算机设备

Also Published As

Publication number Publication date
AU1756801A (en) 2001-06-06
CA2359133A1 (fr) 2001-05-17
EP1141873A4 (fr) 2002-02-06
EP1141873A1 (fr) 2001-10-10
JP2003514306A (ja) 2003-04-15

Similar Documents

Publication Publication Date Title
US20050203791A1 (en) Method and system for anticipating, identifying, analyzing and meeting consumer needs
US7739160B1 (en) Dynamic, rule-based, tax-decision system
US20020107761A1 (en) Methods and systems for improved channel sales support in electronic commerce
US20030225625A1 (en) Returns management systems and methods therefor
WO2001035293A1 (fr) Methodes et procedes permettant de calculer des prix au moyen d'un systeme informatique
KR20010033456A (ko) 통합된 기업-대-기업간 웹 상거래 및 비즈니스 자동화시스템
US7340406B1 (en) Business rules system
US20210334782A1 (en) Method and system for negotiating, generating, documenting, and fulfilling vendor financing opportunities
JP6908229B2 (ja) 照合プログラムおよびデータ照合方法
WO2020190840A1 (fr) Systèmes et procédés d'optimisation électronique de la planification de marchandises
US20080294496A1 (en) Methods, systems, and computer program products for automating supply chain planning processes
US11494828B2 (en) Componentized order entry and editing system and method
US7908187B2 (en) Supporting chargeable subcontracting when outsourcing manufacturing of an assembled unit while supplying components
EP0514231A2 (fr) Système à ordinateur de la gérance de travail
Jones Spotlight on midlevel ERP software
US11829782B2 (en) System and method for contextual navigation in applications
US11809904B2 (en) System and method for executing multiple scripts at a single extension point
US20230128539A1 (en) Systems And Methods For Providing Dynamic Fulfillment Defaults
JP3150650B2 (ja) ビジネス支援データ処理用記録媒体
KR102533474B1 (ko) 상품 거래 통합 관리 방법 및 시스템
US20240005406A1 (en) Computer-implemented method for evaluating an investment
JP3322829B2 (ja) 問屋用売上代金回収管理装置と問屋における売上代金回収管理方法、及び問屋用売上代金回収管理プログラムを記録したコンピュータ読み取り可能な記録媒体
Iyer Effective SAP SD
KR100847970B1 (ko) 컴퓨터 네트워크에서의 반복 주문 관리 시스템 및 방법
Iyer et al. Effective pricing with SAP ERP

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

WWE Wipo information: entry into national phase

Ref document number: 17568/01

Country of ref document: AU

ENP Entry into the national phase

Ref document number: 2359133

Country of ref document: CA

Ref document number: 2359133

Country of ref document: CA

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 2001 536956

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: IN/PCT/2001/942/CHE

Country of ref document: IN

WWE Wipo information: entry into national phase

Ref document number: 2000980284

Country of ref document: EP

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWP Wipo information: published in national office

Ref document number: 2000980284

Country of ref document: EP

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

WWW Wipo information: withdrawn in national office

Ref document number: 2000980284

Country of ref document: EP