DB guys - help doing a price upload

[Maury Markowitz]

I'm just starting my journey into Presta's back end, so I'm wondering if someone can help bootstrap me...

 

I need to import retail and wholesale prices and inventory levels into Presta. I have these in a CSV that exports from our inventory system. The Reference in Presta is the primary key from the inventory system, so matching is easy.

 

 

The only twist is that some of the products, about 50 out of 400, are represented in Presta as Combinations. Those do have the right Reference, so I can still match up OK.

 

So...

 

1) can I import prices and stock levels into Combinations? Can someone show me an example?

 

2) if not, can someone outline the tables involved in storing all this data? I'm good with ODBC and SQL, but I'm new to the DDL.

 

Thanks!

[NemoPS]

Hi,

These are the fields needed for a CSV in order to add(edit combinations

 

 

Product ID*

Attribute (Name:Type:Position)*

Value (Value:Position)*

Supplier reference

Reference

EAN13

UPC

Wholesale price

Impact on price

Ecotax

Quantity

Minimal quantity

Impact on weight

Default (0 = No, 1 = Yes)

Image position

Image URL

Delete existing images (0 = No, 1 = Yes)

ID / Name of shop

You can use the regular CSV import and select the combination type. I assume, however, that you erase those product's combinations before trying... But I have never used it so it's just an assumption

[maio]

Hi Nemo,

I've been importing products from csv quite fine,

 

but now a problem has come up:

when i import a product with 4 category it doesn't show up

 

what's the matter with the 4 categories?

 

this happens only when 1 of the 4 categories is "home"

Edited March 29, 2013 by maio (see edit history)

[Maury Markowitz]

Sorry, my notices were going to my junk mail folder, I'm just finding these threads now (the forum software needs to have a list of my threads, that "last 5" is useless!).

 

Anyway, I was able to figure all of this out by going in using ODBC and poking numbers directly into the DB. However, this demonstrated to my satisfaction that Combinations are *very poorly* implemented in Presta. Instead of simply having a normal Product with a flag that says "I am a Combo", instead they have an entirely different table for the combos. Of course, this basically looks just like the Product table. And since I might want to localize it or multi-store it, it also has all the associated tables for those. And since I might want to price it or keep inventory, those too.

 

As a result, combos *seriously* mess up the data model. It really should be dropped outright, and replaced by something called "Variations" (nothing is being combined, so I'm not sure why they're called "Combos") that is nothing more than a flag on Product and a single table for variation info - exactly how packs work now.

 

This would eliminate about a dozen tables and god knows how much code. Then I could simply filter them out of the front-office product lists simply by looking at the flag. Better yet, I could put up a badge in the lists that says "multiple variations", which is very useful to know. When the user clicks into the details, it's easy enough to gather up the related products, just switch the lookup tables from combos back to products+variations. Finally, I could have the back end display the variations in the product list or filter them out simply by including that column in the display. This would make editing WAY easier.

 

And here's the big reason to do this. Right now combos do not appear anywhere except directly in the product page. That means they have no SEO information. Yet users might be looking for the name of the product, like "red iPod". So by making Variations which are simply Products, I get all my SEO back on top of all the other advantages!

 

I have an ever growing list of things I'd like to do with Product:

 

- we need "Variations" instead of "Combos", as above

 

- "Families" link together arbitrary products into a single page. It's similar to the concept for combos/variations, where we have multiple products on a single Product page in the front-office. The difference is that I can put *anything* into the Family, not just an arbitrary list of Attributes. The front-office page then moves the add-to-cart and related information into a table with a separate line for each product in the Family, so I can add "6 of those, 1 of those and 2 of those" without going to three different pages.

 

- why do we have Features *and* Attributes? There's no reason for this if you look at the underlying data. One is a list of values, the other *can be* a list. This is baffling. All you need is a flag in Features that is the "Attribute type" in Attributues and you have 100% functionality overlap.

 

- I'd like to have "Ghosts", which are Products that we don't sell but we put in our catalog in order to capture SEO. So if I don't sell iPhones, I can still put iPhone in my product list, but redirect it to a page that lists similar products, like the Galaxy S3. I can maintain that list of similar products either as a Family or through the existing Accessories concept.