Merchandise products in sales productlists

[JobDoesburg]

Is your feature request related to a problem? Please describe.

With the new sales app, it would be nice to have the possibility (for the board) to also do merchandise sales via this system.

Describe the solution you'd like

Make a sales.ProductList of merchandise.Items

Motivation

Merchandise products are also products.

Additional context

• Perhaps, we want to make MerchandiseItems actually extend Products (so the sales app doesn't need to change too much).
• We should think about how to go with different sizes. For example, maybe we want to keep what we currently have as MerchandiseProducts and then have multiple MerchandiseVariants for different sizes, that are the actual products. This way, we can display a single merchandise product but actually have multiple versions for it.
• We should think about how this would work with product lists and prices.

[se-bastiaan]

Why can't this just be a regular product list? Do we really need to keep track of the size?

[JobDoesburg]

Why can't this just be a regular product list?

It feels weird to have this data in the website twice, both in a product list and in the merchandise app. I think we can couple this.

Do we really need to keep track of the size?

Yes, for the bookkeeping.

[se-bastiaan]

I thought that the sales app was just for the payments, not for the bookkeeping. What I think you are suggesting is building an inventory system.

Look, I get the idea. But coupling the simplest app that we have just to make it possible to do something without the changes makes me feel uncomfortable. I know I always take the conservative "we don't really need this" stance. But this could be solved by creating a product list where all the sizes are a different product, which they essentially are. Or by adding the possibility to add varieties to a product. And not couple it at all.

That still leaves me wondering if the sales app really needs to know the size, because the price does not change based on that value. The idea of the sales app was to make it possible for Thalia Pay to be used at borrels. Put it in an easy to use formfactor. This goes quite a bit further, we could just as well use an existing webshop system and integrate thalia pay as payment method.

[JobDoesburg]

What I think you are suggesting is building an inventory system.

No that's not my point (yet - I'll wait for you to leave the Technicie before I'm building that, for my own safety).

But this could be solved by creating a product list where all the sizes are a different product, which they essentially are. Or by adding the possibility to add varieties to a product. And no couple it at all.

If that's what we're building, then the only coupling we would introduce in the merchandise app is a single ForeignKey. For me it just feels the same as Events and photo Albums.

That still leaves me wondering if the sales app really needs to know the size, because the price does not change based on that value.

If we're not storing that information, then there's no point in using this whole app at all, as it would require the board to keep a separate spreadsheet with this information

[se-bastiaan]

What I think you are suggesting is building an inventory system.

No that's not my point (yet - I'll wait for you to leave the Technicie before I'm building that, for my own safety).

Oh I am not saying I am against that idea. Don't assume that. Since we have Thalia Pay now concrexit is already more important than it was before. And adding something like that will make it larger, but it is not something that is complex. But knowing you it will be still be so complex in the end that you probably have to start over because building on top of what we have now is useless. And Oscar exists already btw. Not the subject of the issue anyways.

(If you re-use the products from sales though, and use signals for each product sale in a order to decrease the amount in stock)

But this could be solved by creating a product list where all the sizes are a different product, which they essentially are. Or by adding the possibility to add varieties to a product. And no couple it at all.

If that's what we're building, then the only coupling we would introduce in the merchandise app is a single ForeignKey. For me it just feels the same as Events and photo Albums.

But can you explain to me why the coupling would be worth the complexity? It's not so simple. How would it work with the ForeignKey exactly? What else would you need to make it possible. Think about what the least complex solution is and balance it with data duplication. Do you need the ForeignKey to accomplish your goal?

You are comparing it to something that I also think is not something we should have done either. But because I am the only one thinking that complexity and coupling is bad I can hardly stop you all.

That still leaves me wondering if the sales app really needs to know the size, because the price does not change based on that value.

If we're not storing that information, then there's no point in using this whole app at all, as it would require the board to keep a separate spreadsheet with this information

I thought the point would be to be able to use Thalia Pay as payment method? And since this is not inventory they still

[JobDoesburg]

Will be implemented in #3464