Needing to import data to inventory items to a custom field. Any wisdom?
I'm seeing this has been an idea 'Under Review' for 6 years.
I'm coming across to Lightspeed with a new setup currently and wondering how this hasn't yet been implemented.
I'm getting to the point where I'm close to telling the company director to not go with Lightspeed because it will be impossible to efficiently manage the data.
I see people on here trying to find workarounds using the API though when they post a response detailing how it didn't work there's no response.. 🤷♂️
I was thinking I might be able to pull our Custom Field data across from Woocommerce, though what I'm finding here isn't giving me much hope it can work..
.. The alien does not concern itself with the opinion of humans ..
We have definitely utilized the Retail API for importing inventory items. Here is documentation that involves this endpoint --> https://developers.lightspeedhq.com/retail/endpoints/Item/#post-create-an-item. If you don't have developer-type staff at the ready for facilitating this then there are third-party Lightspeed partners who could assist. Although this would be very beneficial to have included in the Retail web UI.
One caveat about custom item fields. Our business model required a fair amount of item classifications and attributes. Which weren't supported out of the box. Our Retail account rep recommended we begin to leverage custom fields.
For one thing, custom fields aren't really available for any sort of reporting in the Retail web UI. The only way you can really access them are via the API. For another thing, the more custom fields you have defined and the larger your inventory set is, the slower the Retail web UI responds (e.g. - when entering a new item into inventory). Just a heads-up that performance can suffer.
Also piling on the Custom Fields don't help bandwagon. You can't search for them, they don't show up anywhere, they don't do anything (except be there for the API or to look at on the Item record). We needed to store lots of data elements like wine vintage, grape, etc. But no point doing it in LS because you can't use it for anything. We keep a separate item master database and data warehouse for reporting, etc.
At one point (after they had said "of course we have custom fields" and I had signed up, then learned all this) LS suggested Tags was their answer, but it's not a real solution - but take a look.
You will have data challenges, and they will be worse if you try to use both Retail and eCom.
It's interesting to see how each of you were told to use different things for the data storage, one Customs Fields, one Tags..
@gregarican, thanks for your feedback, really helpful to know. ;)
Going deeper on that, did you find that the performance also impacted on sale processing in POS or only back-office operations?
Did you find that there was a 'breaking point' where it became unusable and you had to cut back, and whether there's any difference in the impact whether it's a) having too many Custom Fields, or b) too many variables in a small number of Custom Fields, or c) it's just the combined total of additional data?
Given this would I be correct that you see the same performance degradation over time as your database grows, or was this specifically noticeable with Custom Fields?
@VintageWineGuy, thanks for your example. Yes, I'd been starting to wonder whether I should just not use these Custom Fields at all given what you guys are saying. I guess this must be why after 6 years they've never added them to the Import/Export functions.
My example is similar where I wanted to store specific measurements for each bicycle size that would be taken across to Woo to be used in a filter.
I tested Tags for this though it's just not feasible. Firstly because I need to store a number like '52.5cm' and Tags strip full stops (.). Also, given there's no header associated with the data, I can't see how it's practical to manage in any way. Persoanlly Tags look to me like a hacked on solution, maybe useful for amateur retailers that want to put fluffy names on things, though fairly pointless for anyone who knows what they're doing.
I would prefer to manage all my data via a single import, so maybe I have to reverse my thinking and have Woo as my primary data source where I create Items.
This is inconvenient and will no doubt create hassles for our accounts person who normally does the Item creation..
@Al_Cycleworld : here are a few responses :)
We found the primary slowdowns involved with custom item fields to be in backoffice inventory management (e.g. - adding a new item, editing an existing item) as well as API requests. And yes, the performance grows worse the more items are added into inventory.
I think the last time I measured, it takes about 45 seconds after an item is saved until the screen pops back to display the record was processed along the top banner area. We have about 8,000 active items with roughly a dozen different custom fields defined. I'll include a screen shot of them.
As for the API, if I pull an item list without including custom fields the response comes back in a second or two. If I pull that same item list including custom fields it takes 10 times longer to get the API response.
We haven't abandoned using these custom fields, and just accept the lag times as the cost of doing business in this regard. Although it is disappointing that we weren't pre-warned about overly-relying on them and the fact they aren't accessing in most of the Retail or Analytics UI. This was the suggested solution path by our account rep before we went live.
Yes, I can see where your 'Accessory Dimensions' field could cause a blowout in data size given it's including what I would refer to as the variant header in the field content.
Perhaps efficiency would improve if you created individual Custom Fields for 'Length', 'Lug Width' and 'Buckle Width'. Then the related data could reduce to '115 / 75mm', '20mm' and '16mm' respectively. Though obviously that depends upon how many different variant "headers" you've got in use within the field already. Maybe something to ask the Lightspeed guys about.. 🤷♂️ (even better if they see this and respond here to educate all users..)
This is something I've been considering when creating my Items, being in a seasonal industry we have 21k, though I'm only bringing across 5k initially. I've currently got Size and Colour Custom Fields and will try to only add additional fields when it's a necessary piece of information to display purchasing variant options to the customer. I was initially planning to use Custom Fields to hold what would become Filter options on the website, though it looks like that's not feasible. If I told my accounts guy that he will have to wait 45sec every time he edit an item he'll blow is stack! 😄 My thinking now is that unless the data applies to an actual variant displayed on the website it should be in the Item Description or Specification page text. Complexity is your enemy.. 😉
Arrrgh, I was editing this post and the stupid thing deleted it! (Got to remember to CTRL+C before posting. 💡 ) Here we go again... 🙄
@gregarican, thanks for sharing your experience, it's very helpful. I can see where your 'Accessory Dimensions' field could cause some data bloat as the data content contains what I would actually refer to as variant headers. Perhaps 'Length', 'Lug Width' and 'Buckle Width' would be better converted in to their own Custom Fields, then the actual data could be reduced in size to '115 / 75mm', '20mm' and '16mm' respectively Though that obviously depends upon how many different "headers" you've used in that field across all Items. Would be great for @Lightspeed @Lightspeed Team to chime in here and advise if this suggestion is a path to any substantial improvement..
Being in a seasonal industry we've got 21k Items, though I'm only bringing across 5k initially then will add any stragglers as we go. I'm starting with only Size and Colour Custom Fields and my plan is to only add more if the data actually relates to a purchasing variant for the customer to select on the website. If the data isn't required by the customer to purchase, then it can go in the Item Description or Specifications text.
I had initially planned to use Custom Fields to store the data that would wind up as Filters on our site, though it looks like that's not a viable option. It means we will have to have fractured data management for Retail vs. Online and I won't have any of the website filter data stored in Lightspeed, only in Woocommerce which is tedious, though it does mean that each database will be kept to optimal size. Complexity is your enemy.. 😉
Can't wait to mess with my accounts guy and tell him he's going to have to wait 45sec every time he enters a new Item. He's going to blow his stack! 🤯 😄
💡 Sounds like you're sorted using the API. While searching for solutions I came across Hyperspace, who provide a solution for importing Custom Fields which might be of help to other users. Having a talk with someone there today. https://hyperspace.zendesk.com/hc/en-us/articles/360024461213 (https://hyperspacehq.com)
My recent struggles are outlined here as well. Not sure we can move forward with LightSpeed. The slowdown issue is a real concern. We have 20,000 items and if 8k are giving @gregarican fits, I can't imagine how long it would take for new items we add daily.