I am wondering how people are dealing intra-company movements of stock. For example, for a business which owns several stores with a central warehouse, how are people tracking the transfer of stock between the central warehouse and the stores? Anybody doing more than simple Stock Transfers? We want to be able to make the transfer more like a sale, in so far as, the retail store would make an order for the inventory they need and then the retail store would be able to check the status of the order as it flows through DEAR Inventory.
Anyone doing something like this? Any ideas?
so far it seems to work. We are also integrated to VEND iPad POS and the inventory stays nicely in sync (except when we don't follow the process ...)
Thanks Dan! That's helpful.
Hi Stan and Dan,
We are implementing 17 versions of DEAR Systems where a Central Warehouse supplies 16 other entities. Some of the other entities also supply each other.
We are dealing with this scenario by using the API interface so that one entities purchase order is posted as a sales order in the other system automatically for approval. This follows the standard workflows built into DEAR Systems without the need to duplicate entry.
If you are running more than one entity on the same DEAR Systems installation (using tracking in XERO - assuming you use XERO), you can consider the following as an option that leverages ALL of DS's capabilities:
1. Create the Central Warehouse as a Supplier in DS
2. Create the Outlying Stores as Customers in DS - linking the Outlying Store to the Outlying Warehouse
3. Agree an intercompany price list / policy that charges the stock at average cost - the margin calc = 0% ... the easy way to ensure no margin on the price is to simply enter the following formula in the quantity tab : Price Shown *(1 - Margin Shown) ... if margin is positive or Price Shown * (1 + Margin Shown) if margin is negative. For example : 8 * (1 - 0.375) = 5, or if the price was 10 it would be 10 * (1 - 0.5) = 5
3. Create a sales order in the outlying store that needs the stock - effectively ordering the quantities required. Specify the outlying store as the customer and the fullfillment warehouse as the Central Warehouse. You can use the backorder feature when these Sales Orders are completed which will ensure that the central warehouse can easily place orders with 3d party suppliers and stay on top of demand via a central distribution mechanism
4. Pick, pack, ship and invoice this order as per normal. If there are courier fees or other handling fees, add them on the sales order and then export the sales order - there is an export button at the bottom of the order which will create a CSV which you can use in step 5 below (you will have to move the comment header to the right to be able to use it). The stock is removed from the central warehouse while being transported.
5. Create a new purchase order - specifying the central warehouse as the supplier, but the delivery warehouse as the outlying store. Use the CSV import button to avoid duplication of entry (remember you will have to edit the csv header - moving the comment column. But it is quicker than entering the data)
6. Make sure to include any courier fees included (if the policy is to include handling fees in the cost of the stock - otherwise pass courier fees to an expense account)
7. Receive the purchase order into the outlying warehouse. Process the paperwork as per your governance standards (separate or same person ...). The net effect is a movement of stock from the central warehouse to the outlying warehouse using pick, pack, ship, receive and pack onto shelf. There is a net zero movement in quantities on hand for the group. If handling fees are capitalized, then the true cost of the stock will be reflected in the outlying warehouse.
8. You can setup an intercompany clearing account and settle the events to that clearing account which means your aged debtors and creditors will always be accurate. If you want more info on how to, just let me know.
The big advantage of this approach is that there is no deviation in methods - whatsoever. Each entity is effectively run as a warehouse with full governance. The costs can vary across warehouse - which helps for more effective management decisions.
Let me know your thoughts.
Thanks Guy. Very interesting. I bit involved, but it makes a lot sense and seems to be an effective and relatively efficient way to get it done with the current system. Thank you for taking the time to write it up.
Who does this in your organization?
You mention you use the API. By that, do you mean using the export and import of data for sales and purchases, respectively?
By the way, when you say you are "implementing 17 versions of DEAR Systems" are you saying that you have 17 separate subscriptions, or 17 locations in one subscription? If 17 separate subscriptions, why did you choose to do that versus one subscription? Are the retail locations separate legal entities?
RE the API - it is DEAR's application interface - a set of RESTFUL Web Services allowing us to do some pretty nifty things with the software.
So for example, we are implementing 17 versions of DEAR system (each a separate subscription as each is a separate legal entity), one of the 17 being a central buying and distribution warehouse. So the other entities place a purchase order to the central distribution warehouse. We use a CRON job (a job that runs off a computers clock at defined intervals - every minute) that looks for all new purchase orders in the 16 entities relating to the central distribution warehouse. When it finds a purchase order, it automatically creates the sales order in the central distribution warehouse for fulfillment. This gives the business a near real-time way of managing demand across the group.
Further, the central distribution warehouse charges a defined margin (markup) relative to average cost. We again use the API to dynamically update the price list in the central distribution warehouse and further update the pricing in each of the other entities so that we have daily pricing running in the business.
The export and import of data using the interface is different functionality.
Shout if you want to know more or if we can help in any way.
Thanks for all the information Guy. I have a tech background, so I understand a bit about REST and web services, and I definitely know cron from my UNIX programming years. I do not have my fingers in the code much these days, but I would love to learn a little more of the technical details you are doing for your systems integration. Sounds like might have a LINUX system sitting in between your DEAR instances, with some kind of interface (maybe just a file) for that homegrown system for updating the prices.
We use the issue to production module to assign stock to other departments at full value and also charge an internal margin which is a code we have created for the difference so each department is charged the full value of the stock if they use something from our shelf for a job/
Thanks Michelle. How do you reflect the different departments when you do the Issue To Production transaction?
Hi Dan - When you mentioned that "The shipper fills the order in the morning, updating qty where necessary and adding comments re availability etc ... and completes the transfer. " I assume the shipper does the comments on a line-by-line basis. I am filling like the Stock Transfer needs a comment field for the overall stock transfer, in addition to the line-by-line comments. Thanks, Stan
Seeing this thread is from a year ago. Has Dear made any headway in creating functionality for this very common requirement for multi-site support? Love Guy's insight, but to have to export a sales order, then recreate it as a purchase order seems crazy.
Also hesitant to make our primary warehouse a supplier when we want to track its inventory against Woocommerce orders.