Turn off Quantity

Not sure if this has been done before.

I have a cart with products that have no limit as far as quantities able to purchase. I would like to have it so that the quantity increments just once for each product/attribute combination regardless if there is more than one combination thats the same. So each product/attribute combo only will have a quantity of 1.

Thanks in advance.

What you need is to disable stock quantity functions.
In admin > Configuration > Stock,
set
Check stock level
and
Subtract stock
to false.
You may want to change other settings there, too.

Thanks for the reply.

Something like that.........so say if I bought a blue shirt small and then bought another blue shirt small, each item is placed as a separate item in the shopping cart instead of having the item appear once and the quantity as 2.

Ok, that's not going to happen without some custom coding. If you add two identical items to the cart, they will show as qty 2 of one item - which is exactly what you would be getting. Is there a reason you want them to show twice in the cart?

The reason for this is that each item has a custom attribute that can only be selected once.

item + global attribute + custom attribute

The item and custom attribute cannot be repeated in the same order.

I don't get it... If the item and custom attribute can't be repeated in the same order, how can you have it show twice? What do you mean by "cannot be repeated"? Are the two small blue shirts really identical, or is there something unique about each of them? If there is another attribute that is different between the two, they will show separately in the cart display.

The custom attribute is custom to each customer. In other words, I had to custom code zc to accommodate this feature so my custom attribute is not recognized by zc to be unique. This is part of my problem. If I could be pointed to the code in zc that states that either the attribute is unique or has been selected already, that would be a great help.

Thanks.

Alright...I'm reaching here.........

Could I have my custom attribute populate a dynamic dropdown at the product_info page and have zencart recognize it as being a zc attribute? (i.e. treat it as being unique in the cart.)

I know it seems odd, but quantity does not matter in my case. The quantity can run in the background and not effect the clients UE.

Thanks.

There may be a nomenclature issue here.
If you have an "attribute" that you have defined, ZC will treat it as just another attribute, which if it is different between two otherwise identical items, will make them display separately in the shopping cart.
If you have created a new field for the product type (outside of the attribute structure), that is not the sort of thing that ZC expects the customer to modify, and it will not distinguish between different choices without extra setup work.
A link to see what you have would make it easier to advise, and understand what you want.

Here's a visual to hopefully help out.....

So even though the product and attributes for these 3 items are the same, the applicant name is not. My clients would need to see this information for teh next step in my application.

Solution would be to either have each of the applicants names listed out or to have each item listed out in the shopping cart.

I thought he latter would be the easiest to accomplish. Now Im thinking to list out each applicants name from the database.

Thanks!

So each of the "small blue shirts" the client is buying goes to or relates to a different applicant?
If this is the case, it would seem reasonable to inject the applicant name or whatever identifier into the attribute structure. That would automatically make it work to display a product for each applicant.

I don't know how the client is supposed to indicate the applicant involved with each item... if they type in a name, that can be a standard text input attribute, which you can work on after processing to put the name in an "applicant" table in the db. (It will be in an "orders" table already.)
If they are supposed to select an applicant from an already populated db, there could be some sort of processing to put that into the option values and product attributes... can't say more on this as only you know how the base is set up.
What sort of scale is involved here? Dozens/hundreds/thousands of clients? Dozens/hundreds/thousands of applicants?

Glad the image helped.

Exactly, the applicant is what I want to be identified as being unique. As for you suggestion to associate it withe the existing attribute structure, I feel that is what Im doing already, but how does zc recognize that an attribute is unique. The code for this has eluded me.

The answer to your second question: the products will never exceed 260 but the number of applicants is potentially endless.

Thanks alot for the continued interest in my quest to reverse engineer this.

The next relevant information will be whether the client can type the applicant's name into one or more (first & last name?) text input boxes, or if the applicants are already in the db and need to be selected.

The first method means that all you need to do is copy the text attribute info from the order to the "applicants" table in the db. The shopping cart, invoice, etc. will show the individual products with the associated applicant name.

The second method will require some more sophisticated coding.
If you were "associating it with the existing attribute structure", it should be treated as unique already. Exactly what sort of coding do you have to gather the applicant info?

The customer has to select the applicant from their account prior to selecting product/attribute. The applicants id is selected and stored just as other attributes in the database.

If I could populate a dropdown attribute select at the time of entering the product_info page, that could be on alternative, but I have not yet seen how to dynamically populate a dropdown in zc.

Well, I'm going to keep trying.

Thanks.

I don't know the mechanics of making this happen either. Thinking about it, I would expect something like this:

Find the attribute files in /admin/ for comparison, and make versions that will work automatically on a trigger of new clients and applicants being added to the db.
Add an option name for each client, and add option values to it for each applicant associated with that client. The tricky part would be dynamically populating the product attributes, since each attribute for each product gets a unique id. I'm not sure it would be possible without mangling the attribute system. It might be possible to assign every client with their applicants as attributes to every product, and suppress retrieval/processing/display of all but the current user/client.

How many applicants would reasonably ever be associated with one client? I could imagine a "dummy" attribute set with numbered values, which would be associated with the applicants belonging to the current client. It might be possible to substitute text in the labels of the dummy attributes with the client's applicants.

Is it necessary for the client to enter the applicant's info before selecting the product? (Would an applicant need to be associated with a client outside of a product, or in two or more products?)

The applicant can be selected any time before checkout. Just thought this way would be a little more linear.

Just realized another problem with this. The system does not add the service fee to each item. Since the products price is a fee I pay to the provider of the product and the service fee is my profit, this is a show stopper for me...................seems that forcing the system to recognize that each product/attribute/applicant as unique, doesn't come off to me as being that difficult. Now I am looking at not being able to do this at all with zc............:censored:

How do you have the service fee set up to work? Can you include the service fee in the price of the product, or is that a marketing impossibility?

If it would work ergonomically for the client to input the applicant's name during product selection (first & last name text inputs), that would make everything work easily. You could take those text inputs and transfer them to the applicant table in the db, and each product would show separately in cart/checkout/invoice with the applicant name.

OK, just found your actual site and can see why you want the setup you proposed. It would have saved time to see that earlier. So there could be ultimately hundreds of thousands of clients and applicants, many being just one family, and hopefully repeating business when they travel again. And there is much more than the applicant's name that has to be entered.

It occurs to me that you will be getting a lot of exact duplicate names as you get more applicants in your db, so you will have to sort and retrieve by a more specific selector. For families, the applicant plus account/client should do, but for travel agents, they might have two customers with the same name.

Yeah, sorry should have been more clear from the beginning. Your first suggestion is no big deal, easy fix. Seems though even if I have the customer type in the name, and then select the same country same attribute, different applicant, it still just increments the quantity and the first applicants name is the only one visible.

Much closer to what I need and I appreciate the suggestions!

Even if the applicant has the same name they will not have the same id nor belong to the same customer(id).

I'll keep pushing zc buttons and see what I come up with. The suggestions have given me a little hope.