EasyPopulate 4.0 Support Thread

[propster]

So Propster, as written, no it will not import to Stock by attributes.

It would require a little more work. The Stock By Attributes table does (the version I'm using) include a reference back to the product id, which is also in the products table. Couple that information with the products_model info and you have references to the data that you need in the stock by attributes table. Thing is that table works a lot like (well basically is) the attributes table does, in that there are multiple entries tied to a single object. One of the differences/difficulties is that the data stored for a single stocked item (all the associated attributes) is not the same for all versions of Stock By Atttributes if I am correct. So any "manual" or instructions related to that portion may not be consistent across all versions. Being possible, I would say yes. Quick and easy, I would say relatively no.

But a start would be to look through some of the other import/export functions that work similarily and identify what information is needed to work both directions (import/export). And then carry on. It does seem that the code is robust with the various types of export reports, so this would just be one more report type.

Oh yes, the total # of items would be affected by EP 4 or others, but stock by attributes has it's own quantities and depending again on the installed version, the total may get reset or other things may change depending on how the SBA works, but this mod does not currently interface with the SBA table.

Wow thanks for the speedy response. So basically stock with attributes creates a new table in the database. what I am looking for is a method of linking the entries in this table with the product discription so that i can update the quantities from the inventory supplied. I don't mind creating a lookup table in excell to achieve this. I am just looking for a way to update quantities without having to go through the admin and enter the information manually

[mc12345678]

Wow thanks for the speedy response. So basically stock with attributes creates a new table in the database. what I am looking for is a method of linking the entries in this table with the product discription so that i can update the quantities from the inventory supplied. I don't mind creating a lookup table in excell to achieve this. I am just looking for a way to update quantities without having to go through the admin and enter the information manually

Perhaps Chadster can help with the "format" or setup needed within the program, but looking at the Stock by Attributes table in my database (Table Prefix)products_with_attributes_stock, I have 5 columns:
Stock_id (This is used specifically to identify a unique item's stock),
products_id (Which ties back to the (Table Prefix)products table),
stock_attributes (Which identifies which one or more attributes are associated with the stock_id),
quantity (The total number of items that match the stock_attributes for this product_id and stock_id), and
sort (supposedly to be used to sort the particular stock_id when viewing the products_id, though I don't know if or when that is enforced).

So, perhaps the easiest way to implement this is to only be able to deal with existing items that have a stock_id and not to have to add a new one attribute to an item.

In my list, I have a number for a products_id, and one or more numbers in the stock_attributes, these numbers correspond back to the product itself (which to use this mod requires a model number) and a designated attribute (red, black, whatever you have chosen) that is listed in the (Table Prefix)products_attributes table. So, there are ties back to each of those attributes. By exporting the (table prefix)products_with_attributes_stock table substituting the applicable product name (or model number as desired/needed) and the applicable attribute, the user (you) can intelligently understand what product is being referenced. Include in that output the stock_id and the quantity as a minimum, then when importing the data, (going back to probably using the model number) with the stock_id in the downloaded data, the upload is quite easy because there is only one item in the table that has that stock_id; however, it may also be possible (less likely for a user to make an error) to use the model number and the associated attributes to find in the table the one row that has that product_id and only that one attribute combination (it is possible though not desired to have a product_id that has less attributes identified than those that would be sold, but I think that comes through attempting to incorrectly modify the number of attributes while adjusting quantities at the same time, ie. user error. :) )

That's the basic flow/thought process that I see, and although I have just yesterday tried to update a single item using the Full-EP file format, I did look through a bit of the main controller for EP 4 to see what I might need to do to ensure it worked. I would think that Chadster could identify the areas that would need to be worked in to add the above functionality.

[mc12345678]

Perhaps Chadster can help with the "format" or setup needed within the program, but looking at the Stock by Attributes table in my database (Table Prefix)products_with_attributes_stock, I have 5 columns:
Stock_id (This is used specifically to identify a unique item's stock),
products_id (Which ties back to the (Table Prefix)products table),
stock_attributes (Which identifies which one or more attributes are associated with the stock_id),
quantity (The total number of items that match the stock_attributes for this product_id and stock_id), and
sort (supposedly to be used to sort the particular stock_id when viewing the products_id, though I don't know if or when that is enforced).

So, perhaps the easiest way to implement this is to only be able to deal with existing items that have a stock_id and not to have to add a new one attribute to an item.

In my list, I have a number for a products_id, and one or more numbers in the stock_attributes, these numbers correspond back to the product itself (which to use this mod requires a model number) and a designated attribute (red, black, whatever you have chosen) that is listed in the (Table Prefix)products_attributes table. So, there are ties back to each of those attributes. By exporting the (table prefix)products_with_attributes_stock table substituting the applicable product name (or model number as desired/needed) and the applicable attribute, the user (you) can intelligently understand what product is being referenced. Include in that output the stock_id and the quantity as a minimum, then when importing the data, (going back to probably using the model number) with the stock_id in the downloaded data, the upload is quite easy because there is only one item in the table that has that stock_id; however, it may also be possible (less likely for a user to make an error) to use the model number and the associated attributes to find in the table the one row that has that product_id and only that one attribute combination (it is possible though not desired to have a product_id that has less attributes identified than those that would be sold, but I think that comes through attempting to incorrectly modify the number of attributes while adjusting quantities at the same time, ie. user error. :) )

That's the basic flow/thought process that I see, and although I have just yesterday tried to update a single item using the Full-EP file format, I did look through a bit of the main controller for EP 4 to see what I might need to do to ensure it worked. I would think that Chadster could identify the areas that would need to be worked in to add the above functionality.

Also take a look at a post I put up earlier on a different thread. It takes you to one of the other threads about one/two versions of SBA that are recognized out there. http://www.zen-cart.com/showthread.p...46#post1208146

I implemented the method I described and was able to create SQL that I could use/copy into the admin panel and update the table(s) with the desired information. It is dirty sort of like what you were referring to (using a reference table or something) and is somewhat the foundation to EP, but it also does not afford any type of real checks so would want to implement cautiously. (That means BACKUP, BACKUP, BACKUP and test/check after taking action.)

[chadderuski]

Hey guys,

There MAY be some small hope to do this. But, believe me, the attribute importing code is quite complex.

But, look at the DETAILED attribute export. This is a "special" file as it is one-to-one. When you export this file and look at the first columns, and examine the import code, you see that this is a very basic key lookup and replace loop.

That is why I made the creation of the values different than the updating.

I would be possible to modify the DETAILED attribute export code to also incorporate the SBA tables in a similar manner, and then do the same for the Import code.

Unfortunately, I don't have time right now. Day job + 3 demanding clients and their projects have me inundated.... and I'm trying to get EP4's update to github and the zencart team.

-chadd

[mc12345678]

Hey guys,

There MAY be some small hope to do this. But, believe me, the attribute importing code is quite complex.

But, look at the DETAILED attribute export. This is a "special" file as it is one-to-one. When you export this file and look at the first columns, and examine the import code, you see that this is a very basic key lookup and replace loop.

That is why I made the creation of the values different than the updating.

I would be possible to modify the DETAILED attribute export code to also incorporate the SBA tables in a similar manner, and then do the same for the Import code.

Unfortunately, I don't have time right now. Day job + 3 demanding clients and their projects have me inundated.... and I'm trying to get EP4's update to github and the zencart team.

-chadd

Fully understood about having (or not having) the time. Part of the reason to try to document the process that might be needed and talk about what we have to work with. For me, the above direction may be enough to develop the code (same here time permitting), but just because I get my version to work doesn't mean that it would work for other versions of SBA, which to be honest I'm not 100% sure which version I installed. (2 years ago and I didn't take good notes like I should have about what specifically I installed and did to make it work, but it does or I have to make some manual tweaks once in a while.)

That said, thanks for the insight into where to look "next". Probably may end up as a mix of a couple of the routines, but would seem that in general a one-to-one would at least get the specific table updated. Would still need to pull from other tables to provide user friendly info, but seems even each of those is a one-to-one relationship.