There are two distinct models for organizing your hub and spoke distribution architecture: Flexible and Strict. In this article, we will explore how to create a Flexible architecture and detail the user experience in both the Demand Planning and Purchasing Automation modules.
Within the Flexible model, distributors typically fall into two subtypes, which will be referenced throughout this guide:
A. Independent Multi-Location: You have multiple locations that operate largely independently. Transfers or group purchases between locations are occasional and ad-hoc, with no strong processes currently defined. You likely do not have a central purchasing or planning function.
B. Coordinated Network: You have multiple locations and have reached a scale where you want to start planning and purchasing centrally. This helps consistently optimize lead times, supplier targets, and transfers between locations. You have defined replenishment paths for items between locations and create your demand plans assuming those paths will be followed. However, you are flexible if those paths are occasionally broken based on current inventory status.
Choosing a Flexible architecture has the largest impact on Purchasing. You will use Purchase Groups and/or Group Buys to aggregate purchase lines for the same item across different locations into a single purchase from the supplier.
Recommended Solution
This guide will detail all of the configurations and settings you have access to. In general we recommend the following:
To understand more about each decision:
Define Purchase Groups: Purchase Groups define a supplier and a set of locations whose purchase requirements you want to aggregate for that supplier. These saved groups can be quickly accessed from Recurrency to generate a new purchase order (PO) that includes needs from multiple locations.
In a Coordinated Network, you likely already have this information documented, and configuring these in Recurrency can help save you time when creating purchase orders.
Using Group Buys: if you aren’t using Purchase Groups but still want to be able to combine purchase requirements from multiple locations into a single purchase order, you can use Group Buys.
For Independent Architectures, you will use Group Buys to combine requirements at the moment you generate Purchase Orders. For Coordinated Networks, if you need to make an exception to a Purchase Group, you can do so by creating an ad-hoc Group Buy.
Create Replenishment Paths for those Purchase Groups: if you use a purchasing group consistently, your lead times for getting inventory to requirement locations will likely be different than if you purchased directly from the supplier to those locations. Configuring the Replenishment Paths in Recurrency for those suppliers and locations will optimize the min/max recommendations by adjusting lead times accordingly.
💡 This is important for Coordinated Architectures, but not for Independent ones.
Configure Supplier Targets: enabling supplier targets will allow you to more effectively track how close you are to hitting supplier incentives.
💡 This is recommended for everyone.
Enable Transfer Backorders: this allows Recurrency to automatically create Transfer Backorders (TBOs) after you generate a grouped purchase order (i.e. using a Purchase Group). Creating TBOs allows for better tracking and inspection of where inventory is within your network. Additionally, the TBO will automatically become a Transfer Order once the Purchase Order is complete, eliminating a step in your process.
For Independent Architectures, coordinating transfers between your locations can require more overhead and planning. In this case, you may not want Transfer Backorders to automatically generate and strain your warehouse team.
For Coordinated Architectures, since you frequently run transfers between locations, creating the Transfer Backorder automatically reduces overhead and ensures items leave the purchase location quickly.
Demand Planning in Recurrency with a Flexible Hub & Spoke Model
Recurrency calculates the minimum and maximum inventory levels for each item at a specific location. If you have a defined replenishment path, the calculation considers the total lead time taken for inventory to move from the supplier to the location, including all intermediate steps (i.e. transfers between locations).
For most distributors, very little will change in Recurrency’s Demand Planning module when you chose to do Flexible Hub and Spoke. You are still treating each location like an independent entity that needs to manage its own demand, order cycles, and safety stock.
You should review min/max recommendations regularly and either accept, or modify Recurrency’s recommendations.
Setting Replenishment Paths
If you chose to set Replenishment Paths for some (or all) stockable items, Recurrency’s calculation of lead times for those items will change.
For example, if you have the following scenario:
Without replenishment paths defined, Recurrency will show the lead time for an item as the Lead Time from Supplier to Requirement Location which tracks the time it takes for the supplier to fulfill a purchase order to that specific location.
With replenishment paths defined, the assumption is that the item will normally follow a path that includes at least one transfer step. This path will generally be longer than if the item were shipped directly to the location, so it's important to factor in the additional lead time to avoid running out of stock while waiting for items to arrive.
The updated lead time in this case will be Lead Time from Supplier to Purchase Location + Transfer Time from Purchase to Requirement. If there are multiple transfer points along your replenishment path, then the lead time will factor in the transfer time to each subsequent stop along the path to the requirement location.
To clarify what this would look like in our example:
Recurrency automatically sets Safety Stock to be half of the item’s lead time (unless you manually set an override for that value). Increases in Lead Time will also increase the Safety Stock we recommend you hold.
Purchasing in Recurrency with a Flexible Hub & Spoke Model
After setting your dynamic min/max values for items, you can now create purchase orders from your suppliers. Within Purchasing, you have several options for how to create purchase orders. We recommend the following:
Define Purchase Groups: Create purchase groups to bundle different purchase requirements from various locations into a single purchase order, helping you consistently hit your supplier targets.
Define Supplier Targets: To hit a given target, you must inform the system what the target is.
Use Transfer Backorders: Using transfer backorders ensures visibility into what inventory belongs where, even after bundling purchase requirements into a single purchase order. It also reduces the manual maintenance and overhead needed to move inventory between your locations.
Using Purchase Groups and Creating an Ad-Hoc Group Buys
Creating purchase groups makes it easy to reuse combinations of locations for specific suppliers. Purchase Groups need to be created separately from configuring replenishment paths, so you should set aside time for this task.
To learn more about using Purchase Groups, visit this support article.
There may be some cases where you need to make a purchase from a supplier, but your currently defined group doesn’t have enough purchase requirements to hit your target. In these cases you may want to expand or redefine the group to include other locations. You can do this by creating an ad-hoc purchase group through Purchase Targets. If you select multiple locations for the same supplier, you’ll have the option to combine purchase requirements by selecting “Group Buy.” Here you can then decide the purchase location to combine requirements into. Learn more about Group Buys here.
Using Transfer Backorders
In the Settings page within Recurrency, you can decide whether or not group buys (which includes both Purchase Groups and Ad-Hoc Group Buys) should automatically create a Transfer Backorder.
Transfer Backorders (TBOs) are registered at the purchase location and indicate how much of the incoming Purchase Order should be transferred to the requirement location.
Using TBOs significantly impacts how netstock is recognized at different locations. Consider the following example:
In this example, we’ve bundled the purchasing amounts needed into a single purchase line into Los Angeles. With Transfer Backorders, we’ve also automatically allocated the amount needed for San Francisco and Sacramento.
Netstock combines your currently available inventory, increments by any incoming stock arriving at that location (e.g. incoming POs, transfers, etc.), and decrements any outgoing stock (e.g. reserved, outgoing transfers, etc.). The Purchase Order we created is linked to Los Angeles, so San Francisco and Sacramento locations do not show any incoming stock from Purchase Orders. With Transfer Backorders, San Francisco and Sacramento do show the incoming transfers, so their netstock is increased by the TBO amount.
For Los Angeles, while it has 37 items incoming on the Purchase Order, the TBOs allocate 22 of those for outgoing transfers. So Los Angeles’s netstock is only incremented 15 (37-22).
Transfer Backorders make it significantly easier to understand how the inventory from a Group Purchase will be split amongst the grouped locations. Automatically creating the TBO also ensures that inventory moves as quickly as possible from the Purchase location to the Requirement locations.
Not Using Transfer Backorders
There are cases where you may not want to use Transfer Backorders (TBO), including:
Long Lead Times: When you make a Group Purchase, you are making determinations about purchase amounts based on the current state of your inventory. If it can take several weeks for that inventory to actually arrive, the actual amounts you want to transfer to your requirement locations might change so you don’t want those TBOs automatically created.
Requirement Location Warehouse Space: Not all locations have the same amount of physical space. A requirement location may need a certain amount to meet demand over an extended period, but they can’t actually hold that inventory at that space. In these cases, you still want to group purchase to ensure all locations are having their needs met, but the inventory needs to stay at the Purchase location and then be incrementally transferred to the requirement location
Without TBOs, there is no record that the requirement locations will be receiving increased inventory at some point. This means their netstock never updates after the Group Purchase is created, potentially leading to a scenario where a location appears to need more inventory for a specific item even though there is an open purchase order that accounts for it.
For example:
Los Angeles now looks like it has way more stock than it needs, and San Francisco and Sacramento are both still very low. If you aren’t paying close attention, you could accidentally issue a second round of purchase orders for San Francisco and Sacramento.
The important part though is that the total netstock across all locations is the same if you use TBOs or not. If you don’t use TBOs, you should review netstock and purchase requirements across the entire purchase group instead of location by location.
Recurrency provides a setting called Purchasing Hub and Spoke to manage this scenario. If you do not plan on using TBOs, you should change this setting to Group Locations into Single Lines. This will ensure that Purchase Groups calculate the recommend purchase quantity by first aggregating the netstock across the purchase group.