We regularly transfer stock to FBA, either by pallet load or by Parcelforce shipment.
At present we are creating a new order, populating the order with the items, setting the sale value as zero and then either generating a courier label through open orders and processing, or booking a pallet and then processing once it is collected.
This has the advantage of:
1. Accurately keeping a nice audit trail of what was processed, who processed it and when it was sent, with tracking details
2. Ensuring that keying in errors are not present as opposed to manually adjusting stock levels
3. Allowing us to easily print courier labels for the shipments from the open orders screen for small shipments
In reality for us, given the price to book a time specific pallet delivery to FBA it doesn't actually work out much cheaper per unit to use a pallet compared to using 30Kg boxes by courier a lot of the time.
This also has 2 related fundamental problems:
1. If we use open orders to send 50 widgets from default to FBA, this counts those 50 widgets as a sale when we send them to FBA, then when FBA sells them it counts them again (ie we get 100 sales in our query data screen where actually only 50 are real, the other 50 were just the transfer from default to FBA). This is a huge problem as we use linnworks sales data to generate our reorder levels
2. As we set the value of the order as zero when it is sent to FBA, this is messing up our average sale price data for our stock as it's counting the order to FBA as a sale, and a sale with no value at that. Again we rely on this data to give us an indication of our revenue / profits for each week / month.
So moving towards a better solution, would it not be worthwhile adding a button to the new order screen called something like "FBA transfer" which allows us to create an order for FBA, deducts the order from default (or wherever it is being sent from) but ignores the order for the purposes of gathering sales quantities and values?
From a technical perspective this should be quite simple, it would give a full audit trail, linked to the user who created the order and then to the one who processed it and also would allow the FBA transfer to be tracked but would not contaminate the sales data as is currently the case.
Any reason why this is not a good idea?
You make a really good point about the stock being in nowhere land.
With that in mind our spec would be:
1. The ability to print courier shipping labels from linnworks for goods being sent to the FBA
2. Once goods have been sent to the FBA, they get deducted from 'default' and added to another location perhaps called 'FBA transit'
3. Once FBA starts checking these goods in every checked item gets deducted from 'FBA transit' - items are already added to the FBA location in linnworks so this bit is already in place.
With respect to reorder levels, I personally just use query data to pick out FBA sales.
Ideally you'd book in FBA transfers from a completely separate screen but for the sake of making development time small, I could live with it from open orders. It's essential for us to be able to print off a courier label easily and have the tracking number stored in the system and also for the stock to auto deduct from default.
This is a common issue for Amazon sellers and one I hope will come in a form of a feature or at least an app in Linnworks soon. To my knowledge (and this is dated knowledge and I will need to confirm) Amazon didn't have this feature available in their API, though if/when this changes then I think it would be a great feature to include in Linnworks Warehouse transfer tool.
All the best,
Fitted Commerce - Ecommerce Agency and Linnworks Specialists
The Linnworks User Hub - Facebook Group
"This is a common issue for Amazon sellers and one I hope will come in a form of a feature or at least an app in Linnworks soon"
I'm not sure which bit you are referring to, but if you mean 'stock in transit' it is possible to to capture stock that's inbound to Amazon...as soon as you click a Shipment 'Mark as shipped', it shows up in the corresponding Amazon report (which can be download via their GetReport API ...I'm pulling in this report presently via my own API.
It's my main issue with the position that linnworks finds itself in presently, it increasingly feels like 'go and pay your own developer / do it yourself' is often resulting in multiple less than perfect individual systems being developed instead of one common, well thought out solution.
FBA is huge, to not have this sorted is a real disappointment (as well as a real life headache for us on a daily basis with respect to generating stock reorder levels as I will not allow staff to make manual edits to stock levels which means all FBA has to go through open orders in order to generate an audit trail and hence is counted as a sale by linnworks of zero value).
One can only hope that this is a transitional period to .NET and these issues will be resolved - although it's not exactly a new issue.
I was so desperate to get this all sorted, like I say, I learnt how to write an API....the irony is it took me along time to learn how & deploy (& I came to Linnworks as it was meant to save me time!).
As an aside, I've just been reconciling Amazon (it was their fortnightly disbursement period yesterday........my accounts was peppered with errors due to Linnworks not being robust & capturing the correct order data....
1. Multi Quantity order not being captured (e.g. 4 of the same item sold, Linnworks only showing two sold)
2. Multi item orders errors (i.e. several different items sold, Linnworks only ccpated a couple
...then of course there's the fact that Linnworks doesn't capture Amazon shipping rebates (that was a lot of work for me to deploy my own workaround)
"It's my main issue with the position that linnworks finds itself in presently, it increasingly feels like 'go and pay your own developer / do it yourself'"
It seems to me that the future for Linnworks is 'providing a framework' & then selling third party apps....
App stores work when you have millions of user's, I would say for linnworks' user base an app developer would rarely see a return on their time invested. I particularly think that the idea of anyone sticking around to maintain these apps once they realise that they only have 10 users paying for them and it's not worth the bother is pure fantasy.