Intra-Company Transfers - Corporate & Retail Stores
Stan Ward - Inventory Technology Partners
Hello,
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?
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.
4 people like this
When creating transfers between a warehouse and retail stores or other locations (in the same entity) it would be very useful to rely on the re-order point and re-order quantity to create the transfer quantity. This would mean the movement parameters loaded by sku for a receiving location could be evaluated against available stock to determine what the transfer should be. This can then be fulfilled by the sending location. Dear has this functionality for Purchase Orders to vendors so expect the translation of this to an intercompany transfer between locations should not be difficult to apply. Saves plenty of time as the work needs to be put in upfront to get the the right re-order levels but then the transfer between locations is then a "push of a button"
3 people like this
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.
Kind Regards,
Guy
2 people like this
Hi Stan,
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.
Rgds, Guy
1 person likes this
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/
1 person likes this
We supply our wholesale customers and three of our own retail stores from our central warehouse, and we have struggled with this.
This is what we are currently doing:
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 ...)
1 person likes this
Tom's solution would definitely be the most elegant. This would resolve a lot of manual work for many businesses.
I can see there are a number of other topics / requests that are fundamentally wanting to achieve the same outcome.
DEAR, any thoughts on this?
AtoB Taxi/cab to Stansted Airport &taxi from Stansted Airport. AtoB airport taxi meet you at Stansted Airport and transfer you anywhere in the UK
https://atobtransfer.com/london-uk/stansted-airport-taxis-transfers/
Thanks Michelle. How do you reflect the different departments when you do the Issue To Production transaction?
Guy has a good idea but it seems that the process is a bit long.
For example in my case we have 2 legal entities and 2 dear implementations. It happens that a customer wants something and usually the order is processed in Dear 1 but we are out of stock so we will take it from Dear 2.
The problem is that we just ship it from the warehouse in Dear 2 so it never actually goes to Dear 1 so exporting the sale and creating a purchase order every time can be quite time consuming.
Any suggestion on a workaround so we still keep track of our stock movements?
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
Thanks Dan! That's helpful.
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.
Thanks,
Stan