Wiki

Case Status
Log In

Wiki

 
Manufacturers Integrating with…»Dynamic Pricing
  • RSS Feed

Last modified on 11/21/2014 8:29 AM by User.

Tags:

Dynamic Pricing

Overview

Loading price lists into OASIS by copying and pasting data from the manufacturer is by far the most common method for managing pricing in OASIS. The source of data in this case is a spreadsheet from the manufacturer.
 
The disadvantages of this method usually lead to a phone call to move the spreadsheet to a common website or FTP server allowing the manufacturer to post new pricing that is downloaded into OASIS. This works well if the number of items is small (~20,000 items or so). Larger price files will take a long time to download and result in user frustration when trying to pull down pricing updates.
 
For larger price lists, dynamic pricing is recommended. This document describes the overall technology required and rough guidelines. Please note that each implementation is different as the manufacturer must manage the data source and each company will have a different set of tools to work with.
 

Architecture

 
The overall architecture is a common client side request over the Internet to a server application (service). The pricing data is stored in a relational database indexed by rep, customer and manufacturer brand.
 
When a product is not in OASIS (or if the data is “old”), then a request is made across the internet to the remote server application. Once the information (description, price, etc.) is returned, a copy is stored in the OASIS relational database. This allows data to be cached locally and reduces the number of calls to the remote server.
 
Within this architecture there are four different call types that are made. Please note that these are described generically and may be combined or broken into multiple calls when needed:
  • Catalog match – a request to “get similar” catalog numbers when an unknown catalog number is keyed into OASIS.
  • Product information – a request to get overall product details from a catalog number. Information is typically a description, lead times, and similar information. Pricing is typically not returned. Call is only made once.
  • Authorized pricing – a request for pricing authorized for a given catalog number. We recommend that this include the lowest authorized price, the price where overage is allowed and the overage split (the rep’s take of the overage). Commission rates for each price are required.
  • Customer specific price – a request for the lower price allowed for a customer (typically a distributor). Commission rate for the price is required. Any required quote number should be returned as well.
 
Outside security concerns, these four service calls are all that is required to implement dynamic pricing with OASIS.
 

Security

We recommend all calls be made using a form of secure sockets (e.g. https).
 

Data Lifecycle

Once OASIS downloads any price information, that information is tagged with an end date. That date may be passed as part of the price calls. (Territory and customer prices may have different expiration dates). However, most implementations request that pricing data expires after a set number of days after being pulled from the server. The shorter the time frame, the more calls will be made to the server.  However, longer time frames could result in quoting the wrong price.
 
Common time frames are one week (e.g. expire on Sunday night) or after 30 days. The advantage of having a fixed number of days is that the server will see an even utilization rate as compared to when pricing is expired on a given day (e.g. Sunday night).
 
Item data does not expire – only pricing. Typically an implementation dependent call (not listed) is made to return a list of catalog numbers to “refresh”. This will force OASIS to reload the product information for the items in the list. This is only a concern if OASIS is to be utilized to tell reps when an item has been discontinued. Again, the call is implementation dependent.
 

SOAP – Simple Object Access Protocol

The architecture above could be implemented using most any internet based technology. However, SOAP is the technology typically used. Below is a rough example of dynamic pricing for OASIS using SOAP.
 
Many tools exist for creating SOAP services – from hand coded WSDL files to coding in your favorite language and translating the code to a WSDL file. Below we describe the SOAP calls more as procedure calls than XML documents but the result is the same – a WSDL file.
 

Data Structures

Structure Security
  • Implementation dependent
  • Should include a user/password or some way to identify the company or the individual user.
  • Security information is stored in the OASIS client and provided to the service during all of the calls below.
 
Structure SimilarCatalogNumbers
  • A list of similar catalog numbers
  • Typically returned as a simple array or list.
  • Contains only a string representing a unique catalog number
  • No other information should be returned
  • Typically truncated to a “sane” number of entries (e.g. 32 or 64 catalog numbers).
 
Structure ProductInformation
  • The actual data is implementation dependent, but a description is recommended.
  • Common to have a lead time returned
  • Flags or notes that an item has been discontinued is common
 
Structure AuthorizedPrice
  • A “C” example is shown below
  • Commission rates are strongly recommended to be returned with each price
  • The actual implementation values and content are negotiable.
  • If data is stored in a non floating point data structure in the relational database, please consider a different representation than a double in “C”.
 
struct AuthorizedPrice {
double LowPrice; // Rep’s lowest allowed price w/o a quote
double LowPriceCommissionRate;
double OverageablePrice; // Rep’s lowest price for overage
double OverageablePriceCommisionRate;
double OverageSplit; // optional. Rep's % take of the overage
};
 
Structure CustomerPrice
  • A “C” example is shown below
  • This structure represents a price for an item for a single customer.
 
