POS Sync Intricacies

How your POS System synchronizes its data

Jeremy avatar
Written by Jeremy
Updated over a week ago

Quite a few edge cases have come into play that are the root cause of "why" information is synchronized a particular way and how we handle when things should be different. This article will clear up the feature and what you can expect for the following information.

  1. Product Information

  2. Inventory Information

  3. Pricing

  4. Categories/Brands/Colors


Product Information

Depending on your POS, product information gets sent to RunFree periodically and is queued to process.

RICS

With Rics, as information is change, Rics also queues up to send the changes, and every 15 minutes or so the POS sends the product information in large chunks. That data then gets queued into our system for processing, which could take an additional amount of time, generally within 15 to 60 minutes.

Heartland/SpringBoard

As soon as you make a change in Heartland, a webhook send that change over to us. This change then gets queued like Rics, except the full information for what has changed does not come over, so as the queue processes, Run Free reaches out to Heartland to extract the information that has updated.

LightSpeed

Lightspeed does not communicate directly with RunFree, so as your stores queue time comes up, we reach out to LightSpeed and ask them for any changes that have occurred since the last time we asked.

We then process that information, it gets run through a system of checks for valid meta data, this data then gets applied to the product and released into your hands for confirmation for you to place it for sale.


Inventory Information

Inventory numbers get sent in much the same way as product information above, but when orders occur, there is the possibility of a delay that can occur. Please note the appropriate workflow below, so that you are aware of when issues can happen.

Lets take the scenario where you have Shoe A in stock at your store. Someone purchases Shoe A at 11:00 AM online, and at 11:05 AM, someone picks Shoe A off the shelf in the store and buys it.

Rics

Every 15 minutes or so, Rics asks Run Free "Hey, do you have any online orders?" and we respond with "Yes, these are the items that sold and who to". Now Rics processes this order and with their Inventory queue, which could happen, 15 minutes later, they send back the fact that the inventory has depleted.

If someone had purchased the item in the store before the order got to Rics, the online Order will cause a negative value when it is fulfilled.

Heartland/SpringBoard

When an order is created on Run Free, we generate an "Order" in Heartland, that order waits for fulfillment, and once fulfilled in Run Free on the orders screen, which creates an invoice in Heartland, thus depleting the inventory. That inventory change is then sent to Run Free and queued up for an update.

LightSpeed

When an order is created on RunFree it is immediately sent to LightSpeed, depleting the inventory and updated via the queue above.

There are checks and balances in place, e.g. you are shopping on a page with inventory, then someone depletes the inventory in the store. When a customer adds that item to their online shopping cart, RunFree calls out to the POS to see if the inventory is in fact available. That check is available in the logs on the product page which should be the first thing that is checked when an order, that you don't have inventory for in the store, comes in online. You can also view all of the inventory updates and when they happened.

Pricing

For most systems pricing is pretty simple, you can refer to the following POS for more information. Please note, if the toggle switch for the product price update is turned off, we will not receive price changes for the product in question.

Rics

Price updates are sent in another feed, just like inventory or product, and processed every 15 minutes or so, given the load. Price values from the Markdown field in RICS are mapped to the Price field in Run Free. That said, RICS has a special pricing feature that lets you set price changes in the future. These price changes come over, they are queued in our system, then updated appropriately when the time comes. All price updates are completely ignored if "Auto Update Price" is off though.

Heartland/SpringBoard

A price change in Heartland is probably the fastest way to see an update in RunFree as it immediately sends a product update over, and the product is immediately changed, granted, "Auto Update Price" is selected on the product. This is actually our "Go To" method of making sure the POS is properly integrated.

LightSpeed

Like other values in LightSpeed, pricing is updated on a queued basis. Every 15 minutes or so, we ask LightSpeed if the system had any prices change, and they let us know.

Price Rules applied to particular products do not sync with Run Free. ,If you have internal rules changing the price of products on checkout. Instead of LightSpeed accepting the information we sent them, they turn around and tell us what they think we should have charged. This is important to note for a couple reasons.

  • Price Rules change the LightSpeed price, but not the actual tender that the customer paid.

  • LightSpeed has a known issues, for many years, where the system calculates fractions of a penny wrong. Some programming languages think .055 is .06 and some think it is 0.05. RunFree properly calculates the fraction of a penny up so we may charge $20.01 on a order that costs $20.005 but LightSpeed errors and tells us it is only going to record it as $20.00

Categories/Brand/Colors

Now for the confusing part! We have added a group of options in your "Integration Settings" under "POS" for many reasons. These toggles will decide whether or not AFTER THE FIRST time we get sent product data. If that product data will ever be updates by the POS again.

Here is why...

Colors

A lot of time the POS has unreadable values for colors, a color may be 001 and mean "Black" but when it comes over to us, a lot of stores tend to make the colors more readable. Sometimes even simply changing them from "WHITE" to "White" makes it a little nicer to display. Other stores see the values being like this, and update them in their POS. Depending on where you want that update to occur, you can set the source of record with that toggle switch.

Categories

Categories is the second hardest to explain. When categories come over, they don't come over in a nice hierarchy, the systems send them more like a string of tags. We will get something to the affect of "Mens" and "Shoes" and "Running" and again, sometimes they are completely illegible and a lot of our stores want to finesse the categories into a hierarchy and display them nice on their web site. If you have Categories toggled "Off", any update will not be added to our system. If you have it toggled "On" (Here is the tricky part) we will not remove or change any of the nice things you have done on our side, but we will append any of the new categories that you have added on the POS.

So if in the POS "Stamina" gets added as a new category to the show in question, you could have changed the Run Free site to a nice "Mens > Running Shoes", now "Stamina" is a new top level category that will be displayed.

Generally, our stores have "POS Overwrite Categories" turned off.

Brand Name

Brand Name has a couple settings for a variety of reasons. previous to the (September 2022) Run Free release, if you has Relay/Endless Aisle turned on for your store, your brand name had to match the brand that we have in our Relay system in order for the product to sync together. Now though, simply set the linkage on your brand details and their is no need for the brand names to match.

This is big for "Hoka" vs "Hoka One One" and "Brooks" vs "Brooks Running".

Another setting to note is the "Label" field. If you have a brand that in your POS is an awkward name, don't bother trying to make a bunch of changes and sync it up, simply add a override and the override will be used in place of the name in the POS.

Their is still a case where some RunFree finessing can cause some heart ache with POS synchronization. Namely if you have the same brand in your POS two different ways. Let us say for example that you had imported "Hoka" a long time ago as "Hoka One One" but now you started just doing "Hoka". They will both come over and be listed as 2 separate brands, which is an undesirable outcome. What Run Free has always suggested was to simply use the "Move" command on the brands page, and move all of the older name into the newer. (Be careful with this, if you move Hoka into Brooks, you may be spending a few days cleaning your data). But when that occurs, and you get a product update for one of the older products (Price, Info, Inventory) the POS will again send Run Free "Hoka One One" and you will have a product using the brand you moved our of.

In general, we suggest updating your POS to use the same name, but if this is too big of an ask, simply turn off "POS Overwrite Brand Name" in your settings. This will mean any UPDATE to a product will ignore the brand name value and you can keep your work in Run Free. (Note, if you add new products to the old name, "Hoka One One" will come back and you will have to move those over as well)

Blank Brands - One more thing to point out, Rics sometimes initially sends products with a blank Brand "". When this happens, the product sku gets added to a queue that can only check one every 15 seconds and will call into Rics and ask for a better sku to brand name, which usually resolves blanks after a given period of time. If you do not feel like waiting, simply update those yourself.

Did this answer your question?