What QM Can’t Do (Part 2)

April 19th, 2011

This is the second post in a series explaining certain technical limitations with Quantity Manager.  Today we’ll cover third party tool compatibility.  QM should work OK alongside many other eBay third party tools but caution should be taken when they adjust listing quantities.  In particular we’ll be addressing the situation where a subscriber changes their Inventory in another app and then expects QM to change Inventory accordingly.

Typical issues we hear about include:

  1. I sold something in ProStores® but QM didn’t reduce my Inventory.
  2. I updated listings in Turbo Lister, Blackthorne, or some other listing tool and my Inventories didn’t update.

On the surface these sound like fair complaints.

Why This Isn’t Possible

When certain events like listing creation, sales, or listing revisions occur, eBay sends QM a message.  QM then runs a series of scripts based on the type and content of that message.  When a user revises a listing in any way the message that eBay sends QM contains the quantity available of that listing along with the item number but does not give any uniquely identifiable information.

For our examples we’ll use the following parameters:

Naive Solution

It would seem then that the solution is very simple.  QM should just observe a quantity increase or decrease and reduce Inventory by that amount.  In this example a user simply decreases the available quantity to 3.  QM sees that the quantity available has decreased by 2 and reduces Inventory to 98.

The Problem

It would seem like the above solution should work and it actually will most of the time.  However, in order for this to work every time we must have the following guarantees:

  1. QM will receive all messages.
  2. QM will receive only one copy of each message.
  3. QM will receive all messages in the correct order.

Unfortunately none of these are guaranteed.  Missed messages are lost forever leaving Inventory unchanged.  Duplicate messages would cause Inventory increases or decreases to be doubled or even tripled.  Out of order messages could cause Inventory to go out of sync in unpredictable ways.

Lost Message

In this example the user again decreases the available quantity to 3.  QM never receives the message so Inventory stays at 100 even though it should be 98.

Duplicate Message

In this example the user decreases the available quantity to 3.  QM sees that the quantity available has decreased by 2 and reduces Inventory to 98.  Later a quantity of 2 is sold on eBay and QM reduces the Inventory to 96.  However, eBay sends a duplicate of the original quantity revision so QM again reduces Inventory by 2 to the incorrect amount 94.

Wrong Order

In this example the user decreases the available quantity to 3.  Then the user realizes this was a mistake and corrects it back to 5.  However, the messages are received in reverse order leaving the user with an incorrect Inventory of 98.

Then How Can QM Track Sales?

If you made it this far you may have wondered how QM can accurately track sales if sales and listing notifications have the same limitations.  It turns out all messages from eBay fail to make any of the necessary guarantees.  However for sales and listings these can be easily overcome by polling the eBay site and by having something unique regarding those messages.

Missed sales and listing notifications are currently checked for once every 30 minutes.  This wouldn’t work for tracking revisions because the listing could have been revised multiple times between checks and only the final state would be visible.

Duplicate listing and sales messages are not a problem because each listing and transaction is unique.  If a listing is already in the database the message can just be ignored.  If a sales notification is duplicated then QM sees that the transaction has already been handled so the message is again ignored.

If a listing message or sale message occurs out of order it doesn’t matter for several reasons.  A sale message for a listing not yet in the database triggers QM to retrieve the listing and store it in the database then process the sale.  If two listing notifications arrive out of order they are from different listings so it doesn’t matter.  If two sales messages for the same listing arrive out of order it again doesn’t matter because each message contains the exact amount sold for that transaction.  This allows QM to correctly track the differences in Inventory.

The Good News

As it has been shown there are several pitfalls with supporting this sort of feature.  The good news is that we recognized these issues ahead of time rather than trying to implement a system that had no chance of working.  This means our subscribers do not have to worry about any of the above situations occurring with their accounts.  Instead revision messages are simply used to advise QM of possible changes like price, end time, title, or available quantity (but not Inventory).  None of these impact the way QM behaves.

The Bad News

Unfortunately this means that such a feature will most likely never exist with Quantity Manager nor any other decent 3rd party stand-alone application.

The only way this could ever be supported would require eBay to change the way they handle revisions.  This would require eBay to keep track of every revision ever performed per listing and make that retrievable on a per seller basis.  Furthermore those revisions would need to have a unique identifier and timestamp attached to them.  It is highly unlikely eBay would ever take on such overhead though the site itself does imply that such information is logged.  Anyone is able to click a link on an eBay listing and see what was changed and when it was changed however this information is not available via the API nor does it give specifics.

We have also observed that most 3rd party listing applications make the assumption that they are the one and only app that the seller uses.  What this means is that Turbo Lister, Blackthorne, etc have a tendency to overwrite all settings that were on the listing any time the app is used on that listing.  For example making a simple change to a listing’s description in Turbo Lister can result in any changes that had been made to price, quantity, etc via eBay or another third party tool to be overwritten.  Unfortunately this means that even if eBay did take the necessary steps to allow QM to support this feature it would be very easy for a user to accidentally mess up their Inventories.

Compatibility with specific 3rd party tools could be achieved but would require us working directly with the developers of the other product.  We did try to reach out to ProStores back in 2009 but rather than letting us join their developer’s program they instead ignored us and then ceased accepting new members.  If you are another third party developer and want to ensure your apps are compatible with ours, please contact us.

Leave a Reply

You must be logged in to post a comment.