generate product model, is it possible

I have found a way to generate and assign product IDs (model numbers) within excel when an option is chosen from the dependent menus I have, so I assume if it can be done in excel it should be easier in a database such as sql but I know nothing of sql.

So if I can find a way to get this done in sql, how would I get it to add the unique product Ids into zencart.

any ideas ??

You might be better off using this plugin
https://www.zen-cart.com/downloads.php?do=file&id=2069

Not sure how that would work for this Kobra, if sql is already generating the IDs on an individual basis as a selection is made, does that mean I'd need to find another kind of script to generate the list within sql, then export it to a csv file then import it with easypopulate

but as usual I'm probably missing something

If you already have a method to do this in excel then getting into the database using ep4 should be easy

If I may try to explain a little somethings as this looks confusing...

When a new row of data is added to the products table (one of many tables that define the detail of a product and what to show on ZC), if that row does not include a products_id or depending on the mysql server if that value is zero (0) or null, then mysql assigns the next value for that products_id as tracked by the autonumber record for products_id. If the row has an assigned products_id then the mysql server will try to perform the requested operation (insert, update, delete, etc) based on that products_id.

EP4 (EasyPopulate V4) as recommended by kobra, as well as many other versions of EasyPopulate, was written to use a primary key (similar to a unique products_id) that was independent of the ZC primary key because outside vendors do not supply a products_id that is the same for everyone. At the time of writing, the products_model was chosen as this primary key. Yes, there are some issues with using a vendor's model# only so guidance was provided to make this model# a unique number/letter combination in comparison to all such product (add perhaps a vendor identifier, or some other related information that would make the referenced product unique).

So with such a unique model#, EP4 could take new data from a csv file and populate ZC. This population would generate a new products_id for a model# not in the database, or update the information for a product that had the same model#. (Further why the unique value is/was important.)

In the last year or so, a modification was made to the code to allow population/modification by use of the products_id. Now it is possible through changing a setting in the configuration options to directly access product by their products_id, which includes generating a new one if the import file leaves the products_id as blank.

So, depending on your overall need and planned usage, you could populate ZC with new product by use of the new products_id control method (there are two options, only populate/update product that have an assigned products_id, or populate/update product that have an assigned id (creating the new product in the database if the id is not present and updating product that have a matching id) and also to auto-assign the next products_id for a product that doesn't have a products_id in the file.

So the other "thought" about how EP4 works is that it offers a two way street. Can upload product/info, but can also export that product/info which appears to be where the hangup is/was. In other words, it can be used to push new/updated data, and pull existing data. After the pull, changes can be made and then pushed again or, if the source of the change(s) is external, then the data can be always pushed and as long as the data "key" matches with the appropriate existing record, that record (as well as any that have the matching key) is updated. If the key being pushed is unique and not present in the database then a new product is created.

Does this clarify the situation and operation a little?

What is it that this other "software" is expected to do?

mc12345678:

If I may try to explain a little somethings as this looks confusing...

When a new row of data is added to the products table (one of many tables that define the detail of a product and what to show on ZC), if that row does not include a products_id or depending on the mysql server if that value is zero (0) or null, then mysql assigns the next value for that products_id as tracked by the autonumber record for products_id. If the row has an assigned products_id then the mysql server will try to perform the requested operation (insert, update, delete, etc) based on that products_id.

Are we talking about the same product id ??

I'm referring to a product id//model number, like a catalogue number, eg my product id would be formatted like this, 3AqCa0125, unrelated to any product id that is created when adding an item to the database eg pID=241

This is called the model number in Zen Cart. People will get confused if you call it the product ID, since there's a separate field with that name.

Thread title has been changed.

So the above answer about using EP4 still applies even though still talking about model # only... that is why such depth was provided in the statement as there was a mix of content/discussion originally. In principle still talking about "generating" the model # in a spreadsheet and then uploading it. If wanting to do this via mysql, well, need to know what the "formula" is to get the model# and then a suggestion of the sql query to modify the model# to match can be provided.

Currently the spreadsheet reacts to what options are chosen on a dynamic basis, they are specific to the option chosen, it's not a list that is generated. There are over 18500 product options within this one main category, sad fact is I actually know every product number of every stock item off by heart but getting software to come up with the matching results has been a pain.

Haggis, do your products have attributes? Because if so, this gets a bit tricky.
If you have two attributes, each of which has two choices, you have four potential combinations.
But the product only has a single model number.

Does this make sense?

swguy:

Haggis, do your products have attributes? Because if so, this gets a bit tricky.
If you have two attributes, each of which has two choices, you have four potential combinations.
But the product only has a single model number.

Does this make sense?

It may, but it is also possible to apply/store a customid to each such variant, if in fact this is what is going on. Otherwise it appears that even with such "attributes" that perhaps the product are being "listed" one by one instead of being combined into attribute related product... (Yes I'm making guesses.)

Haggis:

Currently the spreadsheet reacts to what options are chosen on a dynamic basis, they are specific to the option chosen, it's not a list that is generated. There are over 18500 product options within this one main category, sad fact is I actually know every product number of every stock item off by heart but getting software to come up with the matching results has been a pain.

If there is a pattern, there is a program...

mc12345678:

It may, but it is also possible to apply/store a customid to each such variant

Absolutely - but I want to be sure this is the situation before moving forward.

Currently the spreadsheet reacts to what options are chosen on a dynamic basis
Can you share this spreadsheet so that we can see what it is you are attempting first hand?

swguy:

Haggis, do your products have attributes? Because if so, this gets a bit tricky.
If you have two attributes, each of which has two choices, you have four potential combinations.
But the product only has a single model number.

Does this make sense?

The only attribute I'll be using is price based, I tried all the possible variations in attributes, to work out the most efficient control process.

kobra:

Can you share this spreadsheet so that we can see what it is you are attempting first hand?

I can't Kobra, there is too much information within it that could be used by competitors. I do understand why you ask though, it would make it easier to see what I'm trying to achieve

Haggis:

The only attribute I'll be using is price based, I tried all the possible variations in attributes, to work out the most efficient control process.

What do you mean by this? Every attribute that is entered as an attribute through the attributes controller can be price based... Are you indicating that someone would select a price from a dropdown, picklist or otherwise?

Haggis:

I can't Kobra, there is too much information within it that could be used by competitors. I do understand why you ask though, it would make it easier to see what I'm trying to achieve

Can it be somewhat cleansed to provide at least an example of the process?

No need. He's using attributes, so we know enough to direct him.

@Haggis, the products_model field is a single-valued field per model. What you'll need to do is create a new field in your database (suggest using the orders_products table) and populate your computed "model number" based on attribute settings when an order is placed (or perhaps nightly as a cron job). You'll have to write the logic that maps the product and its attributes to one of your model numbers.