I am in the process of setting up a third party fulfillment service, whom has limitations on their ability sync inventory across stores, and as such investigating the concept of having a single store to consolidate the orders and route them their WMS.
Effectively, there are 5 stores, feeding into a gateway store that connects to them. Once an item sells in one store, if the inventory is stocked in another store it is reduced in that store in order to not oversell the item.
Key things to sync would be:
Orders (to the gateway store)
Available Stock on hand (from the gateway store)
fulfillment information (from the gateway store)
Possibility product data (from the gateway store) - Create/Update (same data)
SKU’s are universal, IE: SKU123 would be the same if in multiple stores.
I think additionally, some logic/considerations on the import would be needed:
Changing carrier name/type on orders coming in (in order to route more efficiently based on postcode/channel/etc),
changing the order value to $0, as i dont need to double record this and possibility some other fields (ie: name of customer/etc).
changing the variantID would be needed from webhook order.
preferably fast as possible (catching the web-hook on order creation on the from store and fulfillment back)
inventory would need to be pretty quick to sync to stop any overstocking.
Wondering if anyone has gone down this path before, has any considerations that they would share or even if anything exists to do this. Manipulation needs to happen which lends itself to an IPaaS, but speed is critical.
Total cost of ownership is the biggest problem either building that process or using apps and any maintainence and testing etc.
For new store projects it could be drastically simpler to just have the other sites be frontend proxies for which all checkouts happening on the central stores checkout using the draft orders api, or shopify buy buttons, etc.
Check if the 3PFS has a simple CSV process, it can be drastically simpler to first build a process to collate orders then email a CSV from excel than to finish building a multi-facted api sync for across multiple stores each with their own aspects.
Make sure customers aren’t getting hit double in different areas: payments, notifications , or shipped goods, automations, app behaviors, etc etc.
If the 3PFS does not have an api to interface then you will need a store to store sync app or combination of apps, or use a scriptable app such as usemechanic to build a series of custom processes. There are already starting sync scripts but all are for within a single store. https://tasks.mechanic.dev/?q=sync
There’s also the matter if each individual store has it’s own set of dedicated locations which also have inventory per location or a a prime location that already syncs all inventory for that stores locations. Or other inventory considerations like it’s own inventory pooling because it’s doing something like bundling, or packs, etc.
If the budget matches this level of criticality then you probably need to build you own sync solution to be efficient as possible.
One of the things to watch out for would be infinite loops if using webhooks for a two-way sync. Also some events trigger multiple webhooks - for example order creation will trigger both the inventory update and order create webhook.
We’ve done some of this using our platform, happy to discuss - please email me at anto@comstack.co
Can you share more details about the 3rd party fulfillment service? What integration channel is available in their WMS? Where do the limitations come from?
They have a FTP pickup and dropoff but there is an SLA against this. Realistically I agree that the ownership is the problem in this. Additionally, we provide same day fulfilment (against an SLA), so CSV is not ideal to inbound and outbound SOH/Orders/etc in bulk.
The 3PL has an API, but there is no real API doc’s available to actually use the API and understand how the system works and functions.
I had though about mechanic, but running a multi instance mechanic is a cost inhibitive exercise.
I think the interim is to use something like orderhive to get past the volume of christmas, then go back to either build a custom function and/or more unified solution (either within shopify and/or in an iPaSS) next year.
I figured you would need one store as the inventory source of truth, then each store sends order to that store (at $0.00), and the source of truth syncs back the actual position.
To make it a little more interesting, some products are listed in bundles, where components are shared across multiple sku’s.