Extra Field to display on product listing

[Nick1973]

This extra field is to display a price as two prices need to be applied on the product information page. One which is for display purposes only and a hidden field where the actual price found normally on a zen cart is applied. The reason for this is because the price that is displayed is for single items only and the price that is applied when adding to the cart is x6, x12, x24 as customers buy in bulk.

Before you say it, using unit prices was not sufficient for the task as it applied for example 6 into the quantity box when it should have been 1. e.g. 1 x 6, 1 x 12, 1 x 24. I already tried several combinations using unit prices but they didn't fit the task hence the need to have a separate field to display the single unit product price and when a user adds to the cart it adds 1 x 6, the x 6 is the price that is in the hidden field on the product info page not the displayed price.

This was a development of the custom fields mod by NUMINIX so I haven't exactly reinvented the wheel, more a case of rewriting to fit the task and the field was already in the sql file when the mod is applied, although I did need to add a further extra field for which I just duplicated it everywhere that is was required for display and text entry in the admin. The only problem with the Numinix mod is it does not appear to display a custom field on product listings, just product information pages.

I already looked through pages/PAGENAME/header_php.php and pages/PAGENAME/main_template_vars.php but could not see one for the product listing pages. However I think I might be onto something as I think what I need might be in pages/index/main_template_vars.php so I will report back.

I already spend alot of time developing and marketing anyway so no need to tell me that I should be doing that. As this is for someone else, this is just one of those tasks that needs to be developed for the job and I could not find a mod sufficient in this case.

I will report back on when/if I get a solution as I think what I will have developed will be useful for others too. If anyone else can add to this though I'd gladly appreciate it.

[bn17311]

hi did you try adding p.extra_field_2 to the listing sql in includes/index_filters/default_filter.php like below

$listing_sql = "select " . $select_column_list . " p.products_id, p.products_type, p.master_categories_id, p.manufacturers_id, p.products_price, p.extra_field_2, p.products_tax_class_id, pd.products_description, if(s.status = 1, s.specials_new_products_price, NULL) AS specials_new_products_price, IF(s.status = 1, s.specials_new_products_price, p.products_price) as final_price, p.products_sort_order, p.product_is_call, p.product_is_always_free_shipping, p.products_qty_box_status
       from " . TABLE_PRODUCTS . " p left join " . TABLE_SPECIALS . " s on p.products_id = s.products_id , " .
       TABLE_PRODUCTS_DESCRIPTION . " pd, " .
       TABLE_MANUFACTURERS . " m, " .
       TABLE_PRODUCTS_TO_CATEGORIES . " p2c
       where p.products_status = 1
         and p.manufacturers_id = m.manufacturers_id
         and m.manufacturers_id = '" . (int)$_GET['manufacturers_id'] . "'
         and p.products_id = p2c.products_id
         and pd.products_id = p2c.products_id
         and pd.language_id = '" . (int)$_SESSION['languages_id'] . "'
         and p2c.categories_id = '" . (int)$_GET['filter_id'] . "'" .
         $alpha_sort; 

there is a few instances of it to add to

then in includes/modules/product_listing.php add the following code where you want it to show,

$listing->fields['extra_field_2'] 

i added it right after name code

$listing->fields['products_name'] 

there were 2 instances

this will hopefully get you going on in categories listing

then in includes/modules/pages/products_all/header_php.php add the field to the $products_all_query_raw and then add $products_all->fields['extra_field_2'] to tpl_modules_products_all_listing.php

then do the same for each page you want it in,
bn

[mc12345678]

This extra field is to display a price as two prices need to be applied on the product information page. One which is for display purposes only and a hidden field where the actual price found normally on a zen cart is applied. The reason for this is because the price that is displayed is for single items only and the price that is applied when adding to the cart is x6, x12, x24 as customers buy in bulk.

Before you say it, using unit prices was not sufficient for the task as it applied for example 6 into the quantity box when it should have been 1. e.g. 1 x 6, 1 x 12, 1 x 24. I already tried several combinations using unit prices but they didn't fit the task hence the need to have a separate field to display the single unit product price and when a user adds to the cart it adds 1 x 6, the x 6 is the price that is in the hidden field on the product info page not the displayed price.

