Shoes Website

Pataman

Hi
I am looking for advise please. We currently have a POS system in our shops. It generates a text file of the stock( sizes, colours available etc) we have for a website.
I want to get a website up and running. I have looked at opencart and like it. However I dont want to have to put sizes in options for every style.
Is there any way of the website getting the info from the text file and then only allowing the sizes/colours we have available to be listed?
I have downloaded emagicone store manager for opencart and it sort of does what I am looking for, but I cant get it to link the sizes I have with what the website displays.

Any advise greatly appreciated
Thanks

daymobrew

I use a free Import/Export module that allows me put the product details and variations (like sizes and colours) in an Excel spreadsheet. It's great.

You could have a program that converts the text file to a CSV file that can be imported into Excel. Then you upload the Excel file.

The program could be a simple script on your web site. As it is just processing text (which is fun) it should not be difficult.

Tom Dunne

Pataman wrote: »

Is there any way of the website getting the info from the text file and then only allowing the sizes/colours we have available to be listed?

Short answer, yes, it would be relatively straight forward.

Long answer, it depends. On the website side, you need a script that would load only the fields you require from the generated text file. Technically, that is relatively trivial to do. It's all the bits and bobs that facilitate this uploading that is more involved.

daymobrew wrote: »

I use a free Import/Export module that allows me put the product details and variations (like sizes and colours) in an Excel spreadsheet. It's great.

You could have a program that converts the text file to a CSV file that can be imported into Excel. Then you upload the Excel file.

The program could be a simple script on your web site. As it is just processing text (which is fun) it should not be difficult.

On a slightly pedantic note, a CSV file is a text file, so you need to be careful with your terms so as not to confuse people. Also, the conversion to Excel is an unnecessary step in the process. Any programmer worth their salt should be able to knock together a script to upload a CSV file and load it into a database.

daymobrew

Tom Dunne wrote: »

On a slightly pedantic note, a CSV file is a text file, so you need to be careful with your terms so as not to confuse people. Also, the conversion to Excel is an unnecessary step in the process. Any programmer worth their salt should be able to knock together a script to upload a CSV file and load it into a database.

You are right about the CSV file.

My pedantic comment ;-)
To import the CSV into the database you would have to learn the relationship between the CSV/Excel cells and the database structure. The OpenCart Import/Export module does this correctly so there is no need to reinvent the wheel and potentially introduce bugs.

The Excel file that is uploaded to OpenCart contains product descriptions and prices in one sheet, with the variations in another. There are other sheets for vouchers and discount codes.

Pataman

Thanks for the replies. I cant update it manually. It needs to update with new styles as they are added to my system and therefore to the text file. This normally updates every 10 mins.
I need a piece of script to update the styles on the website with the content of the text file.
Thanks

Tom Dunne

Pataman wrote: »

Thanks for the replies. I cant update it manually. It needs to update with new styles as they are added to my system and therefore to the text file. This normally updates every 10 mins.
I need a piece of script to update the styles on the website with the content of the text file.
Thanks

By the sounds of it, you actually need a few more bits.

First question, how will the text file get to the website? Automated or manually (sounds like the former)?

Secondly, I don't know anything about opencart, but what infrastructure is it based on? PHP/MySQL?

Pataman

Hi Tom
I have an autoftp which does the uploading for me. I think opencart is PHP

Tom Dunne

Pataman wrote: »

Hi Tom
I have an autoftp which does the uploading for me. I think opencart is PHP

Right then, that's fairly straightforward so.

Any decent programmer could knock up a script to read the text file and load it into the database. Easy peasy.

willows

the issue is the shoe sizes.

So on the POS are each of the sizes a seperate SKU.

If so then your import export is not going to work out of the box.

If you can PM me a sample of the output from the POS then we can take a look see what is involved.

We have met this before, where all POS's treat sizes and variants of products as seperate SKU line items. To get these to group nicely on a website requires a little engineering but the time spent doing this is saved to manually sorting them out every time.

PM me with the details and a sample sheet.

professore

Tom Dunne wrote: »

Right then, that's fairly straightforward so.

Any decent programmer could knock up a script to read the text file and load it into the database. Easy peasy.

Haha might not be that easy ... easy to load it into the database but to do it right, avoid duplicates etc not so easy. I've seen lots of those "easy" jobs before.

GreeBo

professore wrote: »

Haha might not be that easy ... easy to load it into the database but to do it right, avoid duplicates etc not so easy. I've seen lots of those "easy" jobs before.

Thats why you get developers to do it and not "IT" people.
It *is* an easy job...

Mrs OBumble

willows wrote: »

all POS's treat sizes and variants of products as seperate SKU line items.

I think you'll find that is pretty much basic to the definition of a SKU.

But as you say, automating the generation of a product hierarchy which includes a suitable level of website display shouldn't be too hard, proivided all the products have similar dimensions.

willows

well it depends on how the SKU's are coded. If they are all the same where we know the first x characters are the base sku the next are the color code and the next x chars are the size then its straight for a programmer to do but not a solution you can implement with out touching code. Easy Straight forward for web app developers, for DIY'ers you'll burn serious hours and alot of heart ache debugging.

Graham

professore wrote: »

Haha might not be that easy ... easy to load it into the database but to do it right, avoid duplicates etc not so easy. I've seen lots of those "easy" jobs before.

+1

GreeBo wrote: »

Thats why you get developers to do it and not "IT" people.
It *is* an easy job...

It's always an easy job for a developer.

A developer who is probably going to want to know the structure of the database and the data in the exported file.

A developer who is probably going to need to map the data in the text file onto multiple tables in the database, work out whether to update the existing records or delete them and create new ones. The developer may want to check that the field types/sizes in the database are suitable for the date in the export file or ascertain if any pre-import processing is required to reformat the data.

The developer will also need to prompt a decision on how to handle products that are removed from the POS system as records will exist for these SKU's in the database but there may be no reference to them in the export files.

The developer may want to consider stock levels, as in what happens when something is sold from the website? Are stock levels reported back to the POS or is the stock level overwritten in the online store in the next import essentially invalidating the online and POS stock count.

The developer may also consider failed uploads, what happens if the import bombs out halfway through? Can the import be rolled back, pick up from where it left off? This could be particularly relevant if the process is happening dozens of times a day rather than a one-off exercise.

The developer may also think about how to schedule this process, how to make sure it runs, consider what happens if it doesn't run, should someone/something be alerted?

Sounds easy.

daymobrew

Graham wrote: »

The developer will also need to prompt a decision on how to handle products that are removed from the POS system as records will exist for these SKU's in the database but there may be no reference to them in the export files.

I suggest seeing how the Import/Export module works - it will show you the relationships between product info and the database.

WRT products removed, I believe that the module deletes everything before adding the contents of the uploaded Excel spreadsheet.

Graham

daymobrew wrote: »

I suggest seeing how the Import/Export module works - it will show you the relationships between product info and the database.

WRT products removed, I believe that the module deletes everything before adding the contents of the uploaded Excel spreadsheet.

Thanks Damo, I was just trying to calibrate the definition of easy :-)

From the thread it would be 'easy' to jump to the conclusion that this is a 10 minute job for 'a developer'.