Skip to main content

Dynamic Pricing

Lauren Smith
Updated
While some manufacturers choose to send price lists directly to agencies for upload into OASIS, this process is often cumbersome and frequently leads to errors in pricing and extended downtime caused by this manual process. Originally, we solved this problem by offering a service that allowed agents to download manufacturers' price files directly into OASIS. This Price File Download service was a considerable improvement in the user experience of agents working with pricing on a daily basis.
 
However, Dynamic Pricing takes this a step further. Using this integration, agents are now able to seamlessly import pricing just by entering part numbers into bills of material. For manufacturers, the update process remains unchanged. Simply send Ingen a price file monthly or quarterly, and we handle the rest.
 

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”), 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, four different call types 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. The call is only made once.
  • Authorized pricing – a request for pricing authorized for a given catalog number. We recommend including 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 a lower price allowed for a customer (typically a distributor). The 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 expire 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 compared to when pricing expires 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 almost 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 nonfloating 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 shown 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 the correct one. OASIS first scans the local OASIS database to do this with dynamic pricing. If matching catalog numbers are found, 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 saved to the OASIS database for the next user.
 
There are several internal checks to keep OASIS from making repetitive calls for non-matching entries. These routines tend to time out after 24 hours. (Example: if the user keys a bad catalog number, OASIS will ask the user once per session, reducing the number of calls to the server.)
 
Most implementations will not call the server unless the user keys at least 3 non-blank characters to limit the number of calls to the server. 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 keys a complete catalog number, OASIS will first search the OASIS database to see if the item data and authorized pricing are available. If not, the required getItem() and getPricing() calls are made to the remote server. If the server returns data, 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 just to 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 several internal checks to keep OASIS from making repetitive calls for non-matching entries. These routines tend to time out after 24 hours. (Example: if the user keys a bad catalog number, OASIS will ask the user once per session, 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 and authorized price.
 
There are several internal checks to keep OASIS from making repetitive calls for non-matching entries. These routines tend to time out 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.)

Related articles

Comments

0 comments

Please sign in to leave a comment.

Powered by Zendesk