Hi Folks,

Read through the manual and it seems like the workflow of prices is SKU Based.

If you have a product that has color options

Blue|Blue
Red|Red

1.) To change the price you have to manually
create
sku =red_product, price = 10.00
sku =blue_product, price = 20.00

2.) Or bulk create using commerce_bpc have price default to 0. Then manually change the price from the admin panel.
3.) Or bulk create then using a custom module do a hook_entity_presave to do your business logic there.
4.) Also I am thinking doing this through "rules" would be .. messy especially on many attributes per entity.

** Proposed way**
5.) I am wondering if the actual attribute color have a place to put in price changes?
Kinda like http://drupal.org/project/options_element with an option to include necessary price change value.
Then use commerce_bpc -- score!

[key] blue
[value] Blue
[price_change] +10

[key] blue
[value] Blue
[price_change] +20
-- what do you guys think about this idea?

Comments

chriscalip’s picture

Project: Commerce Core » Commerce Bulk Product Creation
Issue summary: View changes

better description.

chriscalip’s picture

Issue summary: View changes

better description, trying my best to convey message

rszrama’s picture

Component: Product » User interface
Category: bug » feature

I think it'd be a great idea. The challenge will be making it usable, especially when price changes are static up / down alterations of a base. ^_^

This would probably be better in the Commerce BPC queue, so I'll switch it there.

sven.lauer’s picture

Not sure this really belongs in the BPC queue, but this functionality would surely be especially useful with BPC, so we may as well leave it here.

Really, this should be its independent contrib module---and it would be fairly straight-forward to implement this: All it would take is adding an instance setting to commerce_price (when attached to products) and then implementing hook_field_attach_presave(). The only real question would be how to do the instance setting in a sane way. A not-quite-pretty way would be to simply have a second textarea where the user can enter 'value|price change' rows.

Also, there is the question of how useful simple static, product type level changes are generally---but it would be a start. Ideally, another option would be to enter something like '+10%' and have the base price adjusted by that. Static changes will also get really messy as soon as more than one currency is in play.

There is another issue, ultimately (and that is why it is probably good to have this in the BPC queue): For many use cases, the price delta should really be specifiable per product (set): One shirt may be +10$ in XXL, another +25$. For these cases, it would be REALLY nice to have price delta fields in the bulk creation form. HowEVER I don't see me implementing this soon (unless I happen to need it for a client). I would gladly review a patch, though ;)

sven.lauer’s picture

Version: 7.x-1.x-dev » 7.x-2.x-dev

Commerce bpc will use a "core like" release management, meaning that new features will go into the 2.x branch (but might be backported).

rodvolpe’s picture

Hi Guys!

I am quite new with commerce.
I really need this feature in the admin for a site I am building.
When Bulk Creating I have one Product with 5 diffrent sizes but each size has a different price:

SKU - size 1 = price 20
SKU - size 2 = price 40
SKU - size 3 = price 60
SKU - size 4 = price 80
SKU - size 5 = price 100

Any help would be much appreciated!

sven.lauer’s picture

BPC is not able to do this at present, I'm sorry. Given my limited resources, the following still holds:

HowEVER I don't see me implementing this soon (unless I happen to need it for a client). I would gladly review a patch, though ;)

rodvolpe’s picture

I will try my best.. if I manage to do it I will post it.. tks anyway!

michaellenahan’s picture

I have done this using Rules:

Create a Rule (admin/config/workflow/rules) called, say, "size-5 pricing"

Events
EVENT
After saving a new commerce product

Conditions
ELEMENTS
Data comparison
DATA TO COMPARE
Selected data: commerce-product:sku
OPERATOR
contains
DATA VALUE
--size-5 (this is the right-hand-side fragment of the SKU you want to give a price to).

Actions
Set a data value
Selected data: commerce-product:commerce-price:amount
Value = 10000 (note: key the amount in cents)

This works well, except keeping the prices in the rules interface is not user-friendly for my client.
I'm exploring ways to store the prices for each product-variation elsewhere so the client can change them more easily. Grateful for ideas.

sven.lauer’s picture

Assuming you use taxonomy fields for combination-creation, I wonder if you could have a price field (or price delta field) on the taxonomy terms, and write a rule that retrieves this value and applies it to the price field?

Dubs’s picture

A reasonable workaround I use now is to edit the view and include editable fields (http://drupal.org/project/editablefields). This works well for the prices and anything else that editable fields are compatible with.

ultimike’s picture

Is there Commerce BPC hook that can be leveraged to adjust the price as each product is generated?

Here's my situation - I have 1 product, with 5 different sets of attributes, each one can modify the price of the base item. Each attribute set has anywhere from 2-30 options. Doing the math, it works out to about 2,400 different combinations. Now, I don't mind having 2,400 products, but I'd rather if I didn't have to manually modify the price one-by-one.

I'm thinking that if there is a hook that I can utilize, then I can write some code to modify the prices as the 2,400 products are generated.

Thoughts?

Thanks,
-mike

ziobudda’s picture

@ultimike: any news about this hook ? Have you find it ?

M.

ultimike’s picture

@ziobudda - nope, decided to go with Commerce Customizable Product (https://drupal.org/project/commerce_custom_product), taxonomy, and pricing rules to do the job. In the end, I didn't have to create so many products - all the variations were handled at the line item entity.

-mike

ultimike’s picture

Issue summary: View changes

better description on 5th and proposed way.