This was a development of the custom fields mod by NUMINIX so I haven't exactly reinvented the wheel, more a case of rewriting to fit the task and the field was already in the sql file when the mod is applied, although I did need to add a further extra field for which I just duplicated it everywhere that is was required for display and text entry in the admin. The only problem with the Numinix mod is it does not appear to display a custom field on product listings, just product information pages.

I already looked through pages/PAGENAME/header_php.php and pages/PAGENAME/main_template_vars.php but could not see one for the product listing pages. However I think I might be onto something as I think what I need might be in pages/index/main_template_vars.php so I will report back.

I already spend alot of time developing and marketing anyway so no need to tell me that I should be doing that. As this is for someone else, this is just one of those tasks that needs to be developed for the job and I could not find a mod sufficient in this case.

I will report back on when/if I get a solution as I think what I will have developed will be useful for others too. If anyone else can add to this though I'd gladly appreciate it.

Why not use attributes? Owner enters the individual price on the product page, a reasonable combination of total quantities is entered, the value of whichis multiplied by the unit cost, the first option value in the list is a display only default value asking to select one of the values below. Seeing that inventory of the individual units is not what is desired, seems like that method would be fine, although also could apply stock by attributes to help with that.

Not sure I follow with the discussion of not using the units option. Assuming that the product(s) in question are uniquely identifiable say to a category or with a particular trait, seems would be able to display the individual price by taking the price and dividing it by the units number with applicable rounding. Then could add the quantity to the cart of how many 6 packs, were ordered.

Also, not sure if it would help with this situation, but seems like something similar, take a look at a "plugin" that has checkbox textbox icon product checkout in the title. I think it was developed with some of what you're looking for in mind or at least possibly applicable. Okay, maybe a stretch, but thought it might be worth looking into for your application.

[Nick1973]

Using attributes would be too complicated for the user of the cart so not an option. They need to be able to access everything from the product information entry page in the admin. I see what you are saying but it wouldn't work in this instance as they are looking to enter products speedily and attributes are a longer process. I'm not sure you are getting the requirements, however to give you an idea I am developing a wholesaler cart which I suspect will become very busy both on front end and backend. And in both situations either admin or from frontend the users will want to be able to add to the cart quickly and efficiently. I had obviously thought of the attributes method but like I say, too complex and longwinded.

Unit Price - I'm not even going to go into detail with that one but again I had tried many different combinations and options and it didn't work in this instance hence the need to have this extra price field.

bn17311 seems to have the answer I need anyway so thank you very much to bn17311.

[mc12345678]

Using attributes would be too complicated for the user of the cart so not an option. They need to be able to access everything from the product information entry page in the admin. I see what you are saying but it wouldn't work in this instance as they are looking to enter products speedily and attributes are a longer process. I'm not sure you are getting the requirements, however to give you an idea I am developing a wholesaler cart which I suspect will become very busy both on front end and backend. And in both situations either admin or from frontend the users will want to be able to add to the cart quickly and efficiently. I had obviously thought of the attributes method but like I say, too complex and longwinded.

Unit Price - I'm not even going to go into detail with that one but again I had tried many different combinations and options and it didn't work in this instance hence the need to have this extra price field.

bn17311 seems to have the answer I need anyway so thank you very much to bn17311.

Wholeheartidly agree that I don't "get the requirements", assuming that referring to I don't. Understand what it is you're really trying to do/observe. About the most of it that I got was that at least one price would be entered manually, though it seems there may be two involved which if so could lead to large discrepancies. As far as quick entry there are things such as easy populate and apsona that would allow a one stop update of everything in the cart. (That does not mean that everything that these programs can do is accomplished with a single upload, but that many things can be done with the program and many aspects of the database can be updated.) As long as this additional field is within the products table, then those programs should be able to manipulate them if desired in the future to use one of those programs.

Yes bn17311 propperly identified the areas to update to continue down the path chosen. There have been several questions over the last two days on areas like this: all products, specials,new products etc, guess I need to go back and freshen up my knowledge of how they are put together/function to provide better/quicker assistance.

[Nick1973]

This is what is happening on the cart I am developing.

Price field in the admin would be the total number of products. So 6 x 50p = £3.00 - £3.00 being the price entered in the standard price field in the admin.

Each product has to display a single product price, so the price displayed would be 50p per product.

