by Usama Ahmad | Nov 28, 2017 | New Features
One of the pet peeves of users selling in multiple Eurozone marketplaces is that they are currently required to enter COGS for each marketplace individually.
It is common-sensical enough if you are selling distinct products for each country, or your COGS vary per marketplace for the same product; it is, however, a bit of a drag if you are carrying the same products for all 4 Euro marketplaces and they all have the same COGS.
We have just deployed a feature which makes this burden more tolerable. As of today, when entering COGS for a Eurozone MP via the user interface, you have the ability to click on a button called +Propagate to Other Marketplaces which will… well, er, propagate the COGS you are editing to your choice of other MPs within the same account.
The same feature is available when you use the bulk upload feature: One spreadsheet upload is now sufficient to populate one/any/all of the 4 Euro MPs within one account.
by Usama Ahmad | Nov 28, 2017 | New Features
Not much more to say on this one…
In the Sales -> Orders screen, click on the Tags cell for any given product and type away.
Comma-delimit your input if you want to add multiple tags at once.
by Usama Ahmad | Nov 28, 2017 | New Features
We were not proud of it. Not one bit. I mean the OOE screen did the job, but it was ugly and impractical, right?
No more. We’ve cleaned it up and turned it into a data table, which allows you to do column sorting, filtering and stuff.
Please go to Settings -> Operating Expenses to admire it!
by Usama Ahmad | Nov 10, 2017 | Roadmap
Well, whaddayaknow …!
It does not happen very often 
, but I’ll admit it, I was wrong. (It often happens I’m wrong, just that I rarely admit to it.)
It’s about the storage fees thingy. I have, for a very long time, maintained that Amazon do not provide us storage fees by ASIN. It turns out they do.
There’s a report we already download for other purposes which contains the storage fees by ASIN. A couple of subscribers kept telling me of that report, and I always dismissed it.
I never denied that the report contained ASINs and that it contained storage fees. But I always said these were not reconcilable with the financial transactions we receive from Amazon, which form the basis of all the financials in SellerLegend. So, I was adamant we would not use this.
Now, thanks to Michael’s tenacity, he forced me (yeah, against my will), to have a second look, and lo and behold, there was light!
The storage fees we receive in Amazon’s financial transactions do not carry an ASIN. That is because they are organized not by ASIN, but by fulfilment centre. And also, the fees are delayed by one month. So September fees are passed in October, for example.
Once you take these two facts into account, (and you disregard the fact the report says the reported storage fees are just an ‘estimate’), the report with the ASINs matches the financial transactions by FC exactly.
What does that mean, you say?
Well, it DOES NOT mean that your profits or fees in SellerLegend will be any different. We always considered the storage fees in settlements and, recently, in the P&L. But we counted the storage fees at the total aggregate level.
But it DOES mean that we will soon be able to assign monthly storage fees to ASINs and therefore save you a load of time calculating this manually. It also means you will be able to have a more precise product profitability.
It also means that you’ll be able to gauge how much an ASIN costs to store in FBA and compare the cost against 3rd party storage solutions.
Now, how we squeeze this in the development cycle is another story. I’ll keep you posted.
by Usama Ahmad | Nov 4, 2017 | New Features
Over the past couple of weeks now, we have been downloading orders and financial transactions every 30 minutes instead of every hour.
And by the looks of it, no one even noticed.
In the 20 months we have been operating since launch, no one has ever broached the subject of orders excessively lagging behind.
No one.
Even the XXL accounts (400,000 orders a month and more) have been happily operating with hourly order updates.
Nevertheless, we wanted to experiment and see how our servers would handle doubling their load. The experiment has allowed us to (extensively) optimize the application design and after the optimization, the doubling of the load results in only 9% more server resource utilization.
So, we’ll let the current configuration run for a bit longer (until we have about 5 weeks of performance data). We will then implement a scheme whereby high-volume accounts get refreshed every 15 to 30 minutes and low-volume accounts get refreshed every 45-60 minutes.
And no one will even notice. But it is a nice feature to have marketing-wise. We now just need to find a catchy (or nerdy) marketing name for that feature
