Extra Field to display on product listing

[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.