Lots of data to import

[jmca1968]

v1.3.8a - new user
I have 15,000 unique products. Lets say 30 of them are the same product (t-shirts), but different colors. Should I set them up as individual products, or make use of the product options?

[stevesh]

I would use attributes.

[Muzz]

v1.3.8a - new user
I have 15,000 unique products. Lets say 30 of them are the same product (t-shirts), but different colors. Should I set them up as individual products, or make use of the product options?

I would set them up as Both.

Customers may only potentially view something if they like the color and design. If they see a T-Shirt thats blue for example. Perhaps they don't like blue and don't realize that they can then view the T-Shirt in more detail and select optional colors. You would potentially be turning customers away.

One Method:

Category: Brand: your brand
Product: T-Shirt
Set up attributes for sizing with drop menu.
Set up attributes for each color.

Do NOT ad image yet for T-Shirt.

Then duplicate the Product (Do NOT link it) the number of times you have colors for that T-Shirt. (Example 3 times)

This means you then have 3 empty T-Shirt lines setup with ALL attributes included.

You then login into each product and upload a specific color for each of the 3.

You set the attributes color default button on (Inside attributes of the individual product) to the relevant color of the product your editing.

Hope thats clear enough.

[schoolboy]

I would set them up as Both...

I disagree... You'll have big issues with stock management, and you'll also create lots of duplicated work that will get really confusing. Let's say you are out of stock on LARGE, BLUE, GOLF-SHIRT...

... you will need to edit data in TWO OR MORE places! Can get VERY out-of-hand and will take up ALL your time!

Muzz's technique requires you to add the data MANUALLY. When do you want your store to open... ? In 2020 ?

Far better to use attributes - esp. if you have over 15,000 items.

To upload all this data, you'll need to be very organised.

Does the 15,000 include all different sizes and colours?

... or are there 15,000 styles - each in a range of colours and sizes?

Your answer will help me advise you on how to organise the data for mass upload...

[jmca1968]

Thanks to everyone that replied. Schoolboy, the answer to your question is yes. Let me give you a better example. We will be selling fishing supplies. With that said, the better example is a fishing lure. We have one lure that comes in 5 different sizes and six different colors. Therefore there are 30 unique products just for this one lure. The data from the vendor is just a CSV file of product and price. What I am trying to figure out is:

1. The best way to set the products up in the site (which you have already started advising me on)

2. The best format for the CSV so that I may import the products and not have to do manual data entry for each product. I figured the data structure in the CSV would depend on the answer to number one above.

Thanks for the feedback!

[jmca1968]

Below you can see an actual example in sizes 4, 6, and 8's and two colors; red and white

Unique ID Desc Price
TD03R-RB4 DAIICHI BLEEDING SABIKI Red $1.44
TD03R-RB6 DAIICHI BLEEDING SABIKI Red $1.44
TD03R-RB8 DAIICHI BLEEDING SABIKI Red $1.44
TD03R-W4 DAIICHI BLEEDING SABIKI White $1.44
TD03R-W6 DAIICHI BLEEDING SABIKI White $1.44
TD03R-W8 DAIICHI BLEEDING SABIKI White $1.44

[schoolboy]

From your example, it appears that each variant of the lure is being regarded as a unique product, as each variant has its own SKU (Product Code).

EG:-
Product_model = TD03R-RB4
Product_Name = DAIICHI BLEEDING SABIKI - Size 4: Colour Red
Product_price = $1.44

So, the CSV your supplier is providing is actually a list of products and their variants, where each variant is treated as a SEPARATE PRODUCT.

If you decide to SPLIT OUT the size and colour from each product, so that you can later format this as ATTRIBUTES to a single product, you face a difficult choice. Attributes CANNOT have unique product codes, because zencart regards an attribute as a CHARACTERISTIC of a product, and not as a product itself.

So, if you split out these CHARACTERISTICS (size and colour), you are going to also affect the base product code, and this will require a mass edit of the data your supplier provides.

For example (use the same one above):

Product_model = TD03R delete RB4
Product_Name = DAIICHI BLEEDING SABIKI
- Colour Attribute = Red
- Size Attribute = 4
Product_price = $1.44

If you go this route, a LOT depends on how the supplier has structured their SKU codes. It look like SIZE and COLOUR are indicated by -RB4 and the base product is indicated by TD03R. If this is STANDARD, then reconstructing the SKU's should be achievable using a formula in MSExcel, where you can delete the size and colour defines.