The quantity box must have a value of 1 and at the side of it in text 'x 6' so the frontend user knows that they are adding a pack of products at 50p each.

Now for the price display, it would normally display the full price which would be £3.00, however we don't want this on the product page so this is where the extra field comes in where backend users can enter a single unit price. So the solution is an extra field which is independent and does not calculate when the product is added to the cart. Basically the price is for display purposes only.

Now in a a hidden field the price of 6 x 50p = £3.00 is on the product description page. So when the user adds to the cart they add 1 x 6. This adds to the cart at £3.00.

I have already done the development on the products description page and developed this to work in the cart.##The bit that was missing was displaying this extra 'single unit price' field on the products listing pages. Users will not be buying from product listing pages, they will be forced to view the product before buying so this in turn forces them to add the product at the correct amounts.

Hope thats a bit clearer. You will see it when the site goes live and understand it more as we're pretty close on this one anyway.

[Nick1973]

bn17311 - I've sent you a private message. Please can you send over the files you edited?

Details in the PM.

[mc12345678]

This is what is happening on the cart I am developing.

Price field in the admin would be the total number of products. So 6 x 50p = £3.00 - £3.00 being the price entered in the standard price field in the admin.

Each product has to display a single product price, so the price displayed would be 50p per product.

The quantity box must have a value of 1 and at the side of it in text 'x 6' so the frontend user knows that they are adding a pack of products at 50p each.

Now for the price display, it would normally display the full price which would be £3.00, however we don't want this on the product page so this is where the extra field comes in where backend users can enter a single unit price. So the solution is an extra field which is independent and does not calculate when the product is added to the cart. Basically the price is for display purposes only.

Now in a a hidden field the price of 6 x 50p = £3.00 is on the product description page. So when the user adds to the cart they add 1 x 6. This adds to the cart at £3.00.

I have already done the development on the products description page and developed this to work in the cart.##The bit that was missing was displaying this extra 'single unit price' field on the products listing pages. Users will not be buying from product listing pages, they will be forced to view the product before buying so this in turn forces them to add the product at the correct amounts.

Hope thats a bit clearer. You will see it when the site goes live and understand it more as we're pretty close on this one anyway.

That is much clearer. I realize that you are close to completion on this effort, but still offer my thought(s) on design/implementation/continued use. With the method being applied, it sounds like the store owner will have to enter a few things for each product that could be made a little simpler.
1) Total cost of the bulk item.
2) Per unit cost as independently calculated possibly by calculator.
3) And possibly the quantity of items in the bulk item.

(I wasn't sure about the third attribute as to whether it is calculated or even used.)

Regardless, with the goal of the per item price being shown for a "container" of multiple items, why not let ZC calculate the per item value from the total price and the number of items instead of the store owner having to calculate the per item price and make a change based on a change in total price? This could lead to a discrepancy being displayed.

Okay, so possibly wondering what in the world is this guy talking about:
Product has a total price of 4 (whatever currency)
The product contains 4 items.
The product also comes in different quantities and therefore it seems that a different product entry is made for each of those where each product has it's own description, model number, potentially a upc code, etc.
So the store owner types in the per unit price of 1.

Now as time marches on, the product stays the same, but has become slightly more expensive and so the price increases to 5 for the four items. Under the current plan, the store owner will have to update two fields (at least). The total price and the per unit price. Here the example was chosen so that the math was relatively easy, but one could say well, better pull out the calculator and figure out what the per unit price is, then transcribe that calculated value to the store. (Sure most computers have a calculator easily available and that data can be copied and pasted, etc..) But a single update requires updating two fields. And though I believe this updated unit price is really the only thing added to the product page, there was a lot of discussion about x6, x12, x24, so if the per unit price was not updated but the total price was, then the amount displayed would be less than expected, or worse, if only the per unit price is updated and not the total price, then at checkout (assuming that a customer doesn't ditch because of the discrepancy) the amount collected would be less than expected for an increase in total price.

However, if the extra added field were to be just the quantity of items in the bulk item, the per unit price could be calculated from the total price. Then when that particular item's price changed, only the total price would need to be modified and the per unit price would follow. One data entry to modify one change.

That is unless there is yet another constraint not described and haven't talked about future potential sales/discounts/promotions and how that information would be displayed.

Again, just a thought to keep things simple for running the store and try to minimize errors.