<p>I can't see this being a problem. All variants can have their own pricing. You can also use relations to mix and match different things if you'd like.</p>

<p>There is a <a href="https://imagescience.com.au/services/fine-art-printing/order-fine-art-printing" rel="nofollow noreferrer">fine art printing section</a> on the Image Science web site that may be an example of what you are thinking. There is a full write up of what it took to create the web site here: <a href="https://imagescience.com.au/blog/the-epic-journey-to-the-new-image-science-website" rel="nofollow noreferrer">The Epic Journey to the New Image Science Website</a>.</p>

CC BY-SA 3.0
2017-04-24T14:49:13.777Z
2017-04-24T14:49:13.777Z
Wonko
<p>As Wonko said above, our <a href="https://imagescience.com.au/services/fine-art-printing/order-fine-art-printing" rel="nofollow noreferrer">fine art printing</a> section (actually all our service sections) - are examples of the sort of thing you can do.  The article mentioned is more of a Monkey Magic like epic quest to peace and redemption that an How-To though ;) !</p>

<p>It seems quite complicated but usually if you break it down you will find a lot of the data in forms like that is endlessly repeated stuff - so storing that in channels and bringing it in through relations is Craft bread and butter stuff really.  This makes building out your variants much quicker and less error prone as you're keeping the data DRY.</p>

<p>In short, this is how it is done:</p>

<ul>
<li>We created a channel full of the various repeated options</li>
<li>We relate these to variants using entries fields</li>
<li>In some cases we use multiple entries fields, this will depend on how the services are structured of course</li>
<li>Combined, this ends up creating a unique variant that is one of the available chose options</li>
<li>Each variant also has it's own field for things like 'available for sale' 'visibility' 'note' 'show discount' 'standard price' 'rrp' etc.</li>
</ul>

<p>Then, from those variants, we build the form.  We do this by grabbing all the appropriate variant data into an array, then json encode that, and that is then grabbed by a React form builder we wrote, which unpacks that data and builds the actual form.</p>

<p>Each line on the form represents the adding of one lineItem, so each line is actually added to the cart using <a href="https://github.com/engram-design/MultiAdd" rel="nofollow noreferrer">MultiAdd</a> - all that stuff boils back down to a chosen particular variant id and qty in the end!</p>

<p>Of course each one of these is really a unique thing, so will need a unique approach, but that's one way of doing a more complex form like that.  It's certainly possible, and easier than it looks once you get going. </p>

<p>(An alternate approach could be to use <a href="https://github.com/engram-design/MultiAdd" rel="nofollow noreferrer">MultiAdd</a> to just build a form where all the little addons are added as extra costs to the main product, but that probably has its limits for more complex scenarios like the example you link to).</p>

CC BY-SA 3.0
2017-04-24T23:35:31.850Z
2017-04-24T23:35:31.850Z
Jeremy Daalder
<p>What are the options for creating advanced product options with pricing.
I see there are way to create variants ok - but can this be linked to advanced pricing, e.g. for printing products.
the abaility to select different sizes, material, finish etc all which affect the price and then the quantity which also affects the price.</p>

<p>Similar options which you can see here - <a href="https://www.gogetprint.com/business-cards" rel="nofollow noreferrer">https://www.gogetprint.com/business-cards</a>.</p>

<plugin-craftcommerce><ecommerce><products>
Craft Commerce - Advanced Product Options & Pricing
# Craft Commerce - Advanced Product Options & Pricing

(Asked by: username_0 on 2017-04-24)

What are the options for creating advanced product options with pricing.
I see there are way to create variants ok - but can this be linked to advanced pricing, e.g. for printing products.
the abaility to select different sizes, material, finish etc all which affect the price and then the quantity which also affects the price.

Similar options which you can see here - <https://www.gogetprint.com/business-cards>.

**Tags:** plugin-craftcommerce, ecommerce, products

---

## 2 answers

### Answer by username_1 on 2017-04-24. Score: 1

I can't see this being a problem. All variants can have their own pricing. You can also use relations to mix and match different things if you'd like.

There is a [fine art printing section](https://imagescience.com.au/services/fine-art-printing/order-fine-art-printing) on the Image Science web site that may be an example of what you are thinking. There is a full write up of what it took to create the web site here: [The Epic Journey to the New Image Science Website](https://imagescience.com.au/blog/the-epic-journey-to-the-new-image-science-website).


---

### Answer by username_2 on 2017-04-24. Score: 1

As Wonko said above, our [fine art printing](https://imagescience.com.au/services/fine-art-printing/order-fine-art-printing) section (actually all our service sections) - are examples of the sort of thing you can do. The article mentioned is more of a Monkey Magic like epic quest to peace and redemption that an How-To though ;) !

It seems quite complicated but usually if you break it down you will find a lot of the data in forms like that is endlessly repeated stuff - so storing that in channels and bringing it in through relations is Craft bread and butter stuff really. This makes building out your variants much quicker and less error prone as you're keeping the data DRY.

In short, this is how it is done:

* We created a channel full of the various repeated options
* We relate these to variants using entries fields
* In some cases we use multiple entries fields, this will depend on how the services are structured of course
* Combined, this ends up creating a unique variant that is one of the available chose options
* Each variant also has it's own field for things like 'available for sale' 'visibility' 'note' 'show discount' 'standard price' 'rrp' etc.

Then, from those variants, we build the form. We do this by grabbing all the appropriate variant data into an array, then json encode that, and that is then grabbed by a React form builder we wrote, which unpacks that data and builds the actual form.

Each line on the form represents the adding of one lineItem, so each line is actually added to the cart using [MultiAdd](https://github.com/engram-design/MultiAdd) - all that stuff boils back down to a chosen particular variant id and qty in the end!

Of course each one of these is really a unique thing, so will need a unique approach, but that's one way of doing a more complex form like that. It's certainly possible, and easier than it looks once you get going.

(An alternate approach could be to use [MultiAdd](https://github.com/engram-design/MultiAdd) to just build a form where all the little addons are added as extra costs to the main product, but that probably has its limits for more complex scenarios like the example you link to).


---