But even if you do decide to do this, and then apply COLOUR and SIZE as attributes, your work is not yet done!

This presents a bit of a challenge, because zencart does not have the capacity to make attributes dependant.

So, your implementation of product stock management (by ITEM, then SIZE, then Colour) can be difficult.

Dependant attributes work like this:

Customer selects a product
Customer is presented with the first option - eg: SIZE
Customer selects desired SIZE, and his selection influences the display of the NEXT option - COLOUR.
If colour RED and WHITE are both in stock, both options are made available to customer, who then chooses a colour.
If WHITE is out of stock for the SIZE initially chosen, then only RED is presented as an option.

Zencart cannot do this in a standard install, but STOCK BY ATTRIBUTES module may offer an option.

Either way, you have THREE variables regarding your product set:-

Product NAME
Product SIZE
Product COLOUR

If you decide to use STOCK BY ATTRIBUTES module, then the following should be possible:

Products are all added to the database by NAME only.
SIZE is allocated to product as an attribute.
COLOUR is allocated to product as an attribute.

If I were you, I would rather get the business going first, and load up all the variants as INDIVIDUAL PRODUCTS, as this is the way your supplier manages their product database.

OKAY... so you have a shedload of products in your store... but at least the shop is open for business and you're getting sales. If you then CATEGORIZE your products carefully, and make use of MANUFACTURER filtering, your customers will not have too much of a challenge finding what they want.

THEN... Set up a test site somewhere, and on the TEST site, play around with the attributes stuff. See what it will entail before you unleash it on your customers and your admin staff!

The best way to load up products en-masse is to use Easy Populate and I have a WIKI tutorial showing people how to use Easy Populate.

[jmca1968]

You are correct, each variant of the lure is being regarded as a unique product, with the suppliers unique product code.

Because attributes CANNOT have unique product codes, this would screw up the order process with the supplier, so I think I am forced to load up all sku's.

You can see the site at: www.saltydogstackle.com/dev/ I have a few products at: Saltwater Fishing :: Reels :: Conventional Reels.

As far as the inventory, we are using just in time inventory, so I want to turn the inventory off. If this is not possible, I will write a script that sets every product to 500 in stock every night???

Once there you can see on the left I have imported all products to a catagory called - Imported (16504). I guess I figured if I didn't use attributes, I would have a load of products on the site that was difficult to navigate through and just piss off my potential clients. Also, I guess I will have to manually categorize each of the 16504 products.

Really appreciate the help,

Joseph

[Muzz]

I disagree... You'll have big issues with stock management, and you'll also create lots of duplicated work that will get really confusing. Let's say you are out of stock on LARGE, BLUE, GOLF-SHIRT...

... you will need to edit data in TWO OR MORE places! Can get VERY out-of-hand and will take up ALL your time!

Muzz's technique requires you to add the data MANUALLY. When do you want your store to open... ? In 2020 ?

Far better to use attributes - esp. if you have over 15,000 items.

To upload all this data, you'll need to be very organised.

Does the 15,000 include all different sizes and colours?

... or are there 15,000 styles - each in a range of colours and sizes?

Your answer will help me advise you on how to organise the data for mass upload...

I agree that my method is not fast.

In regards to stock management 'stock by attributes' Mod would resolve this.

I would get your point across in regards to different color being available ASAP on the website. Stating it somewhere obvious so potential clients do enter the product information page to see they can select other colors and view them live.

I think a lot of users like myself may browse a website looking for something in a particular style and color.. if I don't like the color I won't enter the product information page. If I don't enter the product information page I wont see that you have other colors available.. thus loss of a sale.

Another method I use is that I create attribute templates.

You could do this with various color ranges.
You can do the same with sizing.

Then you can either apply the attributes to an entire category or to individual products as desired.

Not sure what Mods your using but would also suggest you check out EZ populate and AJAX image swapper.

Good luck... just remember the ultimate goal is to create sales. Create a plan for the long term because with that many products turning back the clock will probably make more work than starting over again.

[ALiepinieks]

not sure about the comment...

"Because attributes CANNOT have unique product codes, this would screw up the order process with the supplier, so I think I am forced to load up all sku's."

if your codes a relatively uniform (i.e. length and or separators between style/clr) and you have some spreadsheet formula (or macro) skills you should be able to split the data prior to import, and then consolidate it in much the same fashion after export. this would be a far better method as it significantly speeds up your users browsing experience and the flexibility of the data in other environments.