struct AuthorizedPricing {
double LowPrice; // Rep’s lowest allowed price w/o a quote
double LowPriceCommissionRate;
char* QuoteNumber; // Any quote number required for ordering
};
 

Service Calls

Each service call is show as it might look in a “C” based language.
 
SimilarCatalogNumbers getSimilar(Security s, char* Pattern);
  • A security token or other identification on each call is strongly recommended.
  • Pattern – Part of a catalog number, allowing for a search of “like” catalog numbers. Only a match at the end of the catalog string is required.
 
Example:
  SimilarCatalogNumbers scn = svc.getSimilar(sec, “ABC*”);
 
- The call should return catalog numbers beginning with “ABC”
- The call should self limit to at least 30 characters but no more than 100 (for speed).
- When working with OASIS developers, the asterisk may be replace or omitted on the actual call.
 
ProductInformation getItem(Security s, char* CatalogNumber)
  • A security token or other identification on each call is strongly recommended.
  • CatalogNumber – the EXACT catalog number to return details for.
  • Return NULL (or similar) if the item is not found.
  • Only ONE item is allowed to be returned (no lists)
 
Example:
  ItemDetails item = svc.getItem(sec, “ABC-12V-BK-5”);
 
AuthorizedPrice getPricing(Security s, char* CatalogNumber)
  • A security token or other identification on each call is strongly recommended.
  • CatalogNumber – the EXACT catalog number to return details for.
  • Return NULL (or similar) if the item is not found.
  • Only ONE item is allowed to be returned (no lists)
 
Example:
  AuthorizedPrice price = svc.getPricing(sec, “ABC-12V-BK-5”);
 
CustomerPrice getCustomerPrice(Security s, char* Account, char* CatalogNumber);
  • A security token or other identification on each call is strongly recommended.
  • Account – account number for the customer. (Customer account numbers are stored in OASIS. There should be only one account number for pricing and order entry.)
  • CatalogNumber – the EXACT catalog number to return details for.
  • Return NULL (or similar) if the item is not found.
  • Only ONE item is allowed to be returned (no lists)
 
Example:
  CustomerPrice cprice = svc.getCustomerPrice(sec, “1234567”, “ABC-12V-BK-5”);
 
 

Narrative

Calls are made during several user actions within OASIS. Typically there are three use-cases:
  • Catalog number drop-down guidance
  • Show project price
  • Show customer price
 
Catalog number drop-down guidance
As the user is typing a catalog number, OASIS will attempt to guide the user to key a correct catalog number. To do this with dynamic pricing, OASIS first scans the local OASIS database. If matching catalog number are found, then they are shown to the user. However, if the user keys a catalog number that is not a match within the OASIS database, then the remote server is called using the getSmilar() service call. If matching entries are found, the matches are shown to the user and the matches are saved to the OASIS database for the next user.
 
There are a number of internal checks to keep OASIS from making repetitive calls for non-matching entries. These routines tend to timeout after 24 hours. (Example: if the user keys a bad catalog number, OASIS will ask the user once per session thereby reducing the number of calls to the server.)
 
To limit the number of calls to the server, most implementations will not call the server unless the user keys at least 3 non-blank characters. This rule may be altered for each implementation.
 
Show project price
When the user selects a catalog number from the drop-down menu (guidance), or if the user keys a complete catalog number, OASIS will first search the OASIS database for to see if the item data and authorized pricing is available. If not, the required getItem() and getPricing() calls are made to the remote server. If data is returned by the server, then the data is saved to the OASIS database with an end date indicating when the data should be refreshed.
 
Only complete catalog numbers are requested. If “wild card” characters are sent, the service should (at best) assume that part of the catalog number is “undefined” and return the best information for ONE item. However, it is more common to just return NULL if no matching entry is found due to a bad catalog number.
 
(Example: “ABC-*-BK-5” would return a price for the item if there exist multiple voltage options and the price would be the same regardless of the selected voltage. This is suggested behavior but has yet to be implemented.)
 
There are a number of internal checks to keep OASIS from making repetitive calls for non-matching entries. These routines tend to timeout after 24 hours. (Example: if the user keys a bad catalog number, OASIS will ask the user once per session thereby reducing the number of calls to the server.)
 
Show customer price
Once the customer is known (a winning customer on a project/quote or an order), the best price available for the customer is often required. In this case, OASIS will call getItem() if required, but will then call getCustomerPrice(). If getCustomerPrice() returns a customer specific price, that price will be used. However, if no price is returned, then getPricing() will be called when required.
 
All data is cached in the local OASIS database with different expiration dates for each returned customer specific price and each authorized price.
 
There are a number of internal checks to keep OASIS from making repetitive calls for non-matching entries. These routines tend to timeout after 24 hours. (Example: if the user keys a bad catalog number, OASIS will ask the user once per session thereby reducing the number of calls to the server.)