Item Availability & Ordering Rules

Overview

Before you can begin using the automated ordering, there are few key tenets that should be understood regarding what can be ordered, how much, and the rules of precedence to allow you to customize ordering to store/item specifics.  This article deals with the theory and we'll highlight how to accomplish each of these so you can properly set up and order quickly and without confusion.

The Business Case

Its always easiest to start with the business case and terms to describe what the intention is before you get lost in any order generator jargon, Below is a description of a common business use case to help get started.  In the real word, in order to place orders, you need the following pieces of information about the business which will dictate the eventual outcome:

1 - Retailer Pricing and Availability 

Its impossible to order without knowing what items can be sold into specific market/patches and potentially individual stores. This is generally driven by the retailer, so its useful to think about rules you make here as being retailer-driven.  This is the first piece we need to have properly loaded in to the system.  In Avantalytics this is managed by a user upload under the left hand menu "Raw Data Upload" and "Enter / Update Pricing" sub-option.  When you choose this, the screen will look similar to below. 

The use case of this is to allow you to update and manage current pricing and availability.  The upload expects a default of market/patch level pricing and availability in which case the store column should be entered as 0 (zero).  This reflects the most common business case - where you have a fixed price and ability to supply across an entire market/patch.

However, it also will accept store specific pricing and/or availability within the patch - you just put a row for each store specific value instead of entering 0.  The mechanism for determining which record should apply is based on the most specific entry.  So, if you have a store in patch AB that has a different price than all the other stores you would put in a generic market wide entry for all the stores with the normal price.  You would then enter a store specific entry for the one store with the different pricing.  The most specific match is the one that will be used.  The example of pricing is just that - you could instead set all stores to be inactive for an item, then create a single store specific active record to allow one store to order.

Included in this upload are the columns "Active"  "Orderable" "Presence Qty" and "Max Order Qty".  These set the rules on the item - whether it is active, whether it can be ordered (they can be different as items may be turned on or off for periods during the year while remaining active business).  The first two operate with integer flags 0 = inactive and unorderable, 1= active  and orderable respectively in each column.

The last two columns allow you to place retailer driven rules Presence Qty & Max Order Qty.

The first, called "Presence Qty" is sometimes called a "minimum" but it serves to define the amount of product that should be present in the stores, irrespective of rate of sale.  This is most commonly used to ensure shelves are sufficiently full for customer presentation and is useful for stocking initial amounts in the Spring before the sales would dictate such presence.

The second "Max Order Qty" is generally as it sounds.  This sets an upper limit on the amount of item that will be ordered on any single purchase order.  In practice this is rarely used and more practical maximums can be set an managed elsewhere.  Most people will set this value to 0 (zero) which means "no maximum"

2 - Warehouse Inventory Availability

The next piece we need to know in order to place orders is - "What items are available at the warehouse you'll be supplying the orders from".  This is the most general suppliers side way to limit what can be ordered, (and how much of it) at any given time.  This is managed through an upload as well and can be updated as often as you like.  You supply the system with how much of each item you have and any orders placed against that warehouse will deplete the stock and orders can be managed to not exhaust inventory.  In practice most companies upload inventory prior to their order cycle which can be once a day or a couple times a week, depending on their preference.

When ordering, if an item is not listed (no entry is provided) for a given warehouse, any ordering originating from the warehouse will not order that item.  In this way, its the most universal way to include/exclude an item from being able to be ordered.  Bear in mind - the presence of a record (even if the unit on hand is 0) is enough to allow the item to be considered for ordering.  Any ordering template sourcing from the warehouse will still be able to order the item if they choose not constrain their ordering to the available stock level.

• Tip This is the first place to check if you're not seeing an item on ordering results which has been made active by the retailer.  Its most likely its not listed as an item in the warehouse.

Note - Warehouse inventory is retailer specific and can be managed separately.  This allows for segregation of inventory stock to prevent contention or hoarding during the order cycle.

In the screen above you can see that the upload expects the ChainID which is specific to each retailer, it needs the warehouse ID, along with the internal Item (which can be the retailer SKU or your internal inventory system item code).  It needs the most important part - how many units of inventory, and optionally it can accept Child Item# for instances where you have varied inventory of varietal breakouts that all get sold as one item - the order generator will spread the child items to ensure a fairly even mix.

Note - you can choose to do a partial or full update of inventory.  A partial update is a replacement of one or more items inventory values while leaving the rest in place.  This allows you to make realtime changes during an ordering cycle without changing the current inventory values for people who may be in the middle or order placement.  Full replace does as it says - it invalidates the prior inventories and any orders which were incomplete cannot be completed as they were generated against a now defunct count. 

Tip - Its a good idea to coordinate the timing of full replacements with your team as any midway replacement will cause in progress order templates to fail.

3 - Order Assembly Rules (Pack Types)

The third consideration in business involves the multiples by which items can be picked from warehouse inventory.  The real world is - what are the minimum order multiples - can you order just one unit or do you want to order at least a dozen to fill a shelf.  These rules of how items can be ordered are managed as set or "Pack Types".  You can create and use as many pack type rule sets as you like.  You can switch order templates to use different pack types at different times in the season,  or for different templates based on your business need.

The business case is often stated as this -

• "In the beginning of the season its most efficient to order Item X in multiples of 24 so we can most tightly fill a rack. The rate of sale allows us to ship larger quantities so this works, but as the season proceeds to the end, we may not need 24 units based on sales rates, so we lower it to 12 to better match demand at the expense of a less efficient racking".
• "Certain warehouses have much fewer of a few items and we want all stores to get some product before the stock is exhausted, so while 24 might be the right rate-of-sale multiple, we want to set the order multiple at 6 to make sure that a few stores don't receive more stock at the expense of starving the slower volume stores".

Regardless of the reason, the pack types allow you to define the rule set however you like and then you can switch back and forth for any reason as well.  Below is the upload for this.  The upload requires the warehouse ID, the name of the Pack Type (which can be anything you like) the internal item#. 

The Pack Qty is the minimum amount you must order - we call it "Pack Qty" because its how it is "packaged".  If the item were eggs in would be 12 or 18 (or perhaps even 6 in rarer cases). 

The Super Pack is a multiple factor representing the number of pack qty amounts that would fill the container for shipping.  It is arbitrary what the container represents - in the Live Goods industry customers often declare the container to be a "Flower Rack" - in this case then the Super Pack is the number of Pack multiples to fill up a "Flower Rack".  The usefulness of this comes into play if you wish to order by shipping quantity rather than sales dollar amount.

Max Qty - this option is optional and allows you to mandate that no more than this number of units be placed on a given purchase order when ordering using this pack type.  If you recall we have a maximum setting for the pricing / availability, so what is the purpose of this?  Because pack types are separate components from availability - it allows you to set limits which can be applied only when ordering with the specific pack type rather than having to update the availability max.  This means that different people can order with different maximums using the pack type and all people are still constrained by whatever (if any) availability maximum also exists for the item.

Conclusion

So, to summarize - there are three main components you need to have items set up in order to effectively order:

1 - Retailer / Market / Store Availability

2 - Warehouse Availability

3 - Pack Type Inclusion

The combinations you can make allow you to set limits on a store/item basis and provide opportunities to set limits globally, at the warehouse level or even more fine-grained with pack types when running templates.