Attribute Cost

I have a requirement to record product cost in the orders_products table. I have the cost of products without attributes figured out, and cost of products where only one value of an attribute can be selected figured out. But now I have a new requirement where multiple values of an attribute can be selected, and can't quite figure out how and where to calculate the product cost.

A hypothetical example might be purchasing a computer with pre-installed software. The attribute (option name) is "Installed Software" and the attribute values (option values) are (1) MS Office, (2) Chrome Browser, (3) Adobe Reader, (4) Auto CAD, and (5) Photoshop. The customer can select one or more packages for the seller to install and ship the completed computer to the customer. The cost of each software package differs of course, so the total product cost would be the sum of the bare computer plus cost of all software packages installed.

So can someone please suggest an appropriate notifier to use with an observer to calculate the total product cost in this scenario? I'm currently using NOTIFY_ORDER_DURING_CREATE_ADDED_ATTRIBUTE_LINE_ITEM but I suspect there's a better notifier to use.

I have Stock by Attribute installed.

Thank you for any suggestions.

Just to be clear, in the previous post, I'm referring to the cost to the seller, not the price that the customer sees and pays.
Dave

I started to make a long list of notifiers them realized it would help more to understand the needs. For example what are you intending to store? It's obvious you want to see the cost of the product, but there are multiple aspects about cost determination/storage. Just the individual costs (base price, each attribute, one time costs, etc. ) or the overall cost of purchasing the product?

Where have you stored the sellers cost data and how is that broken up or tracked? (Costs x today to purchase but in a week it costs y, purchased z of them at this price, etc)

Where or when do you want to have your sellers cost available? Is it needed for "display"? Is the cost of one attribute dependent on another and if so is that dependency such that a "later" price is affected by an earlier one or the reverse?

I mean there's a lot of options and a lot of places to hook in, there's also some additional places that could use notifiers while strong through some of the processes. For example the Cart method doesn't specifically have a notifier after processing all of the attributes, but one is available going into Trac calculation and somewhat prior to leaving it. A number of those though are setup as override opportunities to divert from normal flow instead of just altering the associated content.

If this really must be built into ZC and the client is averse to using a more appropriate (ERP) solution, I would have thought the solution lies in expanding whatever you are using to manage the stock of attributes.

mc12345678, all good questions. I need to store the total unit cost of the product to the seller at the time of the customer order. That includes the cost of the base product plus the cost of each option selected plus the unit cost of shipping the base product and unit cost of options from the supplier to seller. Yes, those costs change with time and supplier. Cost changes are handled (rightly or wrongly) by computing an average cost of the product, i.e., current inventory times current unit price plus newly acquired inventory times new unit price divided by the sum of current inventory plus newly acquired inventory. This cost is stored manually in a new field in the products table for products without attributes, and in the products_attributes table for products with attributes. With one or two exceptions, the sellers products have only one attribute and up until recently, only one option value could be selected by the customer. Now, the customer can select more than one option value (but only qty one of each option value). There are no cost (or price) dependencies at the current time with choosing multiple option values for these products. In other words, the cost of a software package installed does depend on what other packages are installed in the hypothetical example given.

The products unit cost at the time of a customer's order is displayed on a custom sales report or extracted in a query of the database. It is used to calculate the sellers profit.

For the 1 or 2 exceptions mentioned above, there are cost dependencies. The seller has a tee shirt product with different styles and different sizes. Frankly, dealing with that product is a real pain. I've implemented special code in the sales report and queries that essentially hardcode the cost data. And a solution that accounts for multiple attributes along with one attribute and no attributes would certainly be welcomed.

Also, some of the products involved are tracked by SBA, others are not. So maybe multiple notifiers may need to be involved in a solution.

I hope I have answered your questions. A question for you...I don't know what you are referring to by "Trac calculation" in your post.

torvista,

Yeah, an ERP solution might be best for the organization, but I don't think they're ready for it yet. I understand someone is off looking at packages, but nothing has been reported back yet. I think they want to focus on membership and donation solutions for the time being and the store side of things will come later.

Quote:

---

Originally Posted by torvista

If this really must be built into ZC and the client is averse to using a more appropriate (ERP) solution, I would have thought the solution lies in expanding whatever you are using to manage the stock of attributes.

---

That was exactly my thought. Why not expand the table that includes variant stock to store variant cost?

I did this for a client using @lat9's Products Options Stock module, and it worked like a charm.

Quote:

---

In other words, the cost of a software package installed does depend on what other packages are installed in the hypothetical example given.

---

Ugh, should be In other words, the cost of a software package installed does not depend on what other packages are installed in the hypothetical example given.

Quote:

---

Originally Posted by swguy

That was exactly my thought. Why not expand the table that includes variant stock to store variant cost?

I did this for a client using @lat9's Products Options Stock module, and it worked like a charm.

---

Thanks! I'll look into that approach.

Quote:

---

Originally Posted by mc12345678

For example the Cart method doesn't specifically have a notifier after processing all of the attributes, but one is available going into Trac calculation and somewhat prior to leaving it. A number of those though are setup as override opportunities to divert from normal flow instead of just altering the associated content.

---

Quote:

---

Originally Posted by Dave224

A question for you...I don't know what you are referring to by "Trac calculation" in your post.

---

The area to which I was trying to refer in conflict with auto correct was the calculateTaxForProduct method. There are two notifiers in that method. As such use of the notifier(s) wild depend on the desired or intended result.

Note, if you find a suitable way to incorporate your needs into SBA, your contribution to that plugin would always be welcome.