FBA stock transfers

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?

3 people like this idea
Personally I couldn't work that way (using an order screen to essentially transfer stock). In the end I got so frustrated by this whole shebang, Ipartly rolled my own inventory tracking system.

My biggest problemwith FBA  is ensuring that Amazon don't run out of stock (keeping the pipeline smooth)...Amazon own 'stock getting low' advisory is poor (it's laggy). So, I export Linnworks sales data into Access & do stock prediction in Access (e.g. SKU-01 has had 20 sales over the past month, Amazon hold stock of 10 of SKU-01, therefore they have about 2 weeks stock left.....100pcs of SKU-01 is helf locally, therefore my stock predictor recommends sending 50pcs of SKU-01 etc)

Another problem is that when you deduct stock from Linnworks (when it's on a lorry on it's way to Amazon), it's in 'nowhere land' from an inventory stock level perspective. i therefore rolled my own API to go & get the 'inbound' items from Amazon....I can then embrace these in my stock predictor. I use Linnworks net 'stock adjust' feature, which deducts the stock I've sent to Amazon automatically (no keying errors) using a csv file created from the file I uploaded to Amazon to create the inbound shipment.

I think what ought to be asked for is for Linnworks to better embrace Amazon FBA (instead of a workaround as you're doing -  & also asking for an enhancement of the workaround!). In my opinion, Linnworks out to be able to predict stock for sending to Amazon & track stock that's on it's way to Amazon.


apologies for the typos & bad grammar - that's speed typing for you!


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.

Hey David,

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,

Charlie McBroom


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.

Hi Rob,

I haven't checked it for a while, I will need to see what is available in their API :) 

All the best,

Charlie McBroom


Fitted Commerce - Ecommerce Agency and Linnworks Specialists

The Linnworks User Hub - Facebook Group

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.

Login to post a